From: Sasha Levin Date: Sat, 7 Oct 2023 12:16:02 +0000 (-0400) Subject: Fixes for 4.14 X-Git-Tag: v4.14.327~53^2~1 X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=2040f93c79e3a1632166c4fa025f0a269db50410;p=thirdparty%2Fkernel%2Fstable-queue.git Fixes for 4.14 Signed-off-by: Sasha Levin --- diff --git a/queue-4.14/drivers-net-process-the-result-of-hdlc_open-and-add-.patch b/queue-4.14/drivers-net-process-the-result-of-hdlc_open-and-add-.patch new file mode 100644 index 00000000000..938aaf8f550 --- /dev/null +++ b/queue-4.14/drivers-net-process-the-result-of-hdlc_open-and-add-.patch @@ -0,0 +1,78 @@ +From 1c12931ac4252a67c92d3c8243a0e147c1c955d8 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Tue, 19 Sep 2023 17:25:02 +0300 +Subject: drivers/net: process the result of hdlc_open() and add call of + hdlc_close() in uhdlc_close() + +From: Alexandra Diupina + +[ Upstream commit a59addacf899b1b21a7b7449a1c52c98704c2472 ] + +Process the result of hdlc_open() and call uhdlc_close() +in case of an error. It is necessary to pass the error +code up the control flow, similar to a possible +error in request_irq(). +Also add a hdlc_close() call to the uhdlc_close() +because the comment to hdlc_close() says it must be called +by the hardware driver when the HDLC device is being closed + +Found by Linux Verification Center (linuxtesting.org) with SVACE. + +Fixes: c19b6d246a35 ("drivers/net: support hdlc function for QE-UCC") +Signed-off-by: Alexandra Diupina +Reviewed-by: Christophe Leroy +Signed-off-by: David S. Miller +Signed-off-by: Sasha Levin +--- + drivers/net/wan/fsl_ucc_hdlc.c | 12 ++++++++++-- + 1 file changed, 10 insertions(+), 2 deletions(-) + +diff --git a/drivers/net/wan/fsl_ucc_hdlc.c b/drivers/net/wan/fsl_ucc_hdlc.c +index 978f642dacedd..00cc9b755a852 100644 +--- a/drivers/net/wan/fsl_ucc_hdlc.c ++++ b/drivers/net/wan/fsl_ucc_hdlc.c +@@ -37,6 +37,8 @@ + + #define TDM_PPPOHT_SLIC_MAXIN + ++static int uhdlc_close(struct net_device *dev); ++ + static struct ucc_tdm_info utdm_primary_info = { + .uf_info = { + .tsa = 0, +@@ -662,6 +664,7 @@ static int uhdlc_open(struct net_device *dev) + hdlc_device *hdlc = dev_to_hdlc(dev); + struct ucc_hdlc_private *priv = hdlc->priv; + struct ucc_tdm *utdm = priv->utdm; ++ int rc = 0; + + if (priv->hdlc_busy != 1) { + if (request_irq(priv->ut_info->uf_info.irq, +@@ -684,10 +687,13 @@ static int uhdlc_open(struct net_device *dev) + netif_device_attach(priv->ndev); + napi_enable(&priv->napi); + netif_start_queue(dev); +- hdlc_open(dev); ++ ++ rc = hdlc_open(dev); ++ if (rc) ++ uhdlc_close(dev); + } + +- return 0; ++ return rc; + } + + static void uhdlc_memclean(struct ucc_hdlc_private *priv) +@@ -776,6 +782,8 @@ static int uhdlc_close(struct net_device *dev) + netif_stop_queue(dev); + priv->hdlc_busy = 0; + ++ hdlc_close(dev); ++ + return 0; + } + +-- +2.40.1 + diff --git a/queue-4.14/ipv4-ipv6-fix-handling-of-transhdrlen-in-__ip-6-_app.patch b/queue-4.14/ipv4-ipv6-fix-handling-of-transhdrlen-in-__ip-6-_app.patch new file mode 100644 index 00000000000..13c0afbb9a1 --- /dev/null +++ b/queue-4.14/ipv4-ipv6-fix-handling-of-transhdrlen-in-__ip-6-_app.patch @@ -0,0 +1,81 @@ +From d0e8c9c440845694199e82617ec2a4b242e7f188 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 21 Sep 2023 11:41:19 +0100 +Subject: ipv4, ipv6: Fix handling of transhdrlen in __ip{,6}_append_data() + +From: David Howells + +[ Upstream commit 9d4c75800f61e5d75c1659ba201b6c0c7ead3070 ] + +Including the transhdrlen in length is a problem when the packet is +partially filled (e.g. something like send(MSG_MORE) happened previously) +when appending to an IPv4 or IPv6 packet as we don't want to repeat the +transport header or account for it twice. This can happen under some +circumstances, such as splicing into an L2TP socket. + +The symptom observed is a warning in __ip6_append_data(): + + WARNING: CPU: 1 PID: 5042 at net/ipv6/ip6_output.c:1800 __ip6_append_data.isra.0+0x1be8/0x47f0 net/ipv6/ip6_output.c:1800 + +that occurs when MSG_SPLICE_PAGES is used to append more data to an already +partially occupied skbuff. The warning occurs when 'copy' is larger than +the amount of data in the message iterator. This is because the requested +length includes the transport header length when it shouldn't. This can be +triggered by, for example: + + sfd = socket(AF_INET6, SOCK_DGRAM, IPPROTO_L2TP); + bind(sfd, ...); // ::1 + connect(sfd, ...); // ::1 port 7 + send(sfd, buffer, 4100, MSG_MORE); + sendfile(sfd, dfd, NULL, 1024); + +Fix this by only adding transhdrlen into the length if the write queue is +empty in l2tp_ip6_sendmsg(), analogously to how UDP does things. + +l2tp_ip_sendmsg() looks like it won't suffer from this problem as it builds +the UDP packet itself. + +Fixes: a32e0eec7042 ("l2tp: introduce L2TPv3 IP encapsulation support for IPv6") +Reported-by: syzbot+62cbf263225ae13ff153@syzkaller.appspotmail.com +Link: https://lore.kernel.org/r/0000000000001c12b30605378ce8@google.com/ +Suggested-by: Willem de Bruijn +Signed-off-by: David Howells +cc: Eric Dumazet +cc: Willem de Bruijn +cc: "David S. Miller" +cc: David Ahern +cc: Paolo Abeni +cc: Jakub Kicinski +cc: netdev@vger.kernel.org +cc: bpf@vger.kernel.org +cc: syzkaller-bugs@googlegroups.com +Reviewed-by: Eric Dumazet +Signed-off-by: David S. Miller +Signed-off-by: Sasha Levin +--- + net/l2tp/l2tp_ip6.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/net/l2tp/l2tp_ip6.c b/net/l2tp/l2tp_ip6.c +index a241ead3dd921..d797708a1a5ef 100644 +--- a/net/l2tp/l2tp_ip6.c ++++ b/net/l2tp/l2tp_ip6.c +@@ -532,7 +532,6 @@ static int l2tp_ip6_sendmsg(struct sock *sk, struct msghdr *msg, size_t len) + */ + if (len > INT_MAX - transhdrlen) + return -EMSGSIZE; +- ulen = len + transhdrlen; + + /* Mirror BSD error message compatibility */ + if (msg->msg_flags & MSG_OOB) +@@ -659,6 +658,7 @@ static int l2tp_ip6_sendmsg(struct sock *sk, struct msghdr *msg, size_t len) + + back_from_confirm: + lock_sock(sk); ++ ulen = len + skb_queue_empty(&sk->sk_write_queue) ? transhdrlen : 0; + err = ip6_append_data(sk, ip_generic_getfrag, msg, + ulen, transhdrlen, &ipc6, + &fl6, (struct rt6_info *)dst, +-- +2.40.1 + diff --git a/queue-4.14/modpost-add-missing-else-to-the-of-check.patch b/queue-4.14/modpost-add-missing-else-to-the-of-check.patch new file mode 100644 index 00000000000..0dc03b01a06 --- /dev/null +++ b/queue-4.14/modpost-add-missing-else-to-the-of-check.patch @@ -0,0 +1,54 @@ +From 813fb4d190225c91212bc4a1c1c4371220627736 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 28 Sep 2023 17:28:07 -0300 +Subject: modpost: add missing else to the "of" check + +From: Mauricio Faria de Oliveira + +[ Upstream commit cbc3d00cf88fda95dbcafee3b38655b7a8f2650a ] + +Without this 'else' statement, an "usb" name goes into two handlers: +the first/previous 'if' statement _AND_ the for-loop over 'devtable', +but the latter is useless as it has no 'usb' device_id entry anyway. + +Tested with allmodconfig before/after patch; no changes to *.mod.c: + + git checkout v6.6-rc3 + make -j$(nproc) allmodconfig + make -j$(nproc) olddefconfig + + make -j$(nproc) + find . -name '*.mod.c' | cpio -pd /tmp/before + + # apply patch + + make -j$(nproc) + find . -name '*.mod.c' | cpio -pd /tmp/after + + diff -r /tmp/before/ /tmp/after/ + # no difference + +Fixes: acbef7b76629 ("modpost: fix module autoloading for OF devices with generic compatible property") +Signed-off-by: Mauricio Faria de Oliveira +Signed-off-by: Masahiro Yamada +Signed-off-by: Sasha Levin +--- + scripts/mod/file2alias.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/scripts/mod/file2alias.c b/scripts/mod/file2alias.c +index 55b4c0dc2b935..ac2b11ef37c46 100644 +--- a/scripts/mod/file2alias.c ++++ b/scripts/mod/file2alias.c +@@ -1331,7 +1331,7 @@ void handle_moddevtable(struct module *mod, struct elf_info *info, + /* First handle the "special" cases */ + if (sym_is(name, namelen, "usb")) + do_usb_table(symval, sym->st_size, mod); +- if (sym_is(name, namelen, "of")) ++ else if (sym_is(name, namelen, "of")) + do_of_table(symval, sym->st_size, mod); + else if (sym_is(name, namelen, "pnp")) + do_pnp_device_entry(symval, sym->st_size, mod); +-- +2.40.1 + diff --git a/queue-4.14/net-usb-smsc75xx-fix-uninit-value-access-in-__smsc75.patch b/queue-4.14/net-usb-smsc75xx-fix-uninit-value-access-in-__smsc75.patch new file mode 100644 index 00000000000..be6f94df9bc --- /dev/null +++ b/queue-4.14/net-usb-smsc75xx-fix-uninit-value-access-in-__smsc75.patch @@ -0,0 +1,99 @@ +From d2ed54956e20d10731dd0d573934e7fc9c5e6f21 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Sun, 24 Sep 2023 02:35:49 +0900 +Subject: net: usb: smsc75xx: Fix uninit-value access in __smsc75xx_read_reg + +From: Shigeru Yoshida + +[ Upstream commit e9c65989920f7c28775ec4e0c11b483910fb67b8 ] + +syzbot reported the following uninit-value access issue: + +===================================================== +BUG: KMSAN: uninit-value in smsc75xx_wait_ready drivers/net/usb/smsc75xx.c:975 [inline] +BUG: KMSAN: uninit-value in smsc75xx_bind+0x5c9/0x11e0 drivers/net/usb/smsc75xx.c:1482 +CPU: 0 PID: 8696 Comm: kworker/0:3 Not tainted 5.8.0-rc5-syzkaller #0 +Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 +Workqueue: usb_hub_wq hub_event +Call Trace: + __dump_stack lib/dump_stack.c:77 [inline] + dump_stack+0x21c/0x280 lib/dump_stack.c:118 + kmsan_report+0xf7/0x1e0 mm/kmsan/kmsan_report.c:121 + __msan_warning+0x58/0xa0 mm/kmsan/kmsan_instr.c:215 + smsc75xx_wait_ready drivers/net/usb/smsc75xx.c:975 [inline] + smsc75xx_bind+0x5c9/0x11e0 drivers/net/usb/smsc75xx.c:1482 + usbnet_probe+0x1152/0x3f90 drivers/net/usb/usbnet.c:1737 + usb_probe_interface+0xece/0x1550 drivers/usb/core/driver.c:374 + really_probe+0xf20/0x20b0 drivers/base/dd.c:529 + driver_probe_device+0x293/0x390 drivers/base/dd.c:701 + __device_attach_driver+0x63f/0x830 drivers/base/dd.c:807 + bus_for_each_drv+0x2ca/0x3f0 drivers/base/bus.c:431 + __device_attach+0x4e2/0x7f0 drivers/base/dd.c:873 + device_initial_probe+0x4a/0x60 drivers/base/dd.c:920 + bus_probe_device+0x177/0x3d0 drivers/base/bus.c:491 + device_add+0x3b0e/0x40d0 drivers/base/core.c:2680 + usb_set_configuration+0x380f/0x3f10 drivers/usb/core/message.c:2032 + usb_generic_driver_probe+0x138/0x300 drivers/usb/core/generic.c:241 + usb_probe_device+0x311/0x490 drivers/usb/core/driver.c:272 + really_probe+0xf20/0x20b0 drivers/base/dd.c:529 + driver_probe_device+0x293/0x390 drivers/base/dd.c:701 + __device_attach_driver+0x63f/0x830 drivers/base/dd.c:807 + bus_for_each_drv+0x2ca/0x3f0 drivers/base/bus.c:431 + __device_attach+0x4e2/0x7f0 drivers/base/dd.c:873 + device_initial_probe+0x4a/0x60 drivers/base/dd.c:920 + bus_probe_device+0x177/0x3d0 drivers/base/bus.c:491 + device_add+0x3b0e/0x40d0 drivers/base/core.c:2680 + usb_new_device+0x1bd4/0x2a30 drivers/usb/core/hub.c:2554 + hub_port_connect drivers/usb/core/hub.c:5208 [inline] + hub_port_connect_change drivers/usb/core/hub.c:5348 [inline] + port_event drivers/usb/core/hub.c:5494 [inline] + hub_event+0x5e7b/0x8a70 drivers/usb/core/hub.c:5576 + process_one_work+0x1688/0x2140 kernel/workqueue.c:2269 + worker_thread+0x10bc/0x2730 kernel/workqueue.c:2415 + kthread+0x551/0x590 kernel/kthread.c:292 + ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:293 + +Local variable ----buf.i87@smsc75xx_bind created at: + __smsc75xx_read_reg drivers/net/usb/smsc75xx.c:83 [inline] + smsc75xx_wait_ready drivers/net/usb/smsc75xx.c:968 [inline] + smsc75xx_bind+0x485/0x11e0 drivers/net/usb/smsc75xx.c:1482 + __smsc75xx_read_reg drivers/net/usb/smsc75xx.c:83 [inline] + smsc75xx_wait_ready drivers/net/usb/smsc75xx.c:968 [inline] + smsc75xx_bind+0x485/0x11e0 drivers/net/usb/smsc75xx.c:1482 + +This issue is caused because usbnet_read_cmd() reads less bytes than requested +(zero byte in the reproducer). In this case, 'buf' is not properly filled. + +This patch fixes the issue by returning -ENODATA if usbnet_read_cmd() reads +less bytes than requested. + +Fixes: d0cad871703b ("smsc75xx: SMSC LAN75xx USB gigabit ethernet adapter driver") +Reported-and-tested-by: syzbot+6966546b78d050bb0b5d@syzkaller.appspotmail.com +Closes: https://syzkaller.appspot.com/bug?extid=6966546b78d050bb0b5d +Signed-off-by: Shigeru Yoshida +Reviewed-by: Simon Horman +Link: https://lore.kernel.org/r/20230923173549.3284502-1-syoshida@redhat.com +Signed-off-by: Paolo Abeni +Signed-off-by: Sasha Levin +--- + drivers/net/usb/smsc75xx.c | 4 +++- + 1 file changed, 3 insertions(+), 1 deletion(-) + +diff --git a/drivers/net/usb/smsc75xx.c b/drivers/net/usb/smsc75xx.c +index 313a4b0edc6b3..573d7ad2e7082 100644 +--- a/drivers/net/usb/smsc75xx.c ++++ b/drivers/net/usb/smsc75xx.c +@@ -102,7 +102,9 @@ static int __must_check __smsc75xx_read_reg(struct usbnet *dev, u32 index, + ret = fn(dev, USB_VENDOR_REQUEST_READ_REGISTER, USB_DIR_IN + | USB_TYPE_VENDOR | USB_RECIP_DEVICE, + 0, index, &buf, 4); +- if (unlikely(ret < 0)) { ++ if (unlikely(ret < 4)) { ++ ret = ret < 0 ? ret : -ENODATA; ++ + netdev_warn(dev->net, "Failed to read reg index 0x%08x: %d\n", + index, ret); + return ret; +-- +2.40.1 + diff --git a/queue-4.14/regmap-rbtree-fix-wrong-register-marked-as-in-cache-.patch b/queue-4.14/regmap-rbtree-fix-wrong-register-marked-as-in-cache-.patch new file mode 100644 index 00000000000..f70822fcb99 --- /dev/null +++ b/queue-4.14/regmap-rbtree-fix-wrong-register-marked-as-in-cache-.patch @@ -0,0 +1,50 @@ +From 90dfbc34ac06a36ce28ba468ac4a653e29f646c3 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Fri, 22 Sep 2023 16:37:11 +0100 +Subject: regmap: rbtree: Fix wrong register marked as in-cache when creating + new node + +From: Richard Fitzgerald + +[ Upstream commit 7a795ac8d49e2433e1b97caf5e99129daf8e1b08 ] + +When regcache_rbtree_write() creates a new rbtree_node it was passing the +wrong bit number to regcache_rbtree_set_register(). The bit number is the +offset __in number of registers__, but in the case of creating a new block +regcache_rbtree_write() was not dividing by the address stride to get the +number of registers. + +Fix this by dividing by map->reg_stride. +Compare with regcache_rbtree_read() where the bit is checked. + +This bug meant that the wrong register was marked as present. The register +that was written to the cache could not be read from the cache because it +was not marked as cached. But a nearby register could be marked as having +a cached value even if it was never written to the cache. + +Signed-off-by: Richard Fitzgerald +Fixes: 3f4ff561bc88 ("regmap: rbtree: Make cache_present bitmap per node") +Link: https://lore.kernel.org/r/20230922153711.28103-1-rf@opensource.cirrus.com +Signed-off-by: Mark Brown +Signed-off-by: Sasha Levin +--- + drivers/base/regmap/regcache-rbtree.c | 3 ++- + 1 file changed, 2 insertions(+), 1 deletion(-) + +diff --git a/drivers/base/regmap/regcache-rbtree.c b/drivers/base/regmap/regcache-rbtree.c +index 7353c55270874..b6f8f4059e255 100644 +--- a/drivers/base/regmap/regcache-rbtree.c ++++ b/drivers/base/regmap/regcache-rbtree.c +@@ -467,7 +467,8 @@ static int regcache_rbtree_write(struct regmap *map, unsigned int reg, + if (!rbnode) + return -ENOMEM; + regcache_rbtree_set_register(map, rbnode, +- reg - rbnode->base_reg, value); ++ (reg - rbnode->base_reg) / map->reg_stride, ++ value); + regcache_rbtree_insert(map, &rbtree_ctx->root, rbnode); + rbtree_ctx->cached_rbnode = rbnode; + } +-- +2.40.1 + diff --git a/queue-4.14/scsi-target-core-fix-deadlock-due-to-recursive-locki.patch b/queue-4.14/scsi-target-core-fix-deadlock-due-to-recursive-locki.patch new file mode 100644 index 00000000000..7d22f6fd58c --- /dev/null +++ b/queue-4.14/scsi-target-core-fix-deadlock-due-to-recursive-locki.patch @@ -0,0 +1,98 @@ +From 5df530f9482f030cd90ea4c1d28da5c1d8b900c6 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Mon, 18 Sep 2023 15:58:48 -0700 +Subject: scsi: target: core: Fix deadlock due to recursive locking + +From: Junxiao Bi + +[ Upstream commit a154f5f643c6ecddd44847217a7a3845b4350003 ] + +The following call trace shows a deadlock issue due to recursive locking of +mutex "device_mutex". First lock acquire is in target_for_each_device() and +second in target_free_device(). + + PID: 148266 TASK: ffff8be21ffb5d00 CPU: 10 COMMAND: "iscsi_ttx" + #0 [ffffa2bfc9ec3b18] __schedule at ffffffffa8060e7f + #1 [ffffa2bfc9ec3ba0] schedule at ffffffffa8061224 + #2 [ffffa2bfc9ec3bb8] schedule_preempt_disabled at ffffffffa80615ee + #3 [ffffa2bfc9ec3bc8] __mutex_lock at ffffffffa8062fd7 + #4 [ffffa2bfc9ec3c40] __mutex_lock_slowpath at ffffffffa80631d3 + #5 [ffffa2bfc9ec3c50] mutex_lock at ffffffffa806320c + #6 [ffffa2bfc9ec3c68] target_free_device at ffffffffc0935998 [target_core_mod] + #7 [ffffa2bfc9ec3c90] target_core_dev_release at ffffffffc092f975 [target_core_mod] + #8 [ffffa2bfc9ec3ca0] config_item_put at ffffffffa79d250f + #9 [ffffa2bfc9ec3cd0] config_item_put at ffffffffa79d2583 + #10 [ffffa2bfc9ec3ce0] target_devices_idr_iter at ffffffffc0933f3a [target_core_mod] + #11 [ffffa2bfc9ec3d00] idr_for_each at ffffffffa803f6fc + #12 [ffffa2bfc9ec3d60] target_for_each_device at ffffffffc0935670 [target_core_mod] + #13 [ffffa2bfc9ec3d98] transport_deregister_session at ffffffffc0946408 [target_core_mod] + #14 [ffffa2bfc9ec3dc8] iscsit_close_session at ffffffffc09a44a6 [iscsi_target_mod] + #15 [ffffa2bfc9ec3df0] iscsit_close_connection at ffffffffc09a4a88 [iscsi_target_mod] + #16 [ffffa2bfc9ec3df8] finish_task_switch at ffffffffa76e5d07 + #17 [ffffa2bfc9ec3e78] iscsit_take_action_for_connection_exit at ffffffffc0991c23 [iscsi_target_mod] + #18 [ffffa2bfc9ec3ea0] iscsi_target_tx_thread at ffffffffc09a403b [iscsi_target_mod] + #19 [ffffa2bfc9ec3f08] kthread at ffffffffa76d8080 + #20 [ffffa2bfc9ec3f50] ret_from_fork at ffffffffa8200364 + +Fixes: 36d4cb460bcb ("scsi: target: Avoid that EXTENDED COPY commands trigger lock inversion") +Signed-off-by: Junxiao Bi +Link: https://lore.kernel.org/r/20230918225848.66463-1-junxiao.bi@oracle.com +Reviewed-by: Mike Christie +Signed-off-by: Martin K. Petersen +Signed-off-by: Sasha Levin +--- + drivers/target/target_core_device.c | 11 ++++------- + 1 file changed, 4 insertions(+), 7 deletions(-) + +diff --git a/drivers/target/target_core_device.c b/drivers/target/target_core_device.c +index 68b2fa562201c..907b06056f029 100644 +--- a/drivers/target/target_core_device.c ++++ b/drivers/target/target_core_device.c +@@ -906,7 +906,6 @@ struct se_device *target_find_device(int id, bool do_depend) + EXPORT_SYMBOL(target_find_device); + + struct devices_idr_iter { +- struct config_item *prev_item; + int (*fn)(struct se_device *dev, void *data); + void *data; + }; +@@ -916,11 +915,9 @@ static int target_devices_idr_iter(int id, void *p, void *data) + { + struct devices_idr_iter *iter = data; + struct se_device *dev = p; ++ struct config_item *item; + int ret; + +- config_item_put(iter->prev_item); +- iter->prev_item = NULL; +- + /* + * We add the device early to the idr, so it can be used + * by backend modules during configuration. We do not want +@@ -930,12 +927,13 @@ static int target_devices_idr_iter(int id, void *p, void *data) + if (!(dev->dev_flags & DF_CONFIGURED)) + return 0; + +- iter->prev_item = config_item_get_unless_zero(&dev->dev_group.cg_item); +- if (!iter->prev_item) ++ item = config_item_get_unless_zero(&dev->dev_group.cg_item); ++ if (!item) + return 0; + mutex_unlock(&device_mutex); + + ret = iter->fn(dev, iter->data); ++ config_item_put(item); + + mutex_lock(&device_mutex); + return ret; +@@ -958,7 +956,6 @@ int target_for_each_device(int (*fn)(struct se_device *dev, void *data), + mutex_lock(&device_mutex); + ret = idr_for_each(&devices_idr, target_devices_idr_iter, &iter); + mutex_unlock(&device_mutex); +- config_item_put(iter.prev_item); + return ret; + } + +-- +2.40.1 + diff --git a/queue-4.14/sctp-update-hb-timer-immediately-after-users-change-.patch b/queue-4.14/sctp-update-hb-timer-immediately-after-users-change-.patch new file mode 100644 index 00000000000..76dd061b932 --- /dev/null +++ b/queue-4.14/sctp-update-hb-timer-immediately-after-users-change-.patch @@ -0,0 +1,48 @@ +From 89f0ed614167617cf73149df5620bd600ebd1140 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Sun, 1 Oct 2023 11:04:20 -0400 +Subject: sctp: update hb timer immediately after users change hb_interval + +From: Xin Long + +[ Upstream commit 1f4e803cd9c9166eb8b6c8b0b8e4124f7499fc07 ] + +Currently, when hb_interval is changed by users, it won't take effect +until the next expiry of hb timer. As the default value is 30s, users +have to wait up to 30s to wait its hb_interval update to work. + +This becomes pretty bad in containers where a much smaller value is +usually set on hb_interval. This patch improves it by resetting the +hb timer immediately once the value of hb_interval is updated by users. + +Note that we don't address the already existing 'problem' when sending +a heartbeat 'on demand' if one hb has just been sent(from the timer) +mentioned in: + + https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg590224.html + +Signed-off-by: Xin Long +Reviewed-by: Simon Horman +Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") +Link: https://lore.kernel.org/r/75465785f8ee5df2fb3acdca9b8fafdc18984098.1696172660.git.lucien.xin@gmail.com +Signed-off-by: Jakub Kicinski +Signed-off-by: Sasha Levin +--- + net/sctp/socket.c | 1 + + 1 file changed, 1 insertion(+) + +diff --git a/net/sctp/socket.c b/net/sctp/socket.c +index e5c3c37108e4e..fe26395690f33 100644 +--- a/net/sctp/socket.c ++++ b/net/sctp/socket.c +@@ -2479,6 +2479,7 @@ static int sctp_apply_peer_addr_params(struct sctp_paddrparams *params, + if (trans) { + trans->hbinterval = + msecs_to_jiffies(params->spp_hbinterval); ++ sctp_transport_reset_hb_timer(trans); + } else if (asoc) { + asoc->hbinterval = + msecs_to_jiffies(params->spp_hbinterval); +-- +2.40.1 + diff --git a/queue-4.14/sctp-update-transport-state-when-processing-a-dupcoo.patch b/queue-4.14/sctp-update-transport-state-when-processing-a-dupcoo.patch new file mode 100644 index 00000000000..e043acdc4fb --- /dev/null +++ b/queue-4.14/sctp-update-transport-state-when-processing-a-dupcoo.patch @@ -0,0 +1,67 @@ +From 201b3ad935476d21a615d9c7b250a74b2f75f664 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Sun, 1 Oct 2023 10:58:45 -0400 +Subject: sctp: update transport state when processing a dupcook packet + +From: Xin Long + +[ Upstream commit 2222a78075f0c19ca18db53fd6623afb4aff602d ] + +During the 4-way handshake, the transport's state is set to ACTIVE in +sctp_process_init() when processing INIT_ACK chunk on client or +COOKIE_ECHO chunk on server. + +In the collision scenario below: + + 192.168.1.2 > 192.168.1.1: sctp (1) [INIT] [init tag: 3922216408] + 192.168.1.1 > 192.168.1.2: sctp (1) [INIT] [init tag: 144230885] + 192.168.1.2 > 192.168.1.1: sctp (1) [INIT ACK] [init tag: 3922216408] + 192.168.1.1 > 192.168.1.2: sctp (1) [COOKIE ECHO] + 192.168.1.2 > 192.168.1.1: sctp (1) [COOKIE ACK] + 192.168.1.1 > 192.168.1.2: sctp (1) [INIT ACK] [init tag: 3914796021] + +when processing COOKIE_ECHO on 192.168.1.2, as it's in COOKIE_WAIT state, +sctp_sf_do_dupcook_b() is called by sctp_sf_do_5_2_4_dupcook() where it +creates a new association and sets its transport to ACTIVE then updates +to the old association in sctp_assoc_update(). + +However, in sctp_assoc_update(), it will skip the transport update if it +finds a transport with the same ipaddr already existing in the old asoc, +and this causes the old asoc's transport state not to move to ACTIVE +after the handshake. + +This means if DATA retransmission happens at this moment, it won't be able +to enter PF state because of the check 'transport->state == SCTP_ACTIVE' +in sctp_do_8_2_transport_strike(). + +This patch fixes it by updating the transport in sctp_assoc_update() with +sctp_assoc_add_peer() where it updates the transport state if there is +already a transport with the same ipaddr exists in the old asoc. + +Signed-off-by: Xin Long +Reviewed-by: Simon Horman +Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") +Link: https://lore.kernel.org/r/fd17356abe49713ded425250cc1ae51e9f5846c6.1696172325.git.lucien.xin@gmail.com +Signed-off-by: Jakub Kicinski +Signed-off-by: Sasha Levin +--- + net/sctp/associola.c | 3 +-- + 1 file changed, 1 insertion(+), 2 deletions(-) + +diff --git a/net/sctp/associola.c b/net/sctp/associola.c +index 0a5764016721b..629f56cbe22cb 100644 +--- a/net/sctp/associola.c ++++ b/net/sctp/associola.c +@@ -1204,8 +1204,7 @@ int sctp_assoc_update(struct sctp_association *asoc, + /* Add any peer addresses from the new association. */ + list_for_each_entry(trans, &new->peer.transport_addr_list, + transports) +- if (!sctp_assoc_lookup_paddr(asoc, &trans->ipaddr) && +- !sctp_assoc_add_peer(asoc, &trans->ipaddr, ++ if (!sctp_assoc_add_peer(asoc, &trans->ipaddr, + GFP_ATOMIC, trans->state)) + return -ENOMEM; + +-- +2.40.1 + diff --git a/queue-4.14/series b/queue-4.14/series index a4f5c140f06..071e516413b 100644 --- a/queue-4.14/series +++ b/queue-4.14/series @@ -33,3 +33,14 @@ ext4-fix-rec_len-verify-error.patch net-sched-sch_hfsc-ensure-inner-classes-have-fsc-curve.patch ata-libata-disallow-dev-initiated-lpm-transitions-to-unsupported-states.patch media-dvb-symbol-fixup-for-dvb_attach-again.patch +ubi-refuse-attaching-if-mtd-s-erasesize-is-0.patch +wifi-mwifiex-fix-oob-check-condition-in-mwifiex_proc.patch +drivers-net-process-the-result-of-hdlc_open-and-add-.patch +regmap-rbtree-fix-wrong-register-marked-as-in-cache-.patch +scsi-target-core-fix-deadlock-due-to-recursive-locki.patch +modpost-add-missing-else-to-the-of-check.patch +ipv4-ipv6-fix-handling-of-transhdrlen-in-__ip-6-_app.patch +net-usb-smsc75xx-fix-uninit-value-access-in-__smsc75.patch +tcp-fix-delayed-acks-for-mss-boundary-condition.patch +sctp-update-transport-state-when-processing-a-dupcoo.patch +sctp-update-hb-timer-immediately-after-users-change-.patch diff --git a/queue-4.14/tcp-fix-delayed-acks-for-mss-boundary-condition.patch b/queue-4.14/tcp-fix-delayed-acks-for-mss-boundary-condition.patch new file mode 100644 index 00000000000..0dae1e5e586 --- /dev/null +++ b/queue-4.14/tcp-fix-delayed-acks-for-mss-boundary-condition.patch @@ -0,0 +1,99 @@ +From a90285c4b3ed526fad23a93294595354c9c896de Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Sun, 1 Oct 2023 11:12:39 -0400 +Subject: tcp: fix delayed ACKs for MSS boundary condition + +From: Neal Cardwell + +[ Upstream commit 4720852ed9afb1c5ab84e96135cb5b73d5afde6f ] + +This commit fixes poor delayed ACK behavior that can cause poor TCP +latency in a particular boundary condition: when an application makes +a TCP socket write that is an exact multiple of the MSS size. + +The problem is that there is painful boundary discontinuity in the +current delayed ACK behavior. With the current delayed ACK behavior, +we have: + +(1) If an app reads data when > 1*MSS is unacknowledged, then + tcp_cleanup_rbuf() ACKs immediately because of: + + tp->rcv_nxt - tp->rcv_wup > icsk->icsk_ack.rcv_mss || + +(2) If an app reads all received data, and the packets were < 1*MSS, + and either (a) the app is not ping-pong or (b) we received two + packets < 1*MSS, then tcp_cleanup_rbuf() ACKs immediately beecause + of: + + ((icsk->icsk_ack.pending & ICSK_ACK_PUSHED2) || + ((icsk->icsk_ack.pending & ICSK_ACK_PUSHED) && + !inet_csk_in_pingpong_mode(sk))) && + +(3) *However*: if an app reads exactly 1*MSS of data, + tcp_cleanup_rbuf() does not send an immediate ACK. This is true + even if the app is not ping-pong and the 1*MSS of data had the PSH + bit set, suggesting the sending application completed an + application write. + +Thus if the app is not ping-pong, we have this painful case where +>1*MSS gets an immediate ACK, and <1*MSS gets an immediate ACK, but a +write whose last skb is an exact multiple of 1*MSS can get a 40ms +delayed ACK. This means that any app that transfers data in one +direction and takes care to align write size or packet size with MSS +can suffer this problem. With receive zero copy making 4KB MSS values +more common, it is becoming more common to have application writes +naturally align with MSS, and more applications are likely to +encounter this delayed ACK problem. + +The fix in this commit is to refine the delayed ACK heuristics with a +simple check: immediately ACK a received 1*MSS skb with PSH bit set if +the app reads all data. Why? If an skb has a len of exactly 1*MSS and +has the PSH bit set then it is likely the end of an application +write. So more data may not be arriving soon, and yet the data sender +may be waiting for an ACK if cwnd-bound or using TX zero copy. Thus we +set ICSK_ACK_PUSHED in this case so that tcp_cleanup_rbuf() will send +an ACK immediately if the app reads all of the data and is not +ping-pong. Note that this logic is also executed for the case where +len > MSS, but in that case this logic does not matter (and does not +hurt) because tcp_cleanup_rbuf() will always ACK immediately if the +app reads data and there is more than an MSS of unACKed data. + +Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") +Signed-off-by: Neal Cardwell +Reviewed-by: Yuchung Cheng +Reviewed-by: Eric Dumazet +Cc: Xin Guo +Link: https://lore.kernel.org/r/20231001151239.1866845-2-ncardwell.sw@gmail.com +Signed-off-by: Jakub Kicinski +Signed-off-by: Sasha Levin +--- + net/ipv4/tcp_input.c | 13 +++++++++++++ + 1 file changed, 13 insertions(+) + +diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c +index 444ad17289277..491c16d8e9ddc 100644 +--- a/net/ipv4/tcp_input.c ++++ b/net/ipv4/tcp_input.c +@@ -166,6 +166,19 @@ static void tcp_measure_rcv_mss(struct sock *sk, const struct sk_buff *skb) + if (unlikely(len > icsk->icsk_ack.rcv_mss + + MAX_TCP_OPTION_SPACE)) + tcp_gro_dev_warn(sk, skb, len); ++ /* If the skb has a len of exactly 1*MSS and has the PSH bit ++ * set then it is likely the end of an application write. So ++ * more data may not be arriving soon, and yet the data sender ++ * may be waiting for an ACK if cwnd-bound or using TX zero ++ * copy. So we set ICSK_ACK_PUSHED here so that ++ * tcp_cleanup_rbuf() will send an ACK immediately if the app ++ * reads all of the data and is not ping-pong. If len > MSS ++ * then this logic does not matter (and does not hurt) because ++ * tcp_cleanup_rbuf() will always ACK immediately if the app ++ * reads data and there is more than an MSS of unACKed data. ++ */ ++ if (TCP_SKB_CB(skb)->tcp_flags & TCPHDR_PSH) ++ icsk->icsk_ack.pending |= ICSK_ACK_PUSHED; + } else { + /* Otherwise, we make more careful check taking into account, + * that SACKs block is variable. +-- +2.40.1 + diff --git a/queue-4.14/ubi-refuse-attaching-if-mtd-s-erasesize-is-0.patch b/queue-4.14/ubi-refuse-attaching-if-mtd-s-erasesize-is-0.patch new file mode 100644 index 00000000000..ab6866034ba --- /dev/null +++ b/queue-4.14/ubi-refuse-attaching-if-mtd-s-erasesize-is-0.patch @@ -0,0 +1,45 @@ +From 16cc2456e0736736cc5f6e3029a1564275fb2d9e Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Sun, 23 Apr 2023 19:10:41 +0800 +Subject: ubi: Refuse attaching if mtd's erasesize is 0 + +From: Zhihao Cheng + +[ Upstream commit 017c73a34a661a861712f7cc1393a123e5b2208c ] + +There exists mtd devices with zero erasesize, which will trigger a +divide-by-zero exception while attaching ubi device. +Fix it by refusing attaching if mtd's erasesize is 0. + +Fixes: 801c135ce73d ("UBI: Unsorted Block Images") +Reported-by: Yu Hao +Link: https://lore.kernel.org/lkml/977347543.226888.1682011999468.JavaMail.zimbra@nod.at/T/ +Signed-off-by: Zhihao Cheng +Reviewed-by: Miquel Raynal +Signed-off-by: Richard Weinberger +Signed-off-by: Sasha Levin +--- + drivers/mtd/ubi/build.c | 7 +++++++ + 1 file changed, 7 insertions(+) + +diff --git a/drivers/mtd/ubi/build.c b/drivers/mtd/ubi/build.c +index 4ee1ff84076dc..f42e4b9fdea1a 100644 +--- a/drivers/mtd/ubi/build.c ++++ b/drivers/mtd/ubi/build.c +@@ -869,6 +869,13 @@ int ubi_attach_mtd_dev(struct mtd_info *mtd, int ubi_num, + return -EINVAL; + } + ++ /* UBI cannot work on flashes with zero erasesize. */ ++ if (!mtd->erasesize) { ++ pr_err("ubi: refuse attaching mtd%d - zero erasesize flash is not supported\n", ++ mtd->index); ++ return -EINVAL; ++ } ++ + if (ubi_num == UBI_DEV_NUM_AUTO) { + /* Search for an empty slot in the @ubi_devices array */ + for (ubi_num = 0; ubi_num < UBI_MAX_DEVICES; ubi_num++) +-- +2.40.1 + diff --git a/queue-4.14/wifi-mwifiex-fix-oob-check-condition-in-mwifiex_proc.patch b/queue-4.14/wifi-mwifiex-fix-oob-check-condition-in-mwifiex_proc.patch new file mode 100644 index 00000000000..9d12588d439 --- /dev/null +++ b/queue-4.14/wifi-mwifiex-fix-oob-check-condition-in-mwifiex_proc.patch @@ -0,0 +1,61 @@ +From 6ca175bf0c14bcd22c87ca5e62ba5bc6a2e794bc Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Fri, 8 Sep 2023 18:41:12 +0800 +Subject: wifi: mwifiex: Fix oob check condition in mwifiex_process_rx_packet + +From: Pin-yen Lin + +[ Upstream commit aef7a0300047e7b4707ea0411dc9597cba108fc8 ] + +Only skip the code path trying to access the rfc1042 headers when the +buffer is too small, so the driver can still process packets without +rfc1042 headers. + +Fixes: 119585281617 ("wifi: mwifiex: Fix OOB and integer underflow when rx packets") +Signed-off-by: Pin-yen Lin +Acked-by: Brian Norris +Reviewed-by: Matthew Wang +Signed-off-by: Kalle Valo +Link: https://lore.kernel.org/r/20230908104308.1546501-1-treapking@chromium.org +Signed-off-by: Sasha Levin +--- + drivers/net/wireless/marvell/mwifiex/sta_rx.c | 16 +++++++++------- + 1 file changed, 9 insertions(+), 7 deletions(-) + +diff --git a/drivers/net/wireless/marvell/mwifiex/sta_rx.c b/drivers/net/wireless/marvell/mwifiex/sta_rx.c +index f3c6daeba1b85..346e91b9f2ad7 100644 +--- a/drivers/net/wireless/marvell/mwifiex/sta_rx.c ++++ b/drivers/net/wireless/marvell/mwifiex/sta_rx.c +@@ -98,7 +98,8 @@ int mwifiex_process_rx_packet(struct mwifiex_private *priv, + rx_pkt_len = le16_to_cpu(local_rx_pd->rx_pkt_length); + rx_pkt_hdr = (void *)local_rx_pd + rx_pkt_off; + +- if (sizeof(*rx_pkt_hdr) + rx_pkt_off > skb->len) { ++ if (sizeof(rx_pkt_hdr->eth803_hdr) + sizeof(rfc1042_header) + ++ rx_pkt_off > skb->len) { + mwifiex_dbg(priv->adapter, ERROR, + "wrong rx packet offset: len=%d, rx_pkt_off=%d\n", + skb->len, rx_pkt_off); +@@ -107,12 +108,13 @@ int mwifiex_process_rx_packet(struct mwifiex_private *priv, + return -1; + } + +- if ((!memcmp(&rx_pkt_hdr->rfc1042_hdr, bridge_tunnel_header, +- sizeof(bridge_tunnel_header))) || +- (!memcmp(&rx_pkt_hdr->rfc1042_hdr, rfc1042_header, +- sizeof(rfc1042_header)) && +- ntohs(rx_pkt_hdr->rfc1042_hdr.snap_type) != ETH_P_AARP && +- ntohs(rx_pkt_hdr->rfc1042_hdr.snap_type) != ETH_P_IPX)) { ++ if (sizeof(*rx_pkt_hdr) + rx_pkt_off <= skb->len && ++ ((!memcmp(&rx_pkt_hdr->rfc1042_hdr, bridge_tunnel_header, ++ sizeof(bridge_tunnel_header))) || ++ (!memcmp(&rx_pkt_hdr->rfc1042_hdr, rfc1042_header, ++ sizeof(rfc1042_header)) && ++ ntohs(rx_pkt_hdr->rfc1042_hdr.snap_type) != ETH_P_AARP && ++ ntohs(rx_pkt_hdr->rfc1042_hdr.snap_type) != ETH_P_IPX))) { + /* + * Replace the 803 header and rfc1042 header (llc/snap) with an + * EthernetII header, keep the src/dst and snap_type +-- +2.40.1 +