From: Greg Kroah-Hartman Date: Mon, 7 Oct 2024 17:00:23 +0000 (+0200) Subject: 4.19-stable patches X-Git-Tag: v6.6.55~79 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=c1ffafa928cfedf0c9f37c1645432f382e6fd65d;p=thirdparty%2Fkernel%2Fstable-queue.git 4.19-stable patches added patches: aoe-fix-the-potential-use-after-free-problem-in-more-places.patch clk-rockchip-fix-error-for-unknown-clocks.patch iio-magnetometer-ak8975-fix-reading-for-ak099xx-sensors.patch input-adp5589-keys-fix-adp5589_gpio_get_value.patch media-uapi-linux-cec.h-cec_msg_set_reply_to-zero-flags.patch media-venus-fix-use-after-free-bug-in-venus_remove-due-to-race-condition.patch tomoyo-fallback-to-realpath-if-symlink-s-pathname-does-not-exist.patch --- diff --git a/queue-4.19/aoe-fix-the-potential-use-after-free-problem-in-more-places.patch b/queue-4.19/aoe-fix-the-potential-use-after-free-problem-in-more-places.patch new file mode 100644 index 00000000000..de9444be98d --- /dev/null +++ b/queue-4.19/aoe-fix-the-potential-use-after-free-problem-in-more-places.patch @@ -0,0 +1,98 @@ +From 6d6e54fc71ad1ab0a87047fd9c211e75d86084a3 Mon Sep 17 00:00:00 2001 +From: Chun-Yi Lee +Date: Wed, 2 Oct 2024 11:54:58 +0800 +Subject: aoe: fix the potential use-after-free problem in more places + +From: Chun-Yi Lee + +commit 6d6e54fc71ad1ab0a87047fd9c211e75d86084a3 upstream. + +For fixing CVE-2023-6270, f98364e92662 ("aoe: fix the potential +use-after-free problem in aoecmd_cfg_pkts") makes tx() calling dev_put() +instead of doing in aoecmd_cfg_pkts(). It avoids that the tx() runs +into use-after-free. + +Then Nicolai Stange found more places in aoe have potential use-after-free +problem with tx(). e.g. revalidate(), aoecmd_ata_rw(), resend(), probe() +and aoecmd_cfg_rsp(). Those functions also use aoenet_xmit() to push +packet to tx queue. So they should also use dev_hold() to increase the +refcnt of skb->dev. + +On the other hand, moving dev_put() to tx() causes that the refcnt of +skb->dev be reduced to a negative value, because corresponding +dev_hold() are not called in revalidate(), aoecmd_ata_rw(), resend(), +probe(), and aoecmd_cfg_rsp(). This patch fixed this issue. + +Cc: stable@vger.kernel.org +Link: https://nvd.nist.gov/vuln/detail/CVE-2023-6270 +Fixes: f98364e92662 ("aoe: fix the potential use-after-free problem in aoecmd_cfg_pkts") +Reported-by: Nicolai Stange +Signed-off-by: Chun-Yi Lee +Link: https://lore.kernel.org/stable/20240624064418.27043-1-jlee%40suse.com +Link: https://lore.kernel.org/r/20241002035458.24401-1-jlee@suse.com +Signed-off-by: Jens Axboe +Signed-off-by: Greg Kroah-Hartman +--- + drivers/block/aoe/aoecmd.c | 13 ++++++++++++- + 1 file changed, 12 insertions(+), 1 deletion(-) + +--- a/drivers/block/aoe/aoecmd.c ++++ b/drivers/block/aoe/aoecmd.c +@@ -362,6 +362,7 @@ ata_rw_frameinit(struct frame *f) + } + + ah->cmdstat = ATA_CMD_PIO_READ | writebit | extbit; ++ dev_hold(t->ifp->nd); + skb->dev = t->ifp->nd; + } + +@@ -402,6 +403,8 @@ aoecmd_ata_rw(struct aoedev *d) + __skb_queue_head_init(&queue); + __skb_queue_tail(&queue, skb); + aoenet_xmit(&queue); ++ } else { ++ dev_put(f->t->ifp->nd); + } + return 1; + } +@@ -484,10 +487,13 @@ resend(struct aoedev *d, struct frame *f + memcpy(h->dst, t->addr, sizeof h->dst); + memcpy(h->src, t->ifp->nd->dev_addr, sizeof h->src); + ++ dev_hold(t->ifp->nd); + skb->dev = t->ifp->nd; + skb = skb_clone(skb, GFP_ATOMIC); +- if (skb == NULL) ++ if (skb == NULL) { ++ dev_put(t->ifp->nd); + return; ++ } + f->sent = ktime_get(); + __skb_queue_head_init(&queue); + __skb_queue_tail(&queue, skb); +@@ -618,6 +624,8 @@ probe(struct aoetgt *t) + __skb_queue_head_init(&queue); + __skb_queue_tail(&queue, skb); + aoenet_xmit(&queue); ++ } else { ++ dev_put(f->t->ifp->nd); + } + } + +@@ -1407,6 +1415,7 @@ aoecmd_ata_id(struct aoedev *d) + ah->cmdstat = ATA_CMD_ID_ATA; + ah->lba3 = 0xa0; + ++ dev_hold(t->ifp->nd); + skb->dev = t->ifp->nd; + + d->rttavg = RTTAVG_INIT; +@@ -1416,6 +1425,8 @@ aoecmd_ata_id(struct aoedev *d) + skb = skb_clone(skb, GFP_ATOMIC); + if (skb) + f->sent = ktime_get(); ++ else ++ dev_put(t->ifp->nd); + + return skb; + } diff --git a/queue-4.19/clk-rockchip-fix-error-for-unknown-clocks.patch b/queue-4.19/clk-rockchip-fix-error-for-unknown-clocks.patch new file mode 100644 index 00000000000..eab12e60ced --- /dev/null +++ b/queue-4.19/clk-rockchip-fix-error-for-unknown-clocks.patch @@ -0,0 +1,43 @@ +From 12fd64babaca4dc09d072f63eda76ba44119816a Mon Sep 17 00:00:00 2001 +From: Sebastian Reichel +Date: Mon, 25 Mar 2024 20:33:36 +0100 +Subject: clk: rockchip: fix error for unknown clocks + +From: Sebastian Reichel + +commit 12fd64babaca4dc09d072f63eda76ba44119816a upstream. + +There is a clk == NULL check after the switch to check for +unsupported clk types. Since clk is re-assigned in a loop, +this check is useless right now for anything but the first +round. Let's fix this up by assigning clk = NULL in the +loop before the switch statement. + +Fixes: a245fecbb806 ("clk: rockchip: add basic infrastructure for clock branches") +Cc: stable@vger.kernel.org +Signed-off-by: Sebastian Reichel +[added fixes + stable-cc] +Link: https://lore.kernel.org/r/20240325193609.237182-6-sebastian.reichel@collabora.com +Signed-off-by: Heiko Stuebner +Signed-off-by: Greg Kroah-Hartman +--- + drivers/clk/rockchip/clk.c | 3 ++- + 1 file changed, 2 insertions(+), 1 deletion(-) + +--- a/drivers/clk/rockchip/clk.c ++++ b/drivers/clk/rockchip/clk.c +@@ -444,12 +444,13 @@ void __init rockchip_clk_register_branch + struct rockchip_clk_branch *list, + unsigned int nr_clk) + { +- struct clk *clk = NULL; ++ struct clk *clk; + unsigned int idx; + unsigned long flags; + + for (idx = 0; idx < nr_clk; idx++, list++) { + flags = list->flags; ++ clk = NULL; + + /* catch simple muxes */ + switch (list->branch_type) { diff --git a/queue-4.19/iio-magnetometer-ak8975-fix-reading-for-ak099xx-sensors.patch b/queue-4.19/iio-magnetometer-ak8975-fix-reading-for-ak099xx-sensors.patch new file mode 100644 index 00000000000..d7125a92b4f --- /dev/null +++ b/queue-4.19/iio-magnetometer-ak8975-fix-reading-for-ak099xx-sensors.patch @@ -0,0 +1,78 @@ +From 129464e86c7445a858b790ac2d28d35f58256bbe Mon Sep 17 00:00:00 2001 +From: =?UTF-8?q?Barnab=C3=A1s=20Cz=C3=A9m=C3=A1n?= + +Date: Mon, 19 Aug 2024 00:29:40 +0200 +Subject: iio: magnetometer: ak8975: Fix reading for ak099xx sensors +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Barnabás Czémán + +commit 129464e86c7445a858b790ac2d28d35f58256bbe upstream. + +Move ST2 reading with overflow handling after measurement data +reading. +ST2 register read have to be read after read measurment data, +because it means end of the reading and realease the lock on the data. +Remove ST2 read skip on interrupt based waiting because ST2 required to +be read out at and of the axis read. + +Fixes: 57e73a423b1e ("iio: ak8975: add ak09911 and ak09912 support") +Signed-off-by: Barnabás Czémán +Link: https://patch.msgid.link/20240819-ak09918-v4-2-f0734d14cfb9@mainlining.org +Cc: +Signed-off-by: Jonathan Cameron +Signed-off-by: Greg Kroah-Hartman +--- + drivers/iio/magnetometer/ak8975.c | 32 ++++++++++++++++---------------- + 1 file changed, 16 insertions(+), 16 deletions(-) + +--- a/drivers/iio/magnetometer/ak8975.c ++++ b/drivers/iio/magnetometer/ak8975.c +@@ -673,22 +673,8 @@ static int ak8975_start_read_axis(struct + if (ret < 0) + return ret; + +- /* This will be executed only for non-interrupt based waiting case */ +- if (ret & data->def->ctrl_masks[ST1_DRDY]) { +- ret = i2c_smbus_read_byte_data(client, +- data->def->ctrl_regs[ST2]); +- if (ret < 0) { +- dev_err(&client->dev, "Error in reading ST2\n"); +- return ret; +- } +- if (ret & (data->def->ctrl_masks[ST2_DERR] | +- data->def->ctrl_masks[ST2_HOFL])) { +- dev_err(&client->dev, "ST2 status error 0x%x\n", ret); +- return -EINVAL; +- } +- } +- +- return 0; ++ /* Return with zero if the data is ready. */ ++ return !data->def->ctrl_regs[ST1_DRDY]; + } + + /* Retrieve raw flux value for one of the x, y, or z axis. */ +@@ -715,6 +701,20 @@ static int ak8975_read_axis(struct iio_d + if (ret < 0) + goto exit; + ++ /* Read out ST2 for release lock on measurment data. */ ++ ret = i2c_smbus_read_byte_data(client, data->def->ctrl_regs[ST2]); ++ if (ret < 0) { ++ dev_err(&client->dev, "Error in reading ST2\n"); ++ goto exit; ++ } ++ ++ if (ret & (data->def->ctrl_masks[ST2_DERR] | ++ data->def->ctrl_masks[ST2_HOFL])) { ++ dev_err(&client->dev, "ST2 status error 0x%x\n", ret); ++ ret = -EINVAL; ++ goto exit; ++ } ++ + mutex_unlock(&data->lock); + + pm_runtime_mark_last_busy(&data->client->dev); diff --git a/queue-4.19/input-adp5589-keys-fix-adp5589_gpio_get_value.patch b/queue-4.19/input-adp5589-keys-fix-adp5589_gpio_get_value.patch new file mode 100644 index 00000000000..0a6e6da4359 --- /dev/null +++ b/queue-4.19/input-adp5589-keys-fix-adp5589_gpio_get_value.patch @@ -0,0 +1,49 @@ +From c684771630e64bc39bddffeb65dd8a6612a6b249 Mon Sep 17 00:00:00 2001 +From: Nuno Sa +Date: Tue, 1 Oct 2024 07:47:23 -0700 +Subject: Input: adp5589-keys - fix adp5589_gpio_get_value() + +From: Nuno Sa + +commit c684771630e64bc39bddffeb65dd8a6612a6b249 upstream. + +The adp5589 seems to have the same behavior as similar devices as +explained in commit 910a9f5636f5 ("Input: adp5588-keys - get value from +data out when dir is out"). + +Basically, when the gpio is set as output we need to get the value from +ADP5589_GPO_DATA_OUT_A register instead of ADP5589_GPI_STATUS_A. + +Fixes: 9d2e173644bb ("Input: ADP5589 - new driver for I2C Keypad Decoder and I/O Expander") +Signed-off-by: Nuno Sa +Link: https://lore.kernel.org/r/20241001-b4-dev-adp5589-fw-conversion-v1-2-fca0149dfc47@analog.com +Cc: stable@vger.kernel.org +Signed-off-by: Dmitry Torokhov +Signed-off-by: Greg Kroah-Hartman +--- + drivers/input/keyboard/adp5589-keys.c | 13 ++++++++++--- + 1 file changed, 10 insertions(+), 3 deletions(-) + +--- a/drivers/input/keyboard/adp5589-keys.c ++++ b/drivers/input/keyboard/adp5589-keys.c +@@ -390,10 +390,17 @@ static int adp5589_gpio_get_value(struct + struct adp5589_kpad *kpad = gpiochip_get_data(chip); + unsigned int bank = kpad->var->bank(kpad->gpiomap[off]); + unsigned int bit = kpad->var->bit(kpad->gpiomap[off]); ++ int val; + +- return !!(adp5589_read(kpad->client, +- kpad->var->reg(ADP5589_GPI_STATUS_A) + bank) & +- bit); ++ mutex_lock(&kpad->gpio_lock); ++ if (kpad->dir[bank] & bit) ++ val = kpad->dat_out[bank]; ++ else ++ val = adp5589_read(kpad->client, ++ kpad->var->reg(ADP5589_GPI_STATUS_A) + bank); ++ mutex_unlock(&kpad->gpio_lock); ++ ++ return !!(val & bit); + } + + static void adp5589_gpio_set_value(struct gpio_chip *chip, diff --git a/queue-4.19/media-uapi-linux-cec.h-cec_msg_set_reply_to-zero-flags.patch b/queue-4.19/media-uapi-linux-cec.h-cec_msg_set_reply_to-zero-flags.patch new file mode 100644 index 00000000000..eefe46a1a88 --- /dev/null +++ b/queue-4.19/media-uapi-linux-cec.h-cec_msg_set_reply_to-zero-flags.patch @@ -0,0 +1,44 @@ +From 599f6899051cb70c4e0aa9fd591b9ee220cb6f14 Mon Sep 17 00:00:00 2001 +From: Hans Verkuil +Date: Wed, 7 Aug 2024 09:22:10 +0200 +Subject: media: uapi/linux/cec.h: cec_msg_set_reply_to: zero flags + +From: Hans Verkuil + +commit 599f6899051cb70c4e0aa9fd591b9ee220cb6f14 upstream. + +The cec_msg_set_reply_to() helper function never zeroed the +struct cec_msg flags field, this can cause unexpected behavior +if flags was uninitialized to begin with. + +Signed-off-by: Hans Verkuil +Fixes: 0dbacebede1e ("[media] cec: move the CEC framework out of staging and to media") +Cc: +Signed-off-by: Mauro Carvalho Chehab +Signed-off-by: Greg Kroah-Hartman +--- + include/uapi/linux/cec.h | 6 +++++- + 1 file changed, 5 insertions(+), 1 deletion(-) + +--- a/include/uapi/linux/cec.h ++++ b/include/uapi/linux/cec.h +@@ -132,6 +132,8 @@ static inline void cec_msg_init(struct c + * Set the msg destination to the orig initiator and the msg initiator to the + * orig destination. Note that msg and orig may be the same pointer, in which + * case the change is done in place. ++ * ++ * It also zeroes the reply, timeout and flags fields. + */ + static inline void cec_msg_set_reply_to(struct cec_msg *msg, + struct cec_msg *orig) +@@ -139,7 +141,9 @@ static inline void cec_msg_set_reply_to( + /* The destination becomes the initiator and vice versa */ + msg->msg[0] = (cec_msg_destination(orig) << 4) | + cec_msg_initiator(orig); +- msg->reply = msg->timeout = 0; ++ msg->reply = 0; ++ msg->timeout = 0; ++ msg->flags = 0; + } + + /* cec_msg flags field */ diff --git a/queue-4.19/media-venus-fix-use-after-free-bug-in-venus_remove-due-to-race-condition.patch b/queue-4.19/media-venus-fix-use-after-free-bug-in-venus_remove-due-to-race-condition.patch new file mode 100644 index 00000000000..80e1dc9a251 --- /dev/null +++ b/queue-4.19/media-venus-fix-use-after-free-bug-in-venus_remove-due-to-race-condition.patch @@ -0,0 +1,50 @@ +From c5a85ed88e043474161bbfe54002c89c1cb50ee2 Mon Sep 17 00:00:00 2001 +From: Zheng Wang +Date: Tue, 18 Jun 2024 14:55:59 +0530 +Subject: media: venus: fix use after free bug in venus_remove due to race condition + +From: Zheng Wang + +commit c5a85ed88e043474161bbfe54002c89c1cb50ee2 upstream. + +in venus_probe, core->work is bound with venus_sys_error_handler, which is +used to handle error. The code use core->sys_err_done to make sync work. +The core->work is started in venus_event_notify. + +If we call venus_remove, there might be an unfished work. The possible +sequence is as follows: + +CPU0 CPU1 + + |venus_sys_error_handler +venus_remove | +hfi_destroy | +venus_hfi_destroy | +kfree(hdev); | + |hfi_reinit + |venus_hfi_queues_reinit + |//use hdev + +Fix it by canceling the work in venus_remove. + +Cc: stable@vger.kernel.org +Fixes: af2c3834c8ca ("[media] media: venus: adding core part and helper functions") +Signed-off-by: Zheng Wang +Signed-off-by: Dikshita Agarwal +Signed-off-by: Stanimir Varbanov +Signed-off-by: Hans Verkuil +Signed-off-by: Greg Kroah-Hartman +--- + drivers/media/platform/qcom/venus/core.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/drivers/media/platform/qcom/venus/core.c ++++ b/drivers/media/platform/qcom/venus/core.c +@@ -348,6 +348,7 @@ static int venus_remove(struct platform_ + struct device *dev = core->dev; + int ret; + ++ cancel_delayed_work_sync(&core->work); + ret = pm_runtime_get_sync(dev); + WARN_ON(ret < 0); + diff --git a/queue-4.19/series b/queue-4.19/series index ce0e2e450f0..34f1516d487 100644 --- a/queue-4.19/series +++ b/queue-4.19/series @@ -203,3 +203,10 @@ ocfs2-remove-unreasonable-unlock-in-ocfs2_read_blocks.patch ocfs2-fix-null-ptr-deref-when-journal-load-failed.patch ocfs2-fix-possible-null-ptr-deref-in-ocfs2_set_buffer_uptodate.patch riscv-define-illegal_pointer_value-for-64bit.patch +aoe-fix-the-potential-use-after-free-problem-in-more-places.patch +clk-rockchip-fix-error-for-unknown-clocks.patch +media-uapi-linux-cec.h-cec_msg_set_reply_to-zero-flags.patch +media-venus-fix-use-after-free-bug-in-venus_remove-due-to-race-condition.patch +iio-magnetometer-ak8975-fix-reading-for-ak099xx-sensors.patch +tomoyo-fallback-to-realpath-if-symlink-s-pathname-does-not-exist.patch +input-adp5589-keys-fix-adp5589_gpio_get_value.patch diff --git a/queue-4.19/tomoyo-fallback-to-realpath-if-symlink-s-pathname-does-not-exist.patch b/queue-4.19/tomoyo-fallback-to-realpath-if-symlink-s-pathname-does-not-exist.patch new file mode 100644 index 00000000000..05021b67b5e --- /dev/null +++ b/queue-4.19/tomoyo-fallback-to-realpath-if-symlink-s-pathname-does-not-exist.patch @@ -0,0 +1,52 @@ +From ada1986d07976d60bed5017aa38b7f7cf27883f7 Mon Sep 17 00:00:00 2001 +From: Tetsuo Handa +Date: Wed, 25 Sep 2024 22:30:59 +0900 +Subject: tomoyo: fallback to realpath if symlink's pathname does not exist + +From: Tetsuo Handa + +commit ada1986d07976d60bed5017aa38b7f7cf27883f7 upstream. + +Alfred Agrell found that TOMOYO cannot handle execveat(AT_EMPTY_PATH) +inside chroot environment where /dev and /proc are not mounted, for +commit 51f39a1f0cea ("syscalls: implement execveat() system call") missed +that TOMOYO tries to canonicalize argv[0] when the filename fed to the +executed program as argv[0] is supplied using potentially nonexistent +pathname. + +Since "/dev/fd/" already lost symlink information used for obtaining +that , it is too late to reconstruct symlink's pathname. Although + part of "/dev/fd//" might not be canonicalized, +TOMOYO cannot use tomoyo_realpath_nofollow() when /dev or /proc is not +mounted. Therefore, fallback to tomoyo_realpath_from_path() when +tomoyo_realpath_nofollow() failed. + +Reported-by: Alfred Agrell +Closes: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1082001 +Fixes: 51f39a1f0cea ("syscalls: implement execveat() system call") +Cc: stable@vger.kernel.org # v3.19+ +Signed-off-by: Tetsuo Handa +Signed-off-by: Greg Kroah-Hartman +--- + security/tomoyo/domain.c | 9 ++++++--- + 1 file changed, 6 insertions(+), 3 deletions(-) + +--- a/security/tomoyo/domain.c ++++ b/security/tomoyo/domain.c +@@ -701,10 +701,13 @@ int tomoyo_find_next_domain(struct linux + ee->r.obj = &ee->obj; + ee->obj.path1 = bprm->file->f_path; + /* Get symlink's pathname of program. */ +- retval = -ENOENT; + exename.name = tomoyo_realpath_nofollow(original_name); +- if (!exename.name) +- goto out; ++ if (!exename.name) { ++ /* Fallback to realpath if symlink's pathname does not exist. */ ++ exename.name = tomoyo_realpath_from_path(&bprm->file->f_path); ++ if (!exename.name) ++ goto out; ++ } + tomoyo_fill_path_info(&exename); + retry: + /* Check 'aggregator' directive. */