--- /dev/null
+From f587677addd753627d90047f29942c0ba2b75028 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 11 Jul 2025 16:30:09 +0800
+Subject: block: fix kobject leak in blk_unregister_queue
+
+From: Ming Lei <ming.lei@redhat.com>
+
+[ Upstream commit 3051247e4faa32a3d90c762a243c2c62dde310db ]
+
+The kobject for the queue, `disk->queue_kobj`, is initialized with a
+reference count of 1 via `kobject_init()` in `blk_register_queue()`.
+While `kobject_del()` is called during the unregister path to remove
+the kobject from sysfs, the initial reference is never released.
+
+Add a call to `kobject_put()` in `blk_unregister_queue()` to properly
+decrement the reference count and fix the leak.
+
+Fixes: 2bd85221a625 ("block: untangle request_queue refcounting from sysfs")
+Cc: Christoph Hellwig <hch@lst.de>
+Signed-off-by: Ming Lei <ming.lei@redhat.com>
+Link: https://lore.kernel.org/r/20250711083009.2574432-1-ming.lei@redhat.com
+Signed-off-by: Jens Axboe <axboe@kernel.dk>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ block/blk-sysfs.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/block/blk-sysfs.c b/block/blk-sysfs.c
+index 74839f6f2e0cb..8d15c73a520bd 100644
+--- a/block/blk-sysfs.c
++++ b/block/blk-sysfs.c
+@@ -909,4 +909,5 @@ void blk_unregister_queue(struct gendisk *disk)
+ mutex_unlock(&q->sysfs_dir_lock);
+
+ blk_debugfs_remove(disk);
++ kobject_put(&disk->queue_kobj);
+ }
+--
+2.39.5
+
--- /dev/null
+From 476f110ede919bcfb0d370956f0c44a86de4b91e Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 15 Jul 2025 20:40:13 +0800
+Subject: Bluetooth: btusb: QCA: Fix downloading wrong NVM for WCN6855 GF
+ variant without board ID
+
+From: Zijun Hu <zijun.hu@oss.qualcomm.com>
+
+[ Upstream commit 43015955795a619f7ca4ae69b9c0ffc994c82818 ]
+
+For GF variant of WCN6855 without board ID programmed
+btusb_generate_qca_nvm_name() will chose wrong NVM
+'qca/nvm_usb_00130201.bin' to download.
+
+Fix by choosing right NVM 'qca/nvm_usb_00130201_gf.bin'.
+Also simplify NVM choice logic of btusb_generate_qca_nvm_name().
+
+Fixes: d6cba4e6d0e2 ("Bluetooth: btusb: Add support using different nvm for variant WCN6855 controller")
+Signed-off-by: Zijun Hu <zijun.hu@oss.qualcomm.com>
+Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/bluetooth/btusb.c | 78 ++++++++++++++++++++++-----------------
+ 1 file changed, 44 insertions(+), 34 deletions(-)
+
+diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
+index e0dd698896088..db507a66fa8ac 100644
+--- a/drivers/bluetooth/btusb.c
++++ b/drivers/bluetooth/btusb.c
+@@ -3736,6 +3736,32 @@ static const struct qca_device_info qca_devices_table[] = {
+ { 0x00190200, 40, 4, 16 }, /* WCN785x 2.0 */
+ };
+
++static u16 qca_extract_board_id(const struct qca_version *ver)
++{
++ u16 flag = le16_to_cpu(ver->flag);
++ u16 board_id = 0;
++
++ if (((flag >> 8) & 0xff) == QCA_FLAG_MULTI_NVM) {
++ /* The board_id should be split into two bytes
++ * The 1st byte is chip ID, and the 2nd byte is platform ID
++ * For example, board ID 0x010A, 0x01 is platform ID. 0x0A is chip ID
++ * we have several platforms, and platform IDs are continuously added
++ * Platform ID:
++ * 0x00 is for Mobile
++ * 0x01 is for X86
++ * 0x02 is for Automotive
++ * 0x03 is for Consumer electronic
++ */
++ board_id = (ver->chip_id << 8) + ver->platform_id;
++ }
++
++ /* Take 0xffff as invalid board ID */
++ if (board_id == 0xffff)
++ board_id = 0;
++
++ return board_id;
++}
++
+ static int btusb_qca_send_vendor_req(struct usb_device *udev, u8 request,
+ void *data, u16 size)
+ {
+@@ -3892,44 +3918,28 @@ static void btusb_generate_qca_nvm_name(char *fwname, size_t max_size,
+ const struct qca_version *ver)
+ {
+ u32 rom_version = le32_to_cpu(ver->rom_version);
+- u16 flag = le16_to_cpu(ver->flag);
++ const char *variant;
++ int len;
++ u16 board_id;
+
+- if (((flag >> 8) & 0xff) == QCA_FLAG_MULTI_NVM) {
+- /* The board_id should be split into two bytes
+- * The 1st byte is chip ID, and the 2nd byte is platform ID
+- * For example, board ID 0x010A, 0x01 is platform ID. 0x0A is chip ID
+- * we have several platforms, and platform IDs are continuously added
+- * Platform ID:
+- * 0x00 is for Mobile
+- * 0x01 is for X86
+- * 0x02 is for Automotive
+- * 0x03 is for Consumer electronic
+- */
+- u16 board_id = (ver->chip_id << 8) + ver->platform_id;
+- const char *variant;
++ board_id = qca_extract_board_id(ver);
+
+- switch (le32_to_cpu(ver->ram_version)) {
+- case WCN6855_2_0_RAM_VERSION_GF:
+- case WCN6855_2_1_RAM_VERSION_GF:
+- variant = "_gf";
+- break;
+- default:
+- variant = "";
+- break;
+- }
+-
+- if (board_id == 0) {
+- snprintf(fwname, max_size, "qca/nvm_usb_%08x%s.bin",
+- rom_version, variant);
+- } else {
+- snprintf(fwname, max_size, "qca/nvm_usb_%08x%s_%04x.bin",
+- rom_version, variant, board_id);
+- }
+- } else {
+- snprintf(fwname, max_size, "qca/nvm_usb_%08x.bin",
+- rom_version);
++ switch (le32_to_cpu(ver->ram_version)) {
++ case WCN6855_2_0_RAM_VERSION_GF:
++ case WCN6855_2_1_RAM_VERSION_GF:
++ variant = "_gf";
++ break;
++ default:
++ variant = NULL;
++ break;
+ }
+
++ len = snprintf(fwname, max_size, "qca/nvm_usb_%08x", rom_version);
++ if (variant)
++ len += snprintf(fwname + len, max_size - len, "%s", variant);
++ if (board_id)
++ len += snprintf(fwname + len, max_size - len, "_%04x", board_id);
++ len += snprintf(fwname + len, max_size - len, ".bin");
+ }
+
+ static int btusb_setup_qca_load_nvm(struct hci_dev *hdev,
+--
+2.39.5
+
--- /dev/null
+From 0468cd09505cf3dabcdc207c7092c36e2420e104 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Mon, 7 Jul 2025 19:28:29 +0000
+Subject: Bluetooth: Fix null-ptr-deref in l2cap_sock_resume_cb()
+
+From: Kuniyuki Iwashima <kuniyu@google.com>
+
+[ Upstream commit a0075accbf0d76c2dad1ad3993d2e944505d99a0 ]
+
+syzbot reported null-ptr-deref in l2cap_sock_resume_cb(). [0]
+
+l2cap_sock_resume_cb() has a similar problem that was fixed by commit
+1bff51ea59a9 ("Bluetooth: fix use-after-free error in lock_sock_nested()").
+
+Since both l2cap_sock_kill() and l2cap_sock_resume_cb() are executed
+under l2cap_sock_resume_cb(), we can avoid the issue simply by checking
+if chan->data is NULL.
+
+Let's not access to the killed socket in l2cap_sock_resume_cb().
+
+[0]:
+BUG: KASAN: null-ptr-deref in instrument_atomic_write include/linux/instrumented.h:82 [inline]
+BUG: KASAN: null-ptr-deref in clear_bit include/asm-generic/bitops/instrumented-atomic.h:41 [inline]
+BUG: KASAN: null-ptr-deref in l2cap_sock_resume_cb+0xb4/0x17c net/bluetooth/l2cap_sock.c:1711
+Write of size 8 at addr 0000000000000570 by task kworker/u9:0/52
+
+CPU: 1 UID: 0 PID: 52 Comm: kworker/u9:0 Not tainted 6.16.0-rc4-syzkaller-g7482bb149b9f #0 PREEMPT
+Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025
+Workqueue: hci0 hci_rx_work
+Call trace:
+ show_stack+0x2c/0x3c arch/arm64/kernel/stacktrace.c:501 (C)
+ __dump_stack+0x30/0x40 lib/dump_stack.c:94
+ dump_stack_lvl+0xd8/0x12c lib/dump_stack.c:120
+ print_report+0x58/0x84 mm/kasan/report.c:524
+ kasan_report+0xb0/0x110 mm/kasan/report.c:634
+ check_region_inline mm/kasan/generic.c:-1 [inline]
+ kasan_check_range+0x264/0x2a4 mm/kasan/generic.c:189
+ __kasan_check_write+0x20/0x30 mm/kasan/shadow.c:37
+ instrument_atomic_write include/linux/instrumented.h:82 [inline]
+ clear_bit include/asm-generic/bitops/instrumented-atomic.h:41 [inline]
+ l2cap_sock_resume_cb+0xb4/0x17c net/bluetooth/l2cap_sock.c:1711
+ l2cap_security_cfm+0x524/0xea0 net/bluetooth/l2cap_core.c:7357
+ hci_auth_cfm include/net/bluetooth/hci_core.h:2092 [inline]
+ hci_auth_complete_evt+0x2e8/0xa4c net/bluetooth/hci_event.c:3514
+ hci_event_func net/bluetooth/hci_event.c:7511 [inline]
+ hci_event_packet+0x650/0xe9c net/bluetooth/hci_event.c:7565
+ hci_rx_work+0x320/0xb18 net/bluetooth/hci_core.c:4070
+ process_one_work+0x7e8/0x155c kernel/workqueue.c:3238
+ process_scheduled_works kernel/workqueue.c:3321 [inline]
+ worker_thread+0x958/0xed8 kernel/workqueue.c:3402
+ kthread+0x5fc/0x75c kernel/kthread.c:464
+ ret_from_fork+0x10/0x20 arch/arm64/kernel/entry.S:847
+
+Fixes: d97c899bde33 ("Bluetooth: Introduce L2CAP channel callback for resuming")
+Reported-by: syzbot+e4d73b165c3892852d22@syzkaller.appspotmail.com
+Closes: https://lore.kernel.org/all/686c12bd.a70a0220.29fe6c.0b13.GAE@google.com/
+Signed-off-by: Kuniyuki Iwashima <kuniyu@google.com>
+Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ net/bluetooth/l2cap_sock.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+diff --git a/net/bluetooth/l2cap_sock.c b/net/bluetooth/l2cap_sock.c
+index aaaaf9733b589..9a906977c8723 100644
+--- a/net/bluetooth/l2cap_sock.c
++++ b/net/bluetooth/l2cap_sock.c
+@@ -1687,6 +1687,9 @@ static void l2cap_sock_resume_cb(struct l2cap_chan *chan)
+ {
+ struct sock *sk = chan->data;
+
++ if (!sk)
++ return;
++
+ if (test_and_clear_bit(FLAG_PENDING_SECURITY, &chan->flags)) {
+ sk->sk_state = BT_CONNECTED;
+ chan->state = BT_CONNECTED;
+--
+2.39.5
+
--- /dev/null
+From 018f666a838775f1424ad9c821b67d0fb7ddf059 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 9 Jul 2025 09:53:11 +0200
+Subject: Bluetooth: hci_sync: fix connectable extended advertising when using
+ static random address
+
+From: Alessandro Gasbarroni <alex.gasbarroni@gmail.com>
+
+[ Upstream commit d85edab911a4c1fcbe3f08336eff5c7feec567d0 ]
+
+Currently, the connectable flag used by the setup of an extended
+advertising instance drives whether we require privacy when trying to pass
+a random address to the advertising parameters (Own Address).
+If privacy is not required, then it automatically falls back to using the
+controller's public address. This can cause problems when using controllers
+that do not have a public address set, but instead use a static random
+address.
+
+e.g. Assume a BLE controller that does not have a public address set.
+The controller upon powering is set with a random static address by default
+by the kernel.
+
+ < HCI Command: LE Set Random Address (0x08|0x0005) plen 6
+ Address: E4:AF:26:D8:3E:3A (Static)
+ > HCI Event: Command Complete (0x0e) plen 4
+ LE Set Random Address (0x08|0x0005) ncmd 1
+ Status: Success (0x00)
+
+Setting non-connectable extended advertisement parameters in bluetoothctl
+mgmt
+
+ add-ext-adv-params -r 0x801 -x 0x802 -P 2M -g 1
+
+correctly sets Own address type as Random
+
+ < HCI Command: LE Set Extended Advertising Parameters (0x08|0x0036)
+ plen 25
+ ...
+ Own address type: Random (0x01)
+
+Setting connectable extended advertisement parameters in bluetoothctl mgmt
+
+ add-ext-adv-params -r 0x801 -x 0x802 -P 2M -g -c 1
+
+mistakenly sets Own address type to Public (which causes to use Public
+Address 00:00:00:00:00:00)
+
+ < HCI Command: LE Set Extended Advertising Parameters (0x08|0x0036)
+ plen 25
+ ...
+ Own address type: Public (0x00)
+
+This causes either the controller to emit an Invalid Parameters error or to
+mishandle the advertising.
+
+This patch makes sure that we use the already set static random address
+when requesting a connectable extended advertising when we don't require
+privacy and our public address is not set (00:00:00:00:00:00).
+
+Fixes: 3fe318ee72c5 ("Bluetooth: move hci_get_random_address() to hci_sync")
+Signed-off-by: Alessandro Gasbarroni <alex.gasbarroni@gmail.com>
+Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ net/bluetooth/hci_sync.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/net/bluetooth/hci_sync.c b/net/bluetooth/hci_sync.c
+index e1df1c62017d9..01aca07707117 100644
+--- a/net/bluetooth/hci_sync.c
++++ b/net/bluetooth/hci_sync.c
+@@ -6796,8 +6796,8 @@ int hci_get_random_address(struct hci_dev *hdev, bool require_privacy,
+ return 0;
+ }
+
+- /* No privacy so use a public address. */
+- *own_addr_type = ADDR_LE_DEV_PUBLIC;
++ /* No privacy, use the current address */
++ hci_copy_identity_address(hdev, rand_addr, own_addr_type);
+
+ return 0;
+ }
+--
+2.39.5
+
--- /dev/null
+From 363bc5d6057d34e03d8bbaab1ca8165a9c632add Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 16 Jul 2025 09:40:49 -0400
+Subject: Bluetooth: L2CAP: Fix attempting to adjust outgoing MTU
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
+
+[ Upstream commit d24e4a7fedae121d33fb32ad785b87046527eedb ]
+
+Configuration request only configure the incoming direction of the peer
+initiating the request, so using the MTU is the other direction shall
+not be used, that said the spec allows the peer responding to adjust:
+
+Bluetooth Core 6.1, Vol 3, Part A, Section 4.5
+
+ 'Each configuration parameter value (if any is present) in an
+ L2CAP_CONFIGURATION_RSP packet reflects an ‘adjustment’ to a
+ configuration parameter value that has been sent (or, in case of
+ default values, implied) in the corresponding
+ L2CAP_CONFIGURATION_REQ packet.'
+
+That said adjusting the MTU in the response shall be limited to ERTM
+channels only as for older modes the remote stack may not be able to
+detect the adjustment causing it to silently drop packets.
+
+Link: https://github.com/bluez/bluez/issues/1422
+Link: https://gitlab.archlinux.org/archlinux/packaging/packages/linux/-/issues/149
+Link: https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/4793
+Fixes: 042bb9603c44 ("Bluetooth: L2CAP: Fix L2CAP MTU negotiation")
+Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ net/bluetooth/l2cap_core.c | 26 +++++++++++++++++++++-----
+ 1 file changed, 21 insertions(+), 5 deletions(-)
+
+diff --git a/net/bluetooth/l2cap_core.c b/net/bluetooth/l2cap_core.c
+index f9995a405e35c..dabc07700197c 100644
+--- a/net/bluetooth/l2cap_core.c
++++ b/net/bluetooth/l2cap_core.c
+@@ -3485,12 +3485,28 @@ static int l2cap_parse_conf_req(struct l2cap_chan *chan, void *data, size_t data
+ /* Configure output options and let the other side know
+ * which ones we don't like. */
+
+- /* If MTU is not provided in configure request, use the most recently
+- * explicitly or implicitly accepted value for the other direction,
+- * or the default value.
++ /* If MTU is not provided in configure request, try adjusting it
++ * to the current output MTU if it has been set
++ *
++ * Bluetooth Core 6.1, Vol 3, Part A, Section 4.5
++ *
++ * Each configuration parameter value (if any is present) in an
++ * L2CAP_CONFIGURATION_RSP packet reflects an ‘adjustment’ to a
++ * configuration parameter value that has been sent (or, in case
++ * of default values, implied) in the corresponding
++ * L2CAP_CONFIGURATION_REQ packet.
+ */
+- if (mtu == 0)
+- mtu = chan->imtu ? chan->imtu : L2CAP_DEFAULT_MTU;
++ if (!mtu) {
++ /* Only adjust for ERTM channels as for older modes the
++ * remote stack may not be able to detect that the
++ * adjustment causing it to silently drop packets.
++ */
++ if (chan->mode == L2CAP_MODE_ERTM &&
++ chan->omtu && chan->omtu != L2CAP_DEFAULT_MTU)
++ mtu = chan->omtu;
++ else
++ mtu = L2CAP_DEFAULT_MTU;
++ }
+
+ if (mtu < L2CAP_DEFAULT_MIN_MTU)
+ result = L2CAP_CONF_UNACCEPT;
+--
+2.39.5
+
--- /dev/null
+From ce222856bf9a1f16c377cd7073639f2708cbb336 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 2 Jul 2025 11:53:40 -0400
+Subject: Bluetooth: SMP: Fix using HCI_ERROR_REMOTE_USER_TERM on timeout
+
+From: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
+
+[ Upstream commit 6ef99c917688a8510259e565bd1b168b7146295a ]
+
+This replaces the usage of HCI_ERROR_REMOTE_USER_TERM, which as the name
+suggest is to indicate a regular disconnection initiated by an user,
+with HCI_ERROR_AUTH_FAILURE to indicate the session has timeout thus any
+pairing shall be considered as failed.
+
+Fixes: 1e91c29eb60c ("Bluetooth: Use hci_disconnect for immediate disconnection from SMP")
+Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ net/bluetooth/smp.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/net/bluetooth/smp.c b/net/bluetooth/smp.c
+index 7040705876b70..4c00bc50de811 100644
+--- a/net/bluetooth/smp.c
++++ b/net/bluetooth/smp.c
+@@ -1380,7 +1380,7 @@ static void smp_timeout(struct work_struct *work)
+
+ bt_dev_dbg(conn->hcon->hdev, "conn %p", conn);
+
+- hci_disconnect(conn->hcon, HCI_ERROR_REMOTE_USER_TERM);
++ hci_disconnect(conn->hcon, HCI_ERROR_AUTH_FAILURE);
+ }
+
+ static struct smp_chan *smp_chan_create(struct l2cap_conn *conn)
+--
+2.39.5
+
--- /dev/null
+From c29ac26a3115db257fe06409192abab49b593cb0 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Mon, 30 Jun 2025 14:42:23 -0400
+Subject: Bluetooth: SMP: If an unallowed command is received consider it a
+ failure
+
+From: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
+
+[ Upstream commit fe4840df0bdf341f376885271b7680764fe6b34e ]
+
+If a command is received while a bonding is ongoing consider it a
+pairing failure so the session is cleanup properly and the device is
+disconnected immediately instead of continuing with other commands that
+may result in the session to get stuck without ever completing such as
+the case bellow:
+
+> ACL Data RX: Handle 2048 flags 0x02 dlen 21
+ SMP: Identity Information (0x08) len 16
+ Identity resolving key[16]: d7e08edef97d3e62cd2331f82d8073b0
+> ACL Data RX: Handle 2048 flags 0x02 dlen 21
+ SMP: Signing Information (0x0a) len 16
+ Signature key[16]: 1716c536f94e843a9aea8b13ffde477d
+Bluetooth: hci0: unexpected SMP command 0x0a from XX:XX:XX:XX:XX:XX
+> ACL Data RX: Handle 2048 flags 0x02 dlen 12
+ SMP: Identity Address Information (0x09) len 7
+ Address: XX:XX:XX:XX:XX:XX (Intel Corporate)
+
+While accourding to core spec 6.1 the expected order is always BD_ADDR
+first first then CSRK:
+
+When using LE legacy pairing, the keys shall be distributed in the
+following order:
+
+ LTK by the Peripheral
+
+ EDIV and Rand by the Peripheral
+
+ IRK by the Peripheral
+
+ BD_ADDR by the Peripheral
+
+ CSRK by the Peripheral
+
+ LTK by the Central
+
+ EDIV and Rand by the Central
+
+ IRK by the Central
+
+ BD_ADDR by the Central
+
+ CSRK by the Central
+
+When using LE Secure Connections, the keys shall be distributed in the
+following order:
+
+ IRK by the Peripheral
+
+ BD_ADDR by the Peripheral
+
+ CSRK by the Peripheral
+
+ IRK by the Central
+
+ BD_ADDR by the Central
+
+ CSRK by the Central
+
+According to the Core 6.1 for commands used for key distribution "Key
+Rejected" can be used:
+
+ '3.6.1. Key distribution and generation
+
+ A device may reject a distributed key by sending the Pairing Failed command
+ with the reason set to "Key Rejected".
+
+Fixes: b28b4943660f ("Bluetooth: Add strict checks for allowed SMP PDUs")
+Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ net/bluetooth/smp.c | 19 ++++++++++++++++++-
+ net/bluetooth/smp.h | 1 +
+ 2 files changed, 19 insertions(+), 1 deletion(-)
+
+diff --git a/net/bluetooth/smp.c b/net/bluetooth/smp.c
+index 56f7f041c9a60..7040705876b70 100644
+--- a/net/bluetooth/smp.c
++++ b/net/bluetooth/smp.c
+@@ -2978,8 +2978,25 @@ static int smp_sig_channel(struct l2cap_chan *chan, struct sk_buff *skb)
+ if (code > SMP_CMD_MAX)
+ goto drop;
+
+- if (smp && !test_and_clear_bit(code, &smp->allow_cmd))
++ if (smp && !test_and_clear_bit(code, &smp->allow_cmd)) {
++ /* If there is a context and the command is not allowed consider
++ * it a failure so the session is cleanup properly.
++ */
++ switch (code) {
++ case SMP_CMD_IDENT_INFO:
++ case SMP_CMD_IDENT_ADDR_INFO:
++ case SMP_CMD_SIGN_INFO:
++ /* 3.6.1. Key distribution and generation
++ *
++ * A device may reject a distributed key by sending the
++ * Pairing Failed command with the reason set to
++ * "Key Rejected".
++ */
++ smp_failure(conn, SMP_KEY_REJECTED);
++ break;
++ }
+ goto drop;
++ }
+
+ /* If we don't have a context the only allowed commands are
+ * pairing request and security request.
+diff --git a/net/bluetooth/smp.h b/net/bluetooth/smp.h
+index 87a59ec2c9f02..c5da53dfab04f 100644
+--- a/net/bluetooth/smp.h
++++ b/net/bluetooth/smp.h
+@@ -138,6 +138,7 @@ struct smp_cmd_keypress_notify {
+ #define SMP_NUMERIC_COMP_FAILED 0x0c
+ #define SMP_BREDR_PAIRING_IN_PROGRESS 0x0d
+ #define SMP_CROSS_TRANSP_NOT_ALLOWED 0x0e
++#define SMP_KEY_REJECTED 0x0f
+
+ #define SMP_MIN_ENC_KEY_SIZE 7
+ #define SMP_MAX_ENC_KEY_SIZE 16
+--
+2.39.5
+
--- /dev/null
+From a738f9bffb6213d0f021e9b57ca3aae1d5de0845 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 1 Jul 2025 21:47:30 +0200
+Subject: bpf: Reject %p% format string in bprintf-like helpers
+
+From: Paul Chaignon <paul.chaignon@gmail.com>
+
+[ Upstream commit f8242745871f81a3ac37f9f51853d12854fd0b58 ]
+
+static const char fmt[] = "%p%";
+ bpf_trace_printk(fmt, sizeof(fmt));
+
+The above BPF program isn't rejected and causes a kernel warning at
+runtime:
+
+ Please remove unsupported %\x00 in format string
+ WARNING: CPU: 1 PID: 7244 at lib/vsprintf.c:2680 format_decode+0x49c/0x5d0
+
+This happens because bpf_bprintf_prepare skips over the second %,
+detected as punctuation, while processing %p. This patch fixes it by
+not skipping over punctuation. %\x00 is then processed in the next
+iteration and rejected.
+
+Reported-by: syzbot+e2c932aec5c8a6e1d31c@syzkaller.appspotmail.com
+Fixes: 48cac3f4a96d ("bpf: Implement formatted output helpers with bstr_printf")
+Acked-by: Yonghong Song <yonghong.song@linux.dev>
+Signed-off-by: Paul Chaignon <paul.chaignon@gmail.com>
+Link: https://lore.kernel.org/r/a0e06cc479faec9e802ae51ba5d66420523251ee.1751395489.git.paul.chaignon@gmail.com
+Signed-off-by: Alexei Starovoitov <ast@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ kernel/bpf/helpers.c | 11 ++++++++---
+ 1 file changed, 8 insertions(+), 3 deletions(-)
+
+diff --git a/kernel/bpf/helpers.c b/kernel/bpf/helpers.c
+index 8f0b62b04deeb..4b20a72ab8cff 100644
+--- a/kernel/bpf/helpers.c
++++ b/kernel/bpf/helpers.c
+@@ -885,6 +885,13 @@ int bpf_bprintf_prepare(char *fmt, u32 fmt_size, const u64 *raw_args,
+ if (fmt[i] == 'p') {
+ sizeof_cur_arg = sizeof(long);
+
++ if (fmt[i + 1] == 0 || isspace(fmt[i + 1]) ||
++ ispunct(fmt[i + 1])) {
++ if (tmp_buf)
++ cur_arg = raw_args[num_spec];
++ goto nocopy_fmt;
++ }
++
+ if ((fmt[i + 1] == 'k' || fmt[i + 1] == 'u') &&
+ fmt[i + 2] == 's') {
+ fmt_ptype = fmt[i + 1];
+@@ -892,11 +899,9 @@ int bpf_bprintf_prepare(char *fmt, u32 fmt_size, const u64 *raw_args,
+ goto fmt_str;
+ }
+
+- if (fmt[i + 1] == 0 || isspace(fmt[i + 1]) ||
+- ispunct(fmt[i + 1]) || fmt[i + 1] == 'K' ||
++ if (fmt[i + 1] == 'K' ||
+ fmt[i + 1] == 'x' || fmt[i + 1] == 's' ||
+ fmt[i + 1] == 'S') {
+- /* just kernel pointers */
+ if (tmp_buf)
+ cur_arg = raw_args[num_spec];
+ i++;
+--
+2.39.5
+
--- /dev/null
+From e6e911fe6c16ed2cdd7fabeff09b41f91a556b07 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 3 Jul 2025 10:44:18 +0800
+Subject: cachefiles: Fix the incorrect return value in __cachefiles_write()
+
+From: Zizhi Wo <wozizhi@huawei.com>
+
+[ Upstream commit 6b89819b06d8d339da414f06ef3242f79508be5e ]
+
+In __cachefiles_write(), if the return value of the write operation > 0, it
+is set to 0. This makes it impossible to distinguish scenarios where a
+partial write has occurred, and will affect the outer calling functions:
+
+ 1) cachefiles_write_complete() will call "term_func" such as
+netfs_write_subrequest_terminated(). When "ret" in __cachefiles_write()
+is used as the "transferred_or_error" of this function, it can not
+distinguish the amount of data written, makes the WARN meaningless.
+
+ 2) cachefiles_ondemand_fd_write_iter() can only assume all writes were
+successful by default when "ret" is 0, and unconditionally return the full
+length specified by user space.
+
+Fix it by modifying "ret" to reflect the actual number of bytes written.
+Furthermore, returning a value greater than 0 from __cachefiles_write()
+does not affect other call paths, such as cachefiles_issue_write() and
+fscache_write().
+
+Fixes: 047487c947e8 ("cachefiles: Implement the I/O routines")
+Signed-off-by: Zizhi Wo <wozizhi@huawei.com>
+Link: https://lore.kernel.org/20250703024418.2809353-1-wozizhi@huaweicloud.com
+Signed-off-by: Christian Brauner <brauner@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ fs/cachefiles/io.c | 2 --
+ fs/cachefiles/ondemand.c | 4 +---
+ 2 files changed, 1 insertion(+), 5 deletions(-)
+
+diff --git a/fs/cachefiles/io.c b/fs/cachefiles/io.c
+index 009d23cd435b5..239a6002083d7 100644
+--- a/fs/cachefiles/io.c
++++ b/fs/cachefiles/io.c
+@@ -346,8 +346,6 @@ int __cachefiles_write(struct cachefiles_object *object,
+ default:
+ ki->was_async = false;
+ cachefiles_write_complete(&ki->iocb, ret);
+- if (ret > 0)
+- ret = 0;
+ break;
+ }
+
+diff --git a/fs/cachefiles/ondemand.c b/fs/cachefiles/ondemand.c
+index 3389a373faf68..cfa8f23fdfb65 100644
+--- a/fs/cachefiles/ondemand.c
++++ b/fs/cachefiles/ondemand.c
+@@ -84,10 +84,8 @@ static ssize_t cachefiles_ondemand_fd_write_iter(struct kiocb *kiocb,
+
+ trace_cachefiles_ondemand_fd_write(object, file_inode(file), pos, len);
+ ret = __cachefiles_write(object, file, pos, iter, NULL, NULL);
+- if (!ret) {
+- ret = len;
++ if (ret > 0)
+ kiocb->ki_pos += ret;
+- }
+
+ out:
+ fput(file);
+--
+2.39.5
+
--- /dev/null
+From 54c935ff2e53d5da35f52689834631ba4c15c68c Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 16 Jul 2025 08:26:05 +0800
+Subject: hv_netvsc: Set VF priv_flags to IFF_NO_ADDRCONF before open to
+ prevent IPv6 addrconf
+
+From: Li Tian <litian@redhat.com>
+
+[ Upstream commit d7501e076d859d2f381d57bd984ff6db13172727 ]
+
+Set an additional flag IFF_NO_ADDRCONF to prevent ipv6 addrconf.
+
+Commit under Fixes added a new flag change that was not made
+to hv_netvsc resulting in the VF being assinged an IPv6.
+
+Fixes: 8a321cf7becc ("net: add IFF_NO_ADDRCONF and use it in bonding to prevent ipv6 addrconf")
+Suggested-by: Cathy Avery <cavery@redhat.com>
+Signed-off-by: Li Tian <litian@redhat.com>
+Reviewed-by: Xin Long <lucien.xin@gmail.com>
+Link: https://patch.msgid.link/20250716002607.4927-1-litian@redhat.com
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/hyperv/netvsc_drv.c | 5 ++++-
+ 1 file changed, 4 insertions(+), 1 deletion(-)
+
+diff --git a/drivers/net/hyperv/netvsc_drv.c b/drivers/net/hyperv/netvsc_drv.c
+index ce6ac26131b34..f33f9167ba6b6 100644
+--- a/drivers/net/hyperv/netvsc_drv.c
++++ b/drivers/net/hyperv/netvsc_drv.c
+@@ -2313,8 +2313,11 @@ static int netvsc_prepare_bonding(struct net_device *vf_netdev)
+ if (!ndev)
+ return NOTIFY_DONE;
+
+- /* set slave flag before open to prevent IPv6 addrconf */
++ /* Set slave flag and no addrconf flag before open
++ * to prevent IPv6 addrconf.
++ */
+ vf_netdev->flags |= IFF_SLAVE;
++ vf_netdev->priv_flags |= IFF_NO_ADDRCONF;
+ return NOTIFY_DONE;
+ }
+
+--
+2.39.5
+
--- /dev/null
+From 9549cf17968c4e9fd0ca0967774333bf20ff9bef Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 19 Jun 2025 15:27:47 +0200
+Subject: hwmon: (corsair-cpro) Validate the size of the received input buffer
+
+From: Marius Zachmann <mail@mariuszachmann.de>
+
+[ Upstream commit 495a4f0dce9c8c4478c242209748f1ee9e4d5820 ]
+
+Add buffer_recv_size to store the size of the received bytes.
+Validate buffer_recv_size in send_usb_cmd().
+
+Reported-by: syzbot+3bbbade4e1a7ab45ca3b@syzkaller.appspotmail.com
+Closes: https://lore.kernel.org/linux-hwmon/61233ba1-e5ad-4d7a-ba31-3b5d0adcffcc@roeck-us.net
+Fixes: 40c3a4454225 ("hwmon: add Corsair Commander Pro driver")
+Signed-off-by: Marius Zachmann <mail@mariuszachmann.de>
+Link: https://lore.kernel.org/r/20250619132817.39764-5-mail@mariuszachmann.de
+Signed-off-by: Guenter Roeck <linux@roeck-us.net>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/hwmon/corsair-cpro.c | 5 +++++
+ 1 file changed, 5 insertions(+)
+
+diff --git a/drivers/hwmon/corsair-cpro.c b/drivers/hwmon/corsair-cpro.c
+index 280b90646a873..b37f36f55f88a 100644
+--- a/drivers/hwmon/corsair-cpro.c
++++ b/drivers/hwmon/corsair-cpro.c
+@@ -84,6 +84,7 @@ struct ccp_device {
+ struct mutex mutex; /* whenever buffer is used, lock before send_usb_cmd */
+ u8 *cmd_buffer;
+ u8 *buffer;
++ int buffer_recv_size; /* number of received bytes in buffer */
+ int target[6];
+ DECLARE_BITMAP(temp_cnct, NUM_TEMP_SENSORS);
+ DECLARE_BITMAP(fan_cnct, NUM_FANS);
+@@ -139,6 +140,9 @@ static int send_usb_cmd(struct ccp_device *ccp, u8 command, u8 byte1, u8 byte2,
+ if (!t)
+ return -ETIMEDOUT;
+
++ if (ccp->buffer_recv_size != IN_BUFFER_SIZE)
++ return -EPROTO;
++
+ return ccp_get_errno(ccp);
+ }
+
+@@ -150,6 +154,7 @@ static int ccp_raw_event(struct hid_device *hdev, struct hid_report *report, u8
+ spin_lock(&ccp->wait_input_report_lock);
+ if (!completion_done(&ccp->wait_input_report)) {
+ memcpy(ccp->buffer, data, min(IN_BUFFER_SIZE, size));
++ ccp->buffer_recv_size = size;
+ complete_all(&ccp->wait_input_report);
+ }
+ spin_unlock(&ccp->wait_input_report_lock);
+--
+2.39.5
+
--- /dev/null
+From de790c056e0fe21196486e8932af440ed2fa9842 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 22 May 2025 13:16:57 -0400
+Subject: ice: add NULL check in eswitch lag check
+
+From: Dave Ertman <david.m.ertman@intel.com>
+
+[ Upstream commit 3ce58b01ada408b372f15b7c992ed0519840e3cf ]
+
+The function ice_lag_is_switchdev_running() is being called from outside of
+the LAG event handler code. This results in the lag->upper_netdev being
+NULL sometimes. To avoid a NULL-pointer dereference, there needs to be a
+check before it is dereferenced.
+
+Fixes: 776fe19953b0 ("ice: block default rule setting on LAG interface")
+Signed-off-by: Dave Ertman <david.m.ertman@intel.com>
+Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
+Tested-by: Sujai Buvaneswaran <sujai.buvaneswaran@intel.com>
+Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/ethernet/intel/ice/ice_lag.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+diff --git a/drivers/net/ethernet/intel/ice/ice_lag.c b/drivers/net/ethernet/intel/ice/ice_lag.c
+index 4db0b770420e6..8ed9918ea4e89 100644
+--- a/drivers/net/ethernet/intel/ice/ice_lag.c
++++ b/drivers/net/ethernet/intel/ice/ice_lag.c
+@@ -2129,7 +2129,8 @@ bool ice_lag_is_switchdev_running(struct ice_pf *pf)
+ struct ice_lag *lag = pf->lag;
+ struct net_device *tmp_nd;
+
+- if (!ice_is_feature_supported(pf, ICE_F_SRIOV_LAG) || !lag)
++ if (!ice_is_feature_supported(pf, ICE_F_SRIOV_LAG) ||
++ !lag || !lag->upper_netdev)
+ return false;
+
+ rcu_read_lock();
+--
+2.39.5
+
--- /dev/null
+From 5b60d32decb1b6f2633ecb462e7c0f071eeb1b16 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Mon, 14 Jul 2025 22:19:57 +0800
+Subject: ipv6: mcast: Delay put pmc->idev in mld_del_delrec()
+
+From: Yue Haibing <yuehaibing@huawei.com>
+
+[ Upstream commit ae3264a25a4635531264728859dbe9c659fad554 ]
+
+pmc->idev is still used in ip6_mc_clear_src(), so as mld_clear_delrec()
+does, the reference should be put after ip6_mc_clear_src() return.
+
+Fixes: 63ed8de4be81 ("mld: add mc_lock for protecting per-interface mld data")
+Signed-off-by: Yue Haibing <yuehaibing@huawei.com>
+Link: https://patch.msgid.link/20250714141957.3301871-1-yuehaibing@huawei.com
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ net/ipv6/mcast.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/net/ipv6/mcast.c b/net/ipv6/mcast.c
+index 9bb246c09fcee..e153dac47a530 100644
+--- a/net/ipv6/mcast.c
++++ b/net/ipv6/mcast.c
+@@ -803,8 +803,8 @@ static void mld_del_delrec(struct inet6_dev *idev, struct ifmcaddr6 *im)
+ } else {
+ im->mca_crcount = idev->mc_qrv;
+ }
+- in6_dev_put(pmc->idev);
+ ip6_mc_clear_src(pmc);
++ in6_dev_put(pmc->idev);
+ kfree_rcu(pmc, rcu);
+ }
+ }
+--
+2.39.5
+
--- /dev/null
+From 3e9b35b76ce930082b07acae6355c8331e2e8c9a Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 16 Jul 2025 11:35:50 -0400
+Subject: net: bridge: Do not offload IGMP/MLD messages
+
+From: Joseph Huang <Joseph.Huang@garmin.com>
+
+[ Upstream commit 683dc24da8bf199bb7446e445ad7f801c79a550e ]
+
+Do not offload IGMP/MLD messages as it could lead to IGMP/MLD Reports
+being unintentionally flooded to Hosts. Instead, let the bridge decide
+where to send these IGMP/MLD messages.
+
+Consider the case where the local host is sending out reports in response
+to a remote querier like the following:
+
+ mcast-listener-process (IP_ADD_MEMBERSHIP)
+ \
+ br0
+ / \
+ swp1 swp2
+ | |
+ QUERIER SOME-OTHER-HOST
+
+In the above setup, br0 will want to br_forward() reports for
+mcast-listener-process's group(s) via swp1 to QUERIER; but since the
+source hwdom is 0, the report is eligible for tx offloading, and is
+flooded by hardware to both swp1 and swp2, reaching SOME-OTHER-HOST as
+well. (Example and illustration provided by Tobias.)
+
+Fixes: 472111920f1c ("net: bridge: switchdev: allow the TX data plane forwarding to be offloaded")
+Signed-off-by: Joseph Huang <Joseph.Huang@garmin.com>
+Acked-by: Nikolay Aleksandrov <razor@blackwall.org>
+Reviewed-by: Ido Schimmel <idosch@nvidia.com>
+Link: https://patch.msgid.link/20250716153551.1830255-1-Joseph.Huang@garmin.com
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ net/bridge/br_switchdev.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+diff --git a/net/bridge/br_switchdev.c b/net/bridge/br_switchdev.c
+index 7b41ee8740cbb..f10bd6a233dcf 100644
+--- a/net/bridge/br_switchdev.c
++++ b/net/bridge/br_switchdev.c
+@@ -17,6 +17,9 @@ static bool nbp_switchdev_can_offload_tx_fwd(const struct net_bridge_port *p,
+ if (!static_branch_unlikely(&br_switchdev_tx_fwd_offload))
+ return false;
+
++ if (br_multicast_igmp_type(skb))
++ return false;
++
+ return (p->flags & BR_TX_FWD_OFFLOAD) &&
+ (p->hwdom != BR_INPUT_SKB_CB(skb)->src_hwdom);
+ }
+--
+2.39.5
+
--- /dev/null
+From 49df8bd697c5e1f7cecab05a6d242279d3cbef56 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 10 Jul 2025 10:38:46 -0700
+Subject: net: emaclite: Fix missing pointer increment in aligned_read()
+
+From: Alok Tiwari <alok.a.tiwari@oracle.com>
+
+[ Upstream commit 7727ec1523d7973defa1dff8f9c0aad288d04008 ]
+
+Add missing post-increment operators for byte pointers in the
+loop that copies remaining bytes in xemaclite_aligned_read().
+Without the increment, the same byte was written repeatedly
+to the destination.
+This update aligns with xemaclite_aligned_write()
+
+Fixes: bb81b2ddfa19 ("net: add Xilinx emac lite device driver")
+Signed-off-by: Alok Tiwari <alok.a.tiwari@oracle.com>
+Link: https://patch.msgid.link/20250710173849.2381003-1-alok.a.tiwari@oracle.com
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/ethernet/xilinx/xilinx_emaclite.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/drivers/net/ethernet/xilinx/xilinx_emaclite.c b/drivers/net/ethernet/xilinx/xilinx_emaclite.c
+index b358ecc672278..0eff5d4fe35df 100644
+--- a/drivers/net/ethernet/xilinx/xilinx_emaclite.c
++++ b/drivers/net/ethernet/xilinx/xilinx_emaclite.c
+@@ -285,7 +285,7 @@ static void xemaclite_aligned_read(u32 *src_ptr, u8 *dest_ptr,
+
+ /* Read the remaining data */
+ for (; length > 0; length--)
+- *to_u8_ptr = *from_u8_ptr;
++ *to_u8_ptr++ = *from_u8_ptr++;
+ }
+ }
+
+--
+2.39.5
+
--- /dev/null
+From 8631ea8d5ee5f3f5a3119ff3d8f1038a930e675c Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 15 Jul 2025 13:20:53 -0700
+Subject: net/mlx5: Correctly set gso_size when LRO is used
+
+From: Christoph Paasch <cpaasch@openai.com>
+
+[ Upstream commit 531d0d32de3e1b6b77a87bd37de0c2c6e17b496a ]
+
+gso_size is expected by the networking stack to be the size of the
+payload (thus, not including ethernet/IP/TCP-headers). However, cqe_bcnt
+is the full sized frame (including the headers). Dividing cqe_bcnt by
+lro_num_seg will then give incorrect results.
+
+For example, running a bpftrace higher up in the TCP-stack
+(tcp_event_data_recv), we commonly have gso_size set to 1450 or 1451 even
+though in reality the payload was only 1448 bytes.
+
+This can have unintended consequences:
+- In tcp_measure_rcv_mss() len will be for example 1450, but. rcv_mss
+will be 1448 (because tp->advmss is 1448). Thus, we will always
+recompute scaling_ratio each time an LRO-packet is received.
+- In tcp_gro_receive(), it will interfere with the decision whether or
+not to flush and thus potentially result in less gro'ed packets.
+
+So, we need to discount the protocol headers from cqe_bcnt so we can
+actually divide the payload by lro_num_seg to get the real gso_size.
+
+v2:
+ - Use "(unsigned char *)tcp + tcp->doff * 4 - skb->data)" to compute header-len
+ (Tariq Toukan <tariqt@nvidia.com>)
+ - Improve commit-message (Gal Pressman <gal@nvidia.com>)
+
+Fixes: e586b3b0baee ("net/mlx5: Ethernet Datapath files")
+Signed-off-by: Christoph Paasch <cpaasch@openai.com>
+Reviewed-by: Tariq Toukan <tariqt@nvidia.com>
+Reviewed-by: Gal Pressman <gal@nvidia.com>
+Link: https://patch.msgid.link/20250715-cpaasch-pf-925-investigate-incorrect-gso_size-on-cx-7-nic-v2-1-e06c3475f3ac@openai.com
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/ethernet/mellanox/mlx5/core/en_rx.c | 12 ++++++++----
+ 1 file changed, 8 insertions(+), 4 deletions(-)
+
+diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_rx.c b/drivers/net/ethernet/mellanox/mlx5/core/en_rx.c
+index 57b0e26696e30..d5731f7be04fd 100644
+--- a/drivers/net/ethernet/mellanox/mlx5/core/en_rx.c
++++ b/drivers/net/ethernet/mellanox/mlx5/core/en_rx.c
+@@ -1159,8 +1159,9 @@ static void mlx5e_lro_update_tcp_hdr(struct mlx5_cqe64 *cqe, struct tcphdr *tcp)
+ }
+ }
+
+-static void mlx5e_lro_update_hdr(struct sk_buff *skb, struct mlx5_cqe64 *cqe,
+- u32 cqe_bcnt)
++static unsigned int mlx5e_lro_update_hdr(struct sk_buff *skb,
++ struct mlx5_cqe64 *cqe,
++ u32 cqe_bcnt)
+ {
+ struct ethhdr *eth = (struct ethhdr *)(skb->data);
+ struct tcphdr *tcp;
+@@ -1211,6 +1212,8 @@ static void mlx5e_lro_update_hdr(struct sk_buff *skb, struct mlx5_cqe64 *cqe,
+ tcp->check = csum_ipv6_magic(&ipv6->saddr, &ipv6->daddr, payload_len,
+ IPPROTO_TCP, check);
+ }
++
++ return (unsigned int)((unsigned char *)tcp + tcp->doff * 4 - skb->data);
+ }
+
+ static void *mlx5e_shampo_get_packet_hd(struct mlx5e_rq *rq, u16 header_index)
+@@ -1567,8 +1570,9 @@ static inline void mlx5e_build_rx_skb(struct mlx5_cqe64 *cqe,
+ mlx5e_macsec_offload_handle_rx_skb(netdev, skb, cqe);
+
+ if (lro_num_seg > 1) {
+- mlx5e_lro_update_hdr(skb, cqe, cqe_bcnt);
+- skb_shinfo(skb)->gso_size = DIV_ROUND_UP(cqe_bcnt, lro_num_seg);
++ unsigned int hdrlen = mlx5e_lro_update_hdr(skb, cqe, cqe_bcnt);
++
++ skb_shinfo(skb)->gso_size = DIV_ROUND_UP(cqe_bcnt - hdrlen, lro_num_seg);
+ /* Subtract one since we already counted this as one
+ * "regular" packet in mlx5e_complete_rx_cqe()
+ */
+--
+2.39.5
+
--- /dev/null
+From 330bec97ee1f7416f7ab67d2536a238b526a07d3 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Mon, 7 Jul 2025 15:58:03 -0400
+Subject: net: phy: Don't register LEDs for genphy
+
+From: Sean Anderson <sean.anderson@linux.dev>
+
+[ Upstream commit f0f2b992d8185a0366be951685e08643aae17d6d ]
+
+If a PHY has no driver, the genphy driver is probed/removed directly in
+phy_attach/detach. If the PHY's ofnode has an "leds" subnode, then the
+LEDs will be (un)registered when probing/removing the genphy driver.
+This could occur if the leds are for a non-generic driver that isn't
+loaded for whatever reason. Synchronously removing the PHY device in
+phy_detach leads to the following deadlock:
+
+rtnl_lock()
+ndo_close()
+ ...
+ phy_detach()
+ phy_remove()
+ phy_leds_unregister()
+ led_classdev_unregister()
+ led_trigger_set()
+ netdev_trigger_deactivate()
+ unregister_netdevice_notifier()
+ rtnl_lock()
+
+There is a corresponding deadlock on the open/register side of things
+(and that one is reported by lockdep), but it requires a race while this
+one is deterministic.
+
+Generic PHYs do not support LEDs anyway, so don't bother registering
+them.
+
+Fixes: 01e5b728e9e4 ("net: phy: Add a binding for PHY LEDs")
+Signed-off-by: Sean Anderson <sean.anderson@linux.dev>
+Link: https://patch.msgid.link/20250707195803.666097-1-sean.anderson@linux.dev
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/phy/phy_device.c | 6 ++++--
+ 1 file changed, 4 insertions(+), 2 deletions(-)
+
+diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
+index cde0e80474a1d..875788918bcb3 100644
+--- a/drivers/net/phy/phy_device.c
++++ b/drivers/net/phy/phy_device.c
+@@ -3377,7 +3377,8 @@ static int phy_probe(struct device *dev)
+ /* Get the LEDs from the device tree, and instantiate standard
+ * LEDs for them.
+ */
+- if (IS_ENABLED(CONFIG_PHYLIB_LEDS))
++ if (IS_ENABLED(CONFIG_PHYLIB_LEDS) && !phy_driver_is_genphy(phydev) &&
++ !phy_driver_is_genphy_10g(phydev))
+ err = of_phy_leds(phydev);
+
+ out:
+@@ -3394,7 +3395,8 @@ static int phy_remove(struct device *dev)
+
+ cancel_delayed_work_sync(&phydev->state_queue);
+
+- if (IS_ENABLED(CONFIG_PHYLIB_LEDS))
++ if (IS_ENABLED(CONFIG_PHYLIB_LEDS) && !phy_driver_is_genphy(phydev) &&
++ !phy_driver_is_genphy_10g(phydev))
+ phy_leds_unregister(phydev);
+
+ phydev->state = PHY_DOWN;
+--
+2.39.5
+
--- /dev/null
+From 6a0182a194b1db7c2bd17f9f016fc08e824e9347 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 17 Jul 2025 02:28:38 +0000
+Subject: net/sched: Return NULL when htb_lookup_leaf encounters an empty
+ rbtree
+
+From: William Liu <will@willsroot.io>
+
+[ Upstream commit 0e1d5d9b5c5966e2e42e298670808590db5ed628 ]
+
+htb_lookup_leaf has a BUG_ON that can trigger with the following:
+
+tc qdisc del dev lo root
+tc qdisc add dev lo root handle 1: htb default 1
+tc class add dev lo parent 1: classid 1:1 htb rate 64bit
+tc qdisc add dev lo parent 1:1 handle 2: netem
+tc qdisc add dev lo parent 2:1 handle 3: blackhole
+ping -I lo -c1 -W0.001 127.0.0.1
+
+The root cause is the following:
+
+1. htb_dequeue calls htb_dequeue_tree which calls the dequeue handler on
+ the selected leaf qdisc
+2. netem_dequeue calls enqueue on the child qdisc
+3. blackhole_enqueue drops the packet and returns a value that is not
+ just NET_XMIT_SUCCESS
+4. Because of this, netem_dequeue calls qdisc_tree_reduce_backlog, and
+ since qlen is now 0, it calls htb_qlen_notify -> htb_deactivate ->
+ htb_deactiviate_prios -> htb_remove_class_from_row -> htb_safe_rb_erase
+5. As this is the only class in the selected hprio rbtree,
+ __rb_change_child in __rb_erase_augmented sets the rb_root pointer to
+ NULL
+6. Because blackhole_dequeue returns NULL, netem_dequeue returns NULL,
+ which causes htb_dequeue_tree to call htb_lookup_leaf with the same
+ hprio rbtree, and fail the BUG_ON
+
+The function graph for this scenario is shown here:
+ 0) | htb_enqueue() {
+ 0) + 13.635 us | netem_enqueue();
+ 0) 4.719 us | htb_activate_prios();
+ 0) # 2249.199 us | }
+ 0) | htb_dequeue() {
+ 0) 2.355 us | htb_lookup_leaf();
+ 0) | netem_dequeue() {
+ 0) + 11.061 us | blackhole_enqueue();
+ 0) | qdisc_tree_reduce_backlog() {
+ 0) | qdisc_lookup_rcu() {
+ 0) 1.873 us | qdisc_match_from_root();
+ 0) 6.292 us | }
+ 0) 1.894 us | htb_search();
+ 0) | htb_qlen_notify() {
+ 0) 2.655 us | htb_deactivate_prios();
+ 0) 6.933 us | }
+ 0) + 25.227 us | }
+ 0) 1.983 us | blackhole_dequeue();
+ 0) + 86.553 us | }
+ 0) # 2932.761 us | qdisc_warn_nonwc();
+ 0) | htb_lookup_leaf() {
+ 0) | BUG_ON();
+ ------------------------------------------
+
+The full original bug report can be seen here [1].
+
+We can fix this just by returning NULL instead of the BUG_ON,
+as htb_dequeue_tree returns NULL when htb_lookup_leaf returns
+NULL.
+
+[1] https://lore.kernel.org/netdev/pF5XOOIim0IuEfhI-SOxTgRvNoDwuux7UHKnE_Y5-zVd4wmGvNk2ceHjKb8ORnzw0cGwfmVu42g9dL7XyJLf1NEzaztboTWcm0Ogxuojoeo=@willsroot.io/
+
+Fixes: 512bb43eb542 ("pkt_sched: sch_htb: Optimize WARN_ONs in htb_dequeue_tree() etc.")
+Signed-off-by: William Liu <will@willsroot.io>
+Signed-off-by: Savino Dicanosa <savy@syst3mfailure.io>
+Link: https://patch.msgid.link/20250717022816.221364-1-will@willsroot.io
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ net/sched/sch_htb.c | 4 +++-
+ 1 file changed, 3 insertions(+), 1 deletion(-)
+
+diff --git a/net/sched/sch_htb.c b/net/sched/sch_htb.c
+index 716da8c6b3def..113b305b0d154 100644
+--- a/net/sched/sch_htb.c
++++ b/net/sched/sch_htb.c
+@@ -821,7 +821,9 @@ static struct htb_class *htb_lookup_leaf(struct htb_prio *hprio, const int prio)
+ u32 *pid;
+ } stk[TC_HTB_MAXDEPTH], *sp = stk;
+
+- BUG_ON(!hprio->row.rb_node);
++ if (unlikely(!hprio->row.rb_node))
++ return NULL;
++
+ sp->root = hprio->row.rb_node;
+ sp->pptr = &hprio->ptr;
+ sp->pid = &hprio->last_ptr_id;
+--
+2.39.5
+
--- /dev/null
+From ef5be7164a6fd007cf9685caf8ba409cdf56fff5 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 10 Jul 2025 03:09:42 -0700
+Subject: net/sched: sch_qfq: Fix race condition on qfq_aggregate
+
+From: Xiang Mei <xmei5@asu.edu>
+
+[ Upstream commit 5e28d5a3f774f118896aec17a3a20a9c5c9dfc64 ]
+
+A race condition can occur when 'agg' is modified in qfq_change_agg
+(called during qfq_enqueue) while other threads access it
+concurrently. For example, qfq_dump_class may trigger a NULL
+dereference, and qfq_delete_class may cause a use-after-free.
+
+This patch addresses the issue by:
+
+1. Moved qfq_destroy_class into the critical section.
+
+2. Added sch_tree_lock protection to qfq_dump_class and
+qfq_dump_class_stats.
+
+Fixes: 462dbc9101ac ("pkt_sched: QFQ Plus: fair-queueing service at DRR cost")
+Signed-off-by: Xiang Mei <xmei5@asu.edu>
+Reviewed-by: Cong Wang <xiyou.wangcong@gmail.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ net/sched/sch_qfq.c | 30 +++++++++++++++++++++---------
+ 1 file changed, 21 insertions(+), 9 deletions(-)
+
+diff --git a/net/sched/sch_qfq.c b/net/sched/sch_qfq.c
+index 5e557b960bde3..a2b321fec13c1 100644
+--- a/net/sched/sch_qfq.c
++++ b/net/sched/sch_qfq.c
+@@ -412,7 +412,7 @@ static int qfq_change_class(struct Qdisc *sch, u32 classid, u32 parentid,
+ bool existing = false;
+ struct nlattr *tb[TCA_QFQ_MAX + 1];
+ struct qfq_aggregate *new_agg = NULL;
+- u32 weight, lmax, inv_w;
++ u32 weight, lmax, inv_w, old_weight, old_lmax;
+ int err;
+ int delta_w;
+
+@@ -446,12 +446,16 @@ static int qfq_change_class(struct Qdisc *sch, u32 classid, u32 parentid,
+ inv_w = ONE_FP / weight;
+ weight = ONE_FP / inv_w;
+
+- if (cl != NULL &&
+- lmax == cl->agg->lmax &&
+- weight == cl->agg->class_weight)
+- return 0; /* nothing to change */
++ if (cl != NULL) {
++ sch_tree_lock(sch);
++ old_weight = cl->agg->class_weight;
++ old_lmax = cl->agg->lmax;
++ sch_tree_unlock(sch);
++ if (lmax == old_lmax && weight == old_weight)
++ return 0; /* nothing to change */
++ }
+
+- delta_w = weight - (cl ? cl->agg->class_weight : 0);
++ delta_w = weight - (cl ? old_weight : 0);
+
+ if (q->wsum + delta_w > QFQ_MAX_WSUM) {
+ NL_SET_ERR_MSG_FMT_MOD(extack,
+@@ -558,10 +562,10 @@ static int qfq_delete_class(struct Qdisc *sch, unsigned long arg,
+
+ qdisc_purge_queue(cl->qdisc);
+ qdisc_class_hash_remove(&q->clhash, &cl->common);
++ qfq_destroy_class(sch, cl);
+
+ sch_tree_unlock(sch);
+
+- qfq_destroy_class(sch, cl);
+ return 0;
+ }
+
+@@ -628,6 +632,7 @@ static int qfq_dump_class(struct Qdisc *sch, unsigned long arg,
+ {
+ struct qfq_class *cl = (struct qfq_class *)arg;
+ struct nlattr *nest;
++ u32 class_weight, lmax;
+
+ tcm->tcm_parent = TC_H_ROOT;
+ tcm->tcm_handle = cl->common.classid;
+@@ -636,8 +641,13 @@ static int qfq_dump_class(struct Qdisc *sch, unsigned long arg,
+ nest = nla_nest_start_noflag(skb, TCA_OPTIONS);
+ if (nest == NULL)
+ goto nla_put_failure;
+- if (nla_put_u32(skb, TCA_QFQ_WEIGHT, cl->agg->class_weight) ||
+- nla_put_u32(skb, TCA_QFQ_LMAX, cl->agg->lmax))
++
++ sch_tree_lock(sch);
++ class_weight = cl->agg->class_weight;
++ lmax = cl->agg->lmax;
++ sch_tree_unlock(sch);
++ if (nla_put_u32(skb, TCA_QFQ_WEIGHT, class_weight) ||
++ nla_put_u32(skb, TCA_QFQ_LMAX, lmax))
+ goto nla_put_failure;
+ return nla_nest_end(skb, nest);
+
+@@ -654,8 +664,10 @@ static int qfq_dump_class_stats(struct Qdisc *sch, unsigned long arg,
+
+ memset(&xstats, 0, sizeof(xstats));
+
++ sch_tree_lock(sch);
+ xstats.weight = cl->agg->class_weight;
+ xstats.lmax = cl->agg->lmax;
++ sch_tree_unlock(sch);
+
+ if (gnet_stats_copy_basic(d, NULL, &cl->bstats, true) < 0 ||
+ gnet_stats_copy_rate_est(d, &cl->rate_est) < 0 ||
+--
+2.39.5
+
--- /dev/null
+From 6da30ac8e0d9893d2de810062fd76c0b34054164 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 16 Jul 2025 11:45:03 +0800
+Subject: net: vlan: fix VLAN 0 refcount imbalance of toggling filtering during
+ runtime
+
+From: Dong Chenchen <dongchenchen2@huawei.com>
+
+[ Upstream commit 579d4f9ca9a9a605184a9b162355f6ba131f678d ]
+
+Assuming the "rx-vlan-filter" feature is enabled on a net device, the
+8021q module will automatically add or remove VLAN 0 when the net device
+is put administratively up or down, respectively. There are a couple of
+problems with the above scheme.
+
+The first problem is a memory leak that can happen if the "rx-vlan-filter"
+feature is disabled while the device is running:
+
+ # ip link add bond1 up type bond mode 0
+ # ethtool -K bond1 rx-vlan-filter off
+ # ip link del dev bond1
+
+When the device is put administratively down the "rx-vlan-filter"
+feature is disabled, so the 8021q module will not remove VLAN 0 and the
+memory will be leaked [1].
+
+Another problem that can happen is that the kernel can automatically
+delete VLAN 0 when the device is put administratively down despite not
+adding it when the device was put administratively up since during that
+time the "rx-vlan-filter" feature was disabled. null-ptr-unref or
+bug_on[2] will be triggered by unregister_vlan_dev() for refcount
+imbalance if toggling filtering during runtime:
+
+$ ip link add bond0 type bond mode 0
+$ ip link add link bond0 name vlan0 type vlan id 0 protocol 802.1q
+$ ethtool -K bond0 rx-vlan-filter off
+$ ifconfig bond0 up
+$ ethtool -K bond0 rx-vlan-filter on
+$ ifconfig bond0 down
+$ ip link del vlan0
+
+Root cause is as below:
+step1: add vlan0 for real_dev, such as bond, team.
+register_vlan_dev
+ vlan_vid_add(real_dev,htons(ETH_P_8021Q),0) //refcnt=1
+step2: disable vlan filter feature and enable real_dev
+step3: change filter from 0 to 1
+vlan_device_event
+ vlan_filter_push_vids
+ ndo_vlan_rx_add_vid //No refcnt added to real_dev vlan0
+step4: real_dev down
+vlan_device_event
+ vlan_vid_del(dev, htons(ETH_P_8021Q), 0); //refcnt=0
+ vlan_info_rcu_free //free vlan0
+step5: delete vlan0
+unregister_vlan_dev
+ BUG_ON(!vlan_info); //vlan_info is null
+
+Fix both problems by noting in the VLAN info whether VLAN 0 was
+automatically added upon NETDEV_UP and based on that decide whether it
+should be deleted upon NETDEV_DOWN, regardless of the state of the
+"rx-vlan-filter" feature.
+
+[1]
+unreferenced object 0xffff8880068e3100 (size 256):
+ comm "ip", pid 384, jiffies 4296130254
+ hex dump (first 32 bytes):
+ 00 20 30 0d 80 88 ff ff 00 00 00 00 00 00 00 00 . 0.............
+ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
+ backtrace (crc 81ce31fa):
+ __kmalloc_cache_noprof+0x2b5/0x340
+ vlan_vid_add+0x434/0x940
+ vlan_device_event.cold+0x75/0xa8
+ notifier_call_chain+0xca/0x150
+ __dev_notify_flags+0xe3/0x250
+ rtnl_configure_link+0x193/0x260
+ rtnl_newlink_create+0x383/0x8e0
+ __rtnl_newlink+0x22c/0xa40
+ rtnl_newlink+0x627/0xb00
+ rtnetlink_rcv_msg+0x6fb/0xb70
+ netlink_rcv_skb+0x11f/0x350
+ netlink_unicast+0x426/0x710
+ netlink_sendmsg+0x75a/0xc20
+ __sock_sendmsg+0xc1/0x150
+ ____sys_sendmsg+0x5aa/0x7b0
+ ___sys_sendmsg+0xfc/0x180
+
+[2]
+kernel BUG at net/8021q/vlan.c:99!
+Oops: invalid opcode: 0000 [#1] SMP KASAN PTI
+CPU: 0 UID: 0 PID: 382 Comm: ip Not tainted 6.16.0-rc3 #61 PREEMPT(voluntary)
+Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
+BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014
+RIP: 0010:unregister_vlan_dev (net/8021q/vlan.c:99 (discriminator 1))
+RSP: 0018:ffff88810badf310 EFLAGS: 00010246
+RAX: 0000000000000000 RBX: ffff88810da84000 RCX: ffffffffb47ceb9a
+RDX: dffffc0000000000 RSI: 0000000000000008 RDI: ffff88810e8b43c8
+RBP: 0000000000000000 R08: 0000000000000000 R09: fffffbfff6cefe80
+R10: ffffffffb677f407 R11: ffff88810badf3c0 R12: ffff88810e8b4000
+R13: 0000000000000000 R14: ffff88810642a5c0 R15: 000000000000017e
+FS: 00007f1ff68c20c0(0000) GS:ffff888163a24000(0000) knlGS:0000000000000000
+CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
+CR2: 00007f1ff5dad240 CR3: 0000000107e56000 CR4: 00000000000006f0
+Call Trace:
+ <TASK>
+rtnl_dellink (net/core/rtnetlink.c:3511 net/core/rtnetlink.c:3553)
+rtnetlink_rcv_msg (net/core/rtnetlink.c:6945)
+netlink_rcv_skb (net/netlink/af_netlink.c:2535)
+netlink_unicast (net/netlink/af_netlink.c:1314 net/netlink/af_netlink.c:1339)
+netlink_sendmsg (net/netlink/af_netlink.c:1883)
+____sys_sendmsg (net/socket.c:712 net/socket.c:727 net/socket.c:2566)
+___sys_sendmsg (net/socket.c:2622)
+__sys_sendmsg (net/socket.c:2652)
+do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94)
+
+Fixes: ad1afb003939 ("vlan_dev: VLAN 0 should be treated as "no vlan tag" (802.1p packet)")
+Reported-by: syzbot+a8b046e462915c65b10b@syzkaller.appspotmail.com
+Closes: https://syzkaller.appspot.com/bug?extid=a8b046e462915c65b10b
+Suggested-by: Ido Schimmel <idosch@idosch.org>
+Signed-off-by: Dong Chenchen <dongchenchen2@huawei.com>
+Reviewed-by: Ido Schimmel <idosch@nvidia.com>
+Link: https://patch.msgid.link/20250716034504.2285203-2-dongchenchen2@huawei.com
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ net/8021q/vlan.c | 42 +++++++++++++++++++++++++++++++++---------
+ net/8021q/vlan.h | 1 +
+ 2 files changed, 34 insertions(+), 9 deletions(-)
+
+diff --git a/net/8021q/vlan.c b/net/8021q/vlan.c
+index b477ba37a6991..422f726346ea5 100644
+--- a/net/8021q/vlan.c
++++ b/net/8021q/vlan.c
+@@ -358,6 +358,35 @@ static int __vlan_device_event(struct net_device *dev, unsigned long event)
+ return err;
+ }
+
++static void vlan_vid0_add(struct net_device *dev)
++{
++ struct vlan_info *vlan_info;
++ int err;
++
++ if (!(dev->features & NETIF_F_HW_VLAN_CTAG_FILTER))
++ return;
++
++ pr_info("adding VLAN 0 to HW filter on device %s\n", dev->name);
++
++ err = vlan_vid_add(dev, htons(ETH_P_8021Q), 0);
++ if (err)
++ return;
++
++ vlan_info = rtnl_dereference(dev->vlan_info);
++ vlan_info->auto_vid0 = true;
++}
++
++static void vlan_vid0_del(struct net_device *dev)
++{
++ struct vlan_info *vlan_info = rtnl_dereference(dev->vlan_info);
++
++ if (!vlan_info || !vlan_info->auto_vid0)
++ return;
++
++ vlan_info->auto_vid0 = false;
++ vlan_vid_del(dev, htons(ETH_P_8021Q), 0);
++}
++
+ static int vlan_device_event(struct notifier_block *unused, unsigned long event,
+ void *ptr)
+ {
+@@ -379,15 +408,10 @@ static int vlan_device_event(struct notifier_block *unused, unsigned long event,
+ return notifier_from_errno(err);
+ }
+
+- if ((event == NETDEV_UP) &&
+- (dev->features & NETIF_F_HW_VLAN_CTAG_FILTER)) {
+- pr_info("adding VLAN 0 to HW filter on device %s\n",
+- dev->name);
+- vlan_vid_add(dev, htons(ETH_P_8021Q), 0);
+- }
+- if (event == NETDEV_DOWN &&
+- (dev->features & NETIF_F_HW_VLAN_CTAG_FILTER))
+- vlan_vid_del(dev, htons(ETH_P_8021Q), 0);
++ if (event == NETDEV_UP)
++ vlan_vid0_add(dev);
++ else if (event == NETDEV_DOWN)
++ vlan_vid0_del(dev);
+
+ vlan_info = rtnl_dereference(dev->vlan_info);
+ if (!vlan_info)
+diff --git a/net/8021q/vlan.h b/net/8021q/vlan.h
+index 5eaf38875554b..c7ffe591d5936 100644
+--- a/net/8021q/vlan.h
++++ b/net/8021q/vlan.h
+@@ -33,6 +33,7 @@ struct vlan_info {
+ struct vlan_group grp;
+ struct list_head vid_list;
+ unsigned int nr_vids;
++ bool auto_vid0;
+ struct rcu_head rcu;
+ };
+
+--
+2.39.5
+
--- /dev/null
+From 7bcc627f0d91dd7a06ec5c1129465581adb77272 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 16 Jul 2025 20:39:14 +0200
+Subject: netfilter: nf_conntrack: fix crash due to removal of uninitialised
+ entry
+
+From: Florian Westphal <fw@strlen.de>
+
+[ Upstream commit 2d72afb340657f03f7261e9243b44457a9228ac7 ]
+
+A crash in conntrack was reported while trying to unlink the conntrack
+entry from the hash bucket list:
+ [exception RIP: __nf_ct_delete_from_lists+172]
+ [..]
+ #7 [ff539b5a2b043aa0] nf_ct_delete at ffffffffc124d421 [nf_conntrack]
+ #8 [ff539b5a2b043ad0] nf_ct_gc_expired at ffffffffc124d999 [nf_conntrack]
+ #9 [ff539b5a2b043ae0] __nf_conntrack_find_get at ffffffffc124efbc [nf_conntrack]
+ [..]
+
+The nf_conn struct is marked as allocated from slab but appears to be in
+a partially initialised state:
+
+ ct hlist pointer is garbage; looks like the ct hash value
+ (hence crash).
+ ct->status is equal to IPS_CONFIRMED|IPS_DYING, which is expected
+ ct->timeout is 30000 (=30s), which is unexpected.
+
+Everything else looks like normal udp conntrack entry. If we ignore
+ct->status and pretend its 0, the entry matches those that are newly
+allocated but not yet inserted into the hash:
+ - ct hlist pointers are overloaded and store/cache the raw tuple hash
+ - ct->timeout matches the relative time expected for a new udp flow
+ rather than the absolute 'jiffies' value.
+
+If it were not for the presence of IPS_CONFIRMED,
+__nf_conntrack_find_get() would have skipped the entry.
+
+Theory is that we did hit following race:
+
+cpu x cpu y cpu z
+ found entry E found entry E
+ E is expired <preemption>
+ nf_ct_delete()
+ return E to rcu slab
+ init_conntrack
+ E is re-inited,
+ ct->status set to 0
+ reply tuplehash hnnode.pprev
+ stores hash value.
+
+cpu y found E right before it was deleted on cpu x.
+E is now re-inited on cpu z. cpu y was preempted before
+checking for expiry and/or confirm bit.
+
+ ->refcnt set to 1
+ E now owned by skb
+ ->timeout set to 30000
+
+If cpu y were to resume now, it would observe E as
+expired but would skip E due to missing CONFIRMED bit.
+
+ nf_conntrack_confirm gets called
+ sets: ct->status |= CONFIRMED
+ This is wrong: E is not yet added
+ to hashtable.
+
+cpu y resumes, it observes E as expired but CONFIRMED:
+ <resumes>
+ nf_ct_expired()
+ -> yes (ct->timeout is 30s)
+ confirmed bit set.
+
+cpu y will try to delete E from the hashtable:
+ nf_ct_delete() -> set DYING bit
+ __nf_ct_delete_from_lists
+
+Even this scenario doesn't guarantee a crash:
+cpu z still holds the table bucket lock(s) so y blocks:
+
+ wait for spinlock held by z
+
+ CONFIRMED is set but there is no
+ guarantee ct will be added to hash:
+ "chaintoolong" or "clash resolution"
+ logic both skip the insert step.
+ reply hnnode.pprev still stores the
+ hash value.
+
+ unlocks spinlock
+ return NF_DROP
+ <unblocks, then
+ crashes on hlist_nulls_del_rcu pprev>
+
+In case CPU z does insert the entry into the hashtable, cpu y will unlink
+E again right away but no crash occurs.
+
+Without 'cpu y' race, 'garbage' hlist is of no consequence:
+ct refcnt remains at 1, eventually skb will be free'd and E gets
+destroyed via: nf_conntrack_put -> nf_conntrack_destroy -> nf_ct_destroy.
+
+To resolve this, move the IPS_CONFIRMED assignment after the table
+insertion but before the unlock.
+
+Pablo points out that the confirm-bit-store could be reordered to happen
+before hlist add resp. the timeout fixup, so switch to set_bit and
+before_atomic memory barrier to prevent this.
+
+It doesn't matter if other CPUs can observe a newly inserted entry right
+before the CONFIRMED bit was set:
+
+Such event cannot be distinguished from above "E is the old incarnation"
+case: the entry will be skipped.
+
+Also change nf_ct_should_gc() to first check the confirmed bit.
+
+The gc sequence is:
+ 1. Check if entry has expired, if not skip to next entry
+ 2. Obtain a reference to the expired entry.
+ 3. Call nf_ct_should_gc() to double-check step 1.
+
+nf_ct_should_gc() is thus called only for entries that already failed an
+expiry check. After this patch, once the confirmed bit check passes
+ct->timeout has been altered to reflect the absolute 'best before' date
+instead of a relative time. Step 3 will therefore not remove the entry.
+
+Without this change to nf_ct_should_gc() we could still get this sequence:
+
+ 1. Check if entry has expired.
+ 2. Obtain a reference.
+ 3. Call nf_ct_should_gc() to double-check step 1:
+ 4 - entry is still observed as expired
+ 5 - meanwhile, ct->timeout is corrected to absolute value on other CPU
+ and confirm bit gets set
+ 6 - confirm bit is seen
+ 7 - valid entry is removed again
+
+First do check 6), then 4) so the gc expiry check always picks up either
+confirmed bit unset (entry gets skipped) or expiry re-check failure for
+re-inited conntrack objects.
+
+This change cannot be backported to releases before 5.19. Without
+commit 8a75a2c17410 ("netfilter: conntrack: remove unconfirmed list")
+|= IPS_CONFIRMED line cannot be moved without further changes.
+
+Cc: Razvan Cojocaru <rzvncj@gmail.com>
+Link: https://lore.kernel.org/netfilter-devel/20250627142758.25664-1-fw@strlen.de/
+Link: https://lore.kernel.org/netfilter-devel/4239da15-83ff-4ca4-939d-faef283471bb@gmail.com/
+Fixes: 1397af5bfd7d ("netfilter: conntrack: remove the percpu dying list")
+Signed-off-by: Florian Westphal <fw@strlen.de>
+Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ include/net/netfilter/nf_conntrack.h | 15 +++++++++++++--
+ net/netfilter/nf_conntrack_core.c | 26 ++++++++++++++++++++------
+ 2 files changed, 33 insertions(+), 8 deletions(-)
+
+diff --git a/include/net/netfilter/nf_conntrack.h b/include/net/netfilter/nf_conntrack.h
+index 4085765c33705..a2c987289401e 100644
+--- a/include/net/netfilter/nf_conntrack.h
++++ b/include/net/netfilter/nf_conntrack.h
+@@ -302,8 +302,19 @@ static inline bool nf_ct_is_expired(const struct nf_conn *ct)
+ /* use after obtaining a reference count */
+ static inline bool nf_ct_should_gc(const struct nf_conn *ct)
+ {
+- return nf_ct_is_expired(ct) && nf_ct_is_confirmed(ct) &&
+- !nf_ct_is_dying(ct);
++ if (!nf_ct_is_confirmed(ct))
++ return false;
++
++ /* load ct->timeout after is_confirmed() test.
++ * Pairs with __nf_conntrack_confirm() which:
++ * 1. Increases ct->timeout value
++ * 2. Inserts ct into rcu hlist
++ * 3. Sets the confirmed bit
++ * 4. Unlocks the hlist lock
++ */
++ smp_acquire__after_ctrl_dep();
++
++ return nf_ct_is_expired(ct) && !nf_ct_is_dying(ct);
+ }
+
+ #define NF_CT_DAY (86400 * HZ)
+diff --git a/net/netfilter/nf_conntrack_core.c b/net/netfilter/nf_conntrack_core.c
+index 34ad5975fbf3b..0081c1a0d5e56 100644
+--- a/net/netfilter/nf_conntrack_core.c
++++ b/net/netfilter/nf_conntrack_core.c
+@@ -1075,6 +1075,12 @@ static int nf_ct_resolve_clash_harder(struct sk_buff *skb, u32 repl_idx)
+
+ hlist_nulls_add_head_rcu(&loser_ct->tuplehash[IP_CT_DIR_REPLY].hnnode,
+ &nf_conntrack_hash[repl_idx]);
++ /* confirmed bit must be set after hlist add, not before:
++ * loser_ct can still be visible to other cpu due to
++ * SLAB_TYPESAFE_BY_RCU.
++ */
++ smp_mb__before_atomic();
++ set_bit(IPS_CONFIRMED_BIT, &loser_ct->status);
+
+ NF_CT_STAT_INC(net, clash_resolve);
+ return NF_ACCEPT;
+@@ -1211,8 +1217,6 @@ __nf_conntrack_confirm(struct sk_buff *skb)
+ * user context, else we insert an already 'dead' hash, blocking
+ * further use of that particular connection -JM.
+ */
+- ct->status |= IPS_CONFIRMED;
+-
+ if (unlikely(nf_ct_is_dying(ct))) {
+ NF_CT_STAT_INC(net, insert_failed);
+ goto dying;
+@@ -1244,7 +1248,7 @@ __nf_conntrack_confirm(struct sk_buff *skb)
+ }
+ }
+
+- /* Timer relative to confirmation time, not original
++ /* Timeout is relative to confirmation time, not original
+ setting time, otherwise we'd get timer wrap in
+ weird delay cases. */
+ ct->timeout += nfct_time_stamp;
+@@ -1252,11 +1256,21 @@ __nf_conntrack_confirm(struct sk_buff *skb)
+ __nf_conntrack_insert_prepare(ct);
+
+ /* Since the lookup is lockless, hash insertion must be done after
+- * starting the timer and setting the CONFIRMED bit. The RCU barriers
+- * guarantee that no other CPU can find the conntrack before the above
+- * stores are visible.
++ * setting ct->timeout. The RCU barriers guarantee that no other CPU
++ * can find the conntrack before the above stores are visible.
+ */
+ __nf_conntrack_hash_insert(ct, hash, reply_hash);
++
++ /* IPS_CONFIRMED unset means 'ct not (yet) in hash', conntrack lookups
++ * skip entries that lack this bit. This happens when a CPU is looking
++ * at a stale entry that is being recycled due to SLAB_TYPESAFE_BY_RCU
++ * or when another CPU encounters this entry right after the insertion
++ * but before the set-confirm-bit below. This bit must not be set until
++ * after __nf_conntrack_hash_insert().
++ */
++ smp_mb__before_atomic();
++ set_bit(IPS_CONFIRMED_BIT, &ct->status);
++
+ nf_conntrack_double_unlock(hash, reply_hash);
+ local_bh_enable();
+
+--
+2.39.5
+
--- /dev/null
+From 6dd1168d0375ba409f0d4d499941a9257ccd667f Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 1 Jul 2025 15:17:17 +0800
+Subject: nvme: fix inconsistent RCU list manipulation in
+ nvme_ns_add_to_ctrl_list()
+
+From: Zheng Qixing <zhengqixing@huawei.com>
+
+[ Upstream commit 80d7762e0a42307ee31b21f090e21349b98c14f6 ]
+
+When inserting a namespace into the controller's namespace list, the
+function uses list_add_rcu() when the namespace is inserted in the middle
+of the list, but falls back to a regular list_add() when adding at the
+head of the list.
+
+This inconsistency could lead to race conditions during concurrent
+access, as users might observe a partially updated list. Fix this by
+consistently using list_add_rcu() in both code paths to ensure proper
+RCU protection throughout the entire function.
+
+Fixes: be647e2c76b2 ("nvme: use srcu for iterating namespace list")
+Signed-off-by: Zheng Qixing <zhengqixing@huawei.com>
+Signed-off-by: Christoph Hellwig <hch@lst.de>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/nvme/host/core.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/drivers/nvme/host/core.c b/drivers/nvme/host/core.c
+index 6e2d0fda3ba4a..9feb47a604659 100644
+--- a/drivers/nvme/host/core.c
++++ b/drivers/nvme/host/core.c
+@@ -3596,7 +3596,7 @@ static void nvme_ns_add_to_ctrl_list(struct nvme_ns *ns)
+ return;
+ }
+ }
+- list_add(&ns->list, &ns->ctrl->namespaces);
++ list_add_rcu(&ns->list, &ns->ctrl->namespaces);
+ }
+
+ static void nvme_alloc_ns(struct nvme_ctrl *ctrl, struct nvme_ns_info *info)
+--
+2.39.5
+
--- /dev/null
+From f98ba178631790840f828b4984158c2ecc97a248 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 15 Jul 2025 09:28:12 +0800
+Subject: nvme: fix misaccounting of nvme-mpath inflight I/O
+
+From: Yu Kuai <yukuai3@huawei.com>
+
+[ Upstream commit 71257925e83eae1cb6913d65ca71927d2220e6d1 ]
+
+Procedures for nvme-mpath IO accounting:
+
+ 1) initialize nvme_request and clear flags;
+ 2) set NVME_MPATH_IO_STATS and increase inflight counter when IO
+ started;
+ 3) check NVME_MPATH_IO_STATS and decrease inflight counter when IO is
+ done;
+
+However, for the case nvme_fail_nonready_command(), both step 1) and 2)
+are skipped, and if old nvme_request set NVME_MPATH_IO_STATS and then
+request is reused, step 3) will still be executed, causing inflight I/O
+counter to be negative.
+
+Fix the problem by clearing nvme_request in nvme_fail_nonready_command().
+
+Fixes: ea5e5f42cd2c ("nvme-fabrics: avoid double completions in nvmf_fail_nonready_command")
+Reported-by: Yi Zhang <yi.zhang@redhat.com>
+Closes: https://lore.kernel.org/all/CAHj4cs_+dauobyYyP805t33WMJVzOWj=7+51p4_j9rA63D9sog@mail.gmail.com/
+Signed-off-by: Yu Kuai <yukuai3@huawei.com>
+Signed-off-by: Christoph Hellwig <hch@lst.de>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/nvme/host/core.c | 4 ++++
+ 1 file changed, 4 insertions(+)
+
+diff --git a/drivers/nvme/host/core.c b/drivers/nvme/host/core.c
+index 9feb47a604659..13221cc0d17d4 100644
+--- a/drivers/nvme/host/core.c
++++ b/drivers/nvme/host/core.c
+@@ -689,6 +689,10 @@ blk_status_t nvme_fail_nonready_command(struct nvme_ctrl *ctrl,
+ !test_bit(NVME_CTRL_FAILFAST_EXPIRED, &ctrl->flags) &&
+ !blk_noretry_request(rq) && !(rq->cmd_flags & REQ_NVME_MPATH))
+ return BLK_STS_RESOURCE;
++
++ if (!(rq->rq_flags & RQF_DONTPREP))
++ nvme_clear_nvme_request(rq);
++
+ return nvme_host_path_error(rq);
+ }
+ EXPORT_SYMBOL_GPL(nvme_fail_nonready_command);
+--
+2.39.5
+
--- /dev/null
+From b40a2c1562c29fbfa017742d450ffb402271679a Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 17 Jul 2025 08:55:50 +0000
+Subject: Revert "cgroup_freezer: cgroup_freezing: Check if not frozen"
+
+From: Chen Ridong <chenridong@huawei.com>
+
+[ Upstream commit 14a67b42cb6f3ab66f41603c062c5056d32ea7dd ]
+
+This reverts commit cff5f49d433fcd0063c8be7dd08fa5bf190c6c37.
+
+Commit cff5f49d433f ("cgroup_freezer: cgroup_freezing: Check if not
+frozen") modified the cgroup_freezing() logic to verify that the FROZEN
+flag is not set, affecting the return value of the freezing() function,
+in order to address a warning in __thaw_task.
+
+A race condition exists that may allow tasks to escape being frozen. The
+following scenario demonstrates this issue:
+
+CPU 0 (get_signal path) CPU 1 (freezer.state reader)
+try_to_freeze read freezer.state
+__refrigerator freezer_read
+ update_if_frozen
+WRITE_ONCE(current->__state, TASK_FROZEN);
+ ...
+ /* Task is now marked frozen */
+ /* frozen(task) == true */
+ /* Assuming other tasks are frozen */
+ freezer->state |= CGROUP_FROZEN;
+/* freezing(current) returns false */
+/* because cgroup is frozen (not freezing) */
+break out
+__set_current_state(TASK_RUNNING);
+/* Bug: Task resumes running when it should remain frozen */
+
+The existing !frozen(p) check in __thaw_task makes the
+WARN_ON_ONCE(freezing(p)) warning redundant. Removing this warning enables
+reverting the commit cff5f49d433f ("cgroup_freezer: cgroup_freezing: Check
+if not frozen") to resolve the issue.
+
+The warning has been removed in the previous patch. This patch revert the
+commit cff5f49d433f ("cgroup_freezer: cgroup_freezing: Check if not
+frozen") to complete the fix.
+
+Fixes: cff5f49d433f ("cgroup_freezer: cgroup_freezing: Check if not frozen")
+Reported-by: Zhong Jiawei<zhongjiawei1@huawei.com>
+Signed-off-by: Chen Ridong <chenridong@huawei.com>
+Signed-off-by: Tejun Heo <tj@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ kernel/cgroup/legacy_freezer.c | 8 +-------
+ 1 file changed, 1 insertion(+), 7 deletions(-)
+
+diff --git a/kernel/cgroup/legacy_freezer.c b/kernel/cgroup/legacy_freezer.c
+index a3e13e6d5ee40..bee2f9ea5e4ae 100644
+--- a/kernel/cgroup/legacy_freezer.c
++++ b/kernel/cgroup/legacy_freezer.c
+@@ -66,15 +66,9 @@ static struct freezer *parent_freezer(struct freezer *freezer)
+ bool cgroup_freezing(struct task_struct *task)
+ {
+ bool ret;
+- unsigned int state;
+
+ rcu_read_lock();
+- /* Check if the cgroup is still FREEZING, but not FROZEN. The extra
+- * !FROZEN check is required, because the FREEZING bit is not cleared
+- * when the state FROZEN is reached.
+- */
+- state = task_freezer(task)->state;
+- ret = (state & CGROUP_FREEZING) && !(state & CGROUP_FROZEN);
++ ret = task_freezer(task)->state & CGROUP_FREEZING;
+ rcu_read_unlock();
+
+ return ret;
+--
+2.39.5
+
--- /dev/null
+From 09351ec1f7b3bda68c839e90fbb5fdc4623fc181 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 11 Jul 2025 18:21:19 +0000
+Subject: rpl: Fix use-after-free in rpl_do_srh_inline().
+
+From: Kuniyuki Iwashima <kuniyu@google.com>
+
+[ Upstream commit b640daa2822a39ff76e70200cb2b7b892b896dce ]
+
+Running lwt_dst_cache_ref_loop.sh in selftest with KASAN triggers
+the splat below [0].
+
+rpl_do_srh_inline() fetches ipv6_hdr(skb) and accesses it after
+skb_cow_head(), which is illegal as the header could be freed then.
+
+Let's fix it by making oldhdr to a local struct instead of a pointer.
+
+[0]:
+[root@fedora net]# ./lwt_dst_cache_ref_loop.sh
+...
+TEST: rpl (input)
+[ 57.631529] ==================================================================
+BUG: KASAN: slab-use-after-free in rpl_do_srh_inline.isra.0 (net/ipv6/rpl_iptunnel.c:174)
+Read of size 40 at addr ffff888122bf96d8 by task ping6/1543
+
+CPU: 50 UID: 0 PID: 1543 Comm: ping6 Not tainted 6.16.0-rc5-01302-gfadd1e6231b1 #23 PREEMPT(voluntary)
+Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
+Call Trace:
+ <IRQ>
+ dump_stack_lvl (lib/dump_stack.c:122)
+ print_report (mm/kasan/report.c:409 mm/kasan/report.c:521)
+ kasan_report (mm/kasan/report.c:221 mm/kasan/report.c:636)
+ kasan_check_range (mm/kasan/generic.c:175 (discriminator 1) mm/kasan/generic.c:189 (discriminator 1))
+ __asan_memmove (mm/kasan/shadow.c:94 (discriminator 2))
+ rpl_do_srh_inline.isra.0 (net/ipv6/rpl_iptunnel.c:174)
+ rpl_input (net/ipv6/rpl_iptunnel.c:201 net/ipv6/rpl_iptunnel.c:282)
+ lwtunnel_input (net/core/lwtunnel.c:459)
+ ipv6_rcv (./include/net/dst.h:471 (discriminator 1) ./include/net/dst.h:469 (discriminator 1) net/ipv6/ip6_input.c:79 (discriminator 1) ./include/linux/netfilter.h:317 (discriminator 1) ./include/linux/netfilter.h:311 (discriminator 1) net/ipv6/ip6_input.c:311 (discriminator 1))
+ __netif_receive_skb_one_core (net/core/dev.c:5967)
+ process_backlog (./include/linux/rcupdate.h:869 net/core/dev.c:6440)
+ __napi_poll.constprop.0 (net/core/dev.c:7452)
+ net_rx_action (net/core/dev.c:7518 net/core/dev.c:7643)
+ handle_softirqs (kernel/softirq.c:579)
+ do_softirq (kernel/softirq.c:480 (discriminator 20))
+ </IRQ>
+ <TASK>
+ __local_bh_enable_ip (kernel/softirq.c:407)
+ __dev_queue_xmit (net/core/dev.c:4740)
+ ip6_finish_output2 (./include/linux/netdevice.h:3358 ./include/net/neighbour.h:526 ./include/net/neighbour.h:540 net/ipv6/ip6_output.c:141)
+ ip6_finish_output (net/ipv6/ip6_output.c:215 net/ipv6/ip6_output.c:226)
+ ip6_output (./include/linux/netfilter.h:306 net/ipv6/ip6_output.c:248)
+ ip6_send_skb (net/ipv6/ip6_output.c:1983)
+ rawv6_sendmsg (net/ipv6/raw.c:588 net/ipv6/raw.c:918)
+ __sys_sendto (net/socket.c:714 (discriminator 1) net/socket.c:729 (discriminator 1) net/socket.c:2228 (discriminator 1))
+ __x64_sys_sendto (net/socket.c:2231)
+ do_syscall_64 (arch/x86/entry/syscall_64.c:63 (discriminator 1) arch/x86/entry/syscall_64.c:94 (discriminator 1))
+ entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)
+RIP: 0033:0x7f68cffb2a06
+Code: 5d e8 41 8b 93 08 03 00 00 59 5e 48 83 f8 fc 75 19 83 e2 39 83 fa 08 75 11 e8 26 ff ff ff 66 0f 1f 44 00 00 48 8b 45 10 0f 05 <48> 8b 5d f8 c9 c3 0f 1f 40 00 f3 0f 1e fa 55 48 89 e5 48 83 ec 08
+RSP: 002b:00007ffefb7c53d0 EFLAGS: 00000202 ORIG_RAX: 000000000000002c
+RAX: ffffffffffffffda RBX: 0000564cd69f10a0 RCX: 00007f68cffb2a06
+RDX: 0000000000000040 RSI: 0000564cd69f10a4 RDI: 0000000000000003
+RBP: 00007ffefb7c53f0 R08: 0000564cd6a032ac R09: 000000000000001c
+R10: 0000000000000000 R11: 0000000000000202 R12: 0000564cd69f10a4
+R13: 0000000000000040 R14: 00007ffefb7c66e0 R15: 0000564cd69f10a0
+ </TASK>
+
+Allocated by task 1543:
+ kasan_save_stack (mm/kasan/common.c:48)
+ kasan_save_track (mm/kasan/common.c:60 (discriminator 1) mm/kasan/common.c:69 (discriminator 1))
+ __kasan_slab_alloc (mm/kasan/common.c:319 mm/kasan/common.c:345)
+ kmem_cache_alloc_node_noprof (./include/linux/kasan.h:250 mm/slub.c:4148 mm/slub.c:4197 mm/slub.c:4249)
+ kmalloc_reserve (net/core/skbuff.c:581 (discriminator 88))
+ __alloc_skb (net/core/skbuff.c:669)
+ __ip6_append_data (net/ipv6/ip6_output.c:1672 (discriminator 1))
+ ip6_append_data (net/ipv6/ip6_output.c:1859)
+ rawv6_sendmsg (net/ipv6/raw.c:911)
+ __sys_sendto (net/socket.c:714 (discriminator 1) net/socket.c:729 (discriminator 1) net/socket.c:2228 (discriminator 1))
+ __x64_sys_sendto (net/socket.c:2231)
+ do_syscall_64 (arch/x86/entry/syscall_64.c:63 (discriminator 1) arch/x86/entry/syscall_64.c:94 (discriminator 1))
+ entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)
+
+Freed by task 1543:
+ kasan_save_stack (mm/kasan/common.c:48)
+ kasan_save_track (mm/kasan/common.c:60 (discriminator 1) mm/kasan/common.c:69 (discriminator 1))
+ kasan_save_free_info (mm/kasan/generic.c:579 (discriminator 1))
+ __kasan_slab_free (mm/kasan/common.c:271)
+ kmem_cache_free (mm/slub.c:4643 (discriminator 3) mm/slub.c:4745 (discriminator 3))
+ pskb_expand_head (net/core/skbuff.c:2274)
+ rpl_do_srh_inline.isra.0 (net/ipv6/rpl_iptunnel.c:158 (discriminator 1))
+ rpl_input (net/ipv6/rpl_iptunnel.c:201 net/ipv6/rpl_iptunnel.c:282)
+ lwtunnel_input (net/core/lwtunnel.c:459)
+ ipv6_rcv (./include/net/dst.h:471 (discriminator 1) ./include/net/dst.h:469 (discriminator 1) net/ipv6/ip6_input.c:79 (discriminator 1) ./include/linux/netfilter.h:317 (discriminator 1) ./include/linux/netfilter.h:311 (discriminator 1) net/ipv6/ip6_input.c:311 (discriminator 1))
+ __netif_receive_skb_one_core (net/core/dev.c:5967)
+ process_backlog (./include/linux/rcupdate.h:869 net/core/dev.c:6440)
+ __napi_poll.constprop.0 (net/core/dev.c:7452)
+ net_rx_action (net/core/dev.c:7518 net/core/dev.c:7643)
+ handle_softirqs (kernel/softirq.c:579)
+ do_softirq (kernel/softirq.c:480 (discriminator 20))
+ __local_bh_enable_ip (kernel/softirq.c:407)
+ __dev_queue_xmit (net/core/dev.c:4740)
+ ip6_finish_output2 (./include/linux/netdevice.h:3358 ./include/net/neighbour.h:526 ./include/net/neighbour.h:540 net/ipv6/ip6_output.c:141)
+ ip6_finish_output (net/ipv6/ip6_output.c:215 net/ipv6/ip6_output.c:226)
+ ip6_output (./include/linux/netfilter.h:306 net/ipv6/ip6_output.c:248)
+ ip6_send_skb (net/ipv6/ip6_output.c:1983)
+ rawv6_sendmsg (net/ipv6/raw.c:588 net/ipv6/raw.c:918)
+ __sys_sendto (net/socket.c:714 (discriminator 1) net/socket.c:729 (discriminator 1) net/socket.c:2228 (discriminator 1))
+ __x64_sys_sendto (net/socket.c:2231)
+ do_syscall_64 (arch/x86/entry/syscall_64.c:63 (discriminator 1) arch/x86/entry/syscall_64.c:94 (discriminator 1))
+ entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)
+
+The buggy address belongs to the object at ffff888122bf96c0
+ which belongs to the cache skbuff_small_head of size 704
+The buggy address is located 24 bytes inside of
+ freed 704-byte region [ffff888122bf96c0, ffff888122bf9980)
+
+The buggy address belongs to the physical page:
+page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x122bf8
+head: order:3 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0
+flags: 0x200000000000040(head|node=0|zone=2)
+page_type: f5(slab)
+raw: 0200000000000040 ffff888101fc0a00 ffffea000464dc00 0000000000000002
+raw: 0000000000000000 0000000080270027 00000000f5000000 0000000000000000
+head: 0200000000000040 ffff888101fc0a00 ffffea000464dc00 0000000000000002
+head: 0000000000000000 0000000080270027 00000000f5000000 0000000000000000
+head: 0200000000000003 ffffea00048afe01 00000000ffffffff 00000000ffffffff
+head: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000
+page dumped because: kasan: bad access detected
+
+Memory state around the buggy address:
+ ffff888122bf9580: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
+ ffff888122bf9600: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
+>ffff888122bf9680: fc fc fc fc fc fc fc fc fa fb fb fb fb fb fb fb
+ ^
+ ffff888122bf9700: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
+ ffff888122bf9780: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
+
+Fixes: a7a29f9c361f8 ("net: ipv6: add rpl sr tunnel")
+Signed-off-by: Kuniyuki Iwashima <kuniyu@google.com>
+Reviewed-by: Simon Horman <horms@kernel.org>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ net/ipv6/rpl_iptunnel.c | 8 ++++----
+ 1 file changed, 4 insertions(+), 4 deletions(-)
+
+diff --git a/net/ipv6/rpl_iptunnel.c b/net/ipv6/rpl_iptunnel.c
+index 28fc7fae57972..523aa8c9b382f 100644
+--- a/net/ipv6/rpl_iptunnel.c
++++ b/net/ipv6/rpl_iptunnel.c
+@@ -129,13 +129,13 @@ static int rpl_do_srh_inline(struct sk_buff *skb, const struct rpl_lwt *rlwt,
+ struct dst_entry *cache_dst)
+ {
+ struct ipv6_rpl_sr_hdr *isrh, *csrh;
+- const struct ipv6hdr *oldhdr;
++ struct ipv6hdr oldhdr;
+ struct ipv6hdr *hdr;
+ unsigned char *buf;
+ size_t hdrlen;
+ int err;
+
+- oldhdr = ipv6_hdr(skb);
++ memcpy(&oldhdr, ipv6_hdr(skb), sizeof(oldhdr));
+
+ buf = kcalloc(struct_size(srh, segments.addr, srh->segments_left), 2, GFP_ATOMIC);
+ if (!buf)
+@@ -147,7 +147,7 @@ static int rpl_do_srh_inline(struct sk_buff *skb, const struct rpl_lwt *rlwt,
+ memcpy(isrh, srh, sizeof(*isrh));
+ memcpy(isrh->rpl_segaddr, &srh->rpl_segaddr[1],
+ (srh->segments_left - 1) * 16);
+- isrh->rpl_segaddr[srh->segments_left - 1] = oldhdr->daddr;
++ isrh->rpl_segaddr[srh->segments_left - 1] = oldhdr.daddr;
+
+ ipv6_rpl_srh_compress(csrh, isrh, &srh->rpl_segaddr[0],
+ isrh->segments_left - 1);
+@@ -169,7 +169,7 @@ static int rpl_do_srh_inline(struct sk_buff *skb, const struct rpl_lwt *rlwt,
+ skb_mac_header_rebuild(skb);
+
+ hdr = ipv6_hdr(skb);
+- memmove(hdr, oldhdr, sizeof(*hdr));
++ memmove(hdr, &oldhdr, sizeof(*hdr));
+ isrh = (void *)hdr + sizeof(*hdr);
+ memcpy(isrh, csrh, hdrlen);
+
+--
+2.39.5
+
--- /dev/null
+From 6c542cc42339078271c7b9118482d105452f9c9f Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 17 Jul 2025 08:43:42 +0100
+Subject: rxrpc: Fix recv-recv race of completed call
+
+From: David Howells <dhowells@redhat.com>
+
+[ Upstream commit 962fb1f651c2cf2083e0c3ef53ba69e3b96d3fbc ]
+
+If a call receives an event (such as incoming data), the call gets placed
+on the socket's queue and a thread in recvmsg can be awakened to go and
+process it. Once the thread has picked up the call off of the queue,
+further events will cause it to be requeued, and once the socket lock is
+dropped (recvmsg uses call->user_mutex to allow the socket to be used in
+parallel), a second thread can come in and its recvmsg can pop the call off
+the socket queue again.
+
+In such a case, the first thread will be receiving stuff from the call and
+the second thread will be blocked on call->user_mutex. The first thread
+can, at this point, process both the event that it picked call for and the
+event that the second thread picked the call for and may see the call
+terminate - in which case the call will be "released", decoupling the call
+from the user call ID assigned to it (RXRPC_USER_CALL_ID in the control
+message).
+
+The first thread will return okay, but then the second thread will wake up
+holding the user_mutex and, if it sees that the call has been released by
+the first thread, it will BUG thusly:
+
+ kernel BUG at net/rxrpc/recvmsg.c:474!
+
+Fix this by just dequeuing the call and ignoring it if it is seen to be
+already released. We can't tell userspace about it anyway as the user call
+ID has become stale.
+
+Fixes: 248f219cb8bc ("rxrpc: Rewrite the data and ack handling code")
+Reported-by: Junvyyang, Tencent Zhuque Lab <zhuque@tencent.com>
+Signed-off-by: David Howells <dhowells@redhat.com>
+Reviewed-by: Jeffrey Altman <jaltman@auristor.com>
+cc: LePremierHomme <kwqcheii@proton.me>
+cc: Marc Dionne <marc.dionne@auristor.com>
+cc: Simon Horman <horms@kernel.org>
+cc: linux-afs@lists.infradead.org
+Link: https://patch.msgid.link/20250717074350.3767366-3-dhowells@redhat.com
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ include/trace/events/rxrpc.h | 3 +++
+ net/rxrpc/call_accept.c | 1 +
+ net/rxrpc/recvmsg.c | 19 +++++++++++++++++--
+ 3 files changed, 21 insertions(+), 2 deletions(-)
+
+diff --git a/include/trace/events/rxrpc.h b/include/trace/events/rxrpc.h
+index e7c7b63894362..743f8f1f42a74 100644
+--- a/include/trace/events/rxrpc.h
++++ b/include/trace/events/rxrpc.h
+@@ -278,12 +278,15 @@
+ EM(rxrpc_call_put_userid, "PUT user-id ") \
+ EM(rxrpc_call_see_accept, "SEE accept ") \
+ EM(rxrpc_call_see_activate_client, "SEE act-clnt") \
++ EM(rxrpc_call_see_already_released, "SEE alrdy-rl") \
+ EM(rxrpc_call_see_connect_failed, "SEE con-fail") \
+ EM(rxrpc_call_see_connected, "SEE connect ") \
+ EM(rxrpc_call_see_conn_abort, "SEE conn-abt") \
++ EM(rxrpc_call_see_discard, "SEE discard ") \
+ EM(rxrpc_call_see_disconnected, "SEE disconn ") \
+ EM(rxrpc_call_see_distribute_error, "SEE dist-err") \
+ EM(rxrpc_call_see_input, "SEE input ") \
++ EM(rxrpc_call_see_recvmsg, "SEE recvmsg ") \
+ EM(rxrpc_call_see_release, "SEE release ") \
+ EM(rxrpc_call_see_userid_exists, "SEE u-exists") \
+ EM(rxrpc_call_see_waiting_call, "SEE q-conn ") \
+diff --git a/net/rxrpc/call_accept.c b/net/rxrpc/call_accept.c
+index 773bdb2e37daf..37ac8a6656786 100644
+--- a/net/rxrpc/call_accept.c
++++ b/net/rxrpc/call_accept.c
+@@ -219,6 +219,7 @@ void rxrpc_discard_prealloc(struct rxrpc_sock *rx)
+ tail = b->call_backlog_tail;
+ while (CIRC_CNT(head, tail, size) > 0) {
+ struct rxrpc_call *call = b->call_backlog[tail];
++ rxrpc_see_call(call, rxrpc_call_see_discard);
+ rcu_assign_pointer(call->socket, rx);
+ if (rx->discard_new_call) {
+ _debug("discard %lx", call->user_call_ID);
+diff --git a/net/rxrpc/recvmsg.c b/net/rxrpc/recvmsg.c
+index a482f88c5fc5b..e24a44bae9a32 100644
+--- a/net/rxrpc/recvmsg.c
++++ b/net/rxrpc/recvmsg.c
+@@ -351,6 +351,16 @@ int rxrpc_recvmsg(struct socket *sock, struct msghdr *msg, size_t len,
+ goto try_again;
+ }
+
++ rxrpc_see_call(call, rxrpc_call_see_recvmsg);
++ if (test_bit(RXRPC_CALL_RELEASED, &call->flags)) {
++ rxrpc_see_call(call, rxrpc_call_see_already_released);
++ list_del_init(&call->recvmsg_link);
++ spin_unlock_irq(&rx->recvmsg_lock);
++ release_sock(&rx->sk);
++ trace_rxrpc_recvmsg(call->debug_id, rxrpc_recvmsg_unqueue, 0);
++ rxrpc_put_call(call, rxrpc_call_put_recvmsg);
++ goto try_again;
++ }
+ if (!(flags & MSG_PEEK))
+ list_del_init(&call->recvmsg_link);
+ else
+@@ -374,8 +384,13 @@ int rxrpc_recvmsg(struct socket *sock, struct msghdr *msg, size_t len,
+
+ release_sock(&rx->sk);
+
+- if (test_bit(RXRPC_CALL_RELEASED, &call->flags))
+- BUG();
++ if (test_bit(RXRPC_CALL_RELEASED, &call->flags)) {
++ rxrpc_see_call(call, rxrpc_call_see_already_released);
++ mutex_unlock(&call->user_mutex);
++ if (!(flags & MSG_PEEK))
++ rxrpc_put_call(call, rxrpc_call_put_recvmsg);
++ goto try_again;
++ }
+
+ if (test_bit(RXRPC_CALL_HAS_USERID, &call->flags)) {
+ if (flags & MSG_CMSG_COMPAT) {
+--
+2.39.5
+
--- /dev/null
+From 04994cab5b2860e068c68cef95d1c0c45360b8f6 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 17 Jul 2025 08:43:44 +0100
+Subject: rxrpc: Fix transmission of an abort in response to an abort
+
+From: David Howells <dhowells@redhat.com>
+
+[ Upstream commit e9c0b96ec0a34fcacdf9365713578d83cecac34c ]
+
+Under some circumstances, such as when a server socket is closing, ABORT
+packets will be generated in response to incoming packets. Unfortunately,
+this also may include generating aborts in response to incoming aborts -
+which may cause a cycle. It appears this may be made possible by giving
+the client a multicast address.
+
+Fix this such that rxrpc_reject_packet() will refuse to generate aborts in
+response to aborts.
+
+Fixes: 248f219cb8bc ("rxrpc: Rewrite the data and ack handling code")
+Signed-off-by: David Howells <dhowells@redhat.com>
+Reviewed-by: Jeffrey Altman <jaltman@auristor.com>
+cc: Marc Dionne <marc.dionne@auristor.com>
+cc: Junvyyang, Tencent Zhuque Lab <zhuque@tencent.com>
+cc: LePremierHomme <kwqcheii@proton.me>
+cc: Linus Torvalds <torvalds@linux-foundation.org>
+cc: Simon Horman <horms@kernel.org>
+cc: linux-afs@lists.infradead.org
+Link: https://patch.msgid.link/20250717074350.3767366-5-dhowells@redhat.com
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ net/rxrpc/output.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+diff --git a/net/rxrpc/output.c b/net/rxrpc/output.c
+index cad6a7d18e040..4bbb27a48bd8a 100644
+--- a/net/rxrpc/output.c
++++ b/net/rxrpc/output.c
+@@ -589,6 +589,9 @@ void rxrpc_reject_packet(struct rxrpc_local *local, struct sk_buff *skb)
+ __be32 code;
+ int ret, ioc;
+
++ if (sp->hdr.type == RXRPC_PACKET_TYPE_ABORT)
++ return; /* Never abort an abort. */
++
+ rxrpc_see_skb(skb, rxrpc_skb_see_reject);
+
+ iov[0].iov_base = &whdr;
+--
+2.39.5
+
--- /dev/null
+From 74a7a4c50ce5c39b62f706fea96fd569d1f5b802 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 10 Jul 2025 18:04:50 +0200
+Subject: selftests: net: increase inter-packet timeout in udpgro.sh
+
+From: Paolo Abeni <pabeni@redhat.com>
+
+[ Upstream commit 0e9418961f897be59b1fab6e31ae1b09a0bae902 ]
+
+The mentioned test is not very stable when running on top of
+debug kernel build. Increase the inter-packet timeout to allow
+more slack in such environments.
+
+Fixes: 3327a9c46352 ("selftests: add functionals test for UDP GRO")
+Reviewed-by: Simon Horman <horms@kernel.org>
+Link: https://patch.msgid.link/b0370c06ddb3235debf642c17de0284b2cd3c652.1752163107.git.pabeni@redhat.com
+Signed-off-by: Paolo Abeni <pabeni@redhat.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ tools/testing/selftests/net/udpgro.sh | 8 ++++----
+ 1 file changed, 4 insertions(+), 4 deletions(-)
+
+diff --git a/tools/testing/selftests/net/udpgro.sh b/tools/testing/selftests/net/udpgro.sh
+index 53341c8135e88..b65cf09f9914e 100755
+--- a/tools/testing/selftests/net/udpgro.sh
++++ b/tools/testing/selftests/net/udpgro.sh
+@@ -50,7 +50,7 @@ run_one() {
+
+ cfg_veth
+
+- ip netns exec "${PEER_NS}" ./udpgso_bench_rx -C 1000 -R 10 ${rx_args} &
++ ip netns exec "${PEER_NS}" ./udpgso_bench_rx -C 1000 -R 100 ${rx_args} &
+ local PID1=$!
+
+ wait_local_port_listen ${PEER_NS} 8000 udp
+@@ -97,7 +97,7 @@ run_one_nat() {
+ # will land on the 'plain' one
+ ip netns exec "${PEER_NS}" ./udpgso_bench_rx -G ${family} -b ${addr1} -n 0 &
+ local PID1=$!
+- ip netns exec "${PEER_NS}" ./udpgso_bench_rx -C 1000 -R 10 ${family} -b ${addr2%/*} ${rx_args} &
++ ip netns exec "${PEER_NS}" ./udpgso_bench_rx -C 1000 -R 100 ${family} -b ${addr2%/*} ${rx_args} &
+ local PID2=$!
+
+ wait_local_port_listen "${PEER_NS}" 8000 udp
+@@ -119,9 +119,9 @@ run_one_2sock() {
+
+ cfg_veth
+
+- ip netns exec "${PEER_NS}" ./udpgso_bench_rx -C 1000 -R 10 ${rx_args} -p 12345 &
++ ip netns exec "${PEER_NS}" ./udpgso_bench_rx -C 1000 -R 100 ${rx_args} -p 12345 &
+ local PID1=$!
+- ip netns exec "${PEER_NS}" ./udpgso_bench_rx -C 2000 -R 10 ${rx_args} &
++ ip netns exec "${PEER_NS}" ./udpgso_bench_rx -C 2000 -R 100 ${rx_args} &
+ local PID2=$!
+
+ wait_local_port_listen "${PEER_NS}" 12345 udp
+--
+2.39.5
+
comedi-fix-some-signed-shift-left-operations.patch
comedi-fix-use-of-uninitialized-data-in-insn_rw_emulate_bits.patch
comedi-fix-initialization-of-data-for-instructions-that-write-to-subdevice.patch
+soundwire-amd-fix-for-handling-slave-alerts-after-li.patch
+soundwire-amd-fix-for-clearing-command-status-regist.patch
+bpf-reject-p-format-string-in-bprintf-like-helpers.patch
+cachefiles-fix-the-incorrect-return-value-in-__cache.patch
+net-emaclite-fix-missing-pointer-increment-in-aligne.patch
+block-fix-kobject-leak-in-blk_unregister_queue.patch
+net-sched-sch_qfq-fix-race-condition-on-qfq_aggregat.patch
+rpl-fix-use-after-free-in-rpl_do_srh_inline.patch
+smb-client-fix-use-after-free-in-cifs_oplock_break.patch
+nvme-fix-inconsistent-rcu-list-manipulation-in-nvme_.patch
+net-phy-don-t-register-leds-for-genphy.patch
+nvme-fix-misaccounting-of-nvme-mpath-inflight-i-o.patch
+wifi-cfg80211-remove-scan-request-n_channels-counted.patch
+selftests-net-increase-inter-packet-timeout-in-udpgr.patch
+hwmon-corsair-cpro-validate-the-size-of-the-received.patch
+ice-add-null-check-in-eswitch-lag-check.patch
+usb-net-sierra-check-for-no-status-endpoint.patch
+bluetooth-fix-null-ptr-deref-in-l2cap_sock_resume_cb.patch
+bluetooth-hci_sync-fix-connectable-extended-advertis.patch
+bluetooth-smp-if-an-unallowed-command-is-received-co.patch
+bluetooth-smp-fix-using-hci_error_remote_user_term-o.patch
+bluetooth-btusb-qca-fix-downloading-wrong-nvm-for-wc.patch
+net-mlx5-correctly-set-gso_size-when-lro-is-used.patch
+ipv6-mcast-delay-put-pmc-idev-in-mld_del_delrec.patch
+netfilter-nf_conntrack-fix-crash-due-to-removal-of-u.patch
+bluetooth-l2cap-fix-attempting-to-adjust-outgoing-mt.patch
+hv_netvsc-set-vf-priv_flags-to-iff_no_addrconf-befor.patch
+tls-always-refresh-the-queue-when-reading-sock.patch
+net-vlan-fix-vlan-0-refcount-imbalance-of-toggling-f.patch
+net-bridge-do-not-offload-igmp-mld-messages.patch
+net-sched-return-null-when-htb_lookup_leaf-encounter.patch
+rxrpc-fix-recv-recv-race-of-completed-call.patch
+rxrpc-fix-transmission-of-an-abort-in-response-to-an.patch
+revert-cgroup_freezer-cgroup_freezing-check-if-not-f.patch
--- /dev/null
+From defb861a31bf25ee7023cd8f2a2bbb745870fc3a Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Mon, 7 Jul 2025 09:09:26 +0800
+Subject: smb: client: fix use-after-free in cifs_oplock_break
+
+From: Wang Zhaolong <wangzhaolong@huaweicloud.com>
+
+[ Upstream commit 705c79101ccf9edea5a00d761491a03ced314210 ]
+
+A race condition can occur in cifs_oplock_break() leading to a
+use-after-free of the cinode structure when unmounting:
+
+ cifs_oplock_break()
+ _cifsFileInfo_put(cfile)
+ cifsFileInfo_put_final()
+ cifs_sb_deactive()
+ [last ref, start releasing sb]
+ kill_sb()
+ kill_anon_super()
+ generic_shutdown_super()
+ evict_inodes()
+ dispose_list()
+ evict()
+ destroy_inode()
+ call_rcu(&inode->i_rcu, i_callback)
+ spin_lock(&cinode->open_file_lock) <- OK
+ [later] i_callback()
+ cifs_free_inode()
+ kmem_cache_free(cinode)
+ spin_unlock(&cinode->open_file_lock) <- UAF
+ cifs_done_oplock_break(cinode) <- UAF
+
+The issue occurs when umount has already released its reference to the
+superblock. When _cifsFileInfo_put() calls cifs_sb_deactive(), this
+releases the last reference, triggering the immediate cleanup of all
+inodes under RCU. However, cifs_oplock_break() continues to access the
+cinode after this point, resulting in use-after-free.
+
+Fix this by holding an extra reference to the superblock during the
+entire oplock break operation. This ensures that the superblock and
+its inodes remain valid until the oplock break completes.
+
+Link: https://bugzilla.kernel.org/show_bug.cgi?id=220309
+Fixes: b98749cac4a6 ("CIFS: keep FileInfo handle live during oplock break")
+Reviewed-by: Paulo Alcantara (Red Hat) <pc@manguebit.org>
+Signed-off-by: Wang Zhaolong <wangzhaolong@huaweicloud.com>
+Signed-off-by: Steve French <stfrench@microsoft.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ fs/smb/client/file.c | 10 +++++++++-
+ 1 file changed, 9 insertions(+), 1 deletion(-)
+
+diff --git a/fs/smb/client/file.c b/fs/smb/client/file.c
+index d883ed75022c4..99a8c6fbd41a6 100644
+--- a/fs/smb/client/file.c
++++ b/fs/smb/client/file.c
+@@ -5042,7 +5042,8 @@ void cifs_oplock_break(struct work_struct *work)
+ struct cifsFileInfo *cfile = container_of(work, struct cifsFileInfo,
+ oplock_break);
+ struct inode *inode = d_inode(cfile->dentry);
+- struct cifs_sb_info *cifs_sb = CIFS_SB(inode->i_sb);
++ struct super_block *sb = inode->i_sb;
++ struct cifs_sb_info *cifs_sb = CIFS_SB(sb);
+ struct cifsInodeInfo *cinode = CIFS_I(inode);
+ struct cifs_tcon *tcon;
+ struct TCP_Server_Info *server;
+@@ -5052,6 +5053,12 @@ void cifs_oplock_break(struct work_struct *work)
+ __u64 persistent_fid, volatile_fid;
+ __u16 net_fid;
+
++ /*
++ * Hold a reference to the superblock to prevent it and its inodes from
++ * being freed while we are accessing cinode. Otherwise, _cifsFileInfo_put()
++ * may release the last reference to the sb and trigger inode eviction.
++ */
++ cifs_sb_active(sb);
+ wait_on_bit(&cinode->flags, CIFS_INODE_PENDING_WRITERS,
+ TASK_UNINTERRUPTIBLE);
+
+@@ -5124,6 +5131,7 @@ void cifs_oplock_break(struct work_struct *work)
+ cifs_put_tlink(tlink);
+ out:
+ cifs_done_oplock_break(cinode);
++ cifs_sb_deactive(sb);
+ }
+
+ /*
+--
+2.39.5
+
--- /dev/null
+From 1ba2185eb1196666932a57438168cf5cdda65ff9 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 20 Jun 2025 15:55:19 +0530
+Subject: soundwire: amd: fix for clearing command status register
+
+From: Vijendar Mukunda <Vijendar.Mukunda@amd.com>
+
+[ Upstream commit a628e69b6412dc02757a6a23f7f16ce0c14d71f1 ]
+
+To clear the valid result status, 1 should be written to
+ACP_SDW_IMM_CMD_STS register. Update the ACP_SW_IMM_CMD_STS register value
+as 1.
+
+Fixes: d8f48fbdfd9a ("soundwire: amd: Add support for AMD Manager driver")
+Signed-off-by: Vijendar Mukunda <Vijendar.Mukunda@amd.com>
+Link: https://lore.kernel.org/r/20250620102617.73437-1-Vijendar.Mukunda@amd.com
+Signed-off-by: Vinod Koul <vkoul@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/soundwire/amd_manager.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/drivers/soundwire/amd_manager.c b/drivers/soundwire/amd_manager.c
+index ce1c8e1372eed..b89f8067e6cdd 100644
+--- a/drivers/soundwire/amd_manager.c
++++ b/drivers/soundwire/amd_manager.c
+@@ -205,7 +205,7 @@ static u64 amd_sdw_send_cmd_get_resp(struct amd_sdw_manager *amd_manager, u32 lo
+
+ if (sts & AMD_SDW_IMM_RES_VALID) {
+ dev_err(amd_manager->dev, "SDW%x manager is in bad state\n", amd_manager->instance);
+- writel(0x00, amd_manager->mmio + ACP_SW_IMM_CMD_STS);
++ writel(AMD_SDW_IMM_RES_VALID, amd_manager->mmio + ACP_SW_IMM_CMD_STS);
+ }
+ writel(upper_data, amd_manager->mmio + ACP_SW_IMM_CMD_UPPER_WORD);
+ writel(lower_data, amd_manager->mmio + ACP_SW_IMM_CMD_LOWER_QWORD);
+--
+2.39.5
+
--- /dev/null
+From 319569f5b118af31fe2922b38b3275fcb4333446 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 30 May 2025 11:13:39 +0530
+Subject: soundwire: amd: fix for handling slave alerts after link is down
+
+From: Vijendar Mukunda <Vijendar.Mukunda@amd.com>
+
+[ Upstream commit 86a4371b76976158be875dc654ceee35c574b27b ]
+
+Sometimes, its observed that during system level suspend callback
+execution, after link is down, handling pending slave status workqueue
+results in mipi register access failures as shown below.
+
+soundwire sdw-master-0-0: trf on Slave 1 failed:-110 read addr 0 count 1
+rt722-sdca sdw:0:0:025d:0722:01: SDW_DP0_INT recheck read failed:-110
+rt722-sdca sdw:0:0:025d:0722:01: Slave 1 alert handling failed: -110
+amd_sdw_manager amd_sdw_manager.0: SDW0 cmd response timeout occurred
+amd_sdw_manager amd_sdw_manager.0: command timeout for Slave 1
+soundwire sdw-master-0-0: trf on Slave 1 failed:-110 write addr 5c count 1
+amd_sdw_manager amd_sdw_manager.0: SDW0 previous cmd status clear failed
+amd_sdw_manager amd_sdw_manager.0: command timeout for Slave 1
+soundwire sdw-master-0-0: trf on Slave 1 failed:-110 write addr 5d count 1
+amd_sdw_manager amd_sdw_manager.0: SDW0 previous cmd status clear failed
+amd_sdw_manager amd_sdw_manager.0: command timeout for Slave 1
+
+Cancel the pending slave status workqueue prior to initiating clock stop
+sequence during suspend callback execution for both the power modes.
+
+Fixes: 9cf1efc5ed2d ("soundwire: amd: add pm_prepare callback and pm ops support")
+Signed-off-by: Vijendar Mukunda <Vijendar.Mukunda@amd.com>
+Link: https://lore.kernel.org/r/20250530054447.1645807-2-Vijendar.Mukunda@amd.com
+Signed-off-by: Vinod Koul <vkoul@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/soundwire/amd_manager.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+diff --git a/drivers/soundwire/amd_manager.c b/drivers/soundwire/amd_manager.c
+index 31b203ebbae0c..ce1c8e1372eed 100644
+--- a/drivers/soundwire/amd_manager.c
++++ b/drivers/soundwire/amd_manager.c
+@@ -1135,9 +1135,11 @@ static int __maybe_unused amd_suspend(struct device *dev)
+ }
+
+ if (amd_manager->power_mode_mask & AMD_SDW_CLK_STOP_MODE) {
++ cancel_work_sync(&amd_manager->amd_sdw_work);
+ amd_sdw_wake_enable(amd_manager, false);
+ return amd_sdw_clock_stop(amd_manager);
+ } else if (amd_manager->power_mode_mask & AMD_SDW_POWER_OFF_MODE) {
++ cancel_work_sync(&amd_manager->amd_sdw_work);
+ amd_sdw_wake_enable(amd_manager, false);
+ /*
+ * As per hardware programming sequence on AMD platforms,
+--
+2.39.5
+
--- /dev/null
+From 1647b84119f16cfc4d61628537607c7802f2b182 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 16 Jul 2025 07:38:50 -0700
+Subject: tls: always refresh the queue when reading sock
+
+From: Jakub Kicinski <kuba@kernel.org>
+
+[ Upstream commit 4ab26bce3969f8fd925fe6f6f551e4d1a508c68b ]
+
+After recent changes in net-next TCP compacts skbs much more
+aggressively. This unearthed a bug in TLS where we may try
+to operate on an old skb when checking if all skbs in the
+queue have matching decrypt state and geometry.
+
+ BUG: KASAN: slab-use-after-free in tls_strp_check_rcv+0x898/0x9a0 [tls]
+ (net/tls/tls_strp.c:436 net/tls/tls_strp.c:530 net/tls/tls_strp.c:544)
+ Read of size 4 at addr ffff888013085750 by task tls/13529
+
+ CPU: 2 UID: 0 PID: 13529 Comm: tls Not tainted 6.16.0-rc5-virtme
+ Call Trace:
+ kasan_report+0xca/0x100
+ tls_strp_check_rcv+0x898/0x9a0 [tls]
+ tls_rx_rec_wait+0x2c9/0x8d0 [tls]
+ tls_sw_recvmsg+0x40f/0x1aa0 [tls]
+ inet_recvmsg+0x1c3/0x1f0
+
+Always reload the queue, fast path is to have the record in the queue
+when we wake, anyway (IOW the path going down "if !strp->stm.full_len").
+
+Fixes: 0d87bbd39d7f ("tls: strp: make sure the TCP skbs do not have overlapping data")
+Link: https://patch.msgid.link/20250716143850.1520292-1-kuba@kernel.org
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ net/tls/tls_strp.c | 3 +--
+ 1 file changed, 1 insertion(+), 2 deletions(-)
+
+diff --git a/net/tls/tls_strp.c b/net/tls/tls_strp.c
+index 1852fac3e72b7..bea60b0160d1f 100644
+--- a/net/tls/tls_strp.c
++++ b/net/tls/tls_strp.c
+@@ -511,9 +511,8 @@ static int tls_strp_read_sock(struct tls_strparser *strp)
+ if (inq < strp->stm.full_len)
+ return tls_strp_read_copy(strp, true);
+
++ tls_strp_load_anchor_with_queue(strp, inq);
+ if (!strp->stm.full_len) {
+- tls_strp_load_anchor_with_queue(strp, inq);
+-
+ sz = tls_rx_msg_size(strp, strp->anchor);
+ if (sz < 0) {
+ tls_strp_abort_strp(strp, sz);
+--
+2.39.5
+
--- /dev/null
+From a95833b6fb48db64630df4cce544bdef0641ad9e Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Mon, 14 Jul 2025 13:12:56 +0200
+Subject: usb: net: sierra: check for no status endpoint
+
+From: Oliver Neukum <oneukum@suse.com>
+
+[ Upstream commit 4c4ca3c46167518f8534ed70f6e3b4bf86c4d158 ]
+
+The driver checks for having three endpoints and
+having bulk in and out endpoints, but not that
+the third endpoint is interrupt input.
+Rectify the omission.
+
+Reported-by: syzbot+3f89ec3d1d0842e95d50@syzkaller.appspotmail.com
+Closes: https://lore.kernel.org/linux-usb/686d5a9f.050a0220.1ffab7.0017.GAE@google.com/
+Tested-by: syzbot+3f89ec3d1d0842e95d50@syzkaller.appspotmail.com
+Fixes: eb4fd8cd355c8 ("net/usb: add sierra_net.c driver")
+Signed-off-by: Oliver Neukum <oneukum@suse.com>
+Link: https://patch.msgid.link/20250714111326.258378-1-oneukum@suse.com
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/usb/sierra_net.c | 4 ++++
+ 1 file changed, 4 insertions(+)
+
+diff --git a/drivers/net/usb/sierra_net.c b/drivers/net/usb/sierra_net.c
+index 673d3aa837926..42b66adb35f1b 100644
+--- a/drivers/net/usb/sierra_net.c
++++ b/drivers/net/usb/sierra_net.c
+@@ -689,6 +689,10 @@ static int sierra_net_bind(struct usbnet *dev, struct usb_interface *intf)
+ status);
+ return -ENODEV;
+ }
++ if (!dev->status) {
++ dev_err(&dev->udev->dev, "No status endpoint found");
++ return -ENODEV;
++ }
+ /* Initialize sierra private data */
+ priv = kzalloc(sizeof *priv, GFP_KERNEL);
+ if (!priv)
+--
+2.39.5
+
--- /dev/null
+From cc1d5c1002023f5f4891b317910af889d1a7636a Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Mon, 14 Jul 2025 14:21:30 +0200
+Subject: wifi: cfg80211: remove scan request n_channels counted_by
+
+From: Johannes Berg <johannes.berg@intel.com>
+
+[ Upstream commit 444020f4bf06fb86805ee7e7ceec0375485fd94d ]
+
+This reverts commit e3eac9f32ec0 ("wifi: cfg80211: Annotate struct
+cfg80211_scan_request with __counted_by").
+
+This really has been a completely failed experiment. There were
+no actual bugs found, and yet at this point we already have four
+"fixes" to it, with nothing to show for but code churn, and it
+never even made the code any safer.
+
+In all of the cases that ended up getting "fixed", the structure
+is also internally inconsistent after the n_channels setting as
+the channel list isn't actually filled yet. You cannot scan with
+such a structure, that's just wrong. In mac80211, the struct is
+also reused multiple times, so initializing it once is no good.
+
+Some previous "fixes" (e.g. one in brcm80211) are also just setting
+n_channels before accessing the array, under the assumption that the
+code is correct and the array can be accessed, further showing that
+the whole thing is just pointless when the allocation count and use
+count are not separate.
+
+If we really wanted to fix it, we'd need to separately track the
+number of channels allocated and the number of channels currently
+used, but given that no bugs were found despite the numerous syzbot
+reports, that'd just be a waste of time.
+
+Remove the __counted_by() annotation. We really should also remove
+a number of the n_channels settings that are setting up a structure
+that's inconsistent, but that can wait.
+
+Reported-by: syzbot+e834e757bd9b3d3e1251@syzkaller.appspotmail.com
+Closes: https://syzkaller.appspot.com/bug?extid=e834e757bd9b3d3e1251
+Fixes: e3eac9f32ec0 ("wifi: cfg80211: Annotate struct cfg80211_scan_request with __counted_by")
+Link: https://patch.msgid.link/20250714142130.9b0bbb7e1f07.I09112ccde72d445e11348fc2bef68942cb2ffc94@changeid
+Signed-off-by: Johannes Berg <johannes.berg@intel.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ include/net/cfg80211.h | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
+index 802ea3080d0b3..2fb3151ea7c9e 100644
+--- a/include/net/cfg80211.h
++++ b/include/net/cfg80211.h
+@@ -2543,7 +2543,7 @@ struct cfg80211_scan_request {
+ struct cfg80211_scan_6ghz_params *scan_6ghz_params;
+
+ /* keep last */
+- struct ieee80211_channel *channels[] __counted_by(n_channels);
++ struct ieee80211_channel *channels[];
+ };
+
+ static inline void get_random_mask_addr(u8 *buf, const u8 *addr, const u8 *mask)
+--
+2.39.5
+
projects / thirdparty / kernel / stable-queue.git / commitdiff
