The linux-5.4.y commit 8781011a302b ("bpf: Test_progs, add test to catch
retval refine error handling") fails to build when libbpf headers are
not installed, as it tries to include <bpf/bpf_helpers.h>:
progs/test_get_stack_rawtp_err.c:4:10:
fatal error: 'bpf/bpf_helpers.h' file not found
For 5.4-stable (only) the new test prog needs to include "bpf_helpers.h"
instead (like all the rest of progs/*.c do) because 5.4-stable does not
carry commit e01a75c15969 ("libbpf: Move bpf_{helpers, helper_defs,
endian, tracing}.h into libbpf").
Signed-off-by: Kamal Mostafa <kamal(a)canonical.com>
Fixes: 8781011a302b ("bpf: Test_progs, add test to catch retval refine error handling")
Cc: <stable(a)vger.kernel.org> # v5.4
---
tools/testing/selftests/bpf/progs/test_get_stack_rawtp_err.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/testing/selftests/bpf/progs/test_get_stack_rawtp_err.c b/tools/testing/selftests/bpf/progs/test_get_stack_rawtp_err.c
index 8941a41c2a55..cce6d605c017 100644
--- a/tools/testing/selftests/bpf/progs/test_get_stack_rawtp_err.c
+++ b/tools/testing/selftests/bpf/progs/test_get_stack_rawtp_err.c
@@ -1,7 +1,7 @@
// SPDX-License-Identifier: GPL-2.0
#include <linux/bpf.h>
-#include <bpf/bpf_helpers.h>
+#include "bpf_helpers.h"
#define MAX_STACK_RAWTP 10
--
2.17.1
This is a note to let you know that I've just added the patch titled
thunderbolt: Check return value of tb_sw_read() in usb4_switch_op()
to my usb git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git
in the usb-linus branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will hopefully also be merged in Linus's tree for the
next -rc kernel release.
If you have any questions about this process, please let me know.
>From c3bf9930921b33edb31909006607e478751a6f5e Mon Sep 17 00:00:00 2001
From: Mika Westerberg <mika.westerberg(a)linux.intel.com>
Date: Thu, 9 Apr 2020 10:18:10 +0300
Subject: thunderbolt: Check return value of tb_sw_read() in usb4_switch_op()
The function misses checking return value of tb_sw_read() before it
accesses the value that was read. Fix this by checking the return value
first.
Fixes: b04079837b20 ("thunderbolt: Add initial support for USB4")
Signed-off-by: Mika Westerberg <mika.westerberg(a)linux.intel.com>
Reviewed-by: Yehezkel Bernat <yehezkelshb(a)gmail.com>
Cc: stable <stable(a)vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/thunderbolt/usb4.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/thunderbolt/usb4.c b/drivers/thunderbolt/usb4.c
index 3d084cec136f..50c7534ba31e 100644
--- a/drivers/thunderbolt/usb4.c
+++ b/drivers/thunderbolt/usb4.c
@@ -182,6 +182,9 @@ static int usb4_switch_op(struct tb_switch *sw, u16 opcode, u8 *status)
return ret;
ret = tb_sw_read(sw, &val, TB_CFG_SWITCH, ROUTER_CS_26, 1);
+ if (ret)
+ return ret;
+
if (val & ROUTER_CS_26_ONS)
return -EOPNOTSUPP;
--
2.26.2
This is a note to let you know that I've just added the patch titled
coredump: fix crash when umh is disabled
to my driver-core git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git
in the driver-core-linus branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will hopefully also be merged in Linus's tree for the
next -rc kernel release.
If you have any questions about this process, please let me know.
>From 3740d93e37902b31159a82da2d5c8812ed825404 Mon Sep 17 00:00:00 2001
From: Luis Chamberlain <mcgrof(a)kernel.org>
Date: Thu, 16 Apr 2020 16:28:59 +0000
Subject: coredump: fix crash when umh is disabled
Commit 64e90a8acb859 ("Introduce STATIC_USERMODEHELPER to mediate
call_usermodehelper()") added the optiont to disable all
call_usermodehelper() calls by setting STATIC_USERMODEHELPER_PATH to
an empty string. When this is done, and crashdump is triggered, it
will crash on null pointer dereference, since we make assumptions
over what call_usermodehelper_exec() did.
This has been reported by Sergey when one triggers a a coredump
with the following configuration:
```
CONFIG_STATIC_USERMODEHELPER=y
CONFIG_STATIC_USERMODEHELPER_PATH=""
kernel.core_pattern = |/usr/lib/systemd/systemd-coredump %P %u %g %s %t %c %h %e
```
The way disabling the umh was designed was that call_usermodehelper_exec()
would just return early, without an error. But coredump assumes
certain variables are set up for us when this happens, and calls
ile_start_write(cprm.file) with a NULL file.
[ 2.819676] BUG: kernel NULL pointer dereference, address: 0000000000000020
[ 2.819859] #PF: supervisor read access in kernel mode
[ 2.820035] #PF: error_code(0x0000) - not-present page
[ 2.820188] PGD 0 P4D 0
[ 2.820305] Oops: 0000 [#1] SMP PTI
[ 2.820436] CPU: 2 PID: 89 Comm: a Not tainted 5.7.0-rc1+ #7
[ 2.820680] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS ?-20190711_202441-buildvm-armv7-10.arm.fedoraproject.org-2.fc31 04/01/2014
[ 2.821150] RIP: 0010:do_coredump+0xd80/0x1060
[ 2.821385] Code: e8 95 11 ed ff 48 c7 c6 cc a7 b4 81 48 8d bd 28 ff
ff ff 89 c2 e8 70 f1 ff ff 41 89 c2 85 c0 0f 84 72 f7 ff ff e9 b4 fe ff
ff <48> 8b 57 20 0f b7 02 66 25 00 f0 66 3d 00 8
0 0f 84 9c 01 00 00 44
[ 2.822014] RSP: 0000:ffffc9000029bcb8 EFLAGS: 00010246
[ 2.822339] RAX: 0000000000000000 RBX: ffff88803f860000 RCX: 000000000000000a
[ 2.822746] RDX: 0000000000000009 RSI: 0000000000000282 RDI: 0000000000000000
[ 2.823141] RBP: ffffc9000029bde8 R08: 0000000000000000 R09: ffffc9000029bc00
[ 2.823508] R10: 0000000000000001 R11: ffff88803dec90be R12: ffffffff81c39da0
[ 2.823902] R13: ffff88803de84400 R14: 0000000000000000 R15: 0000000000000000
[ 2.824285] FS: 00007fee08183540(0000) GS:ffff88803e480000(0000) knlGS:0000000000000000
[ 2.824767] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 2.825111] CR2: 0000000000000020 CR3: 000000003f856005 CR4: 0000000000060ea0
[ 2.825479] Call Trace:
[ 2.825790] get_signal+0x11e/0x720
[ 2.826087] do_signal+0x1d/0x670
[ 2.826361] ? force_sig_info_to_task+0xc1/0xf0
[ 2.826691] ? force_sig_fault+0x3c/0x40
[ 2.826996] ? do_trap+0xc9/0x100
[ 2.827179] exit_to_usermode_loop+0x49/0x90
[ 2.827359] prepare_exit_to_usermode+0x77/0xb0
[ 2.827559] ? invalid_op+0xa/0x30
[ 2.827747] ret_from_intr+0x20/0x20
[ 2.827921] RIP: 0033:0x55e2c76d2129
[ 2.828107] Code: 2d ff ff ff e8 68 ff ff ff 5d c6 05 18 2f 00 00 01
c3 0f 1f 80 00 00 00 00 c3 0f 1f 80 00 00 00 00 e9 7b ff ff ff 55 48 89
e5 <0f> 0b b8 00 00 00 00 5d c3 66 2e 0f 1f 84 0
0 00 00 00 00 0f 1f 40
[ 2.828603] RSP: 002b:00007fffeba5e080 EFLAGS: 00010246
[ 2.828801] RAX: 000055e2c76d2125 RBX: 0000000000000000 RCX: 00007fee0817c718
[ 2.829034] RDX: 00007fffeba5e188 RSI: 00007fffeba5e178 RDI: 0000000000000001
[ 2.829257] RBP: 00007fffeba5e080 R08: 0000000000000000 R09: 00007fee08193c00
[ 2.829482] R10: 0000000000000009 R11: 0000000000000000 R12: 000055e2c76d2040
[ 2.829727] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
[ 2.829964] CR2: 0000000000000020
[ 2.830149] ---[ end trace ceed83d8c68a1bf1 ]---
```
Cc: <stable(a)vger.kernel.org> # v4.11+
Fixes: 64e90a8acb85 ("Introduce STATIC_USERMODEHELPER to mediate call_usermodehelper()")
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=199795
Reported-by: Tony Vroon <chainsaw(a)gentoo.org>
Reported-by: Sergey Kvachonok <ravenexp(a)gmail.com>
Tested-by: Sergei Trofimovich <slyfox(a)gentoo.org>
Signed-off-by: Luis Chamberlain <mcgrof(a)kernel.org>
Link: https://lore.kernel.org/r/20200416162859.26518-1-mcgrof@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/coredump.c | 8 ++++++++
kernel/umh.c | 5 +++++
2 files changed, 13 insertions(+)
diff --git a/fs/coredump.c b/fs/coredump.c
index 408418e6aa13..478a0d810136 100644
--- a/fs/coredump.c
+++ b/fs/coredump.c
@@ -788,6 +788,14 @@ void do_coredump(const kernel_siginfo_t *siginfo)
if (displaced)
put_files_struct(displaced);
if (!dump_interrupted()) {
+ /*
+ * umh disabled with CONFIG_STATIC_USERMODEHELPER_PATH="" would
+ * have this set to NULL.
+ */
+ if (!cprm.file) {
+ pr_info("Core dump to |%s disabled\n", cn.corename);
+ goto close_fail;
+ }
file_start_write(cprm.file);
core_dumped = binfmt->core_dump(&cprm);
file_end_write(cprm.file);
diff --git a/kernel/umh.c b/kernel/umh.c
index 7f255b5a8845..11bf5eea474c 100644
--- a/kernel/umh.c
+++ b/kernel/umh.c
@@ -544,6 +544,11 @@ EXPORT_SYMBOL_GPL(fork_usermode_blob);
* Runs a user-space application. The application is started
* asynchronously if wait is not set, and runs as a child of system workqueues.
* (ie. it runs with full root capabilities and optimized affinity).
+ *
+ * Note: successful return value does not guarantee the helper was called at
+ * all. You can't rely on sub_info->{init,cleanup} being called even for
+ * UMH_WAIT_* wait modes as STATIC_USERMODEHELPER_PATH="" turns all helpers
+ * into a successful no-op.
*/
int call_usermodehelper_exec(struct subprocess_info *sub_info, int wait)
{
--
2.26.2
Fix a use-after-free noticed by running with KASAN enabled. If
rmi_irq_fn() is run twice in a row, then rmi_f11_attention() (among
others) will end up reading from drvdata->attn_data.data, which was
freed and left dangling in rmi_irq_fn().
Commit 55edde9fff1a ("Input: synaptics-rmi4 - prevent UAF reported by
KASAN") correctly identified and analyzed this bug. However the attempted
fix only NULLed out a local variable, missing the fact that
drvdata->attn_data is a struct, not a pointer.
NULL out the correct pointer in the driver data to prevent the attention
functions from copying from it.
Fixes: 55edde9fff1a ("Input: synaptics-rmi4 - prevent UAF reported by KASAN")
Fixes: b908d3cd812a ("Input: synaptics-rmi4 - allow to add attention data")
Signed-off-by: Evan Green <evgreen(a)chromium.org>
Cc: stable(a)vger.kernel.org
Cc: Nick Desaulniers <nick.desaulniers(a)gmail.com>
---
drivers/input/rmi4/rmi_driver.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/input/rmi4/rmi_driver.c b/drivers/input/rmi4/rmi_driver.c
index 190b9974526bb..c18e1a25bca6e 100644
--- a/drivers/input/rmi4/rmi_driver.c
+++ b/drivers/input/rmi4/rmi_driver.c
@@ -205,7 +205,7 @@ static irqreturn_t rmi_irq_fn(int irq, void *dev_id)
if (count) {
kfree(attn_data.data);
- attn_data.data = NULL;
+ drvdata->attn_data.data = NULL;
}
if (!kfifo_is_empty(&drvdata->attn_fifo))
--
2.24.1
This is a note to let you know that I've just added the patch titled
amba: Initialize dma_parms for amba devices
to my driver-core git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git
in the driver-core-linus branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will hopefully also be merged in Linus's tree for the
next -rc kernel release.
If you have any questions about this process, please let me know.
>From f458488425f1cc9a396aa1d09bb00c48783936da Mon Sep 17 00:00:00 2001
From: Ulf Hansson <ulf.hansson(a)linaro.org>
Date: Wed, 22 Apr 2020 12:10:13 +0200
Subject: amba: Initialize dma_parms for amba devices
It's currently the amba driver's responsibility to initialize the pointer,
dma_parms, for its corresponding struct device. The benefit with this
approach allows us to avoid the initialization and to not waste memory for
the struct device_dma_parameters, as this can be decided on a case by case
basis.
However, it has turned out that this approach is not very practical. Not
only does it lead to open coding, but also to real errors. In principle
callers of dma_set_max_seg_size() doesn't check the error code, but just
assumes it succeeds.
For these reasons, let's do the initialization from the common amba bus at
the device registration point. This also follows the way the PCI devices
are being managed, see pci_device_add().
Suggested-by: Christoph Hellwig <hch(a)lst.de>
Cc: Russell King <linux(a)armlinux.org.uk>
Cc: <stable(a)vger.kernel.org>
Tested-by: Haibo Chen <haibo.chen(a)nxp.com>
Reviewed-by: Arnd Bergmann <arnd(a)arndb.de>
Signed-off-by: Ulf Hansson <ulf.hansson(a)linaro.org>
Reviewed-by: Christoph Hellwig <hch(a)lst.de>
Link: https://lore.kernel.org/r/20200422101013.31267-1-ulf.hansson@linaro.org
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/amba/bus.c | 1 +
include/linux/amba/bus.h | 1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/amba/bus.c b/drivers/amba/bus.c
index fe1523664816..8558b629880b 100644
--- a/drivers/amba/bus.c
+++ b/drivers/amba/bus.c
@@ -645,6 +645,7 @@ static void amba_device_initialize(struct amba_device *dev, const char *name)
dev->dev.release = amba_device_release;
dev->dev.bus = &amba_bustype;
dev->dev.dma_mask = &dev->dev.coherent_dma_mask;
+ dev->dev.dma_parms = &dev->dma_parms;
dev->res.name = dev_name(&dev->dev);
}
diff --git a/include/linux/amba/bus.h b/include/linux/amba/bus.h
index 26f0ecf401ea..0bbfd647f5c6 100644
--- a/include/linux/amba/bus.h
+++ b/include/linux/amba/bus.h
@@ -65,6 +65,7 @@ struct amba_device {
struct device dev;
struct resource res;
struct clk *pclk;
+ struct device_dma_parameters dma_parms;
unsigned int periphid;
unsigned int cid;
struct amba_cs_uci_id uci;
--
2.26.2
This is a note to let you know that I've just added the patch titled
driver core: platform: Initialize dma_parms for platform devices
to my driver-core git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git
in the driver-core-linus branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will hopefully also be merged in Linus's tree for the
next -rc kernel release.
If you have any questions about this process, please let me know.
>From 9495b7e92f716ab2bd6814fab5e97ab4a39adfdd Mon Sep 17 00:00:00 2001
From: Ulf Hansson <ulf.hansson(a)linaro.org>
Date: Wed, 22 Apr 2020 12:09:54 +0200
Subject: driver core: platform: Initialize dma_parms for platform devices
It's currently the platform driver's responsibility to initialize the
pointer, dma_parms, for its corresponding struct device. The benefit with
this approach allows us to avoid the initialization and to not waste memory
for the struct device_dma_parameters, as this can be decided on a case by
case basis.
However, it has turned out that this approach is not very practical. Not
only does it lead to open coding, but also to real errors. In principle
callers of dma_set_max_seg_size() doesn't check the error code, but just
assumes it succeeds.
For these reasons, let's do the initialization from the common platform bus
at the device registration point. This also follows the way the PCI devices
are being managed, see pci_device_add().
Suggested-by: Christoph Hellwig <hch(a)lst.de>
Cc: <stable(a)vger.kernel.org>
Tested-by: Haibo Chen <haibo.chen(a)nxp.com>
Reviewed-by: Arnd Bergmann <arnd(a)arndb.de>
Signed-off-by: Ulf Hansson <ulf.hansson(a)linaro.org>
Reviewed-by: Christoph Hellwig <hch(a)lst.de>
Link: https://lore.kernel.org/r/20200422100954.31211-1-ulf.hansson@linaro.org
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/base/platform.c | 2 ++
include/linux/platform_device.h | 1 +
2 files changed, 3 insertions(+)
diff --git a/drivers/base/platform.c b/drivers/base/platform.c
index 5255550b7c34..b27d0f6c18c9 100644
--- a/drivers/base/platform.c
+++ b/drivers/base/platform.c
@@ -380,6 +380,8 @@ struct platform_object {
*/
static void setup_pdev_dma_masks(struct platform_device *pdev)
{
+ pdev->dev.dma_parms = &pdev->dma_parms;
+
if (!pdev->dev.coherent_dma_mask)
pdev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
if (!pdev->dev.dma_mask) {
diff --git a/include/linux/platform_device.h b/include/linux/platform_device.h
index bdc35753ef7c..77a2aada106d 100644
--- a/include/linux/platform_device.h
+++ b/include/linux/platform_device.h
@@ -25,6 +25,7 @@ struct platform_device {
bool id_auto;
struct device dev;
u64 platform_dma_mask;
+ struct device_dma_parameters dma_parms;
u32 num_resources;
struct resource *resource;
--
2.26.2