From: Sasha Levin Date: Sun, 3 Mar 2024 15:56:44 +0000 (-0500) Subject: Fixes for 5.10 X-Git-Tag: v4.19.309~92^2~2 X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=96e421c229eebf6809648f0a54694ec8a7e308b8;p=thirdparty%2Fkernel%2Fstable-queue.git Fixes for 5.10 Signed-off-by: Sasha Levin --- diff --git a/queue-5.10/afs-fix-endless-loop-in-directory-parsing.patch b/queue-5.10/afs-fix-endless-loop-in-directory-parsing.patch new file mode 100644 index 00000000000..01e3023a87f --- /dev/null +++ b/queue-5.10/afs-fix-endless-loop-in-directory-parsing.patch @@ -0,0 +1,68 @@ +From 85c46bf30e6ca6a842283b27c0b7643daf4f44bc Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Fri, 23 Feb 2024 13:15:02 +0000 +Subject: afs: Fix endless loop in directory parsing + +From: David Howells + +[ Upstream commit 5f7a07646655fb4108da527565dcdc80124b14c4 ] + +If a directory has a block with only ".__afsXXXX" files in it (from +uncompleted silly-rename), these .__afsXXXX files are skipped but without +advancing the file position in the dir_context. This leads to +afs_dir_iterate() repeating the block again and again. + +Fix this by making the code that skips the .__afsXXXX file also manually +advance the file position. + +The symptoms are a soft lookup: + + watchdog: BUG: soft lockup - CPU#3 stuck for 52s! [check:5737] + ... + RIP: 0010:afs_dir_iterate_block+0x39/0x1fd + ... + ? watchdog_timer_fn+0x1a6/0x213 + ... + ? asm_sysvec_apic_timer_interrupt+0x16/0x20 + ? afs_dir_iterate_block+0x39/0x1fd + afs_dir_iterate+0x10a/0x148 + afs_readdir+0x30/0x4a + iterate_dir+0x93/0xd3 + __do_sys_getdents64+0x6b/0xd4 + +This is almost certainly the actual fix for: + + https://bugzilla.kernel.org/show_bug.cgi?id=218496 + +Fixes: 57e9d49c5452 ("afs: Hide silly-rename files from userspace") +Signed-off-by: David Howells +Link: https://lore.kernel.org/r/786185.1708694102@warthog.procyon.org.uk +Reviewed-by: Marc Dionne +cc: Marc Dionne +cc: Markus Suvanto +cc: linux-afs@lists.infradead.org +Signed-off-by: Christian Brauner +Signed-off-by: Sasha Levin +--- + fs/afs/dir.c | 4 +++- + 1 file changed, 3 insertions(+), 1 deletion(-) + +diff --git a/fs/afs/dir.c b/fs/afs/dir.c +index 0b927736ca728..88f0e719c6ac0 100644 +--- a/fs/afs/dir.c ++++ b/fs/afs/dir.c +@@ -423,8 +423,10 @@ static int afs_dir_iterate_block(struct afs_vnode *dvnode, + dire->u.name[0] == '.' && + ctx->actor != afs_lookup_filldir && + ctx->actor != afs_lookup_one_filldir && +- memcmp(dire->u.name, ".__afs", 6) == 0) ++ memcmp(dire->u.name, ".__afs", 6) == 0) { ++ ctx->pos = blkoff + next * sizeof(union afs_xdr_dirent); + continue; ++ } + + /* found the next entry */ + if (!dir_emit(ctx, dire->u.name, nlen, +-- +2.43.0 + diff --git a/queue-5.10/alsa-drop-leftover-snd-rtctimer-stuff-from-makefile.patch b/queue-5.10/alsa-drop-leftover-snd-rtctimer-stuff-from-makefile.patch new file mode 100644 index 00000000000..4cd6cbde1ef --- /dev/null +++ b/queue-5.10/alsa-drop-leftover-snd-rtctimer-stuff-from-makefile.patch @@ -0,0 +1,35 @@ +From 5c4959316bb610aa04d8177c1f864bf83a381fd7 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Wed, 21 Feb 2024 10:21:56 +0100 +Subject: ALSA: Drop leftover snd-rtctimer stuff from Makefile + +From: Takashi Iwai + +[ Upstream commit 4df49712eb54141be00a9312547436d55677f092 ] + +We forgot to remove the line for snd-rtctimer from Makefile while +dropping the functionality. Get rid of the stale line. + +Fixes: 34ce71a96dcb ("ALSA: timer: remove legacy rtctimer") +Link: https://lore.kernel.org/r/20240221092156.28695-1-tiwai@suse.de +Signed-off-by: Takashi Iwai +Signed-off-by: Sasha Levin +--- + sound/core/Makefile | 1 - + 1 file changed, 1 deletion(-) + +diff --git a/sound/core/Makefile b/sound/core/Makefile +index d123587c0fd8f..bc04acf4a45ce 100644 +--- a/sound/core/Makefile ++++ b/sound/core/Makefile +@@ -32,7 +32,6 @@ snd-pcm-dmaengine-objs := pcm_dmaengine.o + snd-rawmidi-objs := rawmidi.o + snd-timer-objs := timer.o + snd-hrtimer-objs := hrtimer.o +-snd-rtctimer-objs := rtctimer.o + snd-hwdep-objs := hwdep.o + snd-seq-device-objs := seq_device.o + +-- +2.43.0 + diff --git a/queue-5.10/bluetooth-avoid-potential-use-after-free-in-hci_erro.patch b/queue-5.10/bluetooth-avoid-potential-use-after-free-in-hci_erro.patch new file mode 100644 index 00000000000..384dab717c9 --- /dev/null +++ b/queue-5.10/bluetooth-avoid-potential-use-after-free-in-hci_erro.patch @@ -0,0 +1,66 @@ +From 2ab9547d32c7ec5a2b21d8a9bada87b9ef91303c Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 4 Jan 2024 11:56:32 +0000 +Subject: Bluetooth: Avoid potential use-after-free in hci_error_reset + +From: Ying Hsu + +[ Upstream commit 2449007d3f73b2842c9734f45f0aadb522daf592 ] + +While handling the HCI_EV_HARDWARE_ERROR event, if the underlying +BT controller is not responding, the GPIO reset mechanism would +free the hci_dev and lead to a use-after-free in hci_error_reset. + +Here's the call trace observed on a ChromeOS device with Intel AX201: + queue_work_on+0x3e/0x6c + __hci_cmd_sync_sk+0x2ee/0x4c0 [bluetooth ] + ? init_wait_entry+0x31/0x31 + __hci_cmd_sync+0x16/0x20 [bluetooth ] + hci_error_reset+0x4f/0xa4 [bluetooth ] + process_one_work+0x1d8/0x33f + worker_thread+0x21b/0x373 + kthread+0x13a/0x152 + ? pr_cont_work+0x54/0x54 + ? kthread_blkcg+0x31/0x31 + ret_from_fork+0x1f/0x30 + +This patch holds the reference count on the hci_dev while processing +a HCI_EV_HARDWARE_ERROR event to avoid potential crash. + +Fixes: c7741d16a57c ("Bluetooth: Perform a power cycle when receiving hardware error event") +Signed-off-by: Ying Hsu +Signed-off-by: Luiz Augusto von Dentz +Signed-off-by: Sasha Levin +--- + net/bluetooth/hci_core.c | 7 ++++--- + 1 file changed, 4 insertions(+), 3 deletions(-) + +diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c +index e33fe4b1c4e29..5f1fbf86e0ceb 100644 +--- a/net/bluetooth/hci_core.c ++++ b/net/bluetooth/hci_core.c +@@ -2318,6 +2318,7 @@ static void hci_error_reset(struct work_struct *work) + { + struct hci_dev *hdev = container_of(work, struct hci_dev, error_reset); + ++ hci_dev_hold(hdev); + BT_DBG("%s", hdev->name); + + if (hdev->hw_error) +@@ -2325,10 +2326,10 @@ static void hci_error_reset(struct work_struct *work) + else + bt_dev_err(hdev, "hardware error 0x%2.2x", hdev->hw_error_code); + +- if (hci_dev_do_close(hdev)) +- return; ++ if (!hci_dev_do_close(hdev)) ++ hci_dev_do_open(hdev); + +- hci_dev_do_open(hdev); ++ hci_dev_put(hdev); + } + + void hci_uuids_clear(struct hci_dev *hdev) +-- +2.43.0 + diff --git a/queue-5.10/bluetooth-enforce-validation-on-max-value-of-connect.patch b/queue-5.10/bluetooth-enforce-validation-on-max-value-of-connect.patch new file mode 100644 index 00000000000..8156a751a2e --- /dev/null +++ b/queue-5.10/bluetooth-enforce-validation-on-max-value-of-connect.patch @@ -0,0 +1,68 @@ +From 3a76ff06428b4e900eb3c1d6ae0762c8d0d54d61 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 25 Jan 2024 14:50:28 +0800 +Subject: Bluetooth: Enforce validation on max value of connection interval + +From: Kai-Heng Feng + +[ Upstream commit e4b019515f950b4e6e5b74b2e1bb03a90cb33039 ] + +Right now Linux BT stack cannot pass test case "GAP/CONN/CPUP/BV-05-C +'Connection Parameter Update Procedure Invalid Parameters Central +Responder'" in Bluetooth Test Suite revision GAP.TS.p44. [0] + +That was revoled by commit c49a8682fc5d ("Bluetooth: validate BLE +connection interval updates"), but later got reverted due to devices +like keyboards and mice may require low connection interval. + +So only validate the max value connection interval to pass the Test +Suite, and let devices to request low connection interval if needed. + +[0] https://www.bluetooth.org/docman/handlers/DownloadDoc.ashx?doc_id=229869 + +Fixes: 68d19d7d9957 ("Revert "Bluetooth: validate BLE connection interval updates"") +Signed-off-by: Kai-Heng Feng +Signed-off-by: Luiz Augusto von Dentz +Signed-off-by: Sasha Levin +--- + net/bluetooth/hci_event.c | 4 ++++ + net/bluetooth/l2cap_core.c | 8 +++++++- + 2 files changed, 11 insertions(+), 1 deletion(-) + +diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c +index ea25bb31b336a..47f37080c0c55 100644 +--- a/net/bluetooth/hci_event.c ++++ b/net/bluetooth/hci_event.c +@@ -5925,6 +5925,10 @@ static void hci_le_remote_conn_param_req_evt(struct hci_dev *hdev, + return send_conn_param_neg_reply(hdev, handle, + HCI_ERROR_UNKNOWN_CONN_ID); + ++ if (max > hcon->le_conn_max_interval) ++ return send_conn_param_neg_reply(hdev, handle, ++ HCI_ERROR_INVALID_LL_PARAMS); ++ + if (hci_check_conn_params(min, max, latency, timeout)) + return send_conn_param_neg_reply(hdev, handle, + HCI_ERROR_INVALID_LL_PARAMS); +diff --git a/net/bluetooth/l2cap_core.c b/net/bluetooth/l2cap_core.c +index a752032e12fcf..580b6d6b970d2 100644 +--- a/net/bluetooth/l2cap_core.c ++++ b/net/bluetooth/l2cap_core.c +@@ -5609,7 +5609,13 @@ static inline int l2cap_conn_param_update_req(struct l2cap_conn *conn, + + memset(&rsp, 0, sizeof(rsp)); + +- err = hci_check_conn_params(min, max, latency, to_multiplier); ++ if (max > hcon->le_conn_max_interval) { ++ BT_DBG("requested connection interval exceeds current bounds."); ++ err = -EINVAL; ++ } else { ++ err = hci_check_conn_params(min, max, latency, to_multiplier); ++ } ++ + if (err) + rsp.result = cpu_to_le16(L2CAP_CONN_PARAM_REJECTED); + else +-- +2.43.0 + diff --git a/queue-5.10/bluetooth-hci_event-fix-handling-of-hci_ev_io_capa_r.patch b/queue-5.10/bluetooth-hci_event-fix-handling-of-hci_ev_io_capa_r.patch new file mode 100644 index 00000000000..95b12c94162 --- /dev/null +++ b/queue-5.10/bluetooth-hci_event-fix-handling-of-hci_ev_io_capa_r.patch @@ -0,0 +1,42 @@ +From c988f0361b73803739631b0788b4b00f5fde0079 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Mon, 22 Jan 2024 09:02:47 -0500 +Subject: Bluetooth: hci_event: Fix handling of HCI_EV_IO_CAPA_REQUEST + +From: Luiz Augusto von Dentz + +[ Upstream commit 7e74aa53a68bf60f6019bd5d9a9a1406ec4d4865 ] + +If we received HCI_EV_IO_CAPA_REQUEST while +HCI_OP_READ_REMOTE_EXT_FEATURES is yet to be responded assume the remote +does support SSP since otherwise this event shouldn't be generated. + +Link: https://lore.kernel.org/linux-bluetooth/CABBYNZ+9UdG1cMZVmdtN3U2aS16AKMCyTARZZyFX7xTEDWcMOw@mail.gmail.com/T/#t +Fixes: c7f59461f5a7 ("Bluetooth: Fix a refcnt underflow problem for hci_conn") +Signed-off-by: Luiz Augusto von Dentz +Signed-off-by: Sasha Levin +--- + net/bluetooth/hci_event.c | 5 ++++- + 1 file changed, 4 insertions(+), 1 deletion(-) + +diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c +index 40e9f1babe9e9..ea25bb31b336a 100644 +--- a/net/bluetooth/hci_event.c ++++ b/net/bluetooth/hci_event.c +@@ -4612,9 +4612,12 @@ static void hci_io_capa_request_evt(struct hci_dev *hdev, struct sk_buff *skb) + hci_dev_lock(hdev); + + conn = hci_conn_hash_lookup_ba(hdev, ACL_LINK, &ev->bdaddr); +- if (!conn || !hci_conn_ssp_enabled(conn)) ++ if (!conn || !hci_dev_test_flag(hdev, HCI_SSP_ENABLED)) + goto unlock; + ++ /* Assume remote supports SSP since it has triggered this event */ ++ set_bit(HCI_CONN_SSP_ENABLED, &conn->flags); ++ + hci_conn_hold(conn); + + if (!hci_dev_test_flag(hdev, HCI_MGMT)) +-- +2.43.0 + diff --git a/queue-5.10/bluetooth-hci_event-fix-wrongly-recorded-wakeup-bd_a.patch b/queue-5.10/bluetooth-hci_event-fix-wrongly-recorded-wakeup-bd_a.patch new file mode 100644 index 00000000000..c83c64cf759 --- /dev/null +++ b/queue-5.10/bluetooth-hci_event-fix-wrongly-recorded-wakeup-bd_a.patch @@ -0,0 +1,42 @@ +From 3470414970b965bd6843b33e8a40bd4902843c2a Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Tue, 9 Jan 2024 19:03:23 +0800 +Subject: Bluetooth: hci_event: Fix wrongly recorded wakeup BD_ADDR + +From: Zijun Hu + +[ Upstream commit 61a5ab72edea7ebc3ad2c6beea29d966f528ebfb ] + +hci_store_wake_reason() wrongly parses event HCI_Connection_Request +as HCI_Connection_Complete and HCI_Connection_Complete as +HCI_Connection_Request, so causes recording wakeup BD_ADDR error and +potential stability issue, fix it by using the correct field. + +Fixes: 2f20216c1d6f ("Bluetooth: Emit controller suspend and resume events") +Signed-off-by: Zijun Hu +Signed-off-by: Luiz Augusto von Dentz +Signed-off-by: Sasha Levin +--- + net/bluetooth/hci_event.c | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c +index 4027c79786fd3..40e9f1babe9e9 100644 +--- a/net/bluetooth/hci_event.c ++++ b/net/bluetooth/hci_event.c +@@ -6139,10 +6139,10 @@ static void hci_store_wake_reason(struct hci_dev *hdev, u8 event, + * keep track of the bdaddr of the connection event that woke us up. + */ + if (event == HCI_EV_CONN_REQUEST) { +- bacpy(&hdev->wake_addr, &conn_complete->bdaddr); ++ bacpy(&hdev->wake_addr, &conn_request->bdaddr); + hdev->wake_addr_type = BDADDR_BREDR; + } else if (event == HCI_EV_CONN_COMPLETE) { +- bacpy(&hdev->wake_addr, &conn_request->bdaddr); ++ bacpy(&hdev->wake_addr, &conn_complete->bdaddr); + hdev->wake_addr_type = BDADDR_BREDR; + } else if (event == HCI_EV_LE_META) { + struct hci_ev_le_meta *le_ev = (void *)skb->data; +-- +2.43.0 + diff --git a/queue-5.10/efi-capsule-loader-fix-incorrect-allocation-size.patch b/queue-5.10/efi-capsule-loader-fix-incorrect-allocation-size.patch new file mode 100644 index 00000000000..3f12673a6dc --- /dev/null +++ b/queue-5.10/efi-capsule-loader-fix-incorrect-allocation-size.patch @@ -0,0 +1,43 @@ +From 1d86fb8a2eeafba036c07f733546a5677bd9cbb0 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Mon, 12 Feb 2024 12:24:40 +0100 +Subject: efi/capsule-loader: fix incorrect allocation size + +From: Arnd Bergmann + +[ Upstream commit fccfa646ef3628097d59f7d9c1a3e84d4b6bb45e ] + +gcc-14 notices that the allocation with sizeof(void) on 32-bit architectures +is not enough for a 64-bit phys_addr_t: + +drivers/firmware/efi/capsule-loader.c: In function 'efi_capsule_open': +drivers/firmware/efi/capsule-loader.c:295:24: error: allocation of insufficient size '4' for type 'phys_addr_t' {aka 'long long unsigned int'} with size '8' [-Werror=alloc-size] + 295 | cap_info->phys = kzalloc(sizeof(void *), GFP_KERNEL); + | ^ + +Use the correct type instead here. + +Fixes: f24c4d478013 ("efi/capsule-loader: Reinstate virtual capsule mapping") +Signed-off-by: Arnd Bergmann +Signed-off-by: Ard Biesheuvel +Signed-off-by: Sasha Levin +--- + drivers/firmware/efi/capsule-loader.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/drivers/firmware/efi/capsule-loader.c b/drivers/firmware/efi/capsule-loader.c +index 3e8d4b51a8140..97bafb5f70389 100644 +--- a/drivers/firmware/efi/capsule-loader.c ++++ b/drivers/firmware/efi/capsule-loader.c +@@ -292,7 +292,7 @@ static int efi_capsule_open(struct inode *inode, struct file *file) + return -ENOMEM; + } + +- cap_info->phys = kzalloc(sizeof(void *), GFP_KERNEL); ++ cap_info->phys = kzalloc(sizeof(phys_addr_t), GFP_KERNEL); + if (!cap_info->phys) { + kfree(cap_info->pages); + kfree(cap_info); +-- +2.43.0 + diff --git a/queue-5.10/ipv6-fix-potential-struct-net-leak-in-inet6_rtm_geta.patch b/queue-5.10/ipv6-fix-potential-struct-net-leak-in-inet6_rtm_geta.patch new file mode 100644 index 00000000000..aa7bcfe7e27 --- /dev/null +++ b/queue-5.10/ipv6-fix-potential-struct-net-leak-in-inet6_rtm_geta.patch @@ -0,0 +1,45 @@ +From ca7d38a04a22481e03b3d54e697ccb99acc1247d Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 22 Feb 2024 12:17:47 +0000 +Subject: ipv6: fix potential "struct net" leak in inet6_rtm_getaddr() + +From: Eric Dumazet + +[ Upstream commit 10bfd453da64a057bcfd1a49fb6b271c48653cdb ] + +It seems that if userspace provides a correct IFA_TARGET_NETNSID value +but no IFA_ADDRESS and IFA_LOCAL attributes, inet6_rtm_getaddr() +returns -EINVAL with an elevated "struct net" refcount. + +Fixes: 6ecf4c37eb3e ("ipv6: enable IFA_TARGET_NETNSID for RTM_GETADDR") +Signed-off-by: Eric Dumazet +Cc: Christian Brauner +Cc: David Ahern +Reviewed-by: David Ahern +Signed-off-by: David S. Miller +Signed-off-by: Sasha Levin +--- + net/ipv6/addrconf.c | 7 ++++--- + 1 file changed, 4 insertions(+), 3 deletions(-) + +diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c +index 150c2f71ec89f..0429c1d50fc92 100644 +--- a/net/ipv6/addrconf.c ++++ b/net/ipv6/addrconf.c +@@ -5436,9 +5436,10 @@ static int inet6_rtm_getaddr(struct sk_buff *in_skb, struct nlmsghdr *nlh, + } + + addr = extract_addr(tb[IFA_ADDRESS], tb[IFA_LOCAL], &peer); +- if (!addr) +- return -EINVAL; +- ++ if (!addr) { ++ err = -EINVAL; ++ goto errout; ++ } + ifm = nlmsg_data(nlh); + if (ifm->ifa_index) + dev = dev_get_by_index(tgt_net, ifm->ifa_index); +-- +2.43.0 + diff --git a/queue-5.10/lan78xx-enable-auto-speed-configuration-for-lan7850-.patch b/queue-5.10/lan78xx-enable-auto-speed-configuration-for-lan7850-.patch new file mode 100644 index 00000000000..cc282db8f8b --- /dev/null +++ b/queue-5.10/lan78xx-enable-auto-speed-configuration-for-lan7850-.patch @@ -0,0 +1,45 @@ +From 129cd332b3aff5b65c6878a79a90326e46a4a177 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 22 Feb 2024 13:38:38 +0100 +Subject: lan78xx: enable auto speed configuration for LAN7850 if no EEPROM is + detected + +From: Oleksij Rempel + +[ Upstream commit 0e67899abfbfdea0c3c0ed3fd263ffc601c5c157 ] + +Same as LAN7800, LAN7850 can be used without EEPROM. If EEPROM is not +present or not flashed, LAN7850 will fail to sync the speed detected by the PHY +with the MAC. In case link speed is 100Mbit, it will accidentally work, +otherwise no data can be transferred. + +Better way would be to implement link_up callback, or set auto speed +configuration unconditionally. But this changes would be more intrusive. +So, for now, set it only if no EEPROM is found. + +Fixes: e69647a19c87 ("lan78xx: Set ASD in MAC_CR when EEE is enabled.") +Signed-off-by: Oleksij Rempel +Link: https://lore.kernel.org/r/20240222123839.2816561-1-o.rempel@pengutronix.de +Signed-off-by: Jakub Kicinski +Signed-off-by: Sasha Levin +--- + drivers/net/usb/lan78xx.c | 3 ++- + 1 file changed, 2 insertions(+), 1 deletion(-) + +diff --git a/drivers/net/usb/lan78xx.c b/drivers/net/usb/lan78xx.c +index 667984efeb3be..c5a666bb86ee4 100644 +--- a/drivers/net/usb/lan78xx.c ++++ b/drivers/net/usb/lan78xx.c +@@ -2527,7 +2527,8 @@ static int lan78xx_reset(struct lan78xx_net *dev) + if (dev->chipid == ID_REV_CHIP_ID_7801_) + buf &= ~MAC_CR_GMII_EN_; + +- if (dev->chipid == ID_REV_CHIP_ID_7800_) { ++ if (dev->chipid == ID_REV_CHIP_ID_7800_ || ++ dev->chipid == ID_REV_CHIP_ID_7850_) { + ret = lan78xx_read_raw_eeprom(dev, 0, 1, &sig); + if (!ret && sig != EEPROM_INDICATOR) { + /* Implies there is no external eeprom. Set mac speed */ +-- +2.43.0 + diff --git a/queue-5.10/mtd-spinand-gigadevice-fix-the-get-ecc-status-issue.patch b/queue-5.10/mtd-spinand-gigadevice-fix-the-get-ecc-status-issue.patch new file mode 100644 index 00000000000..f3d87d79b96 --- /dev/null +++ b/queue-5.10/mtd-spinand-gigadevice-fix-the-get-ecc-status-issue.patch @@ -0,0 +1,63 @@ +From f9289f3a26f81245d85dfe9a6918d3305eea252a Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Wed, 8 Nov 2023 09:07:01 -0600 +Subject: mtd: spinand: gigadevice: Fix the get ecc status issue + +From: Han Xu + +[ Upstream commit 59950610c0c00c7a06d8a75d2ee5d73dba4274cf ] + +Some GigaDevice ecc_get_status functions use on-stack buffer for +spi_mem_op causes spi_mem_check_op failing, fix the issue by using +spinand scratchbuf. + +Fixes: c40c7a990a46 ("mtd: spinand: Add support for GigaDevice GD5F1GQ4UExxG") +Signed-off-by: Han Xu +Signed-off-by: Miquel Raynal +Link: https://lore.kernel.org/linux-mtd/20231108150701.593912-1-han.xu@nxp.com +Signed-off-by: Sasha Levin +--- + drivers/mtd/nand/spi/gigadevice.c | 6 ++++-- + 1 file changed, 4 insertions(+), 2 deletions(-) + +diff --git a/drivers/mtd/nand/spi/gigadevice.c b/drivers/mtd/nand/spi/gigadevice.c +index 1dd1c58980934..313fd45174dd5 100644 +--- a/drivers/mtd/nand/spi/gigadevice.c ++++ b/drivers/mtd/nand/spi/gigadevice.c +@@ -170,7 +170,7 @@ static int gd5fxgq4uexxg_ecc_get_status(struct spinand_device *spinand, + { + u8 status2; + struct spi_mem_op op = SPINAND_GET_FEATURE_OP(GD5FXGQXXEXXG_REG_STATUS2, +- &status2); ++ spinand->scratchbuf); + int ret; + + switch (status & STATUS_ECC_MASK) { +@@ -191,6 +191,7 @@ static int gd5fxgq4uexxg_ecc_get_status(struct spinand_device *spinand, + * report the maximum of 4 in this case + */ + /* bits sorted this way (3...0): ECCS1,ECCS0,ECCSE1,ECCSE0 */ ++ status2 = *(spinand->scratchbuf); + return ((status & STATUS_ECC_MASK) >> 2) | + ((status2 & STATUS_ECC_MASK) >> 4); + +@@ -212,7 +213,7 @@ static int gd5fxgq5xexxg_ecc_get_status(struct spinand_device *spinand, + { + u8 status2; + struct spi_mem_op op = SPINAND_GET_FEATURE_OP(GD5FXGQXXEXXG_REG_STATUS2, +- &status2); ++ spinand->scratchbuf); + int ret; + + switch (status & STATUS_ECC_MASK) { +@@ -232,6 +233,7 @@ static int gd5fxgq5xexxg_ecc_get_status(struct spinand_device *spinand, + * 1 ... 4 bits are flipped (and corrected) + */ + /* bits sorted this way (1...0): ECCSE1, ECCSE0 */ ++ status2 = *(spinand->scratchbuf); + return ((status2 & STATUS_ECC_MASK) >> 4) + 1; + + case STATUS_ECC_UNCOR_ERROR: +-- +2.43.0 + diff --git a/queue-5.10/mtd-spinand-gigadevice-support-gd5f1gq5uexxg.patch b/queue-5.10/mtd-spinand-gigadevice-support-gd5f1gq5uexxg.patch new file mode 100644 index 00000000000..80b8f5ec29b --- /dev/null +++ b/queue-5.10/mtd-spinand-gigadevice-support-gd5f1gq5uexxg.patch @@ -0,0 +1,182 @@ +From da023abc097fe246c78100fc8f1d2444e83226c3 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 11 Feb 2021 12:36:19 +0100 +Subject: mtd: spinand: gigadevice: Support GD5F1GQ5UExxG + +From: Reto Schneider + +[ Upstream commit 469b992489852b500d39048aa0013639dfe9f2e6 ] + +The relevant changes to the already existing GD5F1GQ4UExxG support has +been determined by consulting the GigaDevice product change notice +AN-0392-10, version 1.0 from November 30, 2020. + +As the overlaps are huge, variable names have been generalized +accordingly. + +Apart from the lowered ECC strength (4 instead of 8 bits per 512 bytes), +the new device ID, and the extra quad IO dummy byte, no changes had to +be taken into account. + +New hardware features are not supported, namely: + - Power on reset + - Unique ID + - Double transfer rate (DTR) + - Parameter page + - Random data quad IO + +The inverted semantic of the "driver strength" register bits, defaulting +to 100% instead of 50% for the Q5 devices, got ignored as the driver has +never touched them anyway. + +The no longer supported "read from cache during block erase" +functionality is not reflected as the current SPI NAND core does not +support it anyway. + +Implementation has been tested on MediaTek MT7688 based GARDENA smart +Gateways using both, GigaDevice GD5F1GQ5UEYIG and GD5F1GQ4UBYIG. + +Signed-off-by: Reto Schneider +Reviewed-by: Frieder Schrempf +Reviewed-by: Stefan Roese +Signed-off-by: Miquel Raynal +Link: https://lore.kernel.org/linux-mtd/20210211113619.3502-1-code@reto-schneider.ch +Stable-dep-of: 59950610c0c0 ("mtd: spinand: gigadevice: Fix the get ecc status issue") +Signed-off-by: Sasha Levin +--- + drivers/mtd/nand/spi/gigadevice.c | 69 +++++++++++++++++++++++++++---- + 1 file changed, 60 insertions(+), 9 deletions(-) + +diff --git a/drivers/mtd/nand/spi/gigadevice.c b/drivers/mtd/nand/spi/gigadevice.c +index 33c67403c4aa1..1dd1c58980934 100644 +--- a/drivers/mtd/nand/spi/gigadevice.c ++++ b/drivers/mtd/nand/spi/gigadevice.c +@@ -13,7 +13,10 @@ + #define GD5FXGQ4XA_STATUS_ECC_1_7_BITFLIPS (1 << 4) + #define GD5FXGQ4XA_STATUS_ECC_8_BITFLIPS (3 << 4) + +-#define GD5FXGQ4UEXXG_REG_STATUS2 0xf0 ++#define GD5FXGQ5XE_STATUS_ECC_1_4_BITFLIPS (1 << 4) ++#define GD5FXGQ5XE_STATUS_ECC_4_BITFLIPS (3 << 4) ++ ++#define GD5FXGQXXEXXG_REG_STATUS2 0xf0 + + #define GD5FXGQ4UXFXXG_STATUS_ECC_MASK (7 << 4) + #define GD5FXGQ4UXFXXG_STATUS_ECC_NO_BITFLIPS (0 << 4) +@@ -102,7 +105,7 @@ static int gd5fxgq4xa_ecc_get_status(struct spinand_device *spinand, + return -EINVAL; + } + +-static int gd5fxgq4_variant2_ooblayout_ecc(struct mtd_info *mtd, int section, ++static int gd5fxgqx_variant2_ooblayout_ecc(struct mtd_info *mtd, int section, + struct mtd_oob_region *region) + { + if (section) +@@ -114,7 +117,7 @@ static int gd5fxgq4_variant2_ooblayout_ecc(struct mtd_info *mtd, int section, + return 0; + } + +-static int gd5fxgq4_variant2_ooblayout_free(struct mtd_info *mtd, int section, ++static int gd5fxgqx_variant2_ooblayout_free(struct mtd_info *mtd, int section, + struct mtd_oob_region *region) + { + if (section) +@@ -127,9 +130,10 @@ static int gd5fxgq4_variant2_ooblayout_free(struct mtd_info *mtd, int section, + return 0; + } + +-static const struct mtd_ooblayout_ops gd5fxgq4_variant2_ooblayout = { +- .ecc = gd5fxgq4_variant2_ooblayout_ecc, +- .free = gd5fxgq4_variant2_ooblayout_free, ++/* Valid for Q4/Q5 and Q6 (untested) devices */ ++static const struct mtd_ooblayout_ops gd5fxgqx_variant2_ooblayout = { ++ .ecc = gd5fxgqx_variant2_ooblayout_ecc, ++ .free = gd5fxgqx_variant2_ooblayout_free, + }; + + static int gd5fxgq4xc_ooblayout_256_ecc(struct mtd_info *mtd, int section, +@@ -165,7 +169,7 @@ static int gd5fxgq4uexxg_ecc_get_status(struct spinand_device *spinand, + u8 status) + { + u8 status2; +- struct spi_mem_op op = SPINAND_GET_FEATURE_OP(GD5FXGQ4UEXXG_REG_STATUS2, ++ struct spi_mem_op op = SPINAND_GET_FEATURE_OP(GD5FXGQXXEXXG_REG_STATUS2, + &status2); + int ret; + +@@ -203,6 +207,43 @@ static int gd5fxgq4uexxg_ecc_get_status(struct spinand_device *spinand, + return -EINVAL; + } + ++static int gd5fxgq5xexxg_ecc_get_status(struct spinand_device *spinand, ++ u8 status) ++{ ++ u8 status2; ++ struct spi_mem_op op = SPINAND_GET_FEATURE_OP(GD5FXGQXXEXXG_REG_STATUS2, ++ &status2); ++ int ret; ++ ++ switch (status & STATUS_ECC_MASK) { ++ case STATUS_ECC_NO_BITFLIPS: ++ return 0; ++ ++ case GD5FXGQ5XE_STATUS_ECC_1_4_BITFLIPS: ++ /* ++ * Read status2 register to determine a more fine grained ++ * bit error status ++ */ ++ ret = spi_mem_exec_op(spinand->spimem, &op); ++ if (ret) ++ return ret; ++ ++ /* ++ * 1 ... 4 bits are flipped (and corrected) ++ */ ++ /* bits sorted this way (1...0): ECCSE1, ECCSE0 */ ++ return ((status2 & STATUS_ECC_MASK) >> 4) + 1; ++ ++ case STATUS_ECC_UNCOR_ERROR: ++ return -EBADMSG; ++ ++ default: ++ break; ++ } ++ ++ return -EINVAL; ++} ++ + static int gd5fxgq4ufxxg_ecc_get_status(struct spinand_device *spinand, + u8 status) + { +@@ -282,7 +323,7 @@ static const struct spinand_info gigadevice_spinand_table[] = { + &write_cache_variants, + &update_cache_variants), + SPINAND_HAS_QE_BIT, +- SPINAND_ECCINFO(&gd5fxgq4_variant2_ooblayout, ++ SPINAND_ECCINFO(&gd5fxgqx_variant2_ooblayout, + gd5fxgq4uexxg_ecc_get_status)), + SPINAND_INFO("GD5F1GQ4UFxxG", + SPINAND_ID(SPINAND_READID_METHOD_OPCODE, 0xb1, 0x48), +@@ -292,8 +333,18 @@ static const struct spinand_info gigadevice_spinand_table[] = { + &write_cache_variants, + &update_cache_variants), + SPINAND_HAS_QE_BIT, +- SPINAND_ECCINFO(&gd5fxgq4_variant2_ooblayout, ++ SPINAND_ECCINFO(&gd5fxgqx_variant2_ooblayout, + gd5fxgq4ufxxg_ecc_get_status)), ++ SPINAND_INFO("GD5F1GQ5UExxG", ++ SPINAND_ID(SPINAND_READID_METHOD_OPCODE_DUMMY, 0x51), ++ NAND_MEMORG(1, 2048, 128, 64, 1024, 20, 1, 1, 1), ++ NAND_ECCREQ(4, 512), ++ SPINAND_INFO_OP_VARIANTS(&read_cache_variants, ++ &write_cache_variants, ++ &update_cache_variants), ++ SPINAND_HAS_QE_BIT, ++ SPINAND_ECCINFO(&gd5fxgqx_variant2_ooblayout, ++ gd5fxgq5xexxg_ecc_get_status)), + }; + + static const struct spinand_manufacturer_ops gigadevice_spinand_manuf_ops = { +-- +2.43.0 + diff --git a/queue-5.10/net-ip_tunnel-prevent-perpetual-headroom-growth.patch b/queue-5.10/net-ip_tunnel-prevent-perpetual-headroom-growth.patch new file mode 100644 index 00000000000..732487e266a --- /dev/null +++ b/queue-5.10/net-ip_tunnel-prevent-perpetual-headroom-growth.patch @@ -0,0 +1,181 @@ +From 4cc9714e4310cecd4befc504efdc5c18598dcc81 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Tue, 20 Feb 2024 14:56:02 +0100 +Subject: net: ip_tunnel: prevent perpetual headroom growth + +From: Florian Westphal + +[ Upstream commit 5ae1e9922bbdbaeb9cfbe91085ab75927488ac0f ] + +syzkaller triggered following kasan splat: +BUG: KASAN: use-after-free in __skb_flow_dissect+0x19d1/0x7a50 net/core/flow_dissector.c:1170 +Read of size 1 at addr ffff88812fb4000e by task syz-executor183/5191 +[..] + kasan_report+0xda/0x110 mm/kasan/report.c:588 + __skb_flow_dissect+0x19d1/0x7a50 net/core/flow_dissector.c:1170 + skb_flow_dissect_flow_keys include/linux/skbuff.h:1514 [inline] + ___skb_get_hash net/core/flow_dissector.c:1791 [inline] + __skb_get_hash+0xc7/0x540 net/core/flow_dissector.c:1856 + skb_get_hash include/linux/skbuff.h:1556 [inline] + ip_tunnel_xmit+0x1855/0x33c0 net/ipv4/ip_tunnel.c:748 + ipip_tunnel_xmit+0x3cc/0x4e0 net/ipv4/ipip.c:308 + __netdev_start_xmit include/linux/netdevice.h:4940 [inline] + netdev_start_xmit include/linux/netdevice.h:4954 [inline] + xmit_one net/core/dev.c:3548 [inline] + dev_hard_start_xmit+0x13d/0x6d0 net/core/dev.c:3564 + __dev_queue_xmit+0x7c1/0x3d60 net/core/dev.c:4349 + dev_queue_xmit include/linux/netdevice.h:3134 [inline] + neigh_connected_output+0x42c/0x5d0 net/core/neighbour.c:1592 + ... + ip_finish_output2+0x833/0x2550 net/ipv4/ip_output.c:235 + ip_finish_output+0x31/0x310 net/ipv4/ip_output.c:323 + .. + iptunnel_xmit+0x5b4/0x9b0 net/ipv4/ip_tunnel_core.c:82 + ip_tunnel_xmit+0x1dbc/0x33c0 net/ipv4/ip_tunnel.c:831 + ipgre_xmit+0x4a1/0x980 net/ipv4/ip_gre.c:665 + __netdev_start_xmit include/linux/netdevice.h:4940 [inline] + netdev_start_xmit include/linux/netdevice.h:4954 [inline] + xmit_one net/core/dev.c:3548 [inline] + dev_hard_start_xmit+0x13d/0x6d0 net/core/dev.c:3564 + ... + +The splat occurs because skb->data points past skb->head allocated area. +This is because neigh layer does: + __skb_pull(skb, skb_network_offset(skb)); + +... but skb_network_offset() returns a negative offset and __skb_pull() +arg is unsigned. IOW, we skb->data gets "adjusted" by a huge value. + +The negative value is returned because skb->head and skb->data distance is +more than 64k and skb->network_header (u16) has wrapped around. + +The bug is in the ip_tunnel infrastructure, which can cause +dev->needed_headroom to increment ad infinitum. + +The syzkaller reproducer consists of packets getting routed via a gre +tunnel, and route of gre encapsulated packets pointing at another (ipip) +tunnel. The ipip encapsulation finds gre0 as next output device. + +This results in the following pattern: + +1). First packet is to be sent out via gre0. +Route lookup found an output device, ipip0. + +2). +ip_tunnel_xmit for gre0 bumps gre0->needed_headroom based on the future +output device, rt.dev->needed_headroom (ipip0). + +3). +ip output / start_xmit moves skb on to ipip0. which runs the same +code path again (xmit recursion). + +4). +Routing step for the post-gre0-encap packet finds gre0 as output device +to use for ipip0 encapsulated packet. + +tunl0->needed_headroom is then incremented based on the (already bumped) +gre0 device headroom. + +This repeats for every future packet: + +gre0->needed_headroom gets inflated because previous packets' ipip0 step +incremented rt->dev (gre0) headroom, and ipip0 incremented because gre0 +needed_headroom was increased. + +For each subsequent packet, gre/ipip0->needed_headroom grows until +post-expand-head reallocations result in a skb->head/data distance of +more than 64k. + +Once that happens, skb->network_header (u16) wraps around when +pskb_expand_head tries to make sure that skb_network_offset() is unchanged +after the headroom expansion/reallocation. + +After this skb_network_offset(skb) returns a different (and negative) +result post headroom expansion. + +The next trip to neigh layer (or anything else that would __skb_pull the +network header) makes skb->data point to a memory location outside +skb->head area. + +v2: Cap the needed_headroom update to an arbitarily chosen upperlimit to +prevent perpetual increase instead of dropping the headroom increment +completely. + +Reported-and-tested-by: syzbot+bfde3bef047a81b8fde6@syzkaller.appspotmail.com +Closes: https://groups.google.com/g/syzkaller-bugs/c/fL9G6GtWskY/m/VKk_PR5FBAAJ +Fixes: 243aad830e8a ("ip_gre: include route header_len in max_headroom calculation") +Signed-off-by: Florian Westphal +Reviewed-by: Simon Horman +Link: https://lore.kernel.org/r/20240220135606.4939-1-fw@strlen.de +Signed-off-by: Jakub Kicinski +Signed-off-by: Sasha Levin +--- + net/ipv4/ip_tunnel.c | 28 +++++++++++++++++++++------- + 1 file changed, 21 insertions(+), 7 deletions(-) + +diff --git a/net/ipv4/ip_tunnel.c b/net/ipv4/ip_tunnel.c +index 99f70b990eb13..50f8231e9daec 100644 +--- a/net/ipv4/ip_tunnel.c ++++ b/net/ipv4/ip_tunnel.c +@@ -540,6 +540,20 @@ static int tnl_update_pmtu(struct net_device *dev, struct sk_buff *skb, + return 0; + } + ++static void ip_tunnel_adj_headroom(struct net_device *dev, unsigned int headroom) ++{ ++ /* we must cap headroom to some upperlimit, else pskb_expand_head ++ * will overflow header offsets in skb_headers_offset_update(). ++ */ ++ static const unsigned int max_allowed = 512; ++ ++ if (headroom > max_allowed) ++ headroom = max_allowed; ++ ++ if (headroom > READ_ONCE(dev->needed_headroom)) ++ WRITE_ONCE(dev->needed_headroom, headroom); ++} ++ + void ip_md_tunnel_xmit(struct sk_buff *skb, struct net_device *dev, + u8 proto, int tunnel_hlen) + { +@@ -613,13 +627,13 @@ void ip_md_tunnel_xmit(struct sk_buff *skb, struct net_device *dev, + } + + headroom += LL_RESERVED_SPACE(rt->dst.dev) + rt->dst.header_len; +- if (headroom > READ_ONCE(dev->needed_headroom)) +- WRITE_ONCE(dev->needed_headroom, headroom); +- +- if (skb_cow_head(skb, READ_ONCE(dev->needed_headroom))) { ++ if (skb_cow_head(skb, headroom)) { + ip_rt_put(rt); + goto tx_dropped; + } ++ ++ ip_tunnel_adj_headroom(dev, headroom); ++ + iptunnel_xmit(NULL, rt, skb, fl4.saddr, fl4.daddr, proto, tos, ttl, + df, !net_eq(tunnel->net, dev_net(dev))); + return; +@@ -797,16 +811,16 @@ void ip_tunnel_xmit(struct sk_buff *skb, struct net_device *dev, + + max_headroom = LL_RESERVED_SPACE(rt->dst.dev) + sizeof(struct iphdr) + + rt->dst.header_len + ip_encap_hlen(&tunnel->encap); +- if (max_headroom > READ_ONCE(dev->needed_headroom)) +- WRITE_ONCE(dev->needed_headroom, max_headroom); + +- if (skb_cow_head(skb, READ_ONCE(dev->needed_headroom))) { ++ if (skb_cow_head(skb, max_headroom)) { + ip_rt_put(rt); + dev->stats.tx_dropped++; + kfree_skb(skb); + return; + } + ++ ip_tunnel_adj_headroom(dev, max_headroom); ++ + iptunnel_xmit(NULL, rt, skb, fl4.saddr, fl4.daddr, protocol, tos, ttl, + df, !net_eq(tunnel->net, dev_net(dev))); + return; +-- +2.43.0 + diff --git a/queue-5.10/net-usb-dm9601-fix-wrong-return-value-in-dm9601_mdio.patch b/queue-5.10/net-usb-dm9601-fix-wrong-return-value-in-dm9601_mdio.patch new file mode 100644 index 00000000000..ec3946ff75f --- /dev/null +++ b/queue-5.10/net-usb-dm9601-fix-wrong-return-value-in-dm9601_mdio.patch @@ -0,0 +1,49 @@ +From 93d4425915131a919c9a80a871258c179a0f0520 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Sun, 25 Feb 2024 00:20:06 +0100 +Subject: net: usb: dm9601: fix wrong return value in dm9601_mdio_read + +From: Javier Carrasco + +[ Upstream commit c68b2c9eba38ec3f60f4894b189090febf4d8d22 ] + +The MII code does not check the return value of mdio_read (among +others), and therefore no error code should be sent. A previous fix to +the use of an uninitialized variable propagates negative error codes, +that might lead to wrong operations by the MII library. + +An example of such issues is the use of mii_nway_restart by the dm9601 +driver. The mii_nway_restart function does not check the value returned +by mdio_read, which in this case might be a negative number which could +contain the exact bit the function checks (BMCR_ANENABLE = 0x1000). + +Return zero in case of error, as it is common practice in users of +mdio_read to avoid wrong uses of the return value. + +Fixes: 8f8abb863fa5 ("net: usb: dm9601: fix uninitialized variable use in dm9601_mdio_read") +Signed-off-by: Javier Carrasco +Reviewed-by: Simon Horman +Reviewed-by: Peter Korsgaard +Link: https://lore.kernel.org/r/20240225-dm9601_ret_err-v1-1-02c1d959ea59@gmail.com +Signed-off-by: Jakub Kicinski +Signed-off-by: Sasha Levin +--- + drivers/net/usb/dm9601.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/drivers/net/usb/dm9601.c b/drivers/net/usb/dm9601.c +index 5aad26600b03e..9b7db5fd9e08f 100644 +--- a/drivers/net/usb/dm9601.c ++++ b/drivers/net/usb/dm9601.c +@@ -231,7 +231,7 @@ static int dm9601_mdio_read(struct net_device *netdev, int phy_id, int loc) + err = dm_read_shared_word(dev, 1, loc, &res); + if (err < 0) { + netdev_err(dev->net, "MDIO read error: %d\n", err); +- return err; ++ return 0; + } + + netdev_dbg(dev->net, +-- +2.43.0 + diff --git a/queue-5.10/netfilter-nf_tables-allow-nfproto_inet-in-nft_-match.patch b/queue-5.10/netfilter-nf_tables-allow-nfproto_inet-in-nft_-match.patch new file mode 100644 index 00000000000..d3555a272c8 --- /dev/null +++ b/queue-5.10/netfilter-nf_tables-allow-nfproto_inet-in-nft_-match.patch @@ -0,0 +1,108 @@ +From 2ece0f0ebc9bbda4502e89abd51b7cfdbe0fc173 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 22 Feb 2024 10:33:08 +0000 +Subject: netfilter: nf_tables: allow NFPROTO_INET in + nft_(match/target)_validate() + +From: Ignat Korchagin + +[ Upstream commit 7e0f122c65912740327e4c54472acaa5f85868cb ] + +Commit d0009effa886 ("netfilter: nf_tables: validate NFPROTO_* family") added +some validation of NFPROTO_* families in the nft_compat module, but it broke +the ability to use legacy iptables modules in dual-stack nftables. + +While with legacy iptables one had to independently manage IPv4 and IPv6 +tables, with nftables it is possible to have dual-stack tables sharing the +rules. Moreover, it was possible to use rules based on legacy iptables +match/target modules in dual-stack nftables. + +As an example, the program from [2] creates an INET dual-stack family table +using an xt_bpf based rule, which looks like the following (the actual output +was generated with a patched nft tool as the current nft tool does not parse +dual stack tables with legacy match rules, so consider it for illustrative +purposes only): + +table inet testfw { + chain input { + type filter hook prerouting priority filter; policy accept; + bytecode counter packets 0 bytes 0 accept + } +} + +After d0009effa886 ("netfilter: nf_tables: validate NFPROTO_* family") we get +EOPNOTSUPP for the above program. + +Fix this by allowing NFPROTO_INET for nft_(match/target)_validate(), but also +restrict the functions to classic iptables hooks. + +Changes in v3: + * clarify that upstream nft will not display such configuration properly and + that the output was generated with a patched nft tool + * remove example program from commit description and link to it instead + * no code changes otherwise + +Changes in v2: + * restrict nft_(match/target)_validate() to classic iptables hooks + * rewrite example program to use unmodified libnftnl + +Fixes: d0009effa886 ("netfilter: nf_tables: validate NFPROTO_* family") +Link: https://lore.kernel.org/all/Zc1PfoWN38UuFJRI@calendula/T/#mc947262582c90fec044c7a3398cc92fac7afea72 [1] +Link: https://lore.kernel.org/all/20240220145509.53357-1-ignat@cloudflare.com/ [2] +Reported-by: Jordan Griege +Signed-off-by: Ignat Korchagin +Signed-off-by: Pablo Neira Ayuso +Signed-off-by: Sasha Levin +--- + net/netfilter/nft_compat.c | 20 ++++++++++++++++++++ + 1 file changed, 20 insertions(+) + +diff --git a/net/netfilter/nft_compat.c b/net/netfilter/nft_compat.c +index 77c7362a7db8e..3e0a6e7930c6c 100644 +--- a/net/netfilter/nft_compat.c ++++ b/net/netfilter/nft_compat.c +@@ -336,10 +336,20 @@ static int nft_target_validate(const struct nft_ctx *ctx, + + if (ctx->family != NFPROTO_IPV4 && + ctx->family != NFPROTO_IPV6 && ++ ctx->family != NFPROTO_INET && + ctx->family != NFPROTO_BRIDGE && + ctx->family != NFPROTO_ARP) + return -EOPNOTSUPP; + ++ ret = nft_chain_validate_hooks(ctx->chain, ++ (1 << NF_INET_PRE_ROUTING) | ++ (1 << NF_INET_LOCAL_IN) | ++ (1 << NF_INET_FORWARD) | ++ (1 << NF_INET_LOCAL_OUT) | ++ (1 << NF_INET_POST_ROUTING)); ++ if (ret) ++ return ret; ++ + if (nft_is_base_chain(ctx->chain)) { + const struct nft_base_chain *basechain = + nft_base_chain(ctx->chain); +@@ -584,10 +594,20 @@ static int nft_match_validate(const struct nft_ctx *ctx, + + if (ctx->family != NFPROTO_IPV4 && + ctx->family != NFPROTO_IPV6 && ++ ctx->family != NFPROTO_INET && + ctx->family != NFPROTO_BRIDGE && + ctx->family != NFPROTO_ARP) + return -EOPNOTSUPP; + ++ ret = nft_chain_validate_hooks(ctx->chain, ++ (1 << NF_INET_PRE_ROUTING) | ++ (1 << NF_INET_LOCAL_IN) | ++ (1 << NF_INET_FORWARD) | ++ (1 << NF_INET_LOCAL_OUT) | ++ (1 << NF_INET_POST_ROUTING)); ++ if (ret) ++ return ret; ++ + if (nft_is_base_chain(ctx->chain)) { + const struct nft_base_chain *basechain = + nft_base_chain(ctx->chain); +-- +2.43.0 + diff --git a/queue-5.10/netlink-fix-kernel-infoleak-after-free-in-__skb_data.patch b/queue-5.10/netlink-fix-kernel-infoleak-after-free-in-__skb_data.patch new file mode 100644 index 00000000000..2855d3a892d --- /dev/null +++ b/queue-5.10/netlink-fix-kernel-infoleak-after-free-in-__skb_data.patch @@ -0,0 +1,134 @@ +From 88b0076ac8e105d466d176980cd1c5717d76bdc4 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Wed, 21 Feb 2024 16:40:48 +0900 +Subject: netlink: Fix kernel-infoleak-after-free in __skb_datagram_iter + +From: Ryosuke Yasuoka + +[ Upstream commit 661779e1fcafe1b74b3f3fe8e980c1e207fea1fd ] + +syzbot reported the following uninit-value access issue [1]: + +netlink_to_full_skb() creates a new `skb` and puts the `skb->data` +passed as a 1st arg of netlink_to_full_skb() onto new `skb`. The data +size is specified as `len` and passed to skb_put_data(). This `len` +is based on `skb->end` that is not data offset but buffer offset. The +`skb->end` contains data and tailroom. Since the tailroom is not +initialized when the new `skb` created, KMSAN detects uninitialized +memory area when copying the data. + +This patch resolved this issue by correct the len from `skb->end` to +`skb->len`, which is the actual data offset. + +BUG: KMSAN: kernel-infoleak-after-free in instrument_copy_to_user include/linux/instrumented.h:114 [inline] +BUG: KMSAN: kernel-infoleak-after-free in copy_to_user_iter lib/iov_iter.c:24 [inline] +BUG: KMSAN: kernel-infoleak-after-free in iterate_ubuf include/linux/iov_iter.h:29 [inline] +BUG: KMSAN: kernel-infoleak-after-free in iterate_and_advance2 include/linux/iov_iter.h:245 [inline] +BUG: KMSAN: kernel-infoleak-after-free in iterate_and_advance include/linux/iov_iter.h:271 [inline] +BUG: KMSAN: kernel-infoleak-after-free in _copy_to_iter+0x364/0x2520 lib/iov_iter.c:186 + instrument_copy_to_user include/linux/instrumented.h:114 [inline] + copy_to_user_iter lib/iov_iter.c:24 [inline] + iterate_ubuf include/linux/iov_iter.h:29 [inline] + iterate_and_advance2 include/linux/iov_iter.h:245 [inline] + iterate_and_advance include/linux/iov_iter.h:271 [inline] + _copy_to_iter+0x364/0x2520 lib/iov_iter.c:186 + copy_to_iter include/linux/uio.h:197 [inline] + simple_copy_to_iter+0x68/0xa0 net/core/datagram.c:532 + __skb_datagram_iter+0x123/0xdc0 net/core/datagram.c:420 + skb_copy_datagram_iter+0x5c/0x200 net/core/datagram.c:546 + skb_copy_datagram_msg include/linux/skbuff.h:3960 [inline] + packet_recvmsg+0xd9c/0x2000 net/packet/af_packet.c:3482 + sock_recvmsg_nosec net/socket.c:1044 [inline] + sock_recvmsg net/socket.c:1066 [inline] + sock_read_iter+0x467/0x580 net/socket.c:1136 + call_read_iter include/linux/fs.h:2014 [inline] + new_sync_read fs/read_write.c:389 [inline] + vfs_read+0x8f6/0xe00 fs/read_write.c:470 + ksys_read+0x20f/0x4c0 fs/read_write.c:613 + __do_sys_read fs/read_write.c:623 [inline] + __se_sys_read fs/read_write.c:621 [inline] + __x64_sys_read+0x93/0xd0 fs/read_write.c:621 + do_syscall_x64 arch/x86/entry/common.c:52 [inline] + do_syscall_64+0x44/0x110 arch/x86/entry/common.c:83 + entry_SYSCALL_64_after_hwframe+0x63/0x6b + +Uninit was stored to memory at: + skb_put_data include/linux/skbuff.h:2622 [inline] + netlink_to_full_skb net/netlink/af_netlink.c:181 [inline] + __netlink_deliver_tap_skb net/netlink/af_netlink.c:298 [inline] + __netlink_deliver_tap+0x5be/0xc90 net/netlink/af_netlink.c:325 + netlink_deliver_tap net/netlink/af_netlink.c:338 [inline] + netlink_deliver_tap_kernel net/netlink/af_netlink.c:347 [inline] + netlink_unicast_kernel net/netlink/af_netlink.c:1341 [inline] + netlink_unicast+0x10f1/0x1250 net/netlink/af_netlink.c:1368 + netlink_sendmsg+0x1238/0x13d0 net/netlink/af_netlink.c:1910 + sock_sendmsg_nosec net/socket.c:730 [inline] + __sock_sendmsg net/socket.c:745 [inline] + ____sys_sendmsg+0x9c2/0xd60 net/socket.c:2584 + ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2638 + __sys_sendmsg net/socket.c:2667 [inline] + __do_sys_sendmsg net/socket.c:2676 [inline] + __se_sys_sendmsg net/socket.c:2674 [inline] + __x64_sys_sendmsg+0x307/0x490 net/socket.c:2674 + do_syscall_x64 arch/x86/entry/common.c:52 [inline] + do_syscall_64+0x44/0x110 arch/x86/entry/common.c:83 + entry_SYSCALL_64_after_hwframe+0x63/0x6b + +Uninit was created at: + free_pages_prepare mm/page_alloc.c:1087 [inline] + free_unref_page_prepare+0xb0/0xa40 mm/page_alloc.c:2347 + free_unref_page_list+0xeb/0x1100 mm/page_alloc.c:2533 + release_pages+0x23d3/0x2410 mm/swap.c:1042 + free_pages_and_swap_cache+0xd9/0xf0 mm/swap_state.c:316 + tlb_batch_pages_flush mm/mmu_gather.c:98 [inline] + tlb_flush_mmu_free mm/mmu_gather.c:293 [inline] + tlb_flush_mmu+0x6f5/0x980 mm/mmu_gather.c:300 + tlb_finish_mmu+0x101/0x260 mm/mmu_gather.c:392 + exit_mmap+0x49e/0xd30 mm/mmap.c:3321 + __mmput+0x13f/0x530 kernel/fork.c:1349 + mmput+0x8a/0xa0 kernel/fork.c:1371 + exit_mm+0x1b8/0x360 kernel/exit.c:567 + do_exit+0xd57/0x4080 kernel/exit.c:858 + do_group_exit+0x2fd/0x390 kernel/exit.c:1021 + __do_sys_exit_group kernel/exit.c:1032 [inline] + __se_sys_exit_group kernel/exit.c:1030 [inline] + __x64_sys_exit_group+0x3c/0x50 kernel/exit.c:1030 + do_syscall_x64 arch/x86/entry/common.c:52 [inline] + do_syscall_64+0x44/0x110 arch/x86/entry/common.c:83 + entry_SYSCALL_64_after_hwframe+0x63/0x6b + +Bytes 3852-3903 of 3904 are uninitialized +Memory access of size 3904 starts at ffff88812ea1e000 +Data copied to user address 0000000020003280 + +CPU: 1 PID: 5043 Comm: syz-executor297 Not tainted 6.7.0-rc5-syzkaller-00047-g5bd7ef53ffe5 #0 +Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/10/2023 + +Fixes: 1853c9496460 ("netlink, mmap: transform mmap skb into full skb on taps") +Reported-and-tested-by: syzbot+34ad5fab48f7bf510349@syzkaller.appspotmail.com +Closes: https://syzkaller.appspot.com/bug?extid=34ad5fab48f7bf510349 [1] +Signed-off-by: Ryosuke Yasuoka +Reviewed-by: Eric Dumazet +Link: https://lore.kernel.org/r/20240221074053.1794118-1-ryasuoka@redhat.com +Signed-off-by: Jakub Kicinski +Signed-off-by: Sasha Levin +--- + net/netlink/af_netlink.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/net/netlink/af_netlink.c b/net/netlink/af_netlink.c +index 359f07a53eccf..a2b14434d7aa0 100644 +--- a/net/netlink/af_netlink.c ++++ b/net/netlink/af_netlink.c +@@ -157,7 +157,7 @@ static inline u32 netlink_group_mask(u32 group) + static struct sk_buff *netlink_to_full_skb(const struct sk_buff *skb, + gfp_t gfp_mask) + { +- unsigned int len = skb_end_offset(skb); ++ unsigned int len = skb->len; + struct sk_buff *new; + + new = alloc_skb(len, gfp_mask); +-- +2.43.0 + diff --git a/queue-5.10/power-supply-bq27xxx-i2c-do-not-free-non-existing-ir.patch b/queue-5.10/power-supply-bq27xxx-i2c-do-not-free-non-existing-ir.patch new file mode 100644 index 00000000000..62039df371f --- /dev/null +++ b/queue-5.10/power-supply-bq27xxx-i2c-do-not-free-non-existing-ir.patch @@ -0,0 +1,51 @@ +From b3982cd2c9345e0c8c607516191a783a2123a20f Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 15 Feb 2024 16:51:33 +0100 +Subject: power: supply: bq27xxx-i2c: Do not free non existing IRQ + +From: Hans de Goede + +[ Upstream commit 2df70149e73e79783bcbc7db4fa51ecef0e2022c ] + +The bq27xxx i2c-client may not have an IRQ, in which case +client->irq will be 0. bq27xxx_battery_i2c_probe() already has +an if (client->irq) check wrapping the request_threaded_irq(). + +But bq27xxx_battery_i2c_remove() unconditionally calls +free_irq(client->irq) leading to: + +[ 190.310742] ------------[ cut here ]------------ +[ 190.310843] Trying to free already-free IRQ 0 +[ 190.310861] WARNING: CPU: 2 PID: 1304 at kernel/irq/manage.c:1893 free_irq+0x1b8/0x310 + +Followed by a backtrace when unbinding the driver. Add +an if (client->irq) to bq27xxx_battery_i2c_remove() mirroring +probe() to fix this. + +Fixes: 444ff00734f3 ("power: supply: bq27xxx: Fix I2C IRQ race on remove") +Signed-off-by: Hans de Goede +Link: https://lore.kernel.org/r/20240215155133.70537-1-hdegoede@redhat.com +Signed-off-by: Sebastian Reichel +Signed-off-by: Sasha Levin +--- + drivers/power/supply/bq27xxx_battery_i2c.c | 4 +++- + 1 file changed, 3 insertions(+), 1 deletion(-) + +diff --git a/drivers/power/supply/bq27xxx_battery_i2c.c b/drivers/power/supply/bq27xxx_battery_i2c.c +index 0e32efb10ee78..6fbae8fc2e501 100644 +--- a/drivers/power/supply/bq27xxx_battery_i2c.c ++++ b/drivers/power/supply/bq27xxx_battery_i2c.c +@@ -209,7 +209,9 @@ static int bq27xxx_battery_i2c_remove(struct i2c_client *client) + { + struct bq27xxx_device_info *di = i2c_get_clientdata(client); + +- free_irq(client->irq, di); ++ if (client->irq) ++ free_irq(client->irq, di); ++ + bq27xxx_battery_teardown(di); + + mutex_lock(&battery_mutex); +-- +2.43.0 + diff --git a/queue-5.10/riscv-sparse-memory-vmemmap-out-of-bounds-fix.patch b/queue-5.10/riscv-sparse-memory-vmemmap-out-of-bounds-fix.patch new file mode 100644 index 00000000000..996d6e86a72 --- /dev/null +++ b/queue-5.10/riscv-sparse-memory-vmemmap-out-of-bounds-fix.patch @@ -0,0 +1,50 @@ +From 181010a2392c3fffb2dc1164f47bedee91f26a7e Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 29 Feb 2024 21:17:23 +0200 +Subject: riscv: Sparse-Memory/vmemmap out-of-bounds fix +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Dimitris Vlachos + +[ Upstream commit a11dd49dcb9376776193e15641f84fcc1e5980c9 ] + +Offset vmemmap so that the first page of vmemmap will be mapped +to the first page of physical memory in order to ensure that +vmemmap’s bounds will be respected during +pfn_to_page()/page_to_pfn() operations. +The conversion macros will produce correct SV39/48/57 addresses +for every possible/valid DRAM_BASE inside the physical memory limits. + +v2:Address Alex's comments + +Suggested-by: Alexandre Ghiti +Signed-off-by: Dimitris Vlachos +Reported-by: Dimitris Vlachos +Closes: https://lore.kernel.org/linux-riscv/20240202135030.42265-1-csd4492@csd.uoc.gr +Fixes: d95f1a542c3d ("RISC-V: Implement sparsemem") +Reviewed-by: Alexandre Ghiti +Link: https://lore.kernel.org/r/20240229191723.32779-1-dvlachos@ics.forth.gr +Signed-off-by: Palmer Dabbelt +Signed-off-by: Sasha Levin +--- + arch/riscv/include/asm/pgtable.h | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/arch/riscv/include/asm/pgtable.h b/arch/riscv/include/asm/pgtable.h +index b16304fdf4489..5ab13570daa53 100644 +--- a/arch/riscv/include/asm/pgtable.h ++++ b/arch/riscv/include/asm/pgtable.h +@@ -44,7 +44,7 @@ + * Define vmemmap for pfn_to_page & page_to_pfn calls. Needed if kernel + * is configured with CONFIG_SPARSEMEM_VMEMMAP enabled. + */ +-#define vmemmap ((struct page *)VMEMMAP_START) ++#define vmemmap ((struct page *)VMEMMAP_START - (phys_ram_base >> PAGE_SHIFT)) + + #define PCI_IO_SIZE SZ_16M + #define PCI_IO_END VMEMMAP_START +-- +2.43.0 + diff --git a/queue-5.10/rtnetlink-fix-error-logic-of-ifla_bridge_flags-writi.patch b/queue-5.10/rtnetlink-fix-error-logic-of-ifla_bridge_flags-writi.patch new file mode 100644 index 00000000000..3bec8fffbea --- /dev/null +++ b/queue-5.10/rtnetlink-fix-error-logic-of-ifla_bridge_flags-writi.patch @@ -0,0 +1,83 @@ +From bc110fd86202bab0cb321645f1c2ce36b9ea33bf Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Tue, 27 Feb 2024 20:11:28 +0800 +Subject: rtnetlink: fix error logic of IFLA_BRIDGE_FLAGS writing back + +From: Lin Ma + +[ Upstream commit 743ad091fb46e622f1b690385bb15e3cd3daf874 ] + +In the commit d73ef2d69c0d ("rtnetlink: let rtnl_bridge_setlink checks +IFLA_BRIDGE_MODE length"), an adjustment was made to the old loop logic +in the function `rtnl_bridge_setlink` to enable the loop to also check +the length of the IFLA_BRIDGE_MODE attribute. However, this adjustment +removed the `break` statement and led to an error logic of the flags +writing back at the end of this function. + +if (have_flags) + memcpy(nla_data(attr), &flags, sizeof(flags)); + // attr should point to IFLA_BRIDGE_FLAGS NLA !!! + +Before the mentioned commit, the `attr` is granted to be IFLA_BRIDGE_FLAGS. +However, this is not necessarily true fow now as the updated loop will let +the attr point to the last NLA, even an invalid NLA which could cause +overflow writes. + +This patch introduces a new variable `br_flag` to save the NLA pointer +that points to IFLA_BRIDGE_FLAGS and uses it to resolve the mentioned +error logic. + +Fixes: d73ef2d69c0d ("rtnetlink: let rtnl_bridge_setlink checks IFLA_BRIDGE_MODE length") +Signed-off-by: Lin Ma +Acked-by: Nikolay Aleksandrov +Link: https://lore.kernel.org/r/20240227121128.608110-1-linma@zju.edu.cn +Signed-off-by: Jakub Kicinski +Signed-off-by: Sasha Levin +--- + net/core/rtnetlink.c | 11 +++++------ + 1 file changed, 5 insertions(+), 6 deletions(-) + +diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c +index 021dcfdae2835..8938320f7ba3b 100644 +--- a/net/core/rtnetlink.c ++++ b/net/core/rtnetlink.c +@@ -4903,10 +4903,9 @@ static int rtnl_bridge_setlink(struct sk_buff *skb, struct nlmsghdr *nlh, + struct net *net = sock_net(skb->sk); + struct ifinfomsg *ifm; + struct net_device *dev; +- struct nlattr *br_spec, *attr = NULL; ++ struct nlattr *br_spec, *attr, *br_flags_attr = NULL; + int rem, err = -EOPNOTSUPP; + u16 flags = 0; +- bool have_flags = false; + + if (nlmsg_len(nlh) < sizeof(*ifm)) + return -EINVAL; +@@ -4924,11 +4923,11 @@ static int rtnl_bridge_setlink(struct sk_buff *skb, struct nlmsghdr *nlh, + br_spec = nlmsg_find_attr(nlh, sizeof(struct ifinfomsg), IFLA_AF_SPEC); + if (br_spec) { + nla_for_each_nested(attr, br_spec, rem) { +- if (nla_type(attr) == IFLA_BRIDGE_FLAGS && !have_flags) { ++ if (nla_type(attr) == IFLA_BRIDGE_FLAGS && !br_flags_attr) { + if (nla_len(attr) < sizeof(flags)) + return -EINVAL; + +- have_flags = true; ++ br_flags_attr = attr; + flags = nla_get_u16(attr); + } + +@@ -4972,8 +4971,8 @@ static int rtnl_bridge_setlink(struct sk_buff *skb, struct nlmsghdr *nlh, + } + } + +- if (have_flags) +- memcpy(nla_data(attr), &flags, sizeof(flags)); ++ if (br_flags_attr) ++ memcpy(nla_data(br_flags_attr), &flags, sizeof(flags)); + out: + return err; + } +-- +2.43.0 + diff --git a/queue-5.10/series b/queue-5.10/series index bc7c8787fe4..f9ea2f872a1 100644 --- a/queue-5.10/series +++ b/queue-5.10/series @@ -3,3 +3,22 @@ software-node-provide-replacement-for-device_add_pro.patch platform-x86-touchscreen_dmi-handle-device-propertie.patch platform-x86-touchscreen_dmi-allow-partial-prefix-ma.patch crypto-virtio-akcipher-fix-stack-overflow-on-memcpy.patch +mtd-spinand-gigadevice-support-gd5f1gq5uexxg.patch +mtd-spinand-gigadevice-fix-the-get-ecc-status-issue.patch +netlink-fix-kernel-infoleak-after-free-in-__skb_data.patch +net-ip_tunnel-prevent-perpetual-headroom-growth.patch +tun-fix-xdp_rxq_info-s-queue_index-when-detaching.patch +ipv6-fix-potential-struct-net-leak-in-inet6_rtm_geta.patch +lan78xx-enable-auto-speed-configuration-for-lan7850-.patch +net-usb-dm9601-fix-wrong-return-value-in-dm9601_mdio.patch +bluetooth-avoid-potential-use-after-free-in-hci_erro.patch +bluetooth-hci_event-fix-wrongly-recorded-wakeup-bd_a.patch +bluetooth-hci_event-fix-handling-of-hci_ev_io_capa_r.patch +bluetooth-enforce-validation-on-max-value-of-connect.patch +netfilter-nf_tables-allow-nfproto_inet-in-nft_-match.patch +rtnetlink-fix-error-logic-of-ifla_bridge_flags-writi.patch +efi-capsule-loader-fix-incorrect-allocation-size.patch +power-supply-bq27xxx-i2c-do-not-free-non-existing-ir.patch +alsa-drop-leftover-snd-rtctimer-stuff-from-makefile.patch +afs-fix-endless-loop-in-directory-parsing.patch +riscv-sparse-memory-vmemmap-out-of-bounds-fix.patch diff --git a/queue-5.10/tun-fix-xdp_rxq_info-s-queue_index-when-detaching.patch b/queue-5.10/tun-fix-xdp_rxq_info-s-queue_index-when-detaching.patch new file mode 100644 index 00000000000..041ef916862 --- /dev/null +++ b/queue-5.10/tun-fix-xdp_rxq_info-s-queue_index-when-detaching.patch @@ -0,0 +1,36 @@ +From 15e6131d131502a1a6b6bd7d38415cb2184474eb Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Tue, 20 Feb 2024 11:12:07 +0800 +Subject: tun: Fix xdp_rxq_info's queue_index when detaching + +From: Yunjian Wang + +[ Upstream commit 2a770cdc4382b457ca3d43d03f0f0064f905a0d0 ] + +When a queue(tfile) is detached, we only update tfile's queue_index, +but do not update xdp_rxq_info's queue_index. This patch fixes it. + +Fixes: 8bf5c4ee1889 ("tun: setup xdp_rxq_info") +Signed-off-by: Yunjian Wang +Link: https://lore.kernel.org/r/1708398727-46308-1-git-send-email-wangyunjian@huawei.com +Signed-off-by: Jakub Kicinski +Signed-off-by: Sasha Levin +--- + drivers/net/tun.c | 1 + + 1 file changed, 1 insertion(+) + +diff --git a/drivers/net/tun.c b/drivers/net/tun.c +index 0b25b59f44033..bb0368272a1bb 100644 +--- a/drivers/net/tun.c ++++ b/drivers/net/tun.c +@@ -665,6 +665,7 @@ static void __tun_detach(struct tun_file *tfile, bool clean) + tun->tfiles[tun->numqueues - 1]); + ntfile = rtnl_dereference(tun->tfiles[index]); + ntfile->queue_index = index; ++ ntfile->xdp_rxq.queue_index = index; + rcu_assign_pointer(tun->tfiles[tun->numqueues - 1], + NULL); + +-- +2.43.0 +