Date   

[PATCH 4.19.y-cip 01/26] PCI: endpoint: Add new pci_epc_ops to get EPC features

Lad Prabhakar
 

From: Kishon Vijay Abraham I <kishon@...>

commit 41cb8d189c9d4964df52a6f497cab7b301ae831b upstream.

Add a new pci_epc_ops ->get_features() to get the features
supported by the EPC. Since EPC can provide different features to
different functions, the ->get_features() ops takes _func_no_ as
an argument.

Tested-by: Gustavo Pimentel <gustavo.pimentel@...>
Signed-off-by: Kishon Vijay Abraham I <kishon@...>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@...>
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@...>
---
drivers/pci/endpoint/pci-epc-core.c | 30 +++++++++++++++++++++++++++++
include/linux/pci-epc.h | 22 +++++++++++++++++++++
2 files changed, 52 insertions(+)

diff --git a/drivers/pci/endpoint/pci-epc-core.c b/drivers/pci/endpoint/pci-epc-core.c
index 094dcc3203b8..5a099479d9ab 100644
--- a/drivers/pci/endpoint/pci-epc-core.c
+++ b/drivers/pci/endpoint/pci-epc-core.c
@@ -83,6 +83,36 @@ struct pci_epc *pci_epc_get(const char *epc_name)
}
EXPORT_SYMBOL_GPL(pci_epc_get);

+/**
+ * pci_epc_get_features() - get the features supported by EPC
+ * @epc: the features supported by *this* EPC device will be returned
+ * @func_no: the features supported by the EPC device specific to the
+ * endpoint function with func_no will be returned
+ *
+ * Invoke to get the features provided by the EPC which may be
+ * specific to an endpoint function. Returns pci_epc_features on success
+ * and NULL for any failures.
+ */
+const struct pci_epc_features *pci_epc_get_features(struct pci_epc *epc,
+ u8 func_no)
+{
+ const struct pci_epc_features *epc_features;
+ unsigned long flags;
+
+ if (IS_ERR_OR_NULL(epc) || func_no >= epc->max_functions)
+ return NULL;
+
+ if (!epc->ops->get_features)
+ return NULL;
+
+ spin_lock_irqsave(&epc->lock, flags);
+ epc_features = epc->ops->get_features(epc, func_no);
+ spin_unlock_irqrestore(&epc->lock, flags);
+
+ return epc_features;
+}
+EXPORT_SYMBOL_GPL(pci_epc_get_features);
+
/**
* pci_epc_stop() - stop the PCI link
* @epc: the link of the EPC device that has to be stopped
diff --git a/include/linux/pci-epc.h b/include/linux/pci-epc.h
index 931fda3e5e0d..fcd5e5047546 100644
--- a/include/linux/pci-epc.h
+++ b/include/linux/pci-epc.h
@@ -59,6 +59,8 @@ struct pci_epc_ops {
enum pci_epc_irq_type type, u16 interrupt_num);
int (*start)(struct pci_epc *epc);
void (*stop)(struct pci_epc *epc);
+ const struct pci_epc_features* (*get_features)(struct pci_epc *epc,
+ u8 func_no);
struct module *owner;
};

@@ -103,6 +105,24 @@ struct pci_epc {
unsigned int features;
};

+/**
+ * struct pci_epc_features - features supported by a EPC device per function
+ * @linkup_notifier: indicate if the EPC device can notify EPF driver on link up
+ * @msi_capable: indicate if the endpoint function has MSI capability
+ * @msix_capable: indicate if the endpoint function has MSI-X capability
+ * @reserved_bar: bitmap to indicate reserved BAR unavailable to function driver
+ * @bar_fixed_64bit: bitmap to indicate fixed 64bit BARs
+ * @bar_fixed_size: Array specifying the size supported by each BAR
+ */
+struct pci_epc_features {
+ unsigned int linkup_notifier : 1;
+ unsigned int msi_capable : 1;
+ unsigned int msix_capable : 1;
+ u8 reserved_bar;
+ u8 bar_fixed_64bit;
+ u64 bar_fixed_size[BAR_5 + 1];
+};
+
#define EPC_FEATURE_NO_LINKUP_NOTIFIER BIT(0)
#define EPC_FEATURE_BAR_MASK (BIT(1) | BIT(2) | BIT(3))
#define EPC_FEATURE_MSIX_AVAILABLE BIT(4)
@@ -161,6 +181,8 @@ int pci_epc_raise_irq(struct pci_epc *epc, u8 func_no,
enum pci_epc_irq_type type, u16 interrupt_num);
int pci_epc_start(struct pci_epc *epc);
void pci_epc_stop(struct pci_epc *epc);
+const struct pci_epc_features *pci_epc_get_features(struct pci_epc *epc,
+ u8 func_no);
struct pci_epc *pci_epc_get(const char *epc_name);
void pci_epc_put(struct pci_epc *epc);

--
2.17.1


[PATCH 4.19.y-cip 00/26] Fixes and extension to PCIe EPF

Lad Prabhakar
 

Hi All,

This patch series is part of RFC series [1] ("Add PCIe EP support for
Renesas R-Car Gen3 and RZ/G2x"). For making it more cleaner and easier
to review series [1] is split up as suggested by Pavel, patches 1-22,
30, 32, 49, 50 are included in this set from [1].

[1] https://patchwork.kernel.org/project/cip-dev/list/?series=363279

Cheers,
Prabhakar


Alan Mikhak (5):
PCI: endpoint: Set endpoint controller pointer to NULL
PCI: endpoint: Allocate enough space for fixed size BAR
PCI: endpoint: Skip odd BAR when skipping 64bit BAR
PCI: endpoint: Clear BAR before freeing its space
PCI: endpoint: Cast the page number to phys_addr_t

Hewenliang (1):
tools: PCI: Fix fd leakage

Jean-Jacques Hiblot (1):
tools: PCI: Exit with error code when test fails

Kangjie Lu (1):
PCI: endpoint: Fix a potential NULL pointer dereference

Kishon Vijay Abraham I (17):
PCI: endpoint: Add new pci_epc_ops to get EPC features
PCI: dwc: Add ->get_features() callback function to dw_pcie_ep_ops
PCI: designware-plat: Populate ->get_features() dw_pcie_ep_ops
PCI: pci-dra7xx: Populate ->get_features() dw_pcie_ep_ops
PCI: rockchip: Populate ->get_features() dw_pcie_ep_ops
PCI: cadence: Populate ->get_features() cdns_pcie_epc_ops
PCI: endpoint: Add helper to get first unreserved BAR
PCI: endpoint: Fix pci_epf_alloc_space() to set correct MEM TYPE flags
PCI: pci-epf-test: Remove setting epf_bar flags in function driver
PCI: pci-epf-test: Do not allocate next BARs memory if current BAR is
64Bit
PCI: pci-epf-test: Use pci_epc_get_features() to get EPC features
PCI: cadence: Remove pci_epf_linkup() from Cadence EP driver
PCI: rockchip: Remove pci_epf_linkup() from Rockchip EP driver
PCI: designware-plat: Remove setting epc->features in Designware plat
EP driver
PCI: endpoint: Remove features member in struct pci_epc
PCI: endpoint: Add support to specify alignment for buffers allocated
to BARs
PCI: dwc: Fix dw_pcie_ep_raise_msix_irq() to get correct MSI-X table
address

Kunihiko Hayashi (1):
PCI: endpoint: Fix clearing start entry in configfs

drivers/pci/controller/dwc/pci-dra7xx.c | 13 ++
.../pci/controller/dwc/pcie-designware-ep.c | 12 ++
.../pci/controller/dwc/pcie-designware-plat.c | 17 ++-
drivers/pci/controller/dwc/pcie-designware.h | 1 +
drivers/pci/controller/pcie-cadence-ep.c | 25 ++--
drivers/pci/controller/pcie-rockchip-ep.c | 16 ++-
drivers/pci/endpoint/functions/pci-epf-test.c | 134 +++++++++++-------
drivers/pci/endpoint/pci-ep-cfs.c | 1 +
drivers/pci/endpoint/pci-epc-core.c | 56 +++++++-
drivers/pci/endpoint/pci-epc-mem.c | 2 +-
drivers/pci/endpoint/pci-epf-core.c | 16 ++-
include/linux/pci-epc.h | 33 +++--
include/linux/pci-epf.h | 18 ++-
tools/pci/pcitest.c | 5 +-
14 files changed, 263 insertions(+), 86 deletions(-)

--
2.17.1


Re: If you are using PCIe EP, speak up was Re: [RFC PATCH 4.19.y-cip 00/50] Add PCIe EP support for Renesas R-Car Gen3 and RZ/G2x

Lad Prabhakar
 

Hi Pavel,

-----Original Message-----
From: cip-dev@... <cip-dev@...> On Behalf Of Pavel Machek via lists.cip-project.org
Sent: 20 October 2020 13:02
To: cip-dev@...
Cc: Pavel Machek <pavel@...>; Nobuhiro Iwamatsu <nobuhiro1.iwamatsu@...>; Biju Das <biju.das.jz@...>
Subject: Re: [cip-dev] If you are using PCIe EP, speak up was Re: [RFC PATCH 4.19.y-cip 00/50] Add PCIe EP support for Renesas R-Car Gen3
and RZ/G2x

Hi!

This patch series adds support for PCIe EP on Renesas R-Car Gen3 and
RZ/G2x platforms.
I quickly went through a series and code seems reasonably nice.

* Since the changes are huge I am sending the patches as RFC.
And yes, it is quite big, which might be a problem. OTOH only Renesas
seems to have PCIe EP drivers enabled in their CIP defconfigs, so
there's good chance noone else in CIP project is using this code.

[If someone else _is_ using it or is considering using it, please
speak up.]
We haven't received any response yet, is it OK if I send a non RFC
version or shall we wait for couple of days more ?
I guess I'd like non-RFC version of patches 1-22 in a series. I
believe it makes sense to add 30, 32, 49, 50 to them, as they are
simple and fix a bug.

Would that work for you?
Sure ill get on posting the above mentioned patches as non-RFC in a series.

How do we tackle with rest of the patches ?

Cheers,
Prabhakar

Best regards,
Pavel
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany


Re: Camera CSI support for IMX

Rajashree Sankar <rajashree.sankar@...>
 

Hello Jan,
We have used Yocto Framework provided by NXP from the following link.Refer to the Document 

L4.19.35_1.1.0_LINUX_DOCS  in the above mentioned link.

The DT-bindings and the IMX Camera capture information will be available by following the steps mentioned in the document i.MX_Yocto_Project_User's_Guide from the above link.
The Kernel which we are using is fetched from the bitbake files attached below( linux-yocto_4.19.bb and its append).Could you please let us know whether CSI  Camera capture supported in this kernel be included in the Linux CIP?

Thanks and Regards,
Rajashree Sankar


CONFIDENTIALITY
This e-mail message and any attachments thereto, is intended only for use by the addressee(s) named herein and may contain legally privileged and/or confidential information. If you are not the intended recipient of this e-mail message, you are hereby notified that any dissemination, distribution or copying of this e-mail message, and any attachments thereto, is strictly prohibited. If you have received this e-mail message in error, please immediately notify the sender and permanently delete the original and any copies of this email and any prints thereof.
ABSENT AN EXPRESS STATEMENT TO THE CONTRARY HEREINABOVE, THIS E-MAIL IS NOT INTENDED AS A SUBSTITUTE FOR A WRITING. Notwithstanding the Uniform Electronic Transactions Act or the applicability of any other law of similar substance and effect, absent an express statement to the contrary hereinabove, this e-mail message its contents, and any attachments hereto are not intended to represent an offer or acceptance to enter into a contract and are not otherwise intended to bind the sender, Sanmina Corporation (or any of its subsidiaries), or any other person or entity.


Re: If you are using PCIe EP, speak up was Re: [RFC PATCH 4.19.y-cip 00/50] Add PCIe EP support for Renesas R-Car Gen3 and RZ/G2x

Pavel Machek
 

Hi!

This patch series adds support for PCIe EP on Renesas R-Car Gen3 and
RZ/G2x platforms.
I quickly went through a series and code seems reasonably nice.

* Since the changes are huge I am sending the patches as RFC.
And yes, it is quite big, which might be a problem. OTOH only Renesas
seems to have PCIe EP drivers enabled in their CIP defconfigs, so
there's good chance noone else in CIP project is using this code.

[If someone else _is_ using it or is considering using it, please
speak up.]
We haven't received any response yet, is it OK if I send a non RFC
version or shall we wait for couple of days more ?
I guess I'd like non-RFC version of patches 1-22 in a series. I
believe it makes sense to add 30, 32, 49, 50 to them, as they are
simple and fix a bug.

Would that work for you?

Best regards,
Pavel
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany


Re: If you are using PCIe EP, speak up was Re: [RFC PATCH 4.19.y-cip 00/50] Add PCIe EP support for Renesas R-Car Gen3 and RZ/G2x

Pavel Machek
 

Hi!

I quickly went through a series and code seems reasonably nice.

* Since the changes are huge I am sending the patches as RFC.
And yes, it is quite big, which might be a problem. OTOH only Renesas
seems to have PCIe EP drivers enabled in their CIP defconfigs, so
there's good chance noone else in CIP project is using this code.

[If someone else _is_ using it or is considering using it, please
speak up.]
We haven't received any response yet, is it OK if I send a non RFC version or shall we wait for couple of days more ?
No need to retransmit just now. This version is good enough for
review, let me take a closer look and submit some comments.

Best regards,
Pavel
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany


Re: Camera CSI support for IMX

SZ Lin (林上智) <sz.lin@...>
 

Hi Rajashree,

From: cip-dev@... <cip-dev@...>

Hi Rajashree,

On 16.10.20 12:25, Rajashree Sankar wrote:
 Hello,
We are using Linux-CIP Kernel Version 4.19.140-cip33. We do not find
IMX files  in the Kernel supporting Camera Capture through CSI.Could
you get us  how the support can be added?
Can you be more specific about what kernel driver(s) you are missing? Is latest
5.9 supporting this? Then please provide a reference (driver name, DT bindings
or even commit list).

Or are you referring to a feature of the vendor tree (linux-imx)? Then please talk
to NXP and ask about the status of this, if there is an upstream equivalent by
now or if this has been abandoned by them.

CIP has a strict upstream-first policy, so we can't take any downstream patches.
However, if a feature is upstream and only missed the latest CIP kernel, you can
propose backported patches for integration into that kernel. Preconditions:

- they are not invasive to other drivers or the kernel as a whole

- you are a CIP member, or the CIP member community supports the
backport (as it may increase our workload)
You may find the details of CIP kernel maintenance policies here [1] and here [2]

[1] https://wiki.linuxfoundation.org/civilinfrastructureplatform/cipkernelmaintenance#cip_kernel_maintenance_policies
[2] https://static.sched.com/hosted_files/ossna2020/d0/OSSNA2020-CIPKernelTeam-2.pdf

SZ


Thanks and Regards,
Rajashree Sankar

CONFIDENTIALITY
This e-mail message and any attachments thereto, is intended only for
[...]
If configurable on your client, please disable this footer when posting to public
lists. It's irrelevant here because the content can't be confidential due to the
target public audience. This only bloats your messages.

Jan

--
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux


Re: If you are using PCIe EP, speak up was Re: [RFC PATCH 4.19.y-cip 00/50] Add PCIe EP support for Renesas R-Car Gen3 and RZ/G2x

Lad Prabhakar
 

Hi Pavel,

-----Original Message-----
From: cip-dev@... <cip-dev@...> On Behalf Of Pavel Machek via lists.cip-project.org
Sent: 14 October 2020 10:39
To: Prabhakar Mahadev Lad <prabhakar.mahadev-lad.rj@...>
Cc: cip-dev@...; Nobuhiro Iwamatsu <nobuhiro1.iwamatsu@...>; Pavel Machek <pavel@...>; Biju Das
<biju.das.jz@...>
Subject: [cip-dev] If you are using PCIe EP, speak up was Re: [RFC PATCH 4.19.y-cip 00/50] Add PCIe EP support for Renesas R-Car Gen3 and
RZ/G2x

Hi!

This patch series adds support for PCIe EP on Renesas R-Car Gen3 and
RZ/G2x platforms.
I quickly went through a series and code seems reasonably nice.

* Since the changes are huge I am sending the patches as RFC.
And yes, it is quite big, which might be a problem. OTOH only Renesas
seems to have PCIe EP drivers enabled in their CIP defconfigs, so
there's good chance noone else in CIP project is using this code.

[If someone else _is_ using it or is considering using it, please
speak up.]
We haven't received any response yet, is it OK if I send a non RFC version or shall we wait for couple of days more ?

Cheers,
Prabhakar

Could we get better explanation for 24/ of the series? spinlock is
okay as long as code inside does not sleep, does not neccessarily have
to do with interrupts.

Should 30/ and 31/ be submitted to stable?

* Required EP framework changes and fixes are ported as well.
* All the patches have been cheery picked from upstream kernel.
* Patches [43, 44, 45, 46, 48]/50 are picked from linux-next.
Ok, so we definitely want them in upstream, not in -next. And it might
be good to wait a bit after merge, so it gets some testing in upstream.

* I was skeptic with patch 36/50 "Rename pcie-rcar.c to pcie-rcar-host.c"
this is required as patch 38/50 adds a new file named pcie-rcar.c. Open
for suggestions if this can be handled differently.
* In patch 37/48 I have dropped the changes for host driver as the patch
doesn't apply cleanly and manually applying it was resulting in a
big diff.
Let me take a look at these in bigger detail.

* As the changes touches three other controller drivers I have build tested them
as done similarly while upstreaming R-Car Gen3 PCIe EP driver.
Will this be tested somehow by our automated tests?

Best regards,
Pavel
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany


[cip-kerenl-config] 4.19.y-cip/x86/cip_qemu_defconfig: Enable NF_TABLES_SET

Venkata Pyla
 

From: venkata pyla <venkata.pyla@...>

Add NF_TABLES_SET config to support nftables set infrastructure
which is expecting in fail2ban package to work

Signed-off-by: venkata pyla <venkata.pyla@...>
---
4.19.y-cip/x86/cip_qemu_defconfig | 1 +
1 file changed, 1 insertion(+)

diff --git a/4.19.y-cip/x86/cip_qemu_defconfig b/4.19.y-cip/x86/cip_qemu_defconfig
index b86efeb..7b8fc66 100644
--- a/4.19.y-cip/x86/cip_qemu_defconfig
+++ b/4.19.y-cip/x86/cip_qemu_defconfig
@@ -96,6 +96,7 @@ CONFIG_INET6_ESP=y
CONFIG_NETLABEL=y
CONFIG_NETFILTER=y
# CONFIG_NETFILTER_ADVANCED is not set
+CONFIG_NF_TABLES_SET=y
CONFIG_NF_CONNTRACK=y
CONFIG_NF_CONNTRACK_FTP=y
CONFIG_NF_CONNTRACK_IRC=y
--
2.20.1

The information contained in this e-mail message and in any
attachments/annexure/appendices is confidential to the
recipient and may contain privileged information.
If you are not the intended recipient, please notify the
sender and delete the message along with any
attachments/annexure/appendices. You should not disclose,
copy or otherwise use the information contained in the
message or any annexure. Any views expressed in this e-mail
are those of the individual sender except where the sender
specifically states them to be the views of
Toshiba Software India Pvt. Ltd. (TSIP),Bangalore.

Although this transmission and any attachments are believed to be
free of any virus or other defect that might affect any computer
system into which it is received and opened, it is the responsibility
of the recipient to ensure that it is virus free and no responsibility
is accepted by Toshiba Embedded Software India Pvt. Ltd, for any loss or
damage arising in any way from its use.


Re: Camera CSI support for IMX

Jan Kiszka
 

Hi Rajashree,

On 16.10.20 12:25, Rajashree Sankar wrote:
 Hello,
We are using Linux-CIP Kernel Version 4.19.140-cip33. We do not find IMX
files  in the Kernel supporting Camera Capture through CSI.Could you get
us  how the support can be added?
Can you be more specific about what kernel driver(s) you are missing? Is
latest 5.9 supporting this? Then please provide a reference (driver
name, DT bindings or even commit list).

Or are you referring to a feature of the vendor tree (linux-imx)? Then
please talk to NXP and ask about the status of this, if there is an
upstream equivalent by now or if this has been abandoned by them.

CIP has a strict upstream-first policy, so we can't take any downstream
patches. However, if a feature is upstream and only missed the latest
CIP kernel, you can propose backported patches for integration into that
kernel. Preconditions:

- they are not invasive to other drivers or the kernel as a whole

- you are a CIP member, or the CIP member community supports the
backport (as it may increase our workload)

Thanks and Regards,
Rajashree Sankar

CONFIDENTIALITY
This e-mail message and any attachments thereto, is intended only for
[...]
If configurable on your client, please disable this footer when posting
to public lists. It's irrelevant here because the content can't be
confidential due to the target public audience. This only bloats your
messages.

Jan

--
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux


Camera CSI support for IMX

Rajashree Sankar <rajashree.sankar@...>
 

 Hello,
We are using Linux-CIP Kernel Version 4.19.140-cip33. We do not find IMX
files  in the Kernel supporting Camera Capture through CSI.Could you get
us  how the support can be added?
Thanks and Regards,
Rajashree Sankar

CONFIDENTIALITY
This e-mail message and any attachments thereto, is intended only for use by the addressee(s) named herein and may contain legally privileged and/or confidential information. If you are not the intended recipient of this e-mail message, you are hereby notified that any dissemination, distribution or copying of this e-mail message, and any attachments thereto, is strictly prohibited. If you have received this e-mail message in error, please immediately notify the sender and permanently delete the original and any copies of this email and any prints thereof.
ABSENT AN EXPRESS STATEMENT TO THE CONTRARY HEREINABOVE, THIS E-MAIL IS NOT INTENDED AS A SUBSTITUTE FOR A WRITING. Notwithstanding the Uniform Electronic Transactions Act or the applicability of any other law of similar substance and effect, absent an express statement to the contrary hereinabove, this e-mail message its contents, and any attachments hereto are not intended to represent an offer or acceptance to enter into a contract and are not otherwise intended to bind the sender, Sanmina Corporation (or any of its subsidiaries), or any other person or entity.


Re: Bluetooth CVEs deciphered?

Pavel Machek
 

Hi!

I believe Google has good information which CVE corresponds to which
patch, and I used that to improve cip-kernel-sec. Result is here. Can
you take a look before I start fighting yml?
I believe I indentified the other 2 fixes, too. Here's updated diff.

Best regards,
Pavel

diff --git a/issues/CVE-2020-12351.yml b/issues/CVE-2020-12351.yml
index 63f8b60..a28487e 100644
--- a/issues/CVE-2020-12351.yml
+++ b/issues/CVE-2020-12351.yml
@@ -1,37 +1,14 @@
-description: INTEL-SA-00435
+description: |
+ A heap-based type confusion affecting Linux kernel 4.8 and higher was discovered in net/bluetooth/l2cap_core.c.
+advisory: |
references:
-- https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00435.html
-comments:
- debian/carnil: |-
- CVE-2020-12351, CVE-2020-12352 and CVE-2020-24490 are three
- issues covered by a set of commits/patches sent upstream but
- there is no clear association from the CVEs to the commits. So
- duplicate this entry for now to all three CVEs.
- The commits are:
- https://lore.kernel.org/linux-bluetooth/20200806181714.3216076-1-luiz.dentz@gmail.com/
- https://lore.kernel.org/linux-bluetooth/20200806181714.3216076-2-luiz.dentz@gmail.com/
- https://lore.kernel.org/linux-bluetooth/20200806181714.3216076-3-luiz.dentz@gmail.com/
- https://lore.kernel.org/linux-bluetooth/20200806181714.3216076-4-luiz.dentz@gmail.com/
- which are not yet in mainline, and
- a2ec905d1e16 ("Bluetooth: fix kernel oops in
- store_pending_adv_report") which is in 5.8 (and which was
- backported to 5.7.13, 5.4.56 and 4.19.137).
- The "fixed version" information in INTEL-SA-00435 is thus as
- well contradictory as it mentions the issue to be fixed in 5.9
- or later.
- wens: |-
- The four patches are already in net-next as of 2020-10-14 and should hit
- mainline soon. As far as I can tell, ("Bluetooth: A2MP: Fix not
- initializing all members") fixes commits going all the way back to
- 3.6, when A2MP was added.
- Regarding the culprit commits, the first commit is fixed by a2ec905d1e16
- ("Bluetooth: fix kernel oops in store_pending_adv_report"); the next
- nine are the various "not fully initialized stack variables"; the last
- two are the sk_filter and BT_HS ones, respectfully.
+ https://github.com/google/security-research/security/advisories/GHSA-h637-c88j-47wq
+aliases:
+ GHSA-h637-c88j-47wq
introduced-by:
- mainline: [c215e9397b00b3045a668120ed7dbd89f2866e74, 6b44d9b8d96b37f72ccd7335b32f386a67b7f1f4,
- a28381dc9ca3e54b0678e2cd7c68c1afb2d7cc76, e072f5dab22e7bf0a10daf854acc0fc271396ee7,
- 6113f84fc1a8962aed25f54a115b196e9aea151f, 8e2a0d92c56ec6955526a8b60838c9b00f70540d,
- aa09537d80bf7e6282103618eb496f03e76f2953, 0d868de9d8760c76f6d4c6c777935c05ef272caa,
- 8e05e3ba88adcf7ac644e6ef26676ea7c048a08c, 93c3e8f5c9a0e4dc6b6c93108dcf3ec54ab1191a,
- dbb50887c8f619fc5c3489783ebc3122bc134a31, 6d80dfd094a7b286e95cdcac79efeb7bbb4e226f]
+ mainline: dbb50887c8f619fc5c3489783ebc3122bc134a31
+
+ (no Fixed: tag matching dbb50887c8 in -next).
+
+Probably this fixes it?
+ f19425641cb2572a33cb074d5e30283720bd4d22 .. yep.
\ No newline at end of file
diff --git a/issues/CVE-2020-12352.yml b/issues/CVE-2020-12352.yml
index 63f8b60..64b731d 100644
--- a/issues/CVE-2020-12352.yml
+++ b/issues/CVE-2020-12352.yml
@@ -1,37 +1,19 @@
-description: INTEL-SA-00435
+description: |
+ BadChoice: Stack-Based Information Leak (BleedingTooth)
+ A stack-based information leak affecting Linux kernel 3.6 and higher was discovered in net/bluetooth/a2mp.c.
+advisory: |
references:
-- https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00435.html
-comments:
- debian/carnil: |-
- CVE-2020-12351, CVE-2020-12352 and CVE-2020-24490 are three
- issues covered by a set of commits/patches sent upstream but
- there is no clear association from the CVEs to the commits. So
- duplicate this entry for now to all three CVEs.
- The commits are:
- https://lore.kernel.org/linux-bluetooth/20200806181714.3216076-1-luiz.dentz@gmail.com/
- https://lore.kernel.org/linux-bluetooth/20200806181714.3216076-2-luiz.dentz@gmail.com/
- https://lore.kernel.org/linux-bluetooth/20200806181714.3216076-3-luiz.dentz@gmail.com/
- https://lore.kernel.org/linux-bluetooth/20200806181714.3216076-4-luiz.dentz@gmail.com/
- which are not yet in mainline, and
- a2ec905d1e16 ("Bluetooth: fix kernel oops in
- store_pending_adv_report") which is in 5.8 (and which was
- backported to 5.7.13, 5.4.56 and 4.19.137).
- The "fixed version" information in INTEL-SA-00435 is thus as
- well contradictory as it mentions the issue to be fixed in 5.9
- or later.
- wens: |-
- The four patches are already in net-next as of 2020-10-14 and should hit
- mainline soon. As far as I can tell, ("Bluetooth: A2MP: Fix not
- initializing all members") fixes commits going all the way back to
- 3.6, when A2MP was added.
- Regarding the culprit commits, the first commit is fixed by a2ec905d1e16
- ("Bluetooth: fix kernel oops in store_pending_adv_report"); the next
- nine are the various "not fully initialized stack variables"; the last
- two are the sk_filter and BT_HS ones, respectfully.
+ https://github.com/google/security-research/security/advisories/GHSA-7mh3-gq28-gfrq
+aliases:
+ GHSA-7mh3-gq28-gfrq
introduced-by:
- mainline: [c215e9397b00b3045a668120ed7dbd89f2866e74, 6b44d9b8d96b37f72ccd7335b32f386a67b7f1f4,
- a28381dc9ca3e54b0678e2cd7c68c1afb2d7cc76, e072f5dab22e7bf0a10daf854acc0fc271396ee7,
- 6113f84fc1a8962aed25f54a115b196e9aea151f, 8e2a0d92c56ec6955526a8b60838c9b00f70540d,
- aa09537d80bf7e6282103618eb496f03e76f2953, 0d868de9d8760c76f6d4c6c777935c05ef272caa,
- 8e05e3ba88adcf7ac644e6ef26676ea7c048a08c, 93c3e8f5c9a0e4dc6b6c93108dcf3ec54ab1191a,
- dbb50887c8f619fc5c3489783ebc3122bc134a31, 6d80dfd094a7b286e95cdcac79efeb7bbb4e226f]
+ mainline:
+ 47f2d97d38816aaca94c9b6961c6eff1cfcd0bd6
+ 8e2a0d92c56ec6955526a8b60838c9b00f70540d ?
+fixed-by:
+ probably this: eddb7732119d53400f48a02536a84c509692faa8
+
+Author: Luiz Augusto von Dentz <luiz.von.dentz@...>
+Date: Thu Aug 6 11:17:11 2020 -0700
+
+
\ No newline at end of file
diff --git a/issues/CVE-2020-24490.yml b/issues/CVE-2020-24490.yml
index 63f8b60..8fe3617 100644
--- a/issues/CVE-2020-24490.yml
+++ b/issues/CVE-2020-24490.yml
@@ -1,37 +1,25 @@
-description: INTEL-SA-00435
+description: |
+ BadVibes: Heap-Based Buffer Overflow (BleedingTooth)
+ A heap-based buffer overflow affecting Linux kernel 4.19 and higher was discovered in net/bluetooth/hci_event.c.
+advisory: |
+
references:
-- https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00435.html
+ https://github.com/google/security-research/security/advisories/GHSA-ccx2-w2r4-x649
+aliases:
+ GHSA-ccx2-w2r4-x649
comments:
- debian/carnil: |-
- CVE-2020-12351, CVE-2020-12352 and CVE-2020-24490 are three
- issues covered by a set of commits/patches sent upstream but
- there is no clear association from the CVEs to the commits. So
- duplicate this entry for now to all three CVEs.
- The commits are:
- https://lore.kernel.org/linux-bluetooth/20200806181714.3216076-1-luiz.dentz@gmail.com/
- https://lore.kernel.org/linux-bluetooth/20200806181714.3216076-2-luiz.dentz@gmail.com/
- https://lore.kernel.org/linux-bluetooth/20200806181714.3216076-3-luiz.dentz@gmail.com/
- https://lore.kernel.org/linux-bluetooth/20200806181714.3216076-4-luiz.dentz@gmail.com/
- which are not yet in mainline, and
- a2ec905d1e16 ("Bluetooth: fix kernel oops in
- store_pending_adv_report") which is in 5.8 (and which was
- backported to 5.7.13, 5.4.56 and 4.19.137).
- The "fixed version" information in INTEL-SA-00435 is thus as
- well contradictory as it mentions the issue to be fixed in 5.9
- or later.
- wens: |-
- The four patches are already in net-next as of 2020-10-14 and should hit
- mainline soon. As far as I can tell, ("Bluetooth: A2MP: Fix not
- initializing all members") fixes commits going all the way back to
- 3.6, when A2MP was added.
- Regarding the culprit commits, the first commit is fixed by a2ec905d1e16
- ("Bluetooth: fix kernel oops in store_pending_adv_report"); the next
- nine are the various "not fully initialized stack variables"; the last
- two are the sk_filter and BT_HS ones, respectfully.
+ Pavel Machek:
+ This actually looks like most severe from the recent bluetooth stuff.
+
+ Fix is not one-liner but also not scary. Adds checking at expected places.
introduced-by:
- mainline: [c215e9397b00b3045a668120ed7dbd89f2866e74, 6b44d9b8d96b37f72ccd7335b32f386a67b7f1f4,
- a28381dc9ca3e54b0678e2cd7c68c1afb2d7cc76, e072f5dab22e7bf0a10daf854acc0fc271396ee7,
- 6113f84fc1a8962aed25f54a115b196e9aea151f, 8e2a0d92c56ec6955526a8b60838c9b00f70540d,
- aa09537d80bf7e6282103618eb496f03e76f2953, 0d868de9d8760c76f6d4c6c777935c05ef272caa,
- 8e05e3ba88adcf7ac644e6ef26676ea7c048a08c, 93c3e8f5c9a0e4dc6b6c93108dcf3ec54ab1191a,
- dbb50887c8f619fc5c3489783ebc3122bc134a31, 6d80dfd094a7b286e95cdcac79efeb7bbb4e226f]
+ mainline:
+ c215e9397b00b3045a668120ed7dbd89f2866e74
+ b2cc9761f144e8ef714be8c590603073b80ddc13
+fixed-by:
+ mainline:
+ a2ec905d1e160a33b2e210e45ad30445ef26ce0e
+ 4.19:
+ 5df9e5613d1c51e16b1501a4c75e139fbbe0fb6c
+ -- needs to be backported to 4.4?
+
\ No newline at end of file

--
http://www.livejournal.com/~pavelmachek


Backport c797110d for CVE-2020-25645 [net: geneve]

Pavel Machek
 

Backport c797110d for CVE-2020-25645.

This ... builds. I would not mind getting some testing here.

Best regards,
Pavel

diff --git a/drivers/net/geneve.c b/drivers/net/geneve.c
index ec13e2ae6d16..840ad2e29dbb 100644
--- a/drivers/net/geneve.c
+++ b/drivers/net/geneve.c
@@ -711,7 +711,8 @@ free_dst:
static struct rtable *geneve_get_v4_rt(struct sk_buff *skb,
struct net_device *dev,
struct flowi4 *fl4,
- struct ip_tunnel_info *info)
+ struct ip_tunnel_info *info,
+ __be16 dport, __be16 sport)
{
struct geneve_dev *geneve = netdev_priv(dev);
struct rtable *rt = NULL;
@@ -720,6 +721,8 @@ static struct rtable *geneve_get_v4_rt(struct sk_buff *skb,
memset(fl4, 0, sizeof(*fl4));
fl4->flowi4_mark = skb->mark;
fl4->flowi4_proto = IPPROTO_UDP;
+ fl4->fl4_dport = dport;
+ fl4->fl4_sport = sport;

if (info) {
fl4->daddr = info->key.u.ipv4.dst;
@@ -754,7 +757,8 @@ static struct rtable *geneve_get_v4_rt(struct sk_buff *skb,
static struct dst_entry *geneve_get_v6_dst(struct sk_buff *skb,
struct net_device *dev,
struct flowi6 *fl6,
- struct ip_tunnel_info *info)
+ struct ip_tunnel_info *info,
+ __be16 dport, __be16 sport)
{
struct geneve_dev *geneve = netdev_priv(dev);
struct geneve_sock *gs6 = geneve->sock6;
@@ -764,6 +768,8 @@ static struct dst_entry *geneve_get_v6_dst(struct sk_buff *skb,
memset(fl6, 0, sizeof(*fl6));
fl6->flowi6_mark = skb->mark;
fl6->flowi6_proto = IPPROTO_UDP;
+ fl6->fl6_dport = dport;
+ fl6->fl6_sport = sport;

if (info) {
fl6->daddr = info->key.u.ipv6.dst;
@@ -834,13 +840,14 @@ static netdev_tx_t geneve_xmit_skb(struct sk_buff *skb, struct net_device *dev,
goto tx_error;
}

- rt = geneve_get_v4_rt(skb, dev, &fl4, info);
+ sport = udp_flow_src_port(geneve->net, skb, 1, USHRT_MAX, true);
+ rt = geneve_get_v4_rt(skb, dev, &fl4, info,
+ info->key.tp_dst, sport);
if (IS_ERR(rt)) {
err = PTR_ERR(rt);
goto tx_error;
}

- sport = udp_flow_src_port(geneve->net, skb, 1, USHRT_MAX, true);
skb_reset_mac_header(skb);

if (info) {
@@ -916,13 +923,14 @@ static netdev_tx_t geneve6_xmit_skb(struct sk_buff *skb, struct net_device *dev,
}
}

- dst = geneve_get_v6_dst(skb, dev, &fl6, info);
+ sport = udp_flow_src_port(geneve->net, skb, 1, USHRT_MAX, true);
+ dst = geneve_get_v6_dst(skb, dev, &fl6, info,
+ info->key.tp_dst, sport);
if (IS_ERR(dst)) {
err = PTR_ERR(dst);
goto tx_error;
}

- sport = udp_flow_src_port(geneve->net, skb, 1, USHRT_MAX, true);
skb_reset_mac_header(skb);

if (info) {
@@ -1011,9 +1019,14 @@ static int geneve_fill_metadata_dst(struct net_device *dev, struct sk_buff *skb)
struct dst_entry *dst;
struct flowi6 fl6;
#endif
+ __be16 sport;

if (ip_tunnel_info_af(info) == AF_INET) {
- rt = geneve_get_v4_rt(skb, dev, &fl4, info);
+ sport = udp_flow_src_port(geneve->net, skb,
+ 1, USHRT_MAX, true);
+
+ rt = geneve_get_v4_rt(skb, dev, &fl4, info,
+ info->key.tp_dst, sport);
if (IS_ERR(rt))
return PTR_ERR(rt);

@@ -1021,7 +1034,11 @@ static int geneve_fill_metadata_dst(struct net_device *dev, struct sk_buff *skb)
info->key.u.ipv4.src = fl4.saddr;
#if IS_ENABLED(CONFIG_IPV6)
} else if (ip_tunnel_info_af(info) == AF_INET6) {
- dst = geneve_get_v6_dst(skb, dev, &fl6, info);
+ sport = udp_flow_src_port(geneve->net, skb,
+ 1, USHRT_MAX, true);
+
+ dst = geneve_get_v6_dst(skb, dev, &fl6, info,
+ info->key.tp_dst, sport);
if (IS_ERR(dst))
return PTR_ERR(dst);

@@ -1032,8 +1049,7 @@ static int geneve_fill_metadata_dst(struct net_device *dev, struct sk_buff *skb)
return -EINVAL;
}

- info->key.tp_src = udp_flow_src_port(geneve->net, skb,
- 1, USHRT_MAX, true);
+ info->key.tp_src = sport;
info->key.tp_dst = geneve->dst_port;
return 0;
}


--
http://www.livejournal.com/~pavelmachek


CVE-2020-24490: backporting a2ec905d to 4.4.

Pavel Machek
 

CVE-2020-24490: backporting a2ec905d to 4.4.

Yes, "ext_adv" is always false here, so code could be simplified, but
I believe this is good enough for -stable.

Best regards,
Pavel



diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c
index 03319ab8a7c6..3794616cd87b 100644
--- a/net/bluetooth/hci_event.c
+++ b/net/bluetooth/hci_event.c
@@ -1133,6 +1133,9 @@ static void store_pending_adv_report(struct hci_dev *hdev, bdaddr_t *bdaddr,
{
struct discovery_state *d = &hdev->discovery;

+ if (len > HCI_MAX_AD_LENGTH)
+ return;
+
bacpy(&d->last_adv_addr, bdaddr);
d->last_adv_addr_type = bdaddr_type;
d->last_adv_rssi = rssi;
@@ -4743,7 +4746,8 @@ static struct hci_conn *check_pending_le_conn(struct hci_dev *hdev,

static void process_adv_report(struct hci_dev *hdev, u8 type, bdaddr_t *bdaddr,
u8 bdaddr_type, bdaddr_t *direct_addr,
- u8 direct_addr_type, s8 rssi, u8 *data, u8 len)
+ u8 direct_addr_type, s8 rssi, u8 *data, u8 len,
+ bool ext_adv)
{
struct discovery_state *d = &hdev->discovery;
struct smp_irk *irk;
@@ -4752,6 +4756,11 @@ static void process_adv_report(struct hci_dev *hdev, u8 type, bdaddr_t *bdaddr,
u32 flags;
u8 *ptr, real_len;

+ if (!ext_adv && len > HCI_MAX_AD_LENGTH) {
+ BT_ERR_RATELIMITED("legacy adv larger than 31 bytes");
+ return;
+ }
+
/* Find the end of the data in case the report contains padded zero
* bytes at the end causing an invalid length value.
*
@@ -4812,7 +4821,7 @@ static void process_adv_report(struct hci_dev *hdev, u8 type, bdaddr_t *bdaddr,
*/
conn = check_pending_le_conn(hdev, bdaddr, bdaddr_type, type,
direct_addr);
- if (conn && type == LE_ADV_IND) {
+ if (!ext_adv && conn && type == LE_ADV_IND && len <= HCI_MAX_AD_LENGTH) {
/* Store report for later inclusion by
* mgmt_device_connected
*/
@@ -4866,7 +4875,7 @@ static void process_adv_report(struct hci_dev *hdev, u8 type, bdaddr_t *bdaddr,
* event or send an immediate device found event if the data
* should not be stored for later.
*/
- if (!has_pending_adv_report(hdev)) {
+ if (!ext_adv && !has_pending_adv_report(hdev)) {
/* If the report will trigger a SCAN_REQ store it for
* later merging.
*/
@@ -4901,7 +4910,8 @@ static void process_adv_report(struct hci_dev *hdev, u8 type, bdaddr_t *bdaddr,
/* If the new report will trigger a SCAN_REQ store it for
* later merging.
*/
- if (type == LE_ADV_IND || type == LE_ADV_SCAN_IND) {
+ if (!ext_adv && (type == LE_ADV_IND ||
+ type == LE_ADV_SCAN_IND)) {
store_pending_adv_report(hdev, bdaddr, bdaddr_type,
rssi, flags, data, len);
return;
@@ -4940,7 +4950,7 @@ static void hci_le_adv_report_evt(struct hci_dev *hdev, struct sk_buff *skb)
rssi = ev->data[ev->length];
process_adv_report(hdev, ev->evt_type, &ev->bdaddr,
ev->bdaddr_type, NULL, 0, rssi,
- ev->data, ev->length);
+ ev->data, ev->length, false);

ptr += sizeof(*ev) + ev->length + 1;
}
@@ -5137,7 +5147,8 @@ static void hci_le_direct_adv_report_evt(struct hci_dev *hdev,

process_adv_report(hdev, ev->evt_type, &ev->bdaddr,
ev->bdaddr_type, &ev->direct_addr,
- ev->direct_addr_type, ev->rssi, NULL, 0);
+ ev->direct_addr_type, ev->rssi, NULL, 0,
+ false);

ptr += sizeof(*ev);
}


--
http://www.livejournal.com/~pavelmachek


Bluetooth CVEs deciphered?

Pavel Machek
 

Hi!

I believe Google has good information which CVE corresponds to which
patch, and I used that to improve cip-kernel-sec. Result is here. Can
you take a look before I start fighting yml?

Best regards,
Pavel

diff --git a/issues/CVE-2020-12351.yml b/issues/CVE-2020-12351.yml
index 63f8b60..b7f519b 100644
--- a/issues/CVE-2020-12351.yml
+++ b/issues/CVE-2020-12351.yml
@@ -1,37 +1,9 @@
-description: INTEL-SA-00435
+description: |
+ A heap-based type confusion affecting Linux kernel 4.8 and higher was discovered in net/bluetooth/l2cap_core.c.
+advisory: |
references:
-- https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00435.html
-comments:
- debian/carnil: |-
- CVE-2020-12351, CVE-2020-12352 and CVE-2020-24490 are three
- issues covered by a set of commits/patches sent upstream but
- there is no clear association from the CVEs to the commits. So
- duplicate this entry for now to all three CVEs.
- The commits are:
- https://lore.kernel.org/linux-bluetooth/20200806181714.3216076-1-luiz.dentz@gmail.com/
- https://lore.kernel.org/linux-bluetooth/20200806181714.3216076-2-luiz.dentz@gmail.com/
- https://lore.kernel.org/linux-bluetooth/20200806181714.3216076-3-luiz.dentz@gmail.com/
- https://lore.kernel.org/linux-bluetooth/20200806181714.3216076-4-luiz.dentz@gmail.com/
- which are not yet in mainline, and
- a2ec905d1e16 ("Bluetooth: fix kernel oops in
- store_pending_adv_report") which is in 5.8 (and which was
- backported to 5.7.13, 5.4.56 and 4.19.137).
- The "fixed version" information in INTEL-SA-00435 is thus as
- well contradictory as it mentions the issue to be fixed in 5.9
- or later.
- wens: |-
- The four patches are already in net-next as of 2020-10-14 and should hit
- mainline soon. As far as I can tell, ("Bluetooth: A2MP: Fix not
- initializing all members") fixes commits going all the way back to
- 3.6, when A2MP was added.
- Regarding the culprit commits, the first commit is fixed by a2ec905d1e16
- ("Bluetooth: fix kernel oops in store_pending_adv_report"); the next
- nine are the various "not fully initialized stack variables"; the last
- two are the sk_filter and BT_HS ones, respectfully.
+ https://github.com/google/security-research/security/advisories/GHSA-h637-c88j-47wq
+aliases:
+ GHSA-h637-c88j-47wq
introduced-by:
- mainline: [c215e9397b00b3045a668120ed7dbd89f2866e74, 6b44d9b8d96b37f72ccd7335b32f386a67b7f1f4,
- a28381dc9ca3e54b0678e2cd7c68c1afb2d7cc76, e072f5dab22e7bf0a10daf854acc0fc271396ee7,
- 6113f84fc1a8962aed25f54a115b196e9aea151f, 8e2a0d92c56ec6955526a8b60838c9b00f70540d,
- aa09537d80bf7e6282103618eb496f03e76f2953, 0d868de9d8760c76f6d4c6c777935c05ef272caa,
- 8e05e3ba88adcf7ac644e6ef26676ea7c048a08c, 93c3e8f5c9a0e4dc6b6c93108dcf3ec54ab1191a,
- dbb50887c8f619fc5c3489783ebc3122bc134a31, 6d80dfd094a7b286e95cdcac79efeb7bbb4e226f]
+ mainline: dbb50887c8f619fc5c3489783ebc3122bc134a31
diff --git a/issues/CVE-2020-12352.yml b/issues/CVE-2020-12352.yml
index 63f8b60..372e3ce 100644
--- a/issues/CVE-2020-12352.yml
+++ b/issues/CVE-2020-12352.yml
@@ -1,37 +1,13 @@
-description: INTEL-SA-00435
+description: |
+ BadChoice: Stack-Based Information Leak (BleedingTooth)
+ A stack-based information leak affecting Linux kernel 3.6 and higher was discovered in net/bluetooth/a2mp.c.
+advisory: |
references:
-- https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00435.html
-comments:
- debian/carnil: |-
- CVE-2020-12351, CVE-2020-12352 and CVE-2020-24490 are three
- issues covered by a set of commits/patches sent upstream but
- there is no clear association from the CVEs to the commits. So
- duplicate this entry for now to all three CVEs.
- The commits are:
- https://lore.kernel.org/linux-bluetooth/20200806181714.3216076-1-luiz.dentz@gmail.com/
- https://lore.kernel.org/linux-bluetooth/20200806181714.3216076-2-luiz.dentz@gmail.com/
- https://lore.kernel.org/linux-bluetooth/20200806181714.3216076-3-luiz.dentz@gmail.com/
- https://lore.kernel.org/linux-bluetooth/20200806181714.3216076-4-luiz.dentz@gmail.com/
- which are not yet in mainline, and
- a2ec905d1e16 ("Bluetooth: fix kernel oops in
- store_pending_adv_report") which is in 5.8 (and which was
- backported to 5.7.13, 5.4.56 and 4.19.137).
- The "fixed version" information in INTEL-SA-00435 is thus as
- well contradictory as it mentions the issue to be fixed in 5.9
- or later.
- wens: |-
- The four patches are already in net-next as of 2020-10-14 and should hit
- mainline soon. As far as I can tell, ("Bluetooth: A2MP: Fix not
- initializing all members") fixes commits going all the way back to
- 3.6, when A2MP was added.
- Regarding the culprit commits, the first commit is fixed by a2ec905d1e16
- ("Bluetooth: fix kernel oops in store_pending_adv_report"); the next
- nine are the various "not fully initialized stack variables"; the last
- two are the sk_filter and BT_HS ones, respectfully.
+ https://github.com/google/security-research/security/advisories/GHSA-7mh3-gq28-gfrq
+aliases:
+ GHSA-7mh3-gq28-gfrq
introduced-by:
- mainline: [c215e9397b00b3045a668120ed7dbd89f2866e74, 6b44d9b8d96b37f72ccd7335b32f386a67b7f1f4,
- a28381dc9ca3e54b0678e2cd7c68c1afb2d7cc76, e072f5dab22e7bf0a10daf854acc0fc271396ee7,
- 6113f84fc1a8962aed25f54a115b196e9aea151f, 8e2a0d92c56ec6955526a8b60838c9b00f70540d,
- aa09537d80bf7e6282103618eb496f03e76f2953, 0d868de9d8760c76f6d4c6c777935c05ef272caa,
- 8e05e3ba88adcf7ac644e6ef26676ea7c048a08c, 93c3e8f5c9a0e4dc6b6c93108dcf3ec54ab1191a,
- dbb50887c8f619fc5c3489783ebc3122bc134a31, 6d80dfd094a7b286e95cdcac79efeb7bbb4e226f]
+ mainline:
+ 47f2d97d38816aaca94c9b6961c6eff1cfcd0bd6
+ 8e2a0d92c56ec6955526a8b60838c9b00f70540d
+fixed-by:
\ No newline at end of file
diff --git a/issues/CVE-2020-24490.yml b/issues/CVE-2020-24490.yml
index 63f8b60..8fe3617 100644
--- a/issues/CVE-2020-24490.yml
+++ b/issues/CVE-2020-24490.yml
@@ -1,37 +1,25 @@
-description: INTEL-SA-00435
+description: |
+ BadVibes: Heap-Based Buffer Overflow (BleedingTooth)
+ A heap-based buffer overflow affecting Linux kernel 4.19 and higher was discovered in net/bluetooth/hci_event.c.
+advisory: |
+
references:
-- https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00435.html
+ https://github.com/google/security-research/security/advisories/GHSA-ccx2-w2r4-x649
+aliases:
+ GHSA-ccx2-w2r4-x649
comments:
- debian/carnil: |-
- CVE-2020-12351, CVE-2020-12352 and CVE-2020-24490 are three
- issues covered by a set of commits/patches sent upstream but
- there is no clear association from the CVEs to the commits. So
- duplicate this entry for now to all three CVEs.
- The commits are:
- https://lore.kernel.org/linux-bluetooth/20200806181714.3216076-1-luiz.dentz@gmail.com/
- https://lore.kernel.org/linux-bluetooth/20200806181714.3216076-2-luiz.dentz@gmail.com/
- https://lore.kernel.org/linux-bluetooth/20200806181714.3216076-3-luiz.dentz@gmail.com/
- https://lore.kernel.org/linux-bluetooth/20200806181714.3216076-4-luiz.dentz@gmail.com/
- which are not yet in mainline, and
- a2ec905d1e16 ("Bluetooth: fix kernel oops in
- store_pending_adv_report") which is in 5.8 (and which was
- backported to 5.7.13, 5.4.56 and 4.19.137).
- The "fixed version" information in INTEL-SA-00435 is thus as
- well contradictory as it mentions the issue to be fixed in 5.9
- or later.
- wens: |-
- The four patches are already in net-next as of 2020-10-14 and should hit
- mainline soon. As far as I can tell, ("Bluetooth: A2MP: Fix not
- initializing all members") fixes commits going all the way back to
- 3.6, when A2MP was added.
- Regarding the culprit commits, the first commit is fixed by a2ec905d1e16
- ("Bluetooth: fix kernel oops in store_pending_adv_report"); the next
- nine are the various "not fully initialized stack variables"; the last
- two are the sk_filter and BT_HS ones, respectfully.
+ Pavel Machek:
+ This actually looks like most severe from the recent bluetooth stuff.
+
+ Fix is not one-liner but also not scary. Adds checking at expected places.
introduced-by:
- mainline: [c215e9397b00b3045a668120ed7dbd89f2866e74, 6b44d9b8d96b37f72ccd7335b32f386a67b7f1f4,
- a28381dc9ca3e54b0678e2cd7c68c1afb2d7cc76, e072f5dab22e7bf0a10daf854acc0fc271396ee7,
- 6113f84fc1a8962aed25f54a115b196e9aea151f, 8e2a0d92c56ec6955526a8b60838c9b00f70540d,
- aa09537d80bf7e6282103618eb496f03e76f2953, 0d868de9d8760c76f6d4c6c777935c05ef272caa,
- 8e05e3ba88adcf7ac644e6ef26676ea7c048a08c, 93c3e8f5c9a0e4dc6b6c93108dcf3ec54ab1191a,
- dbb50887c8f619fc5c3489783ebc3122bc134a31, 6d80dfd094a7b286e95cdcac79efeb7bbb4e226f]
+ mainline:
+ c215e9397b00b3045a668120ed7dbd89f2866e74
+ b2cc9761f144e8ef714be8c590603073b80ddc13
+fixed-by:
+ mainline:
+ a2ec905d1e160a33b2e210e45ad30445ef26ce0e
+ 4.19:
+ 5df9e5613d1c51e16b1501a4c75e139fbbe0fb6c
+ -- needs to be backported to 4.4?
+
\ No newline at end of file

--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany


Re: [RFC PATCH 4.19.y-cip 41/50] PCI: rcar: Add endpoint mode support

Pavel Machek
 

Hi!

Plain 0 would be enough
Agreed.

Ill post patches upstream to fix this and then backport or do you
want me to do the changes in place ?
Yes, thank you.

+val |= ASTINTX;
+rcar_pci_write_reg(pcie, val, PCIEINTXR);
+usleep_range(1000, 1001);
+val = rcar_pci_read_reg(pcie, PCIEINTXR);
This is crazy. Either you need exact timing or you don't, but I don't
believe usleep can guarantee microsecond accuracy.

(And you probably don't need it, right?)
Indeed a sleep is needed but checkpatch complains about it so usleep_range() was added.
checkpatch should not be an excuse for crazy code... and this one is
crazy.

Sleep has nowhere near microsecond accuracy. If you can tolerate
bigger delay, feel free to specify reasonable range. But in this case
you probably want "as close as possible to 1msec", and no,
usleep_range is not right primitive for that.

Best regards,
Pavel

--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany


Re: [RFC PATCH 4.19.y-cip 41/50] PCI: rcar: Add endpoint mode support

Lad Prabhakar
 

Hi Pavel,

Thank you for the review.

-----Original Message-----
From: Pavel Machek <pavel@...>
Sent: 14 October 2020 10:22
To: Prabhakar Mahadev Lad <prabhakar.mahadev-lad.rj@...>
Cc: cip-dev@...; Nobuhiro Iwamatsu <nobuhiro1.iwamatsu@...>; Pavel Machek <pavel@...>; Biju Das
<biju.das.jz@...>
Subject: Re: [RFC PATCH 4.19.y-cip 41/50] PCI: rcar: Add endpoint mode support

Hi!

commit 2a6d0d63d99956a66f6605832f11755d74a41951 upstream.

Add support for R-Car PCIe controller to work in endpoint mode.
+ep->ob_window[i].phys_base = res->start;
+ep->ob_window[i].size = resource_size(res);
+/* controller doesn't support multiple allocation
+ * from same window, so set page_size to window size
+ */
Comment not according to CodingStyle.
Yep
+memset(&win, 0x0, sizeof(win));
+memset(&res, 0x0, sizeof(res));
Plain 0 would be enough
Agreed.

Ill post patches upstream to fix this and then backport or do you want me to do the changes in place ?

+val |= ASTINTX;
+rcar_pci_write_reg(pcie, val, PCIEINTXR);
+usleep_range(1000, 1001);
+val = rcar_pci_read_reg(pcie, PCIEINTXR);
This is crazy. Either you need exact timing or you don't, but I don't
believe usleep can guarantee microsecond accuracy.

(And you probably don't need it, right?)
Indeed a sleep is needed but checkpatch complains about it so usleep_range() was added.

Cheers,
Prabhakar

Best regards,
Pavel
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany

Renesas Electronics Europe GmbH, Geschaeftsfuehrer/President: Carsten Jauch, Sitz der Gesellschaft/Registered office: Duesseldorf, Arcadiastrasse 10, 40472 Duesseldorf, Germany, Handelsregister/Commercial Register: Duesseldorf, HRB 3708 USt-IDNr./Tax identification no.: DE 119353406 WEEE-Reg.-Nr./WEEE reg. no.: DE 14978647


Re: [RFC PATCH 4.19.y-cip 00/50] Add PCIe EP support for Renesas R-Car Gen3 and RZ/G2x

Lad Prabhakar
 

Hi Pavel,

-----Original Message-----
From: Pavel Machek <pavel@...>
Sent: 14 October 2020 11:08
To: Prabhakar Mahadev Lad <prabhakar.mahadev-lad.rj@...>
Cc: cip-dev@...; Nobuhiro Iwamatsu <nobuhiro1.iwamatsu@...>; Pavel Machek <pavel@...>; Biju Das
<biju.das.jz@...>
Subject: Re: [RFC PATCH 4.19.y-cip 00/50] Add PCIe EP support for Renesas R-Car Gen3 and RZ/G2x

Hi!

* I was skeptic with patch 36/50 "Rename pcie-rcar.c to pcie-rcar-host.c"
this is required as patch 38/50 adds a new file named pcie-rcar.c. Open
for suggestions if this can be handled differently.
* In patch 37/48 I have dropped the changes for host driver as the patch
doesn't apply cleanly and manually applying it was resulting in a
big diff.
I have no good ideas how to avoid rename.

Given the change in locking previously in the series, manual review of
changes in this area might be good idea, anyway.
The locking changes are wrt EPF framework anyway. OK so I assume you are happy to manual changes to PCIe host driver while posting non RFC version.

In 4.19, there were 75 patches in this area so far, and 5 patches that
would reject due to the rename.

pavel@amd:~/cip/krc$ git log --pretty=oneline v4.19.. drivers/pci/controller/ | wc -l
75
pavel@amd:~/cip/krc$ git log --pretty=oneline v4.19.. drivers/pci/controller/pcie-rcar*.c | wc -l
5

...so we'll get a bit of additional workload from this. It would be
more scary if there were -rt specific changes in this area, but
hopefully there are none.

I expect that you are willing to help if -stable or -rt introduces
conflicting patches in this area?
indeed.

Cheers,
Prabhakar

Best regards,
Pavel
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany

Renesas Electronics Europe GmbH, Geschaeftsfuehrer/President: Carsten Jauch, Sitz der Gesellschaft/Registered office: Duesseldorf, Arcadiastrasse 10, 40472 Duesseldorf, Germany, Handelsregister/Commercial Register: Duesseldorf, HRB 3708 USt-IDNr./Tax identification no.: DE 119353406 WEEE-Reg.-Nr./WEEE reg. no.: DE 14978647


Re: If you are using PCIe EP, speak up was Re: [RFC PATCH 4.19.y-cip 00/50] Add PCIe EP support for Renesas R-Car Gen3 and RZ/G2x

Lad Prabhakar
 

Hi Pavel,

-----Original Message-----
From: cip-dev@... <cip-dev@...> On Behalf Of Pavel Machek via lists.cip-project.org
Sent: 14 October 2020 10:39
To: Prabhakar Mahadev Lad <prabhakar.mahadev-lad.rj@...>
Cc: cip-dev@...; Nobuhiro Iwamatsu <nobuhiro1.iwamatsu@...>; Pavel Machek <pavel@...>; Biju Das
<biju.das.jz@...>
Subject: [cip-dev] If you are using PCIe EP, speak up was Re: [RFC PATCH 4.19.y-cip 00/50] Add PCIe EP support for Renesas R-Car Gen3 and
RZ/G2x

Hi!

This patch series adds support for PCIe EP on Renesas R-Car Gen3 and
RZ/G2x platforms.
I quickly went through a series and code seems reasonably nice.
Thank you for the review. That’s a relief 😊

* Since the changes are huge I am sending the patches as RFC.
And yes, it is quite big, which might be a problem. OTOH only Renesas
seems to have PCIe EP drivers enabled in their CIP defconfigs, so
there's good chance noone else in CIP project is using this code.
Fingers crossed.

[If someone else _is_ using it or is considering using it, please
speak up.]

Could we get better explanation for 24/ of the series? spinlock is
okay as long as code inside does not sleep, does not neccessarily have
to do with interrupts.
Sure this was cherry picked from upstream I haven’t modified the description. Moreover this I had include because the subsequent patches could apply cleanly.

Do want me to just elaborate the commit message you mean ?

Should 30/ and 31/ be submitted to stable?
Yes I do agree.

* Required EP framework changes and fixes are ported as well.
* All the patches have been cheery picked from upstream kernel.
* Patches [43, 44, 45, 46, 48]/50 are picked from linux-next.
Ok, so we definitely want them in upstream, not in -next. And it might
be good to wait a bit after merge, so it gets some testing in upstream.
Sure Ill wait for them, (fyi these are just dt binding documentation and PCI-ID addition patches)

* I was skeptic with patch 36/50 "Rename pcie-rcar.c to pcie-rcar-host.c"
this is required as patch 38/50 adds a new file named pcie-rcar.c. Open
for suggestions if this can be handled differently.
* In patch 37/48 I have dropped the changes for host driver as the patch
doesn't apply cleanly and manually applying it was resulting in a
big diff.
Let me take a look at these in bigger detail.
Sure.

* As the changes touches three other controller drivers I have build tested them
as done similarly while upstreaming R-Car Gen3 PCIe EP driver.
Will this be tested somehow by our automated tests?
You mean the R-Car Gen3 PCIe EP driver ?

Cheers,
Prabhakar

Best regards,
Pavel
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany

Renesas Electronics Europe GmbH, Geschaeftsfuehrer/President: Carsten Jauch, Sitz der Gesellschaft/Registered office: Duesseldorf, Arcadiastrasse 10, 40472 Duesseldorf, Germany, Handelsregister/Commercial Register: Duesseldorf, HRB 3708 USt-IDNr./Tax identification no.: DE 119353406 WEEE-Reg.-Nr./WEEE reg. no.: DE 14978647


CIP IRC weekly meeting today

masashi.kudo@cybertrust.co.jp <masashi.kudo@...>
 

Hi all,

Kindly be reminded to attend the weekly meeting through IRC to discuss technical topics with CIP kernel today.

*Please note that the IRC meeting was rescheduled to UTC (GMT) 09:00 starting from the first week of Apr. according to TSC meeting*
https://www.timeanddate.com/worldclock/meetingdetails.html?year=2020&month=10&day=15&hour=9&min=0&sec=0&p1=224&p2=179&p3=136&p4=37&p5=241&p6=248

USWest USEast UK DE TW JP
02:00 05:00 10:00 11:00 17:00 18:00

Channel:
* irc:chat.freenode.net:6667/cip

Last meeting minutes:
https://irclogs.baserock.org/meetings/cip/2020/10/cip.2020-10-08-09.00.log.html

Agenda:

* Action item
1. Combine root filesystem with kselftest binary - iwamatsu
2. Check whether CVE-2019-0145, CVE-2019-0147, CVE-2019-0148 needs to be backported to 4.4 - masashi910

* Kernel maintenance updates
* Kernel testing
* CIP Security
* AOB

The meeting will take 30 min, although it can be extended to an hour if it makes sense and those involved in the topics can stay. Otherwise, the topic will be taken offline or in the next meeting.

Best regards,
--
M. Kudo
Cybertrust Japan Co., Ltd.

4561 - 4580 of 10158