--- /dev/null
+From 107ea90348c89027249852375bed3cdb87e16ec8 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Sat, 20 Sep 2025 05:11:17 -0700
+Subject: bnxt_en: correct offset handling for IPv6 destination address
+
+From: Alok Tiwari <alok.a.tiwari@oracle.com>
+
+[ Upstream commit 3d3aa9472c6dd0704e9961ed4769caac5b1c8d52 ]
+
+In bnxt_tc_parse_pedit(), the code incorrectly writes IPv6
+destination values to the source address field (saddr) when
+processing pedit offsets within the destination address range.
+
+This patch corrects the assignment to use daddr instead of saddr,
+ensuring that pedit operations on IPv6 destination addresses are
+applied correctly.
+
+Fixes: 9b9eb518e338 ("bnxt_en: Add support for NAT(L3/L4 rewrite)")
+Signed-off-by: Alok Tiwari <alok.a.tiwari@oracle.com>
+Reviewed-by: Somnath Kotur <somnath.kotur@broadcom.com>
+Link: https://patch.msgid.link/20250920121157.351921-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/broadcom/bnxt/bnxt_tc.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt_tc.c b/drivers/net/ethernet/broadcom/bnxt/bnxt_tc.c
+index 775d0b7521ca0..ef2bd84c55ff5 100644
+--- a/drivers/net/ethernet/broadcom/bnxt/bnxt_tc.c
++++ b/drivers/net/ethernet/broadcom/bnxt/bnxt_tc.c
+@@ -243,7 +243,7 @@ bnxt_tc_parse_pedit(struct bnxt *bp, struct bnxt_tc_actions *actions,
+ offset < offset_of_ip6_daddr + 16) {
+ actions->nat.src_xlate = false;
+ idx = (offset - offset_of_ip6_daddr) / 4;
+- actions->nat.l3.ipv6.saddr.s6_addr32[idx] = htonl(val);
++ actions->nat.l3.ipv6.daddr.s6_addr32[idx] = htonl(val);
+ } else {
+ netdev_err(bp->dev,
+ "%s: IPv6_hdr: Invalid pedit field\n",
+--
+2.51.0
+
--- /dev/null
+From f31d83c30782f020f2fd481e5bd7db06fe7669a1 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 18 Sep 2025 18:00:25 +0900
+Subject: can: hi311x: populate ndo_change_mtu() to prevent buffer overflow
+
+From: Vincent Mailhol <mailhol@kernel.org>
+
+[ Upstream commit ac1c7656fa717f29fac3ea073af63f0b9919ec9a ]
+
+Sending an PF_PACKET allows to bypass the CAN framework logic and to
+directly reach the xmit() function of a CAN driver. The only check
+which is performed by the PF_PACKET framework is to make sure that
+skb->len fits the interface's MTU.
+
+Unfortunately, because the sun4i_can driver does not populate its
+net_device_ops->ndo_change_mtu(), it is possible for an attacker to
+configure an invalid MTU by doing, for example:
+
+ $ ip link set can0 mtu 9999
+
+After doing so, the attacker could open a PF_PACKET socket using the
+ETH_P_CANXL protocol:
+
+ socket(PF_PACKET, SOCK_RAW, htons(ETH_P_CANXL))
+
+to inject a malicious CAN XL frames. For example:
+
+ struct canxl_frame frame = {
+ .flags = 0xff,
+ .len = 2048,
+ };
+
+The CAN drivers' xmit() function are calling can_dev_dropped_skb() to
+check that the skb is valid, unfortunately under above conditions, the
+malicious packet is able to go through can_dev_dropped_skb() checks:
+
+ 1. the skb->protocol is set to ETH_P_CANXL which is valid (the
+ function does not check the actual device capabilities).
+
+ 2. the length is a valid CAN XL length.
+
+And so, hi3110_hard_start_xmit() receives a CAN XL frame which it is
+not able to correctly handle and will thus misinterpret it as a CAN
+frame. The driver will consume frame->len as-is with no further
+checks.
+
+This can result in a buffer overflow later on in hi3110_hw_tx() on
+this line:
+
+ memcpy(buf + HI3110_FIFO_EXT_DATA_OFF,
+ frame->data, frame->len);
+
+Here, frame->len corresponds to the flags field of the CAN XL frame.
+In our previous example, we set canxl_frame->flags to 0xff. Because
+the maximum expected length is 8, a buffer overflow of 247 bytes
+occurs!
+
+Populate net_device_ops->ndo_change_mtu() to ensure that the
+interface's MTU can not be set to anything bigger than CAN_MTU. By
+fixing the root cause, this prevents the buffer overflow.
+
+Fixes: 57e83fb9b746 ("can: hi311x: Add Holt HI-311x CAN driver")
+Signed-off-by: Vincent Mailhol <mailhol@kernel.org>
+Link: https://patch.msgid.link/20250918-can-fix-mtu-v1-2-0d1cada9393b@kernel.org
+Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/can/spi/hi311x.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/drivers/net/can/spi/hi311x.c b/drivers/net/can/spi/hi311x.c
+index 28273e84171a2..a7d594a5ad36f 100644
+--- a/drivers/net/can/spi/hi311x.c
++++ b/drivers/net/can/spi/hi311x.c
+@@ -807,6 +807,7 @@ static const struct net_device_ops hi3110_netdev_ops = {
+ .ndo_open = hi3110_open,
+ .ndo_stop = hi3110_stop,
+ .ndo_start_xmit = hi3110_hard_start_xmit,
++ .ndo_change_mtu = can_change_mtu,
+ };
+
+ static const struct of_device_id hi3110_of_match[] = {
+--
+2.51.0
+
--- /dev/null
+From 2d62cada090b6ebf087e7dae8d059161425534c4 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 18 Sep 2025 18:00:27 +0900
+Subject: can: mcba_usb: populate ndo_change_mtu() to prevent buffer overflow
+
+From: Vincent Mailhol <mailhol@kernel.org>
+
+[ Upstream commit 17c8d794527f01def0d1c8b7dc2d7b8d34fed0e6 ]
+
+Sending an PF_PACKET allows to bypass the CAN framework logic and to
+directly reach the xmit() function of a CAN driver. The only check
+which is performed by the PF_PACKET framework is to make sure that
+skb->len fits the interface's MTU.
+
+Unfortunately, because the mcba_usb driver does not populate its
+net_device_ops->ndo_change_mtu(), it is possible for an attacker to
+configure an invalid MTU by doing, for example:
+
+ $ ip link set can0 mtu 9999
+
+After doing so, the attacker could open a PF_PACKET socket using the
+ETH_P_CANXL protocol:
+
+ socket(PF_PACKET, SOCK_RAW, htons(ETH_P_CANXL))
+
+to inject a malicious CAN XL frames. For example:
+
+ struct canxl_frame frame = {
+ .flags = 0xff,
+ .len = 2048,
+ };
+
+The CAN drivers' xmit() function are calling can_dev_dropped_skb() to
+check that the skb is valid, unfortunately under above conditions, the
+malicious packet is able to go through can_dev_dropped_skb() checks:
+
+ 1. the skb->protocol is set to ETH_P_CANXL which is valid (the
+ function does not check the actual device capabilities).
+
+ 2. the length is a valid CAN XL length.
+
+And so, mcba_usb_start_xmit() receives a CAN XL frame which it is not
+able to correctly handle and will thus misinterpret it as a CAN frame.
+
+This can result in a buffer overflow. The driver will consume cf->len
+as-is with no further checks on these lines:
+
+ usb_msg.dlc = cf->len;
+
+ memcpy(usb_msg.data, cf->data, usb_msg.dlc);
+
+Here, cf->len corresponds to the flags field of the CAN XL frame. In
+our previous example, we set canxl_frame->flags to 0xff. Because the
+maximum expected length is 8, a buffer overflow of 247 bytes occurs!
+
+Populate net_device_ops->ndo_change_mtu() to ensure that the
+interface's MTU can not be set to anything bigger than CAN_MTU. By
+fixing the root cause, this prevents the buffer overflow.
+
+Fixes: 51f3baad7de9 ("can: mcba_usb: Add support for Microchip CAN BUS Analyzer")
+Signed-off-by: Vincent Mailhol <mailhol@kernel.org>
+Link: https://patch.msgid.link/20250918-can-fix-mtu-v1-4-0d1cada9393b@kernel.org
+Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/can/usb/mcba_usb.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/drivers/net/can/usb/mcba_usb.c b/drivers/net/can/usb/mcba_usb.c
+index c07e327929ba5..7179eb0fedb1e 100644
+--- a/drivers/net/can/usb/mcba_usb.c
++++ b/drivers/net/can/usb/mcba_usb.c
+@@ -769,6 +769,7 @@ static const struct net_device_ops mcba_netdev_ops = {
+ .ndo_open = mcba_usb_open,
+ .ndo_stop = mcba_usb_close,
+ .ndo_start_xmit = mcba_usb_start_xmit,
++ .ndo_change_mtu = can_change_mtu,
+ };
+
+ /* Microchip CANBUS has hardcoded bittiming values by default.
+--
+2.51.0
+
--- /dev/null
+From e1b9489eebec4d0199a647ffe6436396a017cdd2 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 18 Sep 2025 15:23:57 +0200
+Subject: can: peak_usb: fix shift-out-of-bounds issue
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Stéphane Grosjean <stephane.grosjean@hms-networks.com>
+
+[ Upstream commit c443be70aaee42c2d1d251e0329e0a69dd96ae54 ]
+
+Explicitly uses a 64-bit constant when the number of bits used for its
+shifting is 32 (which is the case for PC CAN FD interfaces supported by
+this driver).
+
+Signed-off-by: Stéphane Grosjean <stephane.grosjean@hms-networks.com>
+Link: https://patch.msgid.link/20250918132413.30071-1-stephane.grosjean@free.fr
+Reported-by: Marc Kleine-Budde <mkl@pengutronix.de>
+Closes: https://lore.kernel.org/20250917-aboriginal-refined-honeybee-82b1aa-mkl@pengutronix.de
+Fixes: bb4785551f64 ("can: usb: PEAK-System Technik USB adapters driver core")
+[mkl: update subject, apply manually]
+Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/can/usb/peak_usb/pcan_usb_core.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/drivers/net/can/usb/peak_usb/pcan_usb_core.c b/drivers/net/can/usb/peak_usb/pcan_usb_core.c
+index 73c1bc3cb70d3..3a963f2a8c441 100644
+--- a/drivers/net/can/usb/peak_usb/pcan_usb_core.c
++++ b/drivers/net/can/usb/peak_usb/pcan_usb_core.c
+@@ -84,7 +84,7 @@ void peak_usb_update_ts_now(struct peak_time_ref *time_ref, u32 ts_now)
+ u32 delta_ts = time_ref->ts_dev_2 - time_ref->ts_dev_1;
+
+ if (time_ref->ts_dev_2 < time_ref->ts_dev_1)
+- delta_ts &= (1 << time_ref->adapter->ts_used_bits) - 1;
++ delta_ts &= (1ULL << time_ref->adapter->ts_used_bits) - 1;
+
+ time_ref->ts_total += delta_ts;
+ }
+--
+2.51.0
+
--- /dev/null
+From 64bba5f8706a0ee10d4ecb8b09e8059678cd3dbb Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 18 Sep 2025 18:00:26 +0900
+Subject: can: sun4i_can: populate ndo_change_mtu() to prevent buffer overflow
+
+From: Vincent Mailhol <mailhol@kernel.org>
+
+[ Upstream commit 61da0bd4102c459823fbe6b8b43b01fb6ace4a22 ]
+
+Sending an PF_PACKET allows to bypass the CAN framework logic and to
+directly reach the xmit() function of a CAN driver. The only check
+which is performed by the PF_PACKET framework is to make sure that
+skb->len fits the interface's MTU.
+
+Unfortunately, because the sun4i_can driver does not populate its
+net_device_ops->ndo_change_mtu(), it is possible for an attacker to
+configure an invalid MTU by doing, for example:
+
+ $ ip link set can0 mtu 9999
+
+After doing so, the attacker could open a PF_PACKET socket using the
+ETH_P_CANXL protocol:
+
+ socket(PF_PACKET, SOCK_RAW, htons(ETH_P_CANXL))
+
+to inject a malicious CAN XL frames. For example:
+
+ struct canxl_frame frame = {
+ .flags = 0xff,
+ .len = 2048,
+ };
+
+The CAN drivers' xmit() function are calling can_dev_dropped_skb() to
+check that the skb is valid, unfortunately under above conditions, the
+malicious packet is able to go through can_dev_dropped_skb() checks:
+
+ 1. the skb->protocol is set to ETH_P_CANXL which is valid (the
+ function does not check the actual device capabilities).
+
+ 2. the length is a valid CAN XL length.
+
+And so, sun4ican_start_xmit() receives a CAN XL frame which it is not
+able to correctly handle and will thus misinterpret it as a CAN frame.
+
+This can result in a buffer overflow. The driver will consume cf->len
+as-is with no further checks on this line:
+
+ dlc = cf->len;
+
+Here, cf->len corresponds to the flags field of the CAN XL frame. In
+our previous example, we set canxl_frame->flags to 0xff. Because the
+maximum expected length is 8, a buffer overflow of 247 bytes occurs a
+couple line below when doing:
+
+ for (i = 0; i < dlc; i++)
+ writel(cf->data[i], priv->base + (dreg + i * 4));
+
+Populate net_device_ops->ndo_change_mtu() to ensure that the
+interface's MTU can not be set to anything bigger than CAN_MTU. By
+fixing the root cause, this prevents the buffer overflow.
+
+Fixes: 0738eff14d81 ("can: Allwinner A10/A20 CAN Controller support - Kernel module")
+Signed-off-by: Vincent Mailhol <mailhol@kernel.org>
+Link: https://patch.msgid.link/20250918-can-fix-mtu-v1-3-0d1cada9393b@kernel.org
+Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/can/sun4i_can.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/drivers/net/can/sun4i_can.c b/drivers/net/can/sun4i_can.c
+index 89796691917b3..1f2402f027742 100644
+--- a/drivers/net/can/sun4i_can.c
++++ b/drivers/net/can/sun4i_can.c
+@@ -751,6 +751,7 @@ static const struct net_device_ops sun4ican_netdev_ops = {
+ .ndo_open = sun4ican_open,
+ .ndo_stop = sun4ican_close,
+ .ndo_start_xmit = sun4ican_start_xmit,
++ .ndo_change_mtu = can_change_mtu,
+ };
+
+ static const struct of_device_id sun4ican_of_match[] = {
+--
+2.51.0
+
--- /dev/null
+From ca3d05f1e4f71ee8ab6ac588877dec27341abafb Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 4 Nov 2020 15:30:29 +0200
+Subject: nexthop: Emit a notification when a nexthop is added
+
+From: Ido Schimmel <idosch@nvidia.com>
+
+[ Upstream commit 732d167bf5f53a8c1e8c53cf7dbffe2a13f63752 ]
+
+Emit a notification in the nexthop notification chain when a new nexthop
+is added (not replaced). The nexthop can either be a new group or a
+single nexthop.
+
+The notification is sent after the nexthop is inserted into the
+red-black tree, as listeners might need to callback into the nexthop
+code with the nexthop ID in order to mark the nexthop as offloaded.
+
+A 'REPLACE' notification is emitted instead of 'ADD' as the distinction
+between the two is not important for in-kernel listeners. In case the
+listener is not familiar with the encoded nexthop ID, it can simply
+treat it as a new one. This is also consistent with the route offload
+API.
+
+Changes since RFC:
+* Reword commit message
+
+Signed-off-by: Ido Schimmel <idosch@nvidia.com>
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Stable-dep-of: 390b3a300d78 ("nexthop: Forbid FDB status change while nexthop is in a group")
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ include/net/nexthop.h | 3 ++-
+ net/ipv4/nexthop.c | 6 +++++-
+ 2 files changed, 7 insertions(+), 2 deletions(-)
+
+diff --git a/include/net/nexthop.h b/include/net/nexthop.h
+index fd87d727aa217..aa19809bfd733 100644
+--- a/include/net/nexthop.h
++++ b/include/net/nexthop.h
+@@ -105,7 +105,8 @@ struct nexthop {
+ };
+
+ enum nexthop_event_type {
+- NEXTHOP_EVENT_DEL
++ NEXTHOP_EVENT_DEL,
++ NEXTHOP_EVENT_REPLACE,
+ };
+
+ int register_nexthop_notifier(struct net *net, struct notifier_block *nb);
+diff --git a/net/ipv4/nexthop.c b/net/ipv4/nexthop.c
+index 0653aa518648c..3063aa1914b1f 100644
+--- a/net/ipv4/nexthop.c
++++ b/net/ipv4/nexthop.c
+@@ -1191,7 +1191,11 @@ static int insert_nexthop(struct net *net, struct nexthop *new_nh,
+
+ rb_link_node_rcu(&new_nh->rb_node, parent, pp);
+ rb_insert_color(&new_nh->rb_node, root);
+- rc = 0;
++
++ rc = call_nexthop_notifiers(net, NEXTHOP_EVENT_REPLACE, new_nh, extack);
++ if (rc)
++ rb_erase(&new_nh->rb_node, &net->nexthop.rb_root);
++
+ out:
+ if (!rc) {
+ nh_base_seq_inc(net);
+--
+2.51.0
+
--- /dev/null
+From 82aa0ae2be4570cca2caa9cc54c25892be3626c2 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 4 Nov 2020 15:30:31 +0200
+Subject: nexthop: Emit a notification when a single nexthop is replaced
+
+From: Ido Schimmel <idosch@nvidia.com>
+
+[ Upstream commit 8c09c9f9d846cdd8a92604c591132985b04fd1d6 ]
+
+The notification is emitted after all the validation checks were
+performed, but before the new configuration (i.e., 'struct nh_info') is
+pointed at by the old shell (i.e., 'struct nexthop'). This prevents the
+need to perform rollback in case the notification is vetoed.
+
+The next patch will also emit a replace notification for all the nexthop
+groups in which the nexthop is used.
+
+Signed-off-by: Ido Schimmel <idosch@nvidia.com>
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Stable-dep-of: 390b3a300d78 ("nexthop: Forbid FDB status change while nexthop is in a group")
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ net/ipv4/nexthop.c | 10 ++++++++++
+ 1 file changed, 10 insertions(+)
+
+diff --git a/net/ipv4/nexthop.c b/net/ipv4/nexthop.c
+index 3063aa1914b1f..d2b338b357220 100644
+--- a/net/ipv4/nexthop.c
++++ b/net/ipv4/nexthop.c
+@@ -1009,12 +1009,22 @@ static int replace_nexthop_single(struct net *net, struct nexthop *old,
+ struct netlink_ext_ack *extack)
+ {
+ struct nh_info *oldi, *newi;
++ int err;
+
+ if (new->is_group) {
+ NL_SET_ERR_MSG(extack, "Can not replace a nexthop with a nexthop group.");
+ return -EINVAL;
+ }
+
++ err = call_nexthop_notifiers(net, NEXTHOP_EVENT_REPLACE, new, extack);
++ if (err)
++ return err;
++
++ /* Hardware flags were set on 'old' as 'new' is not in the red-black
++ * tree. Therefore, inherit the flags from 'old' to 'new'.
++ */
++ new->nh_flags |= old->nh_flags & (RTNH_F_OFFLOAD | RTNH_F_TRAP);
++
+ oldi = rtnl_dereference(old->nh_info);
+ newi = rtnl_dereference(new->nh_info);
+
+--
+2.51.0
+
--- /dev/null
+From 3c0f619db603937bd9b9c12a8f81740bf837f0b3 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Sun, 21 Sep 2025 18:08:22 +0300
+Subject: nexthop: Forbid FDB status change while nexthop is in a group
+
+From: Ido Schimmel <idosch@nvidia.com>
+
+[ Upstream commit 390b3a300d7872cef9588f003b204398be69ce08 ]
+
+The kernel forbids the creation of non-FDB nexthop groups with FDB
+nexthops:
+
+ # ip nexthop add id 1 via 192.0.2.1 fdb
+ # ip nexthop add id 2 group 1
+ Error: Non FDB nexthop group cannot have fdb nexthops.
+
+And vice versa:
+
+ # ip nexthop add id 3 via 192.0.2.2 dev dummy1
+ # ip nexthop add id 4 group 3 fdb
+ Error: FDB nexthop group can only have fdb nexthops.
+
+However, as long as no routes are pointing to a non-FDB nexthop group,
+the kernel allows changing the type of a nexthop from FDB to non-FDB and
+vice versa:
+
+ # ip nexthop add id 5 via 192.0.2.2 dev dummy1
+ # ip nexthop add id 6 group 5
+ # ip nexthop replace id 5 via 192.0.2.2 fdb
+ # echo $?
+ 0
+
+This configuration is invalid and can result in a NPD [1] since FDB
+nexthops are not associated with a nexthop device:
+
+ # ip route add 198.51.100.1/32 nhid 6
+ # ping 198.51.100.1
+
+Fix by preventing nexthop FDB status change while the nexthop is in a
+group:
+
+ # ip nexthop add id 7 via 192.0.2.2 dev dummy1
+ # ip nexthop add id 8 group 7
+ # ip nexthop replace id 7 via 192.0.2.2 fdb
+ Error: Cannot change nexthop FDB status while in a group.
+
+[1]
+BUG: kernel NULL pointer dereference, address: 00000000000003c0
+[...]
+Oops: Oops: 0000 [#1] SMP
+CPU: 6 UID: 0 PID: 367 Comm: ping Not tainted 6.17.0-rc6-virtme-gb65678cacc03 #1 PREEMPT(voluntary)
+Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-4.fc41 04/01/2014
+RIP: 0010:fib_lookup_good_nhc+0x1e/0x80
+[...]
+Call Trace:
+ <TASK>
+ fib_table_lookup+0x541/0x650
+ ip_route_output_key_hash_rcu+0x2ea/0x970
+ ip_route_output_key_hash+0x55/0x80
+ __ip4_datagram_connect+0x250/0x330
+ udp_connect+0x2b/0x60
+ __sys_connect+0x9c/0xd0
+ __x64_sys_connect+0x18/0x20
+ do_syscall_64+0xa4/0x2a0
+ entry_SYSCALL_64_after_hwframe+0x4b/0x53
+
+Fixes: 38428d68719c ("nexthop: support for fdb ecmp nexthops")
+Reported-by: syzbot+6596516dd2b635ba2350@syzkaller.appspotmail.com
+Closes: https://lore.kernel.org/netdev/68c9a4d2.050a0220.3c6139.0e63.GAE@google.com/
+Tested-by: syzbot+6596516dd2b635ba2350@syzkaller.appspotmail.com
+Signed-off-by: Ido Schimmel <idosch@nvidia.com>
+Reviewed-by: David Ahern <dsahern@kernel.org>
+Link: https://patch.msgid.link/20250921150824.149157-2-idosch@nvidia.com
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ net/ipv4/nexthop.c | 7 +++++++
+ 1 file changed, 7 insertions(+)
+
+diff --git a/net/ipv4/nexthop.c b/net/ipv4/nexthop.c
+index d2b338b357220..477d6a6f0de36 100644
+--- a/net/ipv4/nexthop.c
++++ b/net/ipv4/nexthop.c
+@@ -1016,6 +1016,13 @@ static int replace_nexthop_single(struct net *net, struct nexthop *old,
+ return -EINVAL;
+ }
+
++ if (!list_empty(&old->grp_list) &&
++ rtnl_dereference(new->nh_info)->fdb_nh !=
++ rtnl_dereference(old->nh_info)->fdb_nh) {
++ NL_SET_ERR_MSG(extack, "Cannot change nexthop FDB status while in a group");
++ return -EINVAL;
++ }
++
+ err = call_nexthop_notifiers(net, NEXTHOP_EVENT_REPLACE, new, extack);
+ if (err)
+ return err;
+--
+2.51.0
+
--- /dev/null
+From da3fbdc18e8f91c7a6921dc9ed36f2d24b618d96 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 4 Nov 2020 15:30:24 +0200
+Subject: nexthop: Pass extack to nexthop notifier
+
+From: Ido Schimmel <idosch@nvidia.com>
+
+[ Upstream commit 3578d53dcef152a460a2d560c95dcc4399ff04cd ]
+
+The next patch will add extack to the notification info. This allows
+listeners to veto notifications and communicate the reason to user space.
+
+Signed-off-by: Ido Schimmel <idosch@nvidia.com>
+Reviewed-by: David Ahern <dsahern@gmail.com>
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Stable-dep-of: 390b3a300d78 ("nexthop: Forbid FDB status change while nexthop is in a group")
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ net/ipv4/nexthop.c | 5 +++--
+ 1 file changed, 3 insertions(+), 2 deletions(-)
+
+diff --git a/net/ipv4/nexthop.c b/net/ipv4/nexthop.c
+index a508fd94b8be0..0653aa518648c 100644
+--- a/net/ipv4/nexthop.c
++++ b/net/ipv4/nexthop.c
+@@ -38,7 +38,8 @@ static const struct nla_policy rtm_nh_policy[NHA_MAX + 1] = {
+
+ static int call_nexthop_notifiers(struct net *net,
+ enum nexthop_event_type event_type,
+- struct nexthop *nh)
++ struct nexthop *nh,
++ struct netlink_ext_ack *extack)
+ {
+ int err;
+
+@@ -908,7 +909,7 @@ static void __remove_nexthop(struct net *net, struct nexthop *nh,
+ static void remove_nexthop(struct net *net, struct nexthop *nh,
+ struct nl_info *nlinfo)
+ {
+- call_nexthop_notifiers(net, NEXTHOP_EVENT_DEL, nh);
++ call_nexthop_notifiers(net, NEXTHOP_EVENT_DEL, nh, NULL);
+
+ /* remove from the tree */
+ rb_erase(&nh->rb_node, &net->nexthop.rb_root);
+--
+2.51.0
+
--- /dev/null
+From 31c3545e25e708b38ba62d687a435a06adbc215f Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 4 Nov 2020 15:30:27 +0200
+Subject: rtnetlink: Add RTNH_F_TRAP flag
+
+From: Ido Schimmel <idosch@nvidia.com>
+
+[ Upstream commit 968a83f8cf6fd5a107289c57ee3197a52c72f02c ]
+
+The flag indicates to user space that the nexthop is not programmed to
+forward packets in hardware, but rather to trap them to the CPU. This is
+needed, for example, when the MAC of the nexthop neighbour is not
+resolved and packets should reach the CPU to trigger neighbour
+resolution.
+
+The flag will be used in subsequent patches by netdevsim to test nexthop
+objects programming to device drivers and in the future by mlxsw as
+well.
+
+Changes since RFC:
+* Reword commit message
+
+Signed-off-by: Ido Schimmel <idosch@nvidia.com>
+Reviewed-by: David Ahern <dsahern@gmail.com>
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Stable-dep-of: 390b3a300d78 ("nexthop: Forbid FDB status change while nexthop is in a group")
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ include/uapi/linux/rtnetlink.h | 6 ++++--
+ net/ipv4/fib_semantics.c | 2 ++
+ 2 files changed, 6 insertions(+), 2 deletions(-)
+
+diff --git a/include/uapi/linux/rtnetlink.h b/include/uapi/linux/rtnetlink.h
+index 31be7345e0c2e..5fb40c0c57ffd 100644
+--- a/include/uapi/linux/rtnetlink.h
++++ b/include/uapi/linux/rtnetlink.h
+@@ -396,11 +396,13 @@ struct rtnexthop {
+ #define RTNH_F_DEAD 1 /* Nexthop is dead (used by multipath) */
+ #define RTNH_F_PERVASIVE 2 /* Do recursive gateway lookup */
+ #define RTNH_F_ONLINK 4 /* Gateway is forced on link */
+-#define RTNH_F_OFFLOAD 8 /* offloaded route */
++#define RTNH_F_OFFLOAD 8 /* Nexthop is offloaded */
+ #define RTNH_F_LINKDOWN 16 /* carrier-down on nexthop */
+ #define RTNH_F_UNRESOLVED 32 /* The entry is unresolved (ipmr) */
++#define RTNH_F_TRAP 64 /* Nexthop is trapping packets */
+
+-#define RTNH_COMPARE_MASK (RTNH_F_DEAD | RTNH_F_LINKDOWN | RTNH_F_OFFLOAD)
++#define RTNH_COMPARE_MASK (RTNH_F_DEAD | RTNH_F_LINKDOWN | \
++ RTNH_F_OFFLOAD | RTNH_F_TRAP)
+
+ /* Macros to handle hexthops */
+
+diff --git a/net/ipv4/fib_semantics.c b/net/ipv4/fib_semantics.c
+index a308d3f0f845c..48516a403a9bb 100644
+--- a/net/ipv4/fib_semantics.c
++++ b/net/ipv4/fib_semantics.c
+@@ -1705,6 +1705,8 @@ int fib_nexthop_info(struct sk_buff *skb, const struct fib_nh_common *nhc,
+ *flags |= (nhc->nhc_flags & RTNH_F_ONLINK);
+ if (nhc->nhc_flags & RTNH_F_OFFLOAD)
+ *flags |= RTNH_F_OFFLOAD;
++ if (nhc->nhc_flags & RTNH_F_TRAP)
++ *flags |= RTNH_F_TRAP;
+
+ if (!skip_oif && nhc->nhc_dev &&
+ nla_put_u32(skb, RTA_OIF, nhc->nhc_dev->ifindex))
+--
+2.51.0
+
--- /dev/null
+From f9f2a3d5c30338e2e2101a8b11b865dddb53933e Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Sun, 21 Sep 2025 18:08:23 +0300
+Subject: selftests: fib_nexthops: Fix creation of non-FDB nexthops
+
+From: Ido Schimmel <idosch@nvidia.com>
+
+[ Upstream commit c29913109c70383cdf90b6fc792353e1009f24f5 ]
+
+The test creates non-FDB nexthops without a nexthop device which leads
+to the expected failure, but for the wrong reason:
+
+ # ./fib_nexthops.sh -t "ipv6_fdb_grp_fcnal ipv4_fdb_grp_fcnal" -v
+
+ IPv6 fdb groups functional
+ --------------------------
+ [...]
+ COMMAND: ip -netns me-nRsN3E nexthop add id 63 via 2001:db8:91::4
+ Error: Device attribute required for non-blackhole and non-fdb nexthops.
+ COMMAND: ip -netns me-nRsN3E nexthop add id 64 via 2001:db8:91::5
+ Error: Device attribute required for non-blackhole and non-fdb nexthops.
+ COMMAND: ip -netns me-nRsN3E nexthop add id 103 group 63/64 fdb
+ Error: Invalid nexthop id.
+ TEST: Fdb Nexthop group with non-fdb nexthops [ OK ]
+ [...]
+
+ IPv4 fdb groups functional
+ --------------------------
+ [...]
+ COMMAND: ip -netns me-nRsN3E nexthop add id 14 via 172.16.1.2
+ Error: Device attribute required for non-blackhole and non-fdb nexthops.
+ COMMAND: ip -netns me-nRsN3E nexthop add id 15 via 172.16.1.3
+ Error: Device attribute required for non-blackhole and non-fdb nexthops.
+ COMMAND: ip -netns me-nRsN3E nexthop add id 103 group 14/15 fdb
+ Error: Invalid nexthop id.
+ TEST: Fdb Nexthop group with non-fdb nexthops [ OK ]
+
+ COMMAND: ip -netns me-nRsN3E nexthop add id 16 via 172.16.1.2 fdb
+ COMMAND: ip -netns me-nRsN3E nexthop add id 17 via 172.16.1.3 fdb
+ COMMAND: ip -netns me-nRsN3E nexthop add id 104 group 14/15
+ Error: Invalid nexthop id.
+ TEST: Non-Fdb Nexthop group with fdb nexthops [ OK ]
+ [...]
+ COMMAND: ip -netns me-0dlhyd ro add 172.16.0.0/22 nhid 15
+ Error: Nexthop id does not exist.
+ TEST: Route add with fdb nexthop [ OK ]
+
+In addition, as can be seen in the above output, a couple of IPv4 test
+cases used the non-FDB nexthops (14 and 15) when they intended to use
+the FDB nexthops (16 and 17). These test cases only passed because
+failure was expected, but they failed for the wrong reason.
+
+Fix the test to create the non-FDB nexthops with a nexthop device and
+adjust the IPv4 test cases to use the FDB nexthops instead of the
+non-FDB nexthops.
+
+Output after the fix:
+
+ # ./fib_nexthops.sh -t "ipv6_fdb_grp_fcnal ipv4_fdb_grp_fcnal" -v
+
+ IPv6 fdb groups functional
+ --------------------------
+ [...]
+ COMMAND: ip -netns me-lNzfHP nexthop add id 63 via 2001:db8:91::4 dev veth1
+ COMMAND: ip -netns me-lNzfHP nexthop add id 64 via 2001:db8:91::5 dev veth1
+ COMMAND: ip -netns me-lNzfHP nexthop add id 103 group 63/64 fdb
+ Error: FDB nexthop group can only have fdb nexthops.
+ TEST: Fdb Nexthop group with non-fdb nexthops [ OK ]
+ [...]
+
+ IPv4 fdb groups functional
+ --------------------------
+ [...]
+ COMMAND: ip -netns me-lNzfHP nexthop add id 14 via 172.16.1.2 dev veth1
+ COMMAND: ip -netns me-lNzfHP nexthop add id 15 via 172.16.1.3 dev veth1
+ COMMAND: ip -netns me-lNzfHP nexthop add id 103 group 14/15 fdb
+ Error: FDB nexthop group can only have fdb nexthops.
+ TEST: Fdb Nexthop group with non-fdb nexthops [ OK ]
+
+ COMMAND: ip -netns me-lNzfHP nexthop add id 16 via 172.16.1.2 fdb
+ COMMAND: ip -netns me-lNzfHP nexthop add id 17 via 172.16.1.3 fdb
+ COMMAND: ip -netns me-lNzfHP nexthop add id 104 group 16/17
+ Error: Non FDB nexthop group cannot have fdb nexthops.
+ TEST: Non-Fdb Nexthop group with fdb nexthops [ OK ]
+ [...]
+ COMMAND: ip -netns me-lNzfHP ro add 172.16.0.0/22 nhid 16
+ Error: Route cannot point to a fdb nexthop.
+ TEST: Route add with fdb nexthop [ OK ]
+ [...]
+ Tests passed: 30
+ Tests failed: 0
+ Tests skipped: 0
+
+Fixes: 0534c5489c11 ("selftests: net: add fdb nexthop tests")
+Signed-off-by: Ido Schimmel <idosch@nvidia.com>
+Reviewed-by: David Ahern <dsahern@kernel.org>
+Link: https://patch.msgid.link/20250921150824.149157-3-idosch@nvidia.com
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ tools/testing/selftests/net/fib_nexthops.sh | 12 ++++++------
+ 1 file changed, 6 insertions(+), 6 deletions(-)
+
+diff --git a/tools/testing/selftests/net/fib_nexthops.sh b/tools/testing/selftests/net/fib_nexthops.sh
+index 7ece4131dc6fc..cdc7c0ff090f6 100755
+--- a/tools/testing/selftests/net/fib_nexthops.sh
++++ b/tools/testing/selftests/net/fib_nexthops.sh
+@@ -370,8 +370,8 @@ ipv6_fdb_grp_fcnal()
+ log_test $? 0 "Get Fdb nexthop group by id"
+
+ # fdb nexthop group can only contain fdb nexthops
+- run_cmd "$IP nexthop add id 63 via 2001:db8:91::4"
+- run_cmd "$IP nexthop add id 64 via 2001:db8:91::5"
++ run_cmd "$IP nexthop add id 63 via 2001:db8:91::4 dev veth1"
++ run_cmd "$IP nexthop add id 64 via 2001:db8:91::5 dev veth1"
+ run_cmd "$IP nexthop add id 103 group 63/64 fdb"
+ log_test $? 2 "Fdb Nexthop group with non-fdb nexthops"
+
+@@ -450,15 +450,15 @@ ipv4_fdb_grp_fcnal()
+ log_test $? 0 "Get Fdb nexthop group by id"
+
+ # fdb nexthop group can only contain fdb nexthops
+- run_cmd "$IP nexthop add id 14 via 172.16.1.2"
+- run_cmd "$IP nexthop add id 15 via 172.16.1.3"
++ run_cmd "$IP nexthop add id 14 via 172.16.1.2 dev veth1"
++ run_cmd "$IP nexthop add id 15 via 172.16.1.3 dev veth1"
+ run_cmd "$IP nexthop add id 103 group 14/15 fdb"
+ log_test $? 2 "Fdb Nexthop group with non-fdb nexthops"
+
+ # Non fdb nexthop group can not contain fdb nexthops
+ run_cmd "$IP nexthop add id 16 via 172.16.1.2 fdb"
+ run_cmd "$IP nexthop add id 17 via 172.16.1.3 fdb"
+- run_cmd "$IP nexthop add id 104 group 14/15"
++ run_cmd "$IP nexthop add id 104 group 16/17"
+ log_test $? 2 "Non-Fdb Nexthop group with fdb nexthops"
+
+ # fdb nexthop cannot have blackhole
+@@ -485,7 +485,7 @@ ipv4_fdb_grp_fcnal()
+ run_cmd "$BRIDGE fdb add 02:02:00:00:00:14 dev vx10 nhid 12 self"
+ log_test $? 255 "Fdb mac add with nexthop"
+
+- run_cmd "$IP ro add 172.16.0.0/22 nhid 15"
++ run_cmd "$IP ro add 172.16.0.0/22 nhid 16"
+ log_test $? 2 "Route add with fdb nexthop"
+
+ run_cmd "$IP ro add 172.16.0.0/22 nhid 103"
+--
+2.51.0
+
arm64-dts-imx8mp-correct-thermal-sensor-index.patch
cpufreq-initialize-cpufreq-based-invariance-before-s.patch
can-rcar_can-rcar_can_resume-fix-s2ram-with-psci.patch
+can-hi311x-populate-ndo_change_mtu-to-prevent-buffer.patch
+can-sun4i_can-populate-ndo_change_mtu-to-prevent-buf.patch
+can-mcba_usb-populate-ndo_change_mtu-to-prevent-buff.patch
+can-peak_usb-fix-shift-out-of-bounds-issue.patch
+bnxt_en-correct-offset-handling-for-ipv6-destination.patch
+nexthop-pass-extack-to-nexthop-notifier.patch
+rtnetlink-add-rtnh_f_trap-flag.patch
+nexthop-emit-a-notification-when-a-nexthop-is-added.patch
+nexthop-emit-a-notification-when-a-single-nexthop-is.patch
+nexthop-forbid-fdb-status-change-while-nexthop-is-in.patch
+selftests-fib_nexthops-fix-creation-of-non-fdb-nexth.patch
--- /dev/null
+From 5001ea4e3eb3f09622af1a72caaccf53324679ac Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Sat, 20 Sep 2025 05:11:17 -0700
+Subject: bnxt_en: correct offset handling for IPv6 destination address
+
+From: Alok Tiwari <alok.a.tiwari@oracle.com>
+
+[ Upstream commit 3d3aa9472c6dd0704e9961ed4769caac5b1c8d52 ]
+
+In bnxt_tc_parse_pedit(), the code incorrectly writes IPv6
+destination values to the source address field (saddr) when
+processing pedit offsets within the destination address range.
+
+This patch corrects the assignment to use daddr instead of saddr,
+ensuring that pedit operations on IPv6 destination addresses are
+applied correctly.
+
+Fixes: 9b9eb518e338 ("bnxt_en: Add support for NAT(L3/L4 rewrite)")
+Signed-off-by: Alok Tiwari <alok.a.tiwari@oracle.com>
+Reviewed-by: Somnath Kotur <somnath.kotur@broadcom.com>
+Link: https://patch.msgid.link/20250920121157.351921-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/broadcom/bnxt/bnxt_tc.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt_tc.c b/drivers/net/ethernet/broadcom/bnxt/bnxt_tc.c
+index b3473883eae6b..0dd393a4fa80c 100644
+--- a/drivers/net/ethernet/broadcom/bnxt/bnxt_tc.c
++++ b/drivers/net/ethernet/broadcom/bnxt/bnxt_tc.c
+@@ -244,7 +244,7 @@ bnxt_tc_parse_pedit(struct bnxt *bp, struct bnxt_tc_actions *actions,
+ offset < offset_of_ip6_daddr + 16) {
+ actions->nat.src_xlate = false;
+ idx = (offset - offset_of_ip6_daddr) / 4;
+- actions->nat.l3.ipv6.saddr.s6_addr32[idx] = htonl(val);
++ actions->nat.l3.ipv6.daddr.s6_addr32[idx] = htonl(val);
+ } else {
+ netdev_err(bp->dev,
+ "%s: IPv6_hdr: Invalid pedit field\n",
+--
+2.51.0
+
--- /dev/null
+From d85d73b661080954d3cfd3e3797df73b28a34914 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Sat, 18 Sep 2021 18:56:32 +0900
+Subject: can: bittiming: allow TDC{V,O} to be zero and add
+ can_tdc_const::tdc{v,o,f}_min
+
+From: Vincent Mailhol <mailhol.vincent@wanadoo.fr>
+
+[ Upstream commit 63dfe0709643528290c8a6825f278eda0e3f3c2e ]
+
+ISO 11898-1 specifies in section 11.3.3 "Transmitter delay
+compensation" that "the configuration range for [the] SSP position
+shall be at least 0 to 63 minimum time quanta."
+
+Because SSP = TDCV + TDCO, it means that we should allow both TDCV and
+TDCO to hold zero value in order to honor SSP's minimum possible
+value.
+
+However, current implementation assigned special meaning to TDCV and
+TDCO's zero values:
+ * TDCV = 0 -> TDCV is automatically measured by the transceiver.
+ * TDCO = 0 -> TDC is off.
+
+In order to allow for those values to really be zero and to maintain
+current features, we introduce two new flags:
+ * CAN_CTRLMODE_TDC_AUTO indicates that the controller support
+ automatic measurement of TDCV.
+ * CAN_CTRLMODE_TDC_MANUAL indicates that the controller support
+ manual configuration of TDCV. N.B.: current implementation failed
+ to provide an option for the driver to indicate that only manual
+ mode was supported.
+
+TDC is disabled if both CAN_CTRLMODE_TDC_AUTO and
+CAN_CTRLMODE_TDC_MANUAL flags are off, c.f. the helper function
+can_tdc_is_enabled() which is also introduced in this patch.
+
+Also, this patch adds three fields: tdcv_min, tdco_min and tdcf_min to
+struct can_tdc_const. While we are not convinced that those three
+fields could be anything else than zero, we can imagine that some
+controllers might specify a lower bound on these. Thus, those minimums
+are really added "just in case".
+
+Comments of struct can_tdc and can_tdc_const are updated accordingly.
+
+Finally, the changes are applied to the etas_es58x driver.
+
+Link: https://lore.kernel.org/all/20210918095637.20108-2-mailhol.vincent@wanadoo.fr
+Signed-off-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr>
+Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
+Stable-dep-of: 38c0abad45b1 ("can: etas_es58x: populate ndo_change_mtu() to prevent buffer overflow")
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/can/dev/bittiming.c | 10 ++--
+ drivers/net/can/usb/etas_es58x/es58x_fd.c | 7 ++-
+ include/linux/can/bittiming.h | 64 +++++++++++++++++------
+ include/linux/can/dev.h | 4 ++
+ include/uapi/linux/can/netlink.h | 2 +
+ 5 files changed, 65 insertions(+), 22 deletions(-)
+
+diff --git a/drivers/net/can/dev/bittiming.c b/drivers/net/can/dev/bittiming.c
+index b1b5a82f08299..9dda44c0ae9df 100644
+--- a/drivers/net/can/dev/bittiming.c
++++ b/drivers/net/can/dev/bittiming.c
+@@ -182,9 +182,12 @@ void can_calc_tdco(struct net_device *dev)
+ struct can_tdc *tdc = &priv->tdc;
+ const struct can_tdc_const *tdc_const = priv->tdc_const;
+
+- if (!tdc_const)
++ if (!tdc_const ||
++ !(priv->ctrlmode_supported & CAN_CTRLMODE_TDC_AUTO))
+ return;
+
++ priv->ctrlmode &= ~CAN_CTRLMODE_TDC_MASK;
++
+ /* As specified in ISO 11898-1 section 11.3.3 "Transmitter
+ * delay compensation" (TDC) is only applicable if data BRP is
+ * one or two.
+@@ -193,9 +196,10 @@ void can_calc_tdco(struct net_device *dev)
+ /* Reuse "normal" sample point and convert it to time quanta */
+ u32 sample_point_in_tq = can_bit_time(dbt) * dbt->sample_point / 1000;
+
++ if (sample_point_in_tq < tdc_const->tdco_min)
++ return;
+ tdc->tdco = min(sample_point_in_tq, tdc_const->tdco_max);
+- } else {
+- tdc->tdco = 0;
++ priv->ctrlmode |= CAN_CTRLMODE_TDC_AUTO;
+ }
+ }
+ #endif /* CONFIG_CAN_CALC_BITTIMING */
+diff --git a/drivers/net/can/usb/etas_es58x/es58x_fd.c b/drivers/net/can/usb/etas_es58x/es58x_fd.c
+index 26bf4775e884c..b71d1530638b7 100644
+--- a/drivers/net/can/usb/etas_es58x/es58x_fd.c
++++ b/drivers/net/can/usb/etas_es58x/es58x_fd.c
+@@ -427,7 +427,7 @@ static int es58x_fd_enable_channel(struct es58x_priv *priv)
+ es58x_fd_convert_bittiming(&tx_conf_msg.data_bittiming,
+ &priv->can.data_bittiming);
+
+- if (priv->can.tdc.tdco) {
++ if (can_tdc_is_enabled(&priv->can)) {
+ tx_conf_msg.tdc_enabled = 1;
+ tx_conf_msg.tdco = cpu_to_le16(priv->can.tdc.tdco);
+ tx_conf_msg.tdcf = cpu_to_le16(priv->can.tdc.tdcf);
+@@ -504,8 +504,11 @@ static const struct can_bittiming_const es58x_fd_data_bittiming_const = {
+ * Register" from Microchip.
+ */
+ static const struct can_tdc_const es58x_tdc_const = {
++ .tdcv_min = 0,
+ .tdcv_max = 0, /* Manual mode not supported. */
++ .tdco_min = 0,
+ .tdco_max = 127,
++ .tdcf_min = 0,
+ .tdcf_max = 127
+ };
+
+@@ -522,7 +525,7 @@ const struct es58x_parameters es58x_fd_param = {
+ .clock = {.freq = 80 * CAN_MHZ},
+ .ctrlmode_supported = CAN_CTRLMODE_LOOPBACK | CAN_CTRLMODE_LISTENONLY |
+ CAN_CTRLMODE_3_SAMPLES | CAN_CTRLMODE_FD | CAN_CTRLMODE_FD_NON_ISO |
+- CAN_CTRLMODE_CC_LEN8_DLC,
++ CAN_CTRLMODE_CC_LEN8_DLC | CAN_CTRLMODE_TDC_AUTO,
+ .tx_start_of_frame = 0xCEFA, /* FACE in little endian */
+ .rx_start_of_frame = 0xFECA, /* CAFE in little endian */
+ .tx_urb_cmd_max_len = ES58X_FD_TX_URB_CMD_MAX_LEN,
+diff --git a/include/linux/can/bittiming.h b/include/linux/can/bittiming.h
+index 9de6e9053e34f..9e20260611ccb 100644
+--- a/include/linux/can/bittiming.h
++++ b/include/linux/can/bittiming.h
+@@ -19,6 +19,9 @@
+ /* Megahertz */
+ #define CAN_MHZ 1000000UL
+
++#define CAN_CTRLMODE_TDC_MASK \
++ (CAN_CTRLMODE_TDC_AUTO | CAN_CTRLMODE_TDC_MANUAL)
++
+ /*
+ * struct can_tdc - CAN FD Transmission Delay Compensation parameters
+ *
+@@ -33,29 +36,43 @@
+ *
+ * This structure contains the parameters to calculate that SSP.
+ *
+- * @tdcv: Transmitter Delay Compensation Value. Distance, in time
+- * quanta, from when the bit is sent on the TX pin to when it is
+- * received on the RX pin of the transmitter. Possible options:
++ * -+----------- one bit ----------+-- TX pin
++ * |<--- Sample Point --->|
++ *
++ * --+----------- one bit ----------+-- RX pin
++ * |<-------- TDCV -------->|
++ * |<------- TDCO ------->|
++ * |<----------- Secondary Sample Point ---------->|
++ *
++ * @tdcv: Transmitter Delay Compensation Value. The time needed for
++ * the signal to propagate, i.e. the distance, in time quanta,
++ * from the start of the bit on the TX pin to when it is received
++ * on the RX pin. @tdcv depends on the controller modes:
++ *
++ * CAN_CTRLMODE_TDC_AUTO is set: The transceiver dynamically
++ * measures @tdcv for each transmitted CAN FD frame and the
++ * value provided here should be ignored.
+ *
+- * 0: automatic mode. The controller dynamically measures @tdcv
+- * for each transmitted CAN FD frame.
++ * CAN_CTRLMODE_TDC_MANUAL is set: use the fixed provided @tdcv
++ * value.
+ *
+- * Other values: manual mode. Use the fixed provided value.
++ * N.B. CAN_CTRLMODE_TDC_AUTO and CAN_CTRLMODE_TDC_MANUAL are
++ * mutually exclusive. Only one can be set at a time. If both
++ * CAN_TDC_CTRLMODE_AUTO and CAN_TDC_CTRLMODE_MANUAL are unset,
++ * TDC is disabled and all the values of this structure should be
++ * ignored.
+ *
+ * @tdco: Transmitter Delay Compensation Offset. Offset value, in time
+ * quanta, defining the distance between the start of the bit
+ * reception on the RX pin of the transceiver and the SSP
+ * position such that SSP = @tdcv + @tdco.
+ *
+- * If @tdco is zero, then TDC is disabled and both @tdcv and
+- * @tdcf should be ignored.
+- *
+ * @tdcf: Transmitter Delay Compensation Filter window. Defines the
+- * minimum value for the SSP position in time quanta. If SSP is
+- * less than @tdcf, then no delay compensations occur and the
+- * normal sampling point is used instead. The feature is enabled
+- * if and only if @tdcv is set to zero (automatic mode) and @tdcf
+- * is configured to a value greater than @tdco.
++ * minimum value for the SSP position in time quanta. If the SSP
++ * position is less than @tdcf, then no delay compensations occur
++ * and the normal sampling point is used instead. The feature is
++ * enabled if and only if @tdcv is set to zero (automatic mode)
++ * and @tdcf is configured to a value greater than @tdco.
+ */
+ struct can_tdc {
+ u32 tdcv;
+@@ -67,19 +84,32 @@ struct can_tdc {
+ * struct can_tdc_const - CAN hardware-dependent constant for
+ * Transmission Delay Compensation
+ *
+- * @tdcv_max: Transmitter Delay Compensation Value maximum value.
+- * Should be set to zero if the controller does not support
+- * manual mode for tdcv.
++ * @tdcv_min: Transmitter Delay Compensation Value minimum value. If
++ * the controller does not support manual mode for tdcv
++ * (c.f. flag CAN_CTRLMODE_TDC_MANUAL) then this value is
++ * ignored.
++ * @tdcv_max: Transmitter Delay Compensation Value maximum value. If
++ * the controller does not support manual mode for tdcv
++ * (c.f. flag CAN_CTRLMODE_TDC_MANUAL) then this value is
++ * ignored.
++ *
++ * @tdco_min: Transmitter Delay Compensation Offset minimum value.
+ * @tdco_max: Transmitter Delay Compensation Offset maximum value.
+ * Should not be zero. If the controller does not support TDC,
+ * then the pointer to this structure should be NULL.
++ *
++ * @tdcf_min: Transmitter Delay Compensation Filter window minimum
++ * value. If @tdcf_max is zero, this value is ignored.
+ * @tdcf_max: Transmitter Delay Compensation Filter window maximum
+ * value. Should be set to zero if the controller does not
+ * support this feature.
+ */
+ struct can_tdc_const {
++ u32 tdcv_min;
+ u32 tdcv_max;
++ u32 tdco_min;
+ u32 tdco_max;
++ u32 tdcf_min;
+ u32 tdcf_max;
+ };
+
+diff --git a/include/linux/can/dev.h b/include/linux/can/dev.h
+index 2413253e54c70..6dacbbb41e68c 100644
+--- a/include/linux/can/dev.h
++++ b/include/linux/can/dev.h
+@@ -96,6 +96,10 @@ struct can_priv {
+ #endif
+ };
+
++static inline bool can_tdc_is_enabled(const struct can_priv *priv)
++{
++ return !!(priv->ctrlmode & CAN_CTRLMODE_TDC_MASK);
++}
+
+ /* helper to define static CAN controller features at device creation time */
+ static inline void can_set_static_ctrlmode(struct net_device *dev,
+diff --git a/include/uapi/linux/can/netlink.h b/include/uapi/linux/can/netlink.h
+index f730d443b9184..004cd09a7d49d 100644
+--- a/include/uapi/linux/can/netlink.h
++++ b/include/uapi/linux/can/netlink.h
+@@ -101,6 +101,8 @@ struct can_ctrlmode {
+ #define CAN_CTRLMODE_PRESUME_ACK 0x40 /* Ignore missing CAN ACKs */
+ #define CAN_CTRLMODE_FD_NON_ISO 0x80 /* CAN FD in non-ISO mode */
+ #define CAN_CTRLMODE_CC_LEN8_DLC 0x100 /* Classic CAN DLC option */
++#define CAN_CTRLMODE_TDC_AUTO 0x200 /* CAN transiver automatically calculates TDCV */
++#define CAN_CTRLMODE_TDC_MANUAL 0x400 /* TDCV is manually set up by user */
+
+ /*
+ * CAN device statistics
+--
+2.51.0
+
--- /dev/null
+From faac6dc5ddf9dd04b32c70ec983f1dcb3d89905b Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 24 Nov 2021 10:45:36 +0900
+Subject: can: bittiming: replace CAN units with the generic ones from
+ linux/units.h
+
+From: Vincent Mailhol <mailhol.vincent@wanadoo.fr>
+
+[ Upstream commit 330c6d3bfa268794bf692165d0f781f1c2d4d83e ]
+
+In [1], we introduced a set of units in linux/can/bittiming.h. Since
+then, generic SI prefixes were added to linux/units.h in [2]. Those
+new prefixes can perfectly replace CAN specific ones.
+
+This patch replaces all occurrences of the CAN units with their
+corresponding prefix (from linux/units) and the unit (as a comment)
+according to below table.
+
+ CAN units SI metric prefix (from linux/units) + unit (as a comment)
+ ------------------------------------------------------------------------
+ CAN_KBPS KILO /* BPS */
+ CAN_MBPS MEGA /* BPS */
+ CAM_MHZ MEGA /* Hz */
+
+The definition are then removed from linux/can/bittiming.h
+
+[1] commit 1d7750760b70 ("can: bittiming: add CAN_KBPS, CAN_MBPS and
+CAN_MHZ macros")
+
+[2] commit 26471d4a6cf8 ("units: Add SI metric prefix definitions")
+
+Link: https://lore.kernel.org/all/20211124014536.782550-1-mailhol.vincent@wanadoo.fr
+Suggested-by: Jimmy Assarsson <extja@kvaser.com>
+Suggested-by: Oliver Hartkopp <socketcan@hartkopp.net>
+Signed-off-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr>
+Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
+Stable-dep-of: 38c0abad45b1 ("can: etas_es58x: populate ndo_change_mtu() to prevent buffer overflow")
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/can/dev/bittiming.c | 5 +++--
+ drivers/net/can/usb/etas_es58x/es581_4.c | 5 +++--
+ drivers/net/can/usb/etas_es58x/es58x_fd.c | 5 +++--
+ include/linux/can/bittiming.h | 7 -------
+ 4 files changed, 9 insertions(+), 13 deletions(-)
+
+diff --git a/drivers/net/can/dev/bittiming.c b/drivers/net/can/dev/bittiming.c
+index 9dda44c0ae9df..45f8baa56fd39 100644
+--- a/drivers/net/can/dev/bittiming.c
++++ b/drivers/net/can/dev/bittiming.c
+@@ -4,6 +4,7 @@
+ * Copyright (C) 2008-2009 Wolfgang Grandegger <wg@grandegger.com>
+ */
+
++#include <linux/units.h>
+ #include <linux/can/dev.h>
+
+ #ifdef CONFIG_CAN_CALC_BITTIMING
+@@ -81,9 +82,9 @@ int can_calc_bittiming(struct net_device *dev, struct can_bittiming *bt,
+ if (bt->sample_point) {
+ sample_point_nominal = bt->sample_point;
+ } else {
+- if (bt->bitrate > 800 * CAN_KBPS)
++ if (bt->bitrate > 800 * KILO /* BPS */)
+ sample_point_nominal = 750;
+- else if (bt->bitrate > 500 * CAN_KBPS)
++ else if (bt->bitrate > 500 * KILO /* BPS */)
+ sample_point_nominal = 800;
+ else
+ sample_point_nominal = 875;
+diff --git a/drivers/net/can/usb/etas_es58x/es581_4.c b/drivers/net/can/usb/etas_es58x/es581_4.c
+index 14e360c9f2c9a..1bcdcece5ec72 100644
+--- a/drivers/net/can/usb/etas_es58x/es581_4.c
++++ b/drivers/net/can/usb/etas_es58x/es581_4.c
+@@ -10,6 +10,7 @@
+ */
+
+ #include <linux/kernel.h>
++#include <linux/units.h>
+ #include <asm/unaligned.h>
+
+ #include "es58x_core.h"
+@@ -469,8 +470,8 @@ const struct es58x_parameters es581_4_param = {
+ .bittiming_const = &es581_4_bittiming_const,
+ .data_bittiming_const = NULL,
+ .tdc_const = NULL,
+- .bitrate_max = 1 * CAN_MBPS,
+- .clock = {.freq = 50 * CAN_MHZ},
++ .bitrate_max = 1 * MEGA /* BPS */,
++ .clock = {.freq = 50 * MEGA /* Hz */},
+ .ctrlmode_supported = CAN_CTRLMODE_CC_LEN8_DLC,
+ .tx_start_of_frame = 0xAFAF,
+ .rx_start_of_frame = 0xFAFA,
+diff --git a/drivers/net/can/usb/etas_es58x/es58x_fd.c b/drivers/net/can/usb/etas_es58x/es58x_fd.c
+index b71d1530638b7..8ccda748fd084 100644
+--- a/drivers/net/can/usb/etas_es58x/es58x_fd.c
++++ b/drivers/net/can/usb/etas_es58x/es58x_fd.c
+@@ -12,6 +12,7 @@
+ */
+
+ #include <linux/kernel.h>
++#include <linux/units.h>
+ #include <asm/unaligned.h>
+
+ #include "es58x_core.h"
+@@ -521,8 +522,8 @@ const struct es58x_parameters es58x_fd_param = {
+ * Mbps work in an optimal environment but are not recommended
+ * for production environment.
+ */
+- .bitrate_max = 8 * CAN_MBPS,
+- .clock = {.freq = 80 * CAN_MHZ},
++ .bitrate_max = 8 * MEGA /* BPS */,
++ .clock = {.freq = 80 * MEGA /* Hz */},
+ .ctrlmode_supported = CAN_CTRLMODE_LOOPBACK | CAN_CTRLMODE_LISTENONLY |
+ CAN_CTRLMODE_3_SAMPLES | CAN_CTRLMODE_FD | CAN_CTRLMODE_FD_NON_ISO |
+ CAN_CTRLMODE_CC_LEN8_DLC | CAN_CTRLMODE_TDC_AUTO,
+diff --git a/include/linux/can/bittiming.h b/include/linux/can/bittiming.h
+index 9e20260611ccb..9d7c902da245e 100644
+--- a/include/linux/can/bittiming.h
++++ b/include/linux/can/bittiming.h
+@@ -12,13 +12,6 @@
+ #define CAN_SYNC_SEG 1
+
+
+-/* Kilobits and Megabits per second */
+-#define CAN_KBPS 1000UL
+-#define CAN_MBPS 1000000UL
+-
+-/* Megahertz */
+-#define CAN_MHZ 1000000UL
+-
+ #define CAN_CTRLMODE_TDC_MASK \
+ (CAN_CTRLMODE_TDC_AUTO | CAN_CTRLMODE_TDC_MANUAL)
+
+--
+2.51.0
+
--- /dev/null
+From 087fff186c857fba487f83de51ca611ee2b78519 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 27 Jul 2022 19:16:35 +0900
+Subject: can: dev: add generic function can_eth_ioctl_hwts()
+
+From: Vincent Mailhol <mailhol.vincent@wanadoo.fr>
+
+[ Upstream commit 90f942c5a6d775bad1be33ba214755314105da4a ]
+
+Tools based on libpcap (such as tcpdump) expect the SIOCSHWTSTAMP
+ioctl call to be supported. This is also specified in the kernel doc
+[1]. The purpose of this ioctl is to toggle the hardware timestamps.
+
+Currently, CAN devices which support hardware timestamping have those
+always activated. can_eth_ioctl_hwts() is a dumb function that will
+always succeed when requested to set tx_type to HWTSTAMP_TX_ON or
+rx_filter to HWTSTAMP_FILTER_ALL.
+
+[1] Kernel doc: Timestamping, section 3.1 "Hardware Timestamping
+Implementation: Device Drivers"
+Link: https://docs.kernel.org/networking/timestamping.html#hardware-timestamping-implementation-device-drivers
+
+Signed-off-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr>
+Link: https://lore.kernel.org/all/20220727101641.198847-9-mailhol.vincent@wanadoo.fr
+Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
+Stable-dep-of: 38c0abad45b1 ("can: etas_es58x: populate ndo_change_mtu() to prevent buffer overflow")
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/can/dev/dev.c | 29 +++++++++++++++++++++++++++++
+ include/linux/can/dev.h | 1 +
+ 2 files changed, 30 insertions(+)
+
+diff --git a/drivers/net/can/dev/dev.c b/drivers/net/can/dev/dev.c
+index d429a2940e83f..645564b9bff00 100644
+--- a/drivers/net/can/dev/dev.c
++++ b/drivers/net/can/dev/dev.c
+@@ -331,6 +331,35 @@ int can_change_mtu(struct net_device *dev, int new_mtu)
+ }
+ EXPORT_SYMBOL_GPL(can_change_mtu);
+
++/* generic implementation of netdev_ops::ndo_eth_ioctl for CAN devices
++ * supporting hardware timestamps
++ */
++int can_eth_ioctl_hwts(struct net_device *netdev, struct ifreq *ifr, int cmd)
++{
++ struct hwtstamp_config hwts_cfg = { 0 };
++
++ switch (cmd) {
++ case SIOCSHWTSTAMP: /* set */
++ if (copy_from_user(&hwts_cfg, ifr->ifr_data, sizeof(hwts_cfg)))
++ return -EFAULT;
++ if (hwts_cfg.tx_type == HWTSTAMP_TX_ON &&
++ hwts_cfg.rx_filter == HWTSTAMP_FILTER_ALL)
++ return 0;
++ return -ERANGE;
++
++ case SIOCGHWTSTAMP: /* get */
++ hwts_cfg.tx_type = HWTSTAMP_TX_ON;
++ hwts_cfg.rx_filter = HWTSTAMP_FILTER_ALL;
++ if (copy_to_user(ifr->ifr_data, &hwts_cfg, sizeof(hwts_cfg)))
++ return -EFAULT;
++ return 0;
++
++ default:
++ return -EOPNOTSUPP;
++ }
++}
++EXPORT_SYMBOL(can_eth_ioctl_hwts);
++
+ /* generic implementation of ethtool_ops::get_ts_info for CAN devices
+ * supporting hardware timestamps
+ */
+diff --git a/include/linux/can/dev.h b/include/linux/can/dev.h
+index 23f1c9f0109d7..c439735dce6a7 100644
+--- a/include/linux/can/dev.h
++++ b/include/linux/can/dev.h
+@@ -133,6 +133,7 @@ struct can_priv *safe_candev_priv(struct net_device *dev);
+ int open_candev(struct net_device *dev);
+ void close_candev(struct net_device *dev);
+ int can_change_mtu(struct net_device *dev, int new_mtu);
++int can_eth_ioctl_hwts(struct net_device *netdev, struct ifreq *ifr, int cmd);
+ int can_ethtool_op_get_ts_info_hwts(struct net_device *dev,
+ struct ethtool_ts_info *info);
+
+--
+2.51.0
+
--- /dev/null
+From fb81ee434de7081d777fa44d3c8f5c08090825fc Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 27 Jul 2022 19:16:34 +0900
+Subject: can: dev: add generic function can_ethtool_op_get_ts_info_hwts()
+
+From: Vincent Mailhol <mailhol.vincent@wanadoo.fr>
+
+[ Upstream commit 7fb48d25b5ce3bc488dbb019bf1736248181de9a ]
+
+Add function can_ethtool_op_get_ts_info_hwts(). This function will be
+used by CAN devices with hardware TX/RX timestamping support to
+implement ethtool_ops::get_ts_info. This function does not offer
+support to activate/deactivate hardware timestamps at device level nor
+support the filter options (which is currently the case for all CAN
+devices with hardware timestamping support).
+
+The fact that hardware timestamp can not be deactivated at hardware
+level does not impact the userland. As long as the user do not set
+SO_TIMESTAMPING using a setsockopt() or ioctl(), the kernel will not
+emit TX timestamps (RX timestamps will still be reproted as it is the
+case currently).
+
+Drivers which need more fine grained control remains free to implement
+their own function, but we foresee that the generic function
+introduced here will be sufficient for the majority.
+
+Signed-off-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr>
+Link: https://lore.kernel.org/all/20220727101641.198847-8-mailhol.vincent@wanadoo.fr
+Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
+Stable-dep-of: 38c0abad45b1 ("can: etas_es58x: populate ndo_change_mtu() to prevent buffer overflow")
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/can/dev/dev.c | 21 +++++++++++++++++++++
+ include/linux/can/dev.h | 3 +++
+ 2 files changed, 24 insertions(+)
+
+diff --git a/drivers/net/can/dev/dev.c b/drivers/net/can/dev/dev.c
+index 641f84e5beb0c..d429a2940e83f 100644
+--- a/drivers/net/can/dev/dev.c
++++ b/drivers/net/can/dev/dev.c
+@@ -331,6 +331,27 @@ int can_change_mtu(struct net_device *dev, int new_mtu)
+ }
+ EXPORT_SYMBOL_GPL(can_change_mtu);
+
++/* generic implementation of ethtool_ops::get_ts_info for CAN devices
++ * supporting hardware timestamps
++ */
++int can_ethtool_op_get_ts_info_hwts(struct net_device *dev,
++ struct ethtool_ts_info *info)
++{
++ info->so_timestamping =
++ SOF_TIMESTAMPING_TX_SOFTWARE |
++ SOF_TIMESTAMPING_RX_SOFTWARE |
++ SOF_TIMESTAMPING_SOFTWARE |
++ SOF_TIMESTAMPING_TX_HARDWARE |
++ SOF_TIMESTAMPING_RX_HARDWARE |
++ SOF_TIMESTAMPING_RAW_HARDWARE;
++ info->phc_index = -1;
++ info->tx_types = BIT(HWTSTAMP_TX_ON);
++ info->rx_filters = BIT(HWTSTAMP_FILTER_ALL);
++
++ return 0;
++}
++EXPORT_SYMBOL(can_ethtool_op_get_ts_info_hwts);
++
+ /* Common open function when the device gets opened.
+ *
+ * This function should be called in the open function of the device
+diff --git a/include/linux/can/dev.h b/include/linux/can/dev.h
+index 6dacbbb41e68c..23f1c9f0109d7 100644
+--- a/include/linux/can/dev.h
++++ b/include/linux/can/dev.h
+@@ -21,6 +21,7 @@
+ #include <linux/can/length.h>
+ #include <linux/can/netlink.h>
+ #include <linux/can/skb.h>
++#include <linux/ethtool.h>
+ #include <linux/netdevice.h>
+
+ /*
+@@ -132,6 +133,8 @@ struct can_priv *safe_candev_priv(struct net_device *dev);
+ int open_candev(struct net_device *dev);
+ void close_candev(struct net_device *dev);
+ int can_change_mtu(struct net_device *dev, int new_mtu);
++int can_ethtool_op_get_ts_info_hwts(struct net_device *dev,
++ struct ethtool_ts_info *info);
+
+ int register_candev(struct net_device *dev);
+ void unregister_candev(struct net_device *dev);
+--
+2.51.0
+
--- /dev/null
+From db448bfaeee1343f1a5ff833c3796fa5a8a712e1 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 27 Jul 2022 19:16:37 +0900
+Subject: can: etas_es58x: advertise timestamping capabilities and add ioctl
+ support
+
+From: Vincent Mailhol <mailhol.vincent@wanadoo.fr>
+
+[ Upstream commit 1d46efa0008a6d73dad40e78a2b3fa6d3cfb74e4 ]
+
+Currently, userland has no method to query which timestamping features
+are supported by the etas_es58x driver (aside maybe of getting RX
+messages and observe whether or not hardware timestamps stay at zero).
+
+The canonical way for a network driver to advertise what kind of
+timestamping is supports is to implement
+ethtool_ops::get_ts_info(). Here, we use the CAN specific
+can_ethtool_op_get_ts_info_hwts() function to achieve this.
+
+In addition, the driver currently does not support the hardware
+timestamps ioctls. According to [1], SIOCSHWTSTAMP is "must" and
+SIOCGHWTSTAMP is "should". This patch fills up that gap by
+implementing net_device_ops::ndo_eth_ioctl() using the CAN specific
+function can_eth_ioctl_hwts().
+
+[1] kernel doc Timestamping, section 3.1: "Hardware Timestamping
+Implementation: Device Drivers"
+Link: https://docs.kernel.org/networking/timestamping.html#hardware-timestamping-implementation-device-drivers
+
+Signed-off-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr>
+Link: https://lore.kernel.org/all/20220727101641.198847-11-mailhol.vincent@wanadoo.fr
+Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
+Stable-dep-of: 38c0abad45b1 ("can: etas_es58x: populate ndo_change_mtu() to prevent buffer overflow")
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/can/usb/etas_es58x/es58x_core.c | 9 ++++++++-
+ 1 file changed, 8 insertions(+), 1 deletion(-)
+
+diff --git a/drivers/net/can/usb/etas_es58x/es58x_core.c b/drivers/net/can/usb/etas_es58x/es58x_core.c
+index 34d374d301e50..0c0e2363f674b 100644
+--- a/drivers/net/can/usb/etas_es58x/es58x_core.c
++++ b/drivers/net/can/usb/etas_es58x/es58x_core.c
+@@ -10,6 +10,7 @@
+ * Copyright (c) 2020, 2021 Vincent Mailhol <mailhol.vincent@wanadoo.fr>
+ */
+
++#include <linux/ethtool.h>
+ #include <linux/kernel.h>
+ #include <linux/module.h>
+ #include <linux/usb.h>
+@@ -1981,7 +1982,12 @@ static netdev_tx_t es58x_start_xmit(struct sk_buff *skb,
+ static const struct net_device_ops es58x_netdev_ops = {
+ .ndo_open = es58x_open,
+ .ndo_stop = es58x_stop,
+- .ndo_start_xmit = es58x_start_xmit
++ .ndo_start_xmit = es58x_start_xmit,
++ .ndo_eth_ioctl = can_eth_ioctl_hwts,
++};
++
++static const struct ethtool_ops es58x_ethtool_ops = {
++ .get_ts_info = can_ethtool_op_get_ts_info_hwts,
+ };
+
+ /**
+@@ -2088,6 +2094,7 @@ static int es58x_init_netdev(struct es58x_device *es58x_dev, int channel_idx)
+ es58x_init_priv(es58x_dev, es58x_priv(netdev), channel_idx);
+
+ netdev->netdev_ops = &es58x_netdev_ops;
++ netdev->ethtool_ops = &es58x_ethtool_ops;
+ netdev->flags |= IFF_ECHO; /* We support local echo */
+
+ ret = register_candev(netdev);
+--
+2.51.0
+
--- /dev/null
+From 7f4fd3205bfb912bc0c9ebe5493ed38aa68857d3 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 18 Sep 2025 18:00:24 +0900
+Subject: can: etas_es58x: populate ndo_change_mtu() to prevent buffer overflow
+
+From: Vincent Mailhol <mailhol@kernel.org>
+
+[ Upstream commit 38c0abad45b190a30d8284a37264d2127a6ec303 ]
+
+Sending an PF_PACKET allows to bypass the CAN framework logic and to
+directly reach the xmit() function of a CAN driver. The only check
+which is performed by the PF_PACKET framework is to make sure that
+skb->len fits the interface's MTU.
+
+Unfortunately, because the etas_es58x driver does not populate its
+net_device_ops->ndo_change_mtu(), it is possible for an attacker to
+configure an invalid MTU by doing, for example:
+
+ $ ip link set can0 mtu 9999
+
+After doing so, the attacker could open a PF_PACKET socket using the
+ETH_P_CANXL protocol:
+
+ socket(PF_PACKET, SOCK_RAW, htons(ETH_P_CANXL));
+
+to inject a malicious CAN XL frames. For example:
+
+ struct canxl_frame frame = {
+ .flags = 0xff,
+ .len = 2048,
+ };
+
+The CAN drivers' xmit() function are calling can_dev_dropped_skb() to
+check that the skb is valid, unfortunately under above conditions, the
+malicious packet is able to go through can_dev_dropped_skb() checks:
+
+ 1. the skb->protocol is set to ETH_P_CANXL which is valid (the
+ function does not check the actual device capabilities).
+
+ 2. the length is a valid CAN XL length.
+
+And so, es58x_start_xmit() receives a CAN XL frame which it is not
+able to correctly handle and will thus misinterpret it as a CAN(FD)
+frame.
+
+This can result in a buffer overflow. For example, using the es581.4
+variant, the frame will be dispatched to es581_4_tx_can_msg(), go
+through the last check at the beginning of this function:
+
+ if (can_is_canfd_skb(skb))
+ return -EMSGSIZE;
+
+and reach this line:
+
+ memcpy(tx_can_msg->data, cf->data, cf->len);
+
+Here, cf->len corresponds to the flags field of the CAN XL frame. In
+our previous example, we set canxl_frame->flags to 0xff. Because the
+maximum expected length is 8, a buffer overflow of 247 bytes occurs!
+
+Populate net_device_ops->ndo_change_mtu() to ensure that the
+interface's MTU can not be set to anything bigger than CAN_MTU or
+CANFD_MTU (depending on the device capabilities). By fixing the root
+cause, this prevents the buffer overflow.
+
+Fixes: 8537257874e9 ("can: etas_es58x: add core support for ETAS ES58X CAN USB interfaces")
+Signed-off-by: Vincent Mailhol <mailhol@kernel.org>
+Link: https://patch.msgid.link/20250918-can-fix-mtu-v1-1-0d1cada9393b@kernel.org
+Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/can/usb/etas_es58x/es58x_core.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+diff --git a/drivers/net/can/usb/etas_es58x/es58x_core.c b/drivers/net/can/usb/etas_es58x/es58x_core.c
+index b6ee532977734..a8273ad5dd9e0 100644
+--- a/drivers/net/can/usb/etas_es58x/es58x_core.c
++++ b/drivers/net/can/usb/etas_es58x/es58x_core.c
+@@ -7,7 +7,7 @@
+ *
+ * Copyright (c) 2019 Robert Bosch Engineering and Business Solutions. All rights reserved.
+ * Copyright (c) 2020 ETAS K.K.. All rights reserved.
+- * Copyright (c) 2020-2022 Vincent Mailhol <mailhol.vincent@wanadoo.fr>
++ * Copyright (c) 2020-2025 Vincent Mailhol <mailhol@kernel.org>
+ */
+
+ #include <asm/unaligned.h>
+@@ -1984,6 +1984,7 @@ static const struct net_device_ops es58x_netdev_ops = {
+ .ndo_stop = es58x_stop,
+ .ndo_start_xmit = es58x_start_xmit,
+ .ndo_eth_ioctl = can_eth_ioctl_hwts,
++ .ndo_change_mtu = can_change_mtu,
+ };
+
+ static const struct ethtool_ops es58x_ethtool_ops = {
+--
+2.51.0
+
--- /dev/null
+From ca6f40b05e83fcaa8d4f9538c652a68874728137 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Sun, 27 Nov 2022 01:05:25 +0900
+Subject: can: etas_es58x: sort the includes by alphabetic order
+
+From: Vincent Mailhol <mailhol.vincent@wanadoo.fr>
+
+[ Upstream commit 8fd9323ef7210b90d1d209dd4f0d65a8411b60e1 ]
+
+Follow the best practices, reorder the includes.
+
+While doing so, bump up copyright year of each modified files.
+
+Signed-off-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr>
+Link: https://lore.kernel.org/all/20221126160525.87036-1-mailhol.vincent@wanadoo.fr
+Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
+Stable-dep-of: 38c0abad45b1 ("can: etas_es58x: populate ndo_change_mtu() to prevent buffer overflow")
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/can/usb/etas_es58x/es581_4.c | 4 ++--
+ drivers/net/can/usb/etas_es58x/es58x_core.c | 6 +++---
+ drivers/net/can/usb/etas_es58x/es58x_core.h | 8 ++++----
+ drivers/net/can/usb/etas_es58x/es58x_fd.c | 4 ++--
+ 4 files changed, 11 insertions(+), 11 deletions(-)
+
+diff --git a/drivers/net/can/usb/etas_es58x/es581_4.c b/drivers/net/can/usb/etas_es58x/es581_4.c
+index 1bcdcece5ec72..4151b18fd045d 100644
+--- a/drivers/net/can/usb/etas_es58x/es581_4.c
++++ b/drivers/net/can/usb/etas_es58x/es581_4.c
+@@ -6,12 +6,12 @@
+ *
+ * Copyright (c) 2019 Robert Bosch Engineering and Business Solutions. All rights reserved.
+ * Copyright (c) 2020 ETAS K.K.. All rights reserved.
+- * Copyright (c) 2020, 2021 Vincent Mailhol <mailhol.vincent@wanadoo.fr>
++ * Copyright (c) 2020-2022 Vincent Mailhol <mailhol.vincent@wanadoo.fr>
+ */
+
++#include <asm/unaligned.h>
+ #include <linux/kernel.h>
+ #include <linux/units.h>
+-#include <asm/unaligned.h>
+
+ #include "es58x_core.h"
+ #include "es581_4.h"
+diff --git a/drivers/net/can/usb/etas_es58x/es58x_core.c b/drivers/net/can/usb/etas_es58x/es58x_core.c
+index 0c0e2363f674b..b6ee532977734 100644
+--- a/drivers/net/can/usb/etas_es58x/es58x_core.c
++++ b/drivers/net/can/usb/etas_es58x/es58x_core.c
+@@ -7,15 +7,15 @@
+ *
+ * Copyright (c) 2019 Robert Bosch Engineering and Business Solutions. All rights reserved.
+ * Copyright (c) 2020 ETAS K.K.. All rights reserved.
+- * Copyright (c) 2020, 2021 Vincent Mailhol <mailhol.vincent@wanadoo.fr>
++ * Copyright (c) 2020-2022 Vincent Mailhol <mailhol.vincent@wanadoo.fr>
+ */
+
++#include <asm/unaligned.h>
++#include <linux/crc16.h>
+ #include <linux/ethtool.h>
+ #include <linux/kernel.h>
+ #include <linux/module.h>
+ #include <linux/usb.h>
+-#include <linux/crc16.h>
+-#include <asm/unaligned.h>
+
+ #include "es58x_core.h"
+
+diff --git a/drivers/net/can/usb/etas_es58x/es58x_core.h b/drivers/net/can/usb/etas_es58x/es58x_core.h
+index e5033cb5e6959..3d4fd068c8faf 100644
+--- a/drivers/net/can/usb/etas_es58x/es58x_core.h
++++ b/drivers/net/can/usb/etas_es58x/es58x_core.h
+@@ -6,17 +6,17 @@
+ *
+ * Copyright (c) 2019 Robert Bosch Engineering and Business Solutions. All rights reserved.
+ * Copyright (c) 2020 ETAS K.K.. All rights reserved.
+- * Copyright (c) 2020, 2021 Vincent Mailhol <mailhol.vincent@wanadoo.fr>
++ * Copyright (c) 2020-2022 Vincent Mailhol <mailhol.vincent@wanadoo.fr>
+ */
+
+ #ifndef __ES58X_COMMON_H__
+ #define __ES58X_COMMON_H__
+
+-#include <linux/types.h>
+-#include <linux/usb.h>
+-#include <linux/netdevice.h>
+ #include <linux/can.h>
+ #include <linux/can/dev.h>
++#include <linux/netdevice.h>
++#include <linux/types.h>
++#include <linux/usb.h>
+
+ #include "es581_4.h"
+ #include "es58x_fd.h"
+diff --git a/drivers/net/can/usb/etas_es58x/es58x_fd.c b/drivers/net/can/usb/etas_es58x/es58x_fd.c
+index 8ccda748fd084..3693851b36008 100644
+--- a/drivers/net/can/usb/etas_es58x/es58x_fd.c
++++ b/drivers/net/can/usb/etas_es58x/es58x_fd.c
+@@ -8,12 +8,12 @@
+ *
+ * Copyright (c) 2019 Robert Bosch Engineering and Business Solutions. All rights reserved.
+ * Copyright (c) 2020 ETAS K.K.. All rights reserved.
+- * Copyright (c) 2020, 2021 Vincent Mailhol <mailhol.vincent@wanadoo.fr>
++ * Copyright (c) 2020-2022 Vincent Mailhol <mailhol.vincent@wanadoo.fr>
+ */
+
++#include <asm/unaligned.h>
+ #include <linux/kernel.h>
+ #include <linux/units.h>
+-#include <asm/unaligned.h>
+
+ #include "es58x_core.h"
+ #include "es58x_fd.h"
+--
+2.51.0
+
--- /dev/null
+From dcd40c91e5fd1f67a86ed612b03b51ee91b58dbd Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 18 Sep 2025 18:00:25 +0900
+Subject: can: hi311x: populate ndo_change_mtu() to prevent buffer overflow
+
+From: Vincent Mailhol <mailhol@kernel.org>
+
+[ Upstream commit ac1c7656fa717f29fac3ea073af63f0b9919ec9a ]
+
+Sending an PF_PACKET allows to bypass the CAN framework logic and to
+directly reach the xmit() function of a CAN driver. The only check
+which is performed by the PF_PACKET framework is to make sure that
+skb->len fits the interface's MTU.
+
+Unfortunately, because the sun4i_can driver does not populate its
+net_device_ops->ndo_change_mtu(), it is possible for an attacker to
+configure an invalid MTU by doing, for example:
+
+ $ ip link set can0 mtu 9999
+
+After doing so, the attacker could open a PF_PACKET socket using the
+ETH_P_CANXL protocol:
+
+ socket(PF_PACKET, SOCK_RAW, htons(ETH_P_CANXL))
+
+to inject a malicious CAN XL frames. For example:
+
+ struct canxl_frame frame = {
+ .flags = 0xff,
+ .len = 2048,
+ };
+
+The CAN drivers' xmit() function are calling can_dev_dropped_skb() to
+check that the skb is valid, unfortunately under above conditions, the
+malicious packet is able to go through can_dev_dropped_skb() checks:
+
+ 1. the skb->protocol is set to ETH_P_CANXL which is valid (the
+ function does not check the actual device capabilities).
+
+ 2. the length is a valid CAN XL length.
+
+And so, hi3110_hard_start_xmit() receives a CAN XL frame which it is
+not able to correctly handle and will thus misinterpret it as a CAN
+frame. The driver will consume frame->len as-is with no further
+checks.
+
+This can result in a buffer overflow later on in hi3110_hw_tx() on
+this line:
+
+ memcpy(buf + HI3110_FIFO_EXT_DATA_OFF,
+ frame->data, frame->len);
+
+Here, frame->len corresponds to the flags field of the CAN XL frame.
+In our previous example, we set canxl_frame->flags to 0xff. Because
+the maximum expected length is 8, a buffer overflow of 247 bytes
+occurs!
+
+Populate net_device_ops->ndo_change_mtu() to ensure that the
+interface's MTU can not be set to anything bigger than CAN_MTU. By
+fixing the root cause, this prevents the buffer overflow.
+
+Fixes: 57e83fb9b746 ("can: hi311x: Add Holt HI-311x CAN driver")
+Signed-off-by: Vincent Mailhol <mailhol@kernel.org>
+Link: https://patch.msgid.link/20250918-can-fix-mtu-v1-2-0d1cada9393b@kernel.org
+Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/can/spi/hi311x.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/drivers/net/can/spi/hi311x.c b/drivers/net/can/spi/hi311x.c
+index b08b98e6ad1c9..6df2e6fae2687 100644
+--- a/drivers/net/can/spi/hi311x.c
++++ b/drivers/net/can/spi/hi311x.c
+@@ -807,6 +807,7 @@ static const struct net_device_ops hi3110_netdev_ops = {
+ .ndo_open = hi3110_open,
+ .ndo_stop = hi3110_stop,
+ .ndo_start_xmit = hi3110_hard_start_xmit,
++ .ndo_change_mtu = can_change_mtu,
+ };
+
+ static const struct of_device_id hi3110_of_match[] = {
+--
+2.51.0
+
--- /dev/null
+From 424c805717cc85f63de9184eeccc5f825ebda262 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 18 Sep 2025 18:00:27 +0900
+Subject: can: mcba_usb: populate ndo_change_mtu() to prevent buffer overflow
+
+From: Vincent Mailhol <mailhol@kernel.org>
+
+[ Upstream commit 17c8d794527f01def0d1c8b7dc2d7b8d34fed0e6 ]
+
+Sending an PF_PACKET allows to bypass the CAN framework logic and to
+directly reach the xmit() function of a CAN driver. The only check
+which is performed by the PF_PACKET framework is to make sure that
+skb->len fits the interface's MTU.
+
+Unfortunately, because the mcba_usb driver does not populate its
+net_device_ops->ndo_change_mtu(), it is possible for an attacker to
+configure an invalid MTU by doing, for example:
+
+ $ ip link set can0 mtu 9999
+
+After doing so, the attacker could open a PF_PACKET socket using the
+ETH_P_CANXL protocol:
+
+ socket(PF_PACKET, SOCK_RAW, htons(ETH_P_CANXL))
+
+to inject a malicious CAN XL frames. For example:
+
+ struct canxl_frame frame = {
+ .flags = 0xff,
+ .len = 2048,
+ };
+
+The CAN drivers' xmit() function are calling can_dev_dropped_skb() to
+check that the skb is valid, unfortunately under above conditions, the
+malicious packet is able to go through can_dev_dropped_skb() checks:
+
+ 1. the skb->protocol is set to ETH_P_CANXL which is valid (the
+ function does not check the actual device capabilities).
+
+ 2. the length is a valid CAN XL length.
+
+And so, mcba_usb_start_xmit() receives a CAN XL frame which it is not
+able to correctly handle and will thus misinterpret it as a CAN frame.
+
+This can result in a buffer overflow. The driver will consume cf->len
+as-is with no further checks on these lines:
+
+ usb_msg.dlc = cf->len;
+
+ memcpy(usb_msg.data, cf->data, usb_msg.dlc);
+
+Here, cf->len corresponds to the flags field of the CAN XL frame. In
+our previous example, we set canxl_frame->flags to 0xff. Because the
+maximum expected length is 8, a buffer overflow of 247 bytes occurs!
+
+Populate net_device_ops->ndo_change_mtu() to ensure that the
+interface's MTU can not be set to anything bigger than CAN_MTU. By
+fixing the root cause, this prevents the buffer overflow.
+
+Fixes: 51f3baad7de9 ("can: mcba_usb: Add support for Microchip CAN BUS Analyzer")
+Signed-off-by: Vincent Mailhol <mailhol@kernel.org>
+Link: https://patch.msgid.link/20250918-can-fix-mtu-v1-4-0d1cada9393b@kernel.org
+Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/can/usb/mcba_usb.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/drivers/net/can/usb/mcba_usb.c b/drivers/net/can/usb/mcba_usb.c
+index e9ccdcce01cc3..50e1a67661c3e 100644
+--- a/drivers/net/can/usb/mcba_usb.c
++++ b/drivers/net/can/usb/mcba_usb.c
+@@ -769,6 +769,7 @@ static const struct net_device_ops mcba_netdev_ops = {
+ .ndo_open = mcba_usb_open,
+ .ndo_stop = mcba_usb_close,
+ .ndo_start_xmit = mcba_usb_start_xmit,
++ .ndo_change_mtu = can_change_mtu,
+ };
+
+ /* Microchip CANBUS has hardcoded bittiming values by default.
+--
+2.51.0
+
--- /dev/null
+From 17b80caa7c883efe8dc8c40bd8478043b9f5aa10 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 18 Sep 2025 15:23:57 +0200
+Subject: can: peak_usb: fix shift-out-of-bounds issue
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Stéphane Grosjean <stephane.grosjean@hms-networks.com>
+
+[ Upstream commit c443be70aaee42c2d1d251e0329e0a69dd96ae54 ]
+
+Explicitly uses a 64-bit constant when the number of bits used for its
+shifting is 32 (which is the case for PC CAN FD interfaces supported by
+this driver).
+
+Signed-off-by: Stéphane Grosjean <stephane.grosjean@hms-networks.com>
+Link: https://patch.msgid.link/20250918132413.30071-1-stephane.grosjean@free.fr
+Reported-by: Marc Kleine-Budde <mkl@pengutronix.de>
+Closes: https://lore.kernel.org/20250917-aboriginal-refined-honeybee-82b1aa-mkl@pengutronix.de
+Fixes: bb4785551f64 ("can: usb: PEAK-System Technik USB adapters driver core")
+[mkl: update subject, apply manually]
+Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/can/usb/peak_usb/pcan_usb_core.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/drivers/net/can/usb/peak_usb/pcan_usb_core.c b/drivers/net/can/usb/peak_usb/pcan_usb_core.c
+index 6107fef9f4a03..11ca70173fb57 100644
+--- a/drivers/net/can/usb/peak_usb/pcan_usb_core.c
++++ b/drivers/net/can/usb/peak_usb/pcan_usb_core.c
+@@ -89,7 +89,7 @@ void peak_usb_update_ts_now(struct peak_time_ref *time_ref, u32 ts_now)
+ u32 delta_ts = time_ref->ts_dev_2 - time_ref->ts_dev_1;
+
+ if (time_ref->ts_dev_2 < time_ref->ts_dev_1)
+- delta_ts &= (1 << time_ref->adapter->ts_used_bits) - 1;
++ delta_ts &= (1ULL << time_ref->adapter->ts_used_bits) - 1;
+
+ time_ref->ts_total += delta_ts;
+ }
+--
+2.51.0
+
--- /dev/null
+From e371607d23494b8016c2fec497d57c0cde3e83f8 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 18 Sep 2025 18:00:26 +0900
+Subject: can: sun4i_can: populate ndo_change_mtu() to prevent buffer overflow
+
+From: Vincent Mailhol <mailhol@kernel.org>
+
+[ Upstream commit 61da0bd4102c459823fbe6b8b43b01fb6ace4a22 ]
+
+Sending an PF_PACKET allows to bypass the CAN framework logic and to
+directly reach the xmit() function of a CAN driver. The only check
+which is performed by the PF_PACKET framework is to make sure that
+skb->len fits the interface's MTU.
+
+Unfortunately, because the sun4i_can driver does not populate its
+net_device_ops->ndo_change_mtu(), it is possible for an attacker to
+configure an invalid MTU by doing, for example:
+
+ $ ip link set can0 mtu 9999
+
+After doing so, the attacker could open a PF_PACKET socket using the
+ETH_P_CANXL protocol:
+
+ socket(PF_PACKET, SOCK_RAW, htons(ETH_P_CANXL))
+
+to inject a malicious CAN XL frames. For example:
+
+ struct canxl_frame frame = {
+ .flags = 0xff,
+ .len = 2048,
+ };
+
+The CAN drivers' xmit() function are calling can_dev_dropped_skb() to
+check that the skb is valid, unfortunately under above conditions, the
+malicious packet is able to go through can_dev_dropped_skb() checks:
+
+ 1. the skb->protocol is set to ETH_P_CANXL which is valid (the
+ function does not check the actual device capabilities).
+
+ 2. the length is a valid CAN XL length.
+
+And so, sun4ican_start_xmit() receives a CAN XL frame which it is not
+able to correctly handle and will thus misinterpret it as a CAN frame.
+
+This can result in a buffer overflow. The driver will consume cf->len
+as-is with no further checks on this line:
+
+ dlc = cf->len;
+
+Here, cf->len corresponds to the flags field of the CAN XL frame. In
+our previous example, we set canxl_frame->flags to 0xff. Because the
+maximum expected length is 8, a buffer overflow of 247 bytes occurs a
+couple line below when doing:
+
+ for (i = 0; i < dlc; i++)
+ writel(cf->data[i], priv->base + (dreg + i * 4));
+
+Populate net_device_ops->ndo_change_mtu() to ensure that the
+interface's MTU can not be set to anything bigger than CAN_MTU. By
+fixing the root cause, this prevents the buffer overflow.
+
+Fixes: 0738eff14d81 ("can: Allwinner A10/A20 CAN Controller support - Kernel module")
+Signed-off-by: Vincent Mailhol <mailhol@kernel.org>
+Link: https://patch.msgid.link/20250918-can-fix-mtu-v1-3-0d1cada9393b@kernel.org
+Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/can/sun4i_can.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/drivers/net/can/sun4i_can.c b/drivers/net/can/sun4i_can.c
+index 3e5aa2e0ea66e..703389f5f0602 100644
+--- a/drivers/net/can/sun4i_can.c
++++ b/drivers/net/can/sun4i_can.c
+@@ -748,6 +748,7 @@ static const struct net_device_ops sun4ican_netdev_ops = {
+ .ndo_open = sun4ican_open,
+ .ndo_stop = sun4ican_close,
+ .ndo_start_xmit = sun4ican_start_xmit,
++ .ndo_change_mtu = can_change_mtu,
+ };
+
+ static const struct of_device_id sun4ican_of_match[] = {
+--
+2.51.0
+
--- /dev/null
+From 4af17035846a45642e3b180f8c0a348611cd1138 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 18 Sep 2025 17:21:07 +0200
+Subject: ethernet: rvu-af: Remove slash from the driver name
+
+From: Petr Malat <oss@malat.biz>
+
+[ Upstream commit b65678cacc030efd53c38c089fb9b741a2ee34c8 ]
+
+Having a slash in the driver name leads to EIO being returned while
+reading /sys/module/rvu_af/drivers content.
+
+Remove DRV_STRING as it's not used anywhere.
+
+Fixes: 91c6945ea1f9 ("octeontx2-af: cn10k: Add RPM MAC support")
+Signed-off-by: Petr Malat <oss@malat.biz>
+Reviewed-by: Simon Horman <horms@kernel.org>
+Link: https://patch.msgid.link/20250918152106.1798299-1-oss@malat.biz
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/ethernet/marvell/octeontx2/af/cgx.c | 3 +--
+ 1 file changed, 1 insertion(+), 2 deletions(-)
+
+diff --git a/drivers/net/ethernet/marvell/octeontx2/af/cgx.c b/drivers/net/ethernet/marvell/octeontx2/af/cgx.c
+index 4dec201158956..d97a4123438f0 100644
+--- a/drivers/net/ethernet/marvell/octeontx2/af/cgx.c
++++ b/drivers/net/ethernet/marvell/octeontx2/af/cgx.c
+@@ -21,8 +21,7 @@
+ #include "rvu.h"
+ #include "lmac_common.h"
+
+-#define DRV_NAME "Marvell-CGX/RPM"
+-#define DRV_STRING "Marvell CGX/RPM Driver"
++#define DRV_NAME "Marvell-CGX-RPM"
+
+ static LIST_HEAD(cgx_list);
+
+--
+2.51.0
+
--- /dev/null
+From dd2fafb3adb419dcfb75a5da4cfd00dbc979989e Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 11 Jun 2024 15:54:28 +0200
+Subject: net: dsa: lantiq_gswip: do also enable or disable cpu port
+
+From: Martin Schiller <ms@dev.tdt.de>
+
+[ Upstream commit 86b9ea6412af41914ef6549f85a849c3b987f4f3 ]
+
+Before commit 74be4babe72f ("net: dsa: do not enable or disable non user
+ports"), gswip_port_enable/disable() were also executed for the cpu port
+in gswip_setup() which disabled the cpu port during initialization.
+
+Let's restore this by removing the dsa_is_user_port checks. Also, let's
+clean up the gswip_port_enable() function so that we only have to check
+for the cpu port once. The operation reordering done here is safe.
+
+Signed-off-by: Martin Schiller <ms@dev.tdt.de>
+Acked-by: Hauke Mehrtens <hauke@hauke-m.de>
+Reviewed-by: Vladimir Oltean <olteanv@gmail.com>
+Link: https://lore.kernel.org/r/20240611135434.3180973-7-ms@dev.tdt.de
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Stable-dep-of: c0054b25e2f1 ("net: dsa: lantiq_gswip: move gswip_add_single_port_br() call to port_setup()")
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/dsa/lantiq_gswip.c | 24 ++++++++----------------
+ 1 file changed, 8 insertions(+), 16 deletions(-)
+
+diff --git a/drivers/net/dsa/lantiq_gswip.c b/drivers/net/dsa/lantiq_gswip.c
+index 2240a3d351225..f1ed7fff23e27 100644
+--- a/drivers/net/dsa/lantiq_gswip.c
++++ b/drivers/net/dsa/lantiq_gswip.c
+@@ -661,13 +661,18 @@ static int gswip_port_enable(struct dsa_switch *ds, int port,
+ struct gswip_priv *priv = ds->priv;
+ int err;
+
+- if (!dsa_is_user_port(ds, port))
+- return 0;
+-
+ if (!dsa_is_cpu_port(ds, port)) {
++ u32 mdio_phy = 0;
++
+ err = gswip_add_single_port_br(priv, port, true);
+ if (err)
+ return err;
++
++ if (phydev)
++ mdio_phy = phydev->mdio.addr & GSWIP_MDIO_PHY_ADDR_MASK;
++
++ gswip_mdio_mask(priv, GSWIP_MDIO_PHY_ADDR_MASK, mdio_phy,
++ GSWIP_MDIO_PHYp(port));
+ }
+
+ /* RMON Counter Enable for port */
+@@ -680,16 +685,6 @@ static int gswip_port_enable(struct dsa_switch *ds, int port,
+ gswip_switch_mask(priv, 0, GSWIP_SDMA_PCTRL_EN,
+ GSWIP_SDMA_PCTRLp(port));
+
+- if (!dsa_is_cpu_port(ds, port)) {
+- u32 mdio_phy = 0;
+-
+- if (phydev)
+- mdio_phy = phydev->mdio.addr & GSWIP_MDIO_PHY_ADDR_MASK;
+-
+- gswip_mdio_mask(priv, GSWIP_MDIO_PHY_ADDR_MASK, mdio_phy,
+- GSWIP_MDIO_PHYp(port));
+- }
+-
+ return 0;
+ }
+
+@@ -697,9 +692,6 @@ static void gswip_port_disable(struct dsa_switch *ds, int port)
+ {
+ struct gswip_priv *priv = ds->priv;
+
+- if (!dsa_is_user_port(ds, port))
+- return;
+-
+ gswip_switch_mask(priv, GSWIP_FDMA_PCTRL_EN, 0,
+ GSWIP_FDMA_PCTRLp(port));
+ gswip_switch_mask(priv, GSWIP_SDMA_PCTRL_EN, 0,
+--
+2.51.0
+
--- /dev/null
+From 0e301384564ba4d58e4cefaf7c6dc81c7dead8fc Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 18 Sep 2025 10:21:41 +0300
+Subject: net: dsa: lantiq_gswip: move gswip_add_single_port_br() call to
+ port_setup()
+
+From: Vladimir Oltean <vladimir.oltean@nxp.com>
+
+[ Upstream commit c0054b25e2f1045f47b4954cf13a539e5e6047df ]
+
+A port added to a "single port bridge" operates as standalone, and this
+is mutually exclusive to being part of a Linux bridge. In fact,
+gswip_port_bridge_join() calls gswip_add_single_port_br() with
+add=false, i.e. removes the port from the "single port bridge" to enable
+autonomous forwarding.
+
+The blamed commit seems to have incorrectly thought that ds->ops->port_enable()
+is called one time per port, during the setup phase of the switch.
+
+However, it is actually called during the ndo_open() implementation of
+DSA user ports, which is to say that this sequence of events:
+
+1. ip link set swp0 down
+2. ip link add br0 type bridge
+3. ip link set swp0 master br0
+4. ip link set swp0 up
+
+would cause swp0 to join back the "single port bridge" which step 3 had
+just removed it from.
+
+The correct DSA hook for one-time actions per port at switch init time
+is ds->ops->port_setup(). This is what seems to match the coder's
+intention; also see the comment at the beginning of the file:
+
+ * At the initialization the driver allocates one bridge table entry for
+ ~~~~~~~~~~~~~~~~~~~~~
+ * each switch port which is used when the port is used without an
+ * explicit bridge.
+
+Fixes: 8206e0ce96b3 ("net: dsa: lantiq: Add VLAN unaware bridge offloading")
+Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
+Link: https://patch.msgid.link/20250918072142.894692-2-vladimir.oltean@nxp.com
+Tested-by: Daniel Golle <daniel@makrotopia.org>
+Reviewed-by: Daniel Golle <daniel@makrotopia.org>
+Signed-off-by: Paolo Abeni <pabeni@redhat.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/dsa/lantiq_gswip.c | 18 ++++++++++++++----
+ 1 file changed, 14 insertions(+), 4 deletions(-)
+
+diff --git a/drivers/net/dsa/lantiq_gswip.c b/drivers/net/dsa/lantiq_gswip.c
+index f1ed7fff23e27..97d88c25fc992 100644
+--- a/drivers/net/dsa/lantiq_gswip.c
++++ b/drivers/net/dsa/lantiq_gswip.c
+@@ -655,18 +655,27 @@ static int gswip_add_single_port_br(struct gswip_priv *priv, int port, bool add)
+ return 0;
+ }
+
+-static int gswip_port_enable(struct dsa_switch *ds, int port,
+- struct phy_device *phydev)
++static int gswip_port_setup(struct dsa_switch *ds, int port)
+ {
+ struct gswip_priv *priv = ds->priv;
+ int err;
+
+ if (!dsa_is_cpu_port(ds, port)) {
+- u32 mdio_phy = 0;
+-
+ err = gswip_add_single_port_br(priv, port, true);
+ if (err)
+ return err;
++ }
++
++ return 0;
++}
++
++static int gswip_port_enable(struct dsa_switch *ds, int port,
++ struct phy_device *phydev)
++{
++ struct gswip_priv *priv = ds->priv;
++
++ if (!dsa_is_cpu_port(ds, port)) {
++ u32 mdio_phy = 0;
+
+ if (phydev)
+ mdio_phy = phydev->mdio.addr & GSWIP_MDIO_PHY_ADDR_MASK;
+@@ -1794,6 +1803,7 @@ static int gswip_get_sset_count(struct dsa_switch *ds, int port, int sset)
+ static const struct dsa_switch_ops gswip_xrx200_switch_ops = {
+ .get_tag_protocol = gswip_get_tag_protocol,
+ .setup = gswip_setup,
++ .port_setup = gswip_port_setup,
+ .port_enable = gswip_port_enable,
+ .port_disable = gswip_port_disable,
+ .port_bridge_join = gswip_port_bridge_join,
+--
+2.51.0
+
--- /dev/null
+From 61cea404401802b92ef2ba5366a712a2d6e8cda4 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 18 Sep 2025 10:21:42 +0300
+Subject: net: dsa: lantiq_gswip: suppress -EINVAL errors for bridge FDB
+ entries added to the CPU port
+
+From: Vladimir Oltean <vladimir.oltean@nxp.com>
+
+[ Upstream commit 987afe147965ef7a8e7d144ffef0d70af14bb1d4 ]
+
+The blamed commit and others in that patch set started the trend
+of reusing existing DSA driver API for a new purpose: calling
+ds->ops->port_fdb_add() on the CPU port.
+
+The lantiq_gswip driver was not prepared to handle that, as can be seen
+from the many errors that Daniel presents in the logs:
+
+[ 174.050000] gswip 1e108000.switch: port 2 failed to add fa:aa:72:f4:8b:1e vid 1 to fdb: -22
+[ 174.060000] gswip 1e108000.switch lan2: entered promiscuous mode
+[ 174.070000] gswip 1e108000.switch: port 2 failed to add 00:01:02:03:04:02 vid 0 to fdb: -22
+[ 174.090000] gswip 1e108000.switch: port 2 failed to add 00:01:02:03:04:02 vid 1 to fdb: -22
+[ 174.090000] gswip 1e108000.switch: port 2 failed to delete fa:aa:72:f4:8b:1e vid 1 from fdb: -2
+
+The errors are because gswip_port_fdb() wants to get a handle to the
+bridge that originated these FDB events, to associate it with a FID.
+Absolutely honourable purpose, however this only works for user ports.
+
+To get the bridge that generated an FDB entry for the CPU port, one
+would need to look at the db.bridge.dev argument. But this was
+introduced in commit c26933639b54 ("net: dsa: request drivers to perform
+FDB isolation"), first appeared in v5.18, and when the blamed commit was
+introduced in v5.14, no such API existed.
+
+So the core DSA feature was introduced way too soon for lantiq_gswip.
+Not acting on these host FDB entries and suppressing any errors has no
+other negative effect, and practically returns us to not supporting the
+host filtering feature at all - peacefully, this time.
+
+Fixes: 10fae4ac89ce ("net: dsa: include bridge addresses which are local in the host fdb list")
+Reported-by: Daniel Golle <daniel@makrotopia.org>
+Closes: https://lore.kernel.org/netdev/aJfNMLNoi1VOsPrN@pidgin.makrotopia.org/
+Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
+Link: https://patch.msgid.link/20250918072142.894692-3-vladimir.oltean@nxp.com
+Tested-by: Daniel Golle <daniel@makrotopia.org>
+Reviewed-by: Daniel Golle <daniel@makrotopia.org>
+Signed-off-by: Paolo Abeni <pabeni@redhat.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/dsa/lantiq_gswip.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+diff --git a/drivers/net/dsa/lantiq_gswip.c b/drivers/net/dsa/lantiq_gswip.c
+index 97d88c25fc992..c40fd7dd153e8 100644
+--- a/drivers/net/dsa/lantiq_gswip.c
++++ b/drivers/net/dsa/lantiq_gswip.c
+@@ -1337,8 +1337,9 @@ static int gswip_port_fdb(struct dsa_switch *ds, int port,
+ int i;
+ int err;
+
++ /* Operation not supported on the CPU port, don't throw errors */
+ if (!bridge)
+- return -EINVAL;
++ return 0;
+
+ for (i = cpu_port; i < ARRAY_SIZE(priv->vlans); i++) {
+ if (priv->vlans[i].bridge == bridge) {
+--
+2.51.0
+
--- /dev/null
+From f3cd7d4a16328bdf9b4964c5b2c19e4be28f423c Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Sun, 21 Sep 2025 18:08:22 +0300
+Subject: nexthop: Forbid FDB status change while nexthop is in a group
+
+From: Ido Schimmel <idosch@nvidia.com>
+
+[ Upstream commit 390b3a300d7872cef9588f003b204398be69ce08 ]
+
+The kernel forbids the creation of non-FDB nexthop groups with FDB
+nexthops:
+
+ # ip nexthop add id 1 via 192.0.2.1 fdb
+ # ip nexthop add id 2 group 1
+ Error: Non FDB nexthop group cannot have fdb nexthops.
+
+And vice versa:
+
+ # ip nexthop add id 3 via 192.0.2.2 dev dummy1
+ # ip nexthop add id 4 group 3 fdb
+ Error: FDB nexthop group can only have fdb nexthops.
+
+However, as long as no routes are pointing to a non-FDB nexthop group,
+the kernel allows changing the type of a nexthop from FDB to non-FDB and
+vice versa:
+
+ # ip nexthop add id 5 via 192.0.2.2 dev dummy1
+ # ip nexthop add id 6 group 5
+ # ip nexthop replace id 5 via 192.0.2.2 fdb
+ # echo $?
+ 0
+
+This configuration is invalid and can result in a NPD [1] since FDB
+nexthops are not associated with a nexthop device:
+
+ # ip route add 198.51.100.1/32 nhid 6
+ # ping 198.51.100.1
+
+Fix by preventing nexthop FDB status change while the nexthop is in a
+group:
+
+ # ip nexthop add id 7 via 192.0.2.2 dev dummy1
+ # ip nexthop add id 8 group 7
+ # ip nexthop replace id 7 via 192.0.2.2 fdb
+ Error: Cannot change nexthop FDB status while in a group.
+
+[1]
+BUG: kernel NULL pointer dereference, address: 00000000000003c0
+[...]
+Oops: Oops: 0000 [#1] SMP
+CPU: 6 UID: 0 PID: 367 Comm: ping Not tainted 6.17.0-rc6-virtme-gb65678cacc03 #1 PREEMPT(voluntary)
+Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-4.fc41 04/01/2014
+RIP: 0010:fib_lookup_good_nhc+0x1e/0x80
+[...]
+Call Trace:
+ <TASK>
+ fib_table_lookup+0x541/0x650
+ ip_route_output_key_hash_rcu+0x2ea/0x970
+ ip_route_output_key_hash+0x55/0x80
+ __ip4_datagram_connect+0x250/0x330
+ udp_connect+0x2b/0x60
+ __sys_connect+0x9c/0xd0
+ __x64_sys_connect+0x18/0x20
+ do_syscall_64+0xa4/0x2a0
+ entry_SYSCALL_64_after_hwframe+0x4b/0x53
+
+Fixes: 38428d68719c ("nexthop: support for fdb ecmp nexthops")
+Reported-by: syzbot+6596516dd2b635ba2350@syzkaller.appspotmail.com
+Closes: https://lore.kernel.org/netdev/68c9a4d2.050a0220.3c6139.0e63.GAE@google.com/
+Tested-by: syzbot+6596516dd2b635ba2350@syzkaller.appspotmail.com
+Signed-off-by: Ido Schimmel <idosch@nvidia.com>
+Reviewed-by: David Ahern <dsahern@kernel.org>
+Link: https://patch.msgid.link/20250921150824.149157-2-idosch@nvidia.com
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ net/ipv4/nexthop.c | 7 +++++++
+ 1 file changed, 7 insertions(+)
+
+diff --git a/net/ipv4/nexthop.c b/net/ipv4/nexthop.c
+index 633eab6ff55dd..4a8fdaae6bf21 100644
+--- a/net/ipv4/nexthop.c
++++ b/net/ipv4/nexthop.c
+@@ -2114,6 +2114,13 @@ static int replace_nexthop_single(struct net *net, struct nexthop *old,
+ return -EINVAL;
+ }
+
++ if (!list_empty(&old->grp_list) &&
++ rtnl_dereference(new->nh_info)->fdb_nh !=
++ rtnl_dereference(old->nh_info)->fdb_nh) {
++ NL_SET_ERR_MSG(extack, "Cannot change nexthop FDB status while in a group");
++ return -EINVAL;
++ }
++
+ err = call_nexthop_notifiers(net, NEXTHOP_EVENT_REPLACE, new, extack);
+ if (err)
+ return err;
+--
+2.51.0
+
--- /dev/null
+From 7007eb87e400f5e9473683f6357662929d682eba Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Sun, 21 Sep 2025 18:08:23 +0300
+Subject: selftests: fib_nexthops: Fix creation of non-FDB nexthops
+
+From: Ido Schimmel <idosch@nvidia.com>
+
+[ Upstream commit c29913109c70383cdf90b6fc792353e1009f24f5 ]
+
+The test creates non-FDB nexthops without a nexthop device which leads
+to the expected failure, but for the wrong reason:
+
+ # ./fib_nexthops.sh -t "ipv6_fdb_grp_fcnal ipv4_fdb_grp_fcnal" -v
+
+ IPv6 fdb groups functional
+ --------------------------
+ [...]
+ COMMAND: ip -netns me-nRsN3E nexthop add id 63 via 2001:db8:91::4
+ Error: Device attribute required for non-blackhole and non-fdb nexthops.
+ COMMAND: ip -netns me-nRsN3E nexthop add id 64 via 2001:db8:91::5
+ Error: Device attribute required for non-blackhole and non-fdb nexthops.
+ COMMAND: ip -netns me-nRsN3E nexthop add id 103 group 63/64 fdb
+ Error: Invalid nexthop id.
+ TEST: Fdb Nexthop group with non-fdb nexthops [ OK ]
+ [...]
+
+ IPv4 fdb groups functional
+ --------------------------
+ [...]
+ COMMAND: ip -netns me-nRsN3E nexthop add id 14 via 172.16.1.2
+ Error: Device attribute required for non-blackhole and non-fdb nexthops.
+ COMMAND: ip -netns me-nRsN3E nexthop add id 15 via 172.16.1.3
+ Error: Device attribute required for non-blackhole and non-fdb nexthops.
+ COMMAND: ip -netns me-nRsN3E nexthop add id 103 group 14/15 fdb
+ Error: Invalid nexthop id.
+ TEST: Fdb Nexthop group with non-fdb nexthops [ OK ]
+
+ COMMAND: ip -netns me-nRsN3E nexthop add id 16 via 172.16.1.2 fdb
+ COMMAND: ip -netns me-nRsN3E nexthop add id 17 via 172.16.1.3 fdb
+ COMMAND: ip -netns me-nRsN3E nexthop add id 104 group 14/15
+ Error: Invalid nexthop id.
+ TEST: Non-Fdb Nexthop group with fdb nexthops [ OK ]
+ [...]
+ COMMAND: ip -netns me-0dlhyd ro add 172.16.0.0/22 nhid 15
+ Error: Nexthop id does not exist.
+ TEST: Route add with fdb nexthop [ OK ]
+
+In addition, as can be seen in the above output, a couple of IPv4 test
+cases used the non-FDB nexthops (14 and 15) when they intended to use
+the FDB nexthops (16 and 17). These test cases only passed because
+failure was expected, but they failed for the wrong reason.
+
+Fix the test to create the non-FDB nexthops with a nexthop device and
+adjust the IPv4 test cases to use the FDB nexthops instead of the
+non-FDB nexthops.
+
+Output after the fix:
+
+ # ./fib_nexthops.sh -t "ipv6_fdb_grp_fcnal ipv4_fdb_grp_fcnal" -v
+
+ IPv6 fdb groups functional
+ --------------------------
+ [...]
+ COMMAND: ip -netns me-lNzfHP nexthop add id 63 via 2001:db8:91::4 dev veth1
+ COMMAND: ip -netns me-lNzfHP nexthop add id 64 via 2001:db8:91::5 dev veth1
+ COMMAND: ip -netns me-lNzfHP nexthop add id 103 group 63/64 fdb
+ Error: FDB nexthop group can only have fdb nexthops.
+ TEST: Fdb Nexthop group with non-fdb nexthops [ OK ]
+ [...]
+
+ IPv4 fdb groups functional
+ --------------------------
+ [...]
+ COMMAND: ip -netns me-lNzfHP nexthop add id 14 via 172.16.1.2 dev veth1
+ COMMAND: ip -netns me-lNzfHP nexthop add id 15 via 172.16.1.3 dev veth1
+ COMMAND: ip -netns me-lNzfHP nexthop add id 103 group 14/15 fdb
+ Error: FDB nexthop group can only have fdb nexthops.
+ TEST: Fdb Nexthop group with non-fdb nexthops [ OK ]
+
+ COMMAND: ip -netns me-lNzfHP nexthop add id 16 via 172.16.1.2 fdb
+ COMMAND: ip -netns me-lNzfHP nexthop add id 17 via 172.16.1.3 fdb
+ COMMAND: ip -netns me-lNzfHP nexthop add id 104 group 16/17
+ Error: Non FDB nexthop group cannot have fdb nexthops.
+ TEST: Non-Fdb Nexthop group with fdb nexthops [ OK ]
+ [...]
+ COMMAND: ip -netns me-lNzfHP ro add 172.16.0.0/22 nhid 16
+ Error: Route cannot point to a fdb nexthop.
+ TEST: Route add with fdb nexthop [ OK ]
+ [...]
+ Tests passed: 30
+ Tests failed: 0
+ Tests skipped: 0
+
+Fixes: 0534c5489c11 ("selftests: net: add fdb nexthop tests")
+Signed-off-by: Ido Schimmel <idosch@nvidia.com>
+Reviewed-by: David Ahern <dsahern@kernel.org>
+Link: https://patch.msgid.link/20250921150824.149157-3-idosch@nvidia.com
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ tools/testing/selftests/net/fib_nexthops.sh | 12 ++++++------
+ 1 file changed, 6 insertions(+), 6 deletions(-)
+
+diff --git a/tools/testing/selftests/net/fib_nexthops.sh b/tools/testing/selftests/net/fib_nexthops.sh
+index a194dbcb405ae..97c553182e0c5 100755
+--- a/tools/testing/selftests/net/fib_nexthops.sh
++++ b/tools/testing/selftests/net/fib_nexthops.sh
+@@ -440,8 +440,8 @@ ipv6_fdb_grp_fcnal()
+ log_test $? 0 "Get Fdb nexthop group by id"
+
+ # fdb nexthop group can only contain fdb nexthops
+- run_cmd "$IP nexthop add id 63 via 2001:db8:91::4"
+- run_cmd "$IP nexthop add id 64 via 2001:db8:91::5"
++ run_cmd "$IP nexthop add id 63 via 2001:db8:91::4 dev veth1"
++ run_cmd "$IP nexthop add id 64 via 2001:db8:91::5 dev veth1"
+ run_cmd "$IP nexthop add id 103 group 63/64 fdb"
+ log_test $? 2 "Fdb Nexthop group with non-fdb nexthops"
+
+@@ -520,15 +520,15 @@ ipv4_fdb_grp_fcnal()
+ log_test $? 0 "Get Fdb nexthop group by id"
+
+ # fdb nexthop group can only contain fdb nexthops
+- run_cmd "$IP nexthop add id 14 via 172.16.1.2"
+- run_cmd "$IP nexthop add id 15 via 172.16.1.3"
++ run_cmd "$IP nexthop add id 14 via 172.16.1.2 dev veth1"
++ run_cmd "$IP nexthop add id 15 via 172.16.1.3 dev veth1"
+ run_cmd "$IP nexthop add id 103 group 14/15 fdb"
+ log_test $? 2 "Fdb Nexthop group with non-fdb nexthops"
+
+ # Non fdb nexthop group can not contain fdb nexthops
+ run_cmd "$IP nexthop add id 16 via 172.16.1.2 fdb"
+ run_cmd "$IP nexthop add id 17 via 172.16.1.3 fdb"
+- run_cmd "$IP nexthop add id 104 group 14/15"
++ run_cmd "$IP nexthop add id 104 group 16/17"
+ log_test $? 2 "Non-Fdb Nexthop group with fdb nexthops"
+
+ # fdb nexthop cannot have blackhole
+@@ -555,7 +555,7 @@ ipv4_fdb_grp_fcnal()
+ run_cmd "$BRIDGE fdb add 02:02:00:00:00:14 dev vx10 nhid 12 self"
+ log_test $? 255 "Fdb mac add with nexthop"
+
+- run_cmd "$IP ro add 172.16.0.0/22 nhid 15"
++ run_cmd "$IP ro add 172.16.0.0/22 nhid 16"
+ log_test $? 2 "Route add with fdb nexthop"
+
+ run_cmd "$IP ro add 172.16.0.0/22 nhid 103"
+--
+2.51.0
+
cpufreq-initialize-cpufreq-based-invariance-before-s.patch
can-rcar_can-rcar_can_resume-fix-s2ram-with-psci.patch
bpf-reject-bpf_timer-for-preempt_rt.patch
+can-bittiming-allow-tdc-v-o-to-be-zero-and-add-can_t.patch
+can-bittiming-replace-can-units-with-the-generic-one.patch
+can-dev-add-generic-function-can_ethtool_op_get_ts_i.patch
+can-dev-add-generic-function-can_eth_ioctl_hwts.patch
+can-etas_es58x-advertise-timestamping-capabilities-a.patch
+can-etas_es58x-sort-the-includes-by-alphabetic-order.patch
+can-etas_es58x-populate-ndo_change_mtu-to-prevent-bu.patch
+can-hi311x-populate-ndo_change_mtu-to-prevent-buffer.patch
+can-sun4i_can-populate-ndo_change_mtu-to-prevent-buf.patch
+can-mcba_usb-populate-ndo_change_mtu-to-prevent-buff.patch
+can-peak_usb-fix-shift-out-of-bounds-issue.patch
+ethernet-rvu-af-remove-slash-from-the-driver-name.patch
+bnxt_en-correct-offset-handling-for-ipv6-destination.patch
+nexthop-forbid-fdb-status-change-while-nexthop-is-in.patch
+selftests-fib_nexthops-fix-creation-of-non-fdb-nexth.patch
+net-dsa-lantiq_gswip-do-also-enable-or-disable-cpu-p.patch
+net-dsa-lantiq_gswip-move-gswip_add_single_port_br-c.patch
+net-dsa-lantiq_gswip-suppress-einval-errors-for-brid.patch
--- /dev/null
+From 22ebebbcfec33f7b6fa049632722a46b1548fe03 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 18 Sep 2025 18:00:25 +0900
+Subject: can: hi311x: populate ndo_change_mtu() to prevent buffer overflow
+
+From: Vincent Mailhol <mailhol@kernel.org>
+
+[ Upstream commit ac1c7656fa717f29fac3ea073af63f0b9919ec9a ]
+
+Sending an PF_PACKET allows to bypass the CAN framework logic and to
+directly reach the xmit() function of a CAN driver. The only check
+which is performed by the PF_PACKET framework is to make sure that
+skb->len fits the interface's MTU.
+
+Unfortunately, because the sun4i_can driver does not populate its
+net_device_ops->ndo_change_mtu(), it is possible for an attacker to
+configure an invalid MTU by doing, for example:
+
+ $ ip link set can0 mtu 9999
+
+After doing so, the attacker could open a PF_PACKET socket using the
+ETH_P_CANXL protocol:
+
+ socket(PF_PACKET, SOCK_RAW, htons(ETH_P_CANXL))
+
+to inject a malicious CAN XL frames. For example:
+
+ struct canxl_frame frame = {
+ .flags = 0xff,
+ .len = 2048,
+ };
+
+The CAN drivers' xmit() function are calling can_dev_dropped_skb() to
+check that the skb is valid, unfortunately under above conditions, the
+malicious packet is able to go through can_dev_dropped_skb() checks:
+
+ 1. the skb->protocol is set to ETH_P_CANXL which is valid (the
+ function does not check the actual device capabilities).
+
+ 2. the length is a valid CAN XL length.
+
+And so, hi3110_hard_start_xmit() receives a CAN XL frame which it is
+not able to correctly handle and will thus misinterpret it as a CAN
+frame. The driver will consume frame->len as-is with no further
+checks.
+
+This can result in a buffer overflow later on in hi3110_hw_tx() on
+this line:
+
+ memcpy(buf + HI3110_FIFO_EXT_DATA_OFF,
+ frame->data, frame->len);
+
+Here, frame->len corresponds to the flags field of the CAN XL frame.
+In our previous example, we set canxl_frame->flags to 0xff. Because
+the maximum expected length is 8, a buffer overflow of 247 bytes
+occurs!
+
+Populate net_device_ops->ndo_change_mtu() to ensure that the
+interface's MTU can not be set to anything bigger than CAN_MTU. By
+fixing the root cause, this prevents the buffer overflow.
+
+Fixes: 57e83fb9b746 ("can: hi311x: Add Holt HI-311x CAN driver")
+Signed-off-by: Vincent Mailhol <mailhol@kernel.org>
+Link: https://patch.msgid.link/20250918-can-fix-mtu-v1-2-0d1cada9393b@kernel.org
+Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/can/spi/hi311x.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/drivers/net/can/spi/hi311x.c b/drivers/net/can/spi/hi311x.c
+index 28273e84171a2..a7d594a5ad36f 100644
+--- a/drivers/net/can/spi/hi311x.c
++++ b/drivers/net/can/spi/hi311x.c
+@@ -807,6 +807,7 @@ static const struct net_device_ops hi3110_netdev_ops = {
+ .ndo_open = hi3110_open,
+ .ndo_stop = hi3110_stop,
+ .ndo_start_xmit = hi3110_hard_start_xmit,
++ .ndo_change_mtu = can_change_mtu,
+ };
+
+ static const struct of_device_id hi3110_of_match[] = {
+--
+2.51.0
+
--- /dev/null
+From c8607413694ee364107dab1460aef9a43aca7262 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 18 Sep 2025 18:00:27 +0900
+Subject: can: mcba_usb: populate ndo_change_mtu() to prevent buffer overflow
+
+From: Vincent Mailhol <mailhol@kernel.org>
+
+[ Upstream commit 17c8d794527f01def0d1c8b7dc2d7b8d34fed0e6 ]
+
+Sending an PF_PACKET allows to bypass the CAN framework logic and to
+directly reach the xmit() function of a CAN driver. The only check
+which is performed by the PF_PACKET framework is to make sure that
+skb->len fits the interface's MTU.
+
+Unfortunately, because the mcba_usb driver does not populate its
+net_device_ops->ndo_change_mtu(), it is possible for an attacker to
+configure an invalid MTU by doing, for example:
+
+ $ ip link set can0 mtu 9999
+
+After doing so, the attacker could open a PF_PACKET socket using the
+ETH_P_CANXL protocol:
+
+ socket(PF_PACKET, SOCK_RAW, htons(ETH_P_CANXL))
+
+to inject a malicious CAN XL frames. For example:
+
+ struct canxl_frame frame = {
+ .flags = 0xff,
+ .len = 2048,
+ };
+
+The CAN drivers' xmit() function are calling can_dev_dropped_skb() to
+check that the skb is valid, unfortunately under above conditions, the
+malicious packet is able to go through can_dev_dropped_skb() checks:
+
+ 1. the skb->protocol is set to ETH_P_CANXL which is valid (the
+ function does not check the actual device capabilities).
+
+ 2. the length is a valid CAN XL length.
+
+And so, mcba_usb_start_xmit() receives a CAN XL frame which it is not
+able to correctly handle and will thus misinterpret it as a CAN frame.
+
+This can result in a buffer overflow. The driver will consume cf->len
+as-is with no further checks on these lines:
+
+ usb_msg.dlc = cf->len;
+
+ memcpy(usb_msg.data, cf->data, usb_msg.dlc);
+
+Here, cf->len corresponds to the flags field of the CAN XL frame. In
+our previous example, we set canxl_frame->flags to 0xff. Because the
+maximum expected length is 8, a buffer overflow of 247 bytes occurs!
+
+Populate net_device_ops->ndo_change_mtu() to ensure that the
+interface's MTU can not be set to anything bigger than CAN_MTU. By
+fixing the root cause, this prevents the buffer overflow.
+
+Fixes: 51f3baad7de9 ("can: mcba_usb: Add support for Microchip CAN BUS Analyzer")
+Signed-off-by: Vincent Mailhol <mailhol@kernel.org>
+Link: https://patch.msgid.link/20250918-can-fix-mtu-v1-4-0d1cada9393b@kernel.org
+Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/can/usb/mcba_usb.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/drivers/net/can/usb/mcba_usb.c b/drivers/net/can/usb/mcba_usb.c
+index 16fb4fc265183..e43bd02401a24 100644
+--- a/drivers/net/can/usb/mcba_usb.c
++++ b/drivers/net/can/usb/mcba_usb.c
+@@ -769,6 +769,7 @@ static const struct net_device_ops mcba_netdev_ops = {
+ .ndo_open = mcba_usb_open,
+ .ndo_stop = mcba_usb_close,
+ .ndo_start_xmit = mcba_usb_start_xmit,
++ .ndo_change_mtu = can_change_mtu,
+ };
+
+ /* Microchip CANBUS has hardcoded bittiming values by default.
+--
+2.51.0
+
--- /dev/null
+From 9bcaf6bdfb517533b6c70454f99aa3abde808756 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 18 Sep 2025 15:23:57 +0200
+Subject: can: peak_usb: fix shift-out-of-bounds issue
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Stéphane Grosjean <stephane.grosjean@hms-networks.com>
+
+[ Upstream commit c443be70aaee42c2d1d251e0329e0a69dd96ae54 ]
+
+Explicitly uses a 64-bit constant when the number of bits used for its
+shifting is 32 (which is the case for PC CAN FD interfaces supported by
+this driver).
+
+Signed-off-by: Stéphane Grosjean <stephane.grosjean@hms-networks.com>
+Link: https://patch.msgid.link/20250918132413.30071-1-stephane.grosjean@free.fr
+Reported-by: Marc Kleine-Budde <mkl@pengutronix.de>
+Closes: https://lore.kernel.org/20250917-aboriginal-refined-honeybee-82b1aa-mkl@pengutronix.de
+Fixes: bb4785551f64 ("can: usb: PEAK-System Technik USB adapters driver core")
+[mkl: update subject, apply manually]
+Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/can/usb/peak_usb/pcan_usb_core.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/drivers/net/can/usb/peak_usb/pcan_usb_core.c b/drivers/net/can/usb/peak_usb/pcan_usb_core.c
+index 4b18f37beb4c5..14e9b1052c5c6 100644
+--- a/drivers/net/can/usb/peak_usb/pcan_usb_core.c
++++ b/drivers/net/can/usb/peak_usb/pcan_usb_core.c
+@@ -84,7 +84,7 @@ void peak_usb_update_ts_now(struct peak_time_ref *time_ref, u32 ts_now)
+ u32 delta_ts = time_ref->ts_dev_2 - time_ref->ts_dev_1;
+
+ if (time_ref->ts_dev_2 < time_ref->ts_dev_1)
+- delta_ts &= (1 << time_ref->adapter->ts_used_bits) - 1;
++ delta_ts &= (1ULL << time_ref->adapter->ts_used_bits) - 1;
+
+ time_ref->ts_total += delta_ts;
+ }
+--
+2.51.0
+
--- /dev/null
+From 6b90562c45df50158ab1da33878a6fff1aa2b794 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 18 Sep 2025 18:00:26 +0900
+Subject: can: sun4i_can: populate ndo_change_mtu() to prevent buffer overflow
+
+From: Vincent Mailhol <mailhol@kernel.org>
+
+[ Upstream commit 61da0bd4102c459823fbe6b8b43b01fb6ace4a22 ]
+
+Sending an PF_PACKET allows to bypass the CAN framework logic and to
+directly reach the xmit() function of a CAN driver. The only check
+which is performed by the PF_PACKET framework is to make sure that
+skb->len fits the interface's MTU.
+
+Unfortunately, because the sun4i_can driver does not populate its
+net_device_ops->ndo_change_mtu(), it is possible for an attacker to
+configure an invalid MTU by doing, for example:
+
+ $ ip link set can0 mtu 9999
+
+After doing so, the attacker could open a PF_PACKET socket using the
+ETH_P_CANXL protocol:
+
+ socket(PF_PACKET, SOCK_RAW, htons(ETH_P_CANXL))
+
+to inject a malicious CAN XL frames. For example:
+
+ struct canxl_frame frame = {
+ .flags = 0xff,
+ .len = 2048,
+ };
+
+The CAN drivers' xmit() function are calling can_dev_dropped_skb() to
+check that the skb is valid, unfortunately under above conditions, the
+malicious packet is able to go through can_dev_dropped_skb() checks:
+
+ 1. the skb->protocol is set to ETH_P_CANXL which is valid (the
+ function does not check the actual device capabilities).
+
+ 2. the length is a valid CAN XL length.
+
+And so, sun4ican_start_xmit() receives a CAN XL frame which it is not
+able to correctly handle and will thus misinterpret it as a CAN frame.
+
+This can result in a buffer overflow. The driver will consume cf->len
+as-is with no further checks on this line:
+
+ dlc = cf->len;
+
+Here, cf->len corresponds to the flags field of the CAN XL frame. In
+our previous example, we set canxl_frame->flags to 0xff. Because the
+maximum expected length is 8, a buffer overflow of 247 bytes occurs a
+couple line below when doing:
+
+ for (i = 0; i < dlc; i++)
+ writel(cf->data[i], priv->base + (dreg + i * 4));
+
+Populate net_device_ops->ndo_change_mtu() to ensure that the
+interface's MTU can not be set to anything bigger than CAN_MTU. By
+fixing the root cause, this prevents the buffer overflow.
+
+Fixes: 0738eff14d81 ("can: Allwinner A10/A20 CAN Controller support - Kernel module")
+Signed-off-by: Vincent Mailhol <mailhol@kernel.org>
+Link: https://patch.msgid.link/20250918-can-fix-mtu-v1-3-0d1cada9393b@kernel.org
+Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/can/sun4i_can.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/drivers/net/can/sun4i_can.c b/drivers/net/can/sun4i_can.c
+index 0eddd5779e5a2..a1e151d373597 100644
+--- a/drivers/net/can/sun4i_can.c
++++ b/drivers/net/can/sun4i_can.c
+@@ -752,6 +752,7 @@ static const struct net_device_ops sun4ican_netdev_ops = {
+ .ndo_open = sun4ican_open,
+ .ndo_stop = sun4ican_close,
+ .ndo_start_xmit = sun4ican_start_xmit,
++ .ndo_change_mtu = can_change_mtu,
+ };
+
+ static const struct of_device_id sun4ican_of_match[] = {
+--
+2.51.0
+
usb-core-add-0x-prefix-to-quirks-debug-output.patch
ib-mlx5-fix-obj_type-mismatch-for-srq-event-subscrip.patch
can-rcar_can-rcar_can_resume-fix-s2ram-with-psci.patch
+can-hi311x-populate-ndo_change_mtu-to-prevent-buffer.patch
+can-sun4i_can-populate-ndo_change_mtu-to-prevent-buf.patch
+can-mcba_usb-populate-ndo_change_mtu-to-prevent-buff.patch
+can-peak_usb-fix-shift-out-of-bounds-issue.patch
--- /dev/null
+From 2fd2e764c7c8fc5b1e487203ba5bfd41922e998c Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Mon, 25 Aug 2025 11:10:20 -0400
+Subject: Bluetooth: hci_event: Fix UAF in hci_acl_create_conn_sync
+
+From: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
+
+[ Upstream commit 9e622804d57e2d08f0271200606bd1270f75126f ]
+
+This fixes the following UFA in hci_acl_create_conn_sync where a
+connection still pending is command submission (conn->state == BT_OPEN)
+maybe freed, also since this also can happen with the likes of
+hci_le_create_conn_sync fix it as well:
+
+BUG: KASAN: slab-use-after-free in hci_acl_create_conn_sync+0x5ef/0x790 net/bluetooth/hci_sync.c:6861
+Write of size 2 at addr ffff88805ffcc038 by task kworker/u11:2/9541
+
+CPU: 1 UID: 0 PID: 9541 Comm: kworker/u11:2 Not tainted 6.16.0-rc7 #3 PREEMPT(full)
+Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014
+Workqueue: hci3 hci_cmd_sync_work
+Call Trace:
+ <TASK>
+ dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120
+ print_address_description mm/kasan/report.c:378 [inline]
+ print_report+0xca/0x230 mm/kasan/report.c:480
+ kasan_report+0x118/0x150 mm/kasan/report.c:593
+ hci_acl_create_conn_sync+0x5ef/0x790 net/bluetooth/hci_sync.c:6861
+ hci_cmd_sync_work+0x210/0x3a0 net/bluetooth/hci_sync.c:332
+ process_one_work kernel/workqueue.c:3238 [inline]
+ process_scheduled_works+0xae1/0x17b0 kernel/workqueue.c:3321
+ worker_thread+0x8a0/0xda0 kernel/workqueue.c:3402
+ kthread+0x70e/0x8a0 kernel/kthread.c:464
+ ret_from_fork+0x3fc/0x770 arch/x86/kernel/process.c:148
+ ret_from_fork_asm+0x1a/0x30 home/kwqcheii/source/fuzzing/kernel/kasan/linux-6.16-rc7/arch/x86/entry/entry_64.S:245
+ </TASK>
+
+Allocated by task 123736:
+ kasan_save_stack mm/kasan/common.c:47 [inline]
+ kasan_save_track+0x3e/0x80 mm/kasan/common.c:68
+ poison_kmalloc_redzone mm/kasan/common.c:377 [inline]
+ __kasan_kmalloc+0x93/0xb0 mm/kasan/common.c:394
+ kasan_kmalloc include/linux/kasan.h:260 [inline]
+ __kmalloc_cache_noprof+0x230/0x3d0 mm/slub.c:4359
+ kmalloc_noprof include/linux/slab.h:905 [inline]
+ kzalloc_noprof include/linux/slab.h:1039 [inline]
+ __hci_conn_add+0x233/0x1b30 net/bluetooth/hci_conn.c:939
+ hci_conn_add_unset net/bluetooth/hci_conn.c:1051 [inline]
+ hci_connect_acl+0x16c/0x4e0 net/bluetooth/hci_conn.c:1634
+ pair_device+0x418/0xa70 net/bluetooth/mgmt.c:3556
+ hci_mgmt_cmd+0x9c9/0xef0 net/bluetooth/hci_sock.c:1719
+ hci_sock_sendmsg+0x6ca/0xef0 net/bluetooth/hci_sock.c:1839
+ sock_sendmsg_nosec net/socket.c:712 [inline]
+ __sock_sendmsg+0x219/0x270 net/socket.c:727
+ sock_write_iter+0x258/0x330 net/socket.c:1131
+ new_sync_write fs/read_write.c:593 [inline]
+ vfs_write+0x54b/0xa90 fs/read_write.c:686
+ ksys_write+0x145/0x250 fs/read_write.c:738
+ do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
+ do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94
+ entry_SYSCALL_64_after_hwframe+0x77/0x7f
+
+Freed by task 103680:
+ kasan_save_stack mm/kasan/common.c:47 [inline]
+ kasan_save_track+0x3e/0x80 mm/kasan/common.c:68
+ kasan_save_free_info+0x46/0x50 mm/kasan/generic.c:576
+ poison_slab_object mm/kasan/common.c:247 [inline]
+ __kasan_slab_free+0x62/0x70 mm/kasan/common.c:264
+ kasan_slab_free include/linux/kasan.h:233 [inline]
+ slab_free_hook mm/slub.c:2381 [inline]
+ slab_free mm/slub.c:4643 [inline]
+ kfree+0x18e/0x440 mm/slub.c:4842
+ device_release+0x9c/0x1c0
+ kobject_cleanup lib/kobject.c:689 [inline]
+ kobject_release lib/kobject.c:720 [inline]
+ kref_put include/linux/kref.h:65 [inline]
+ kobject_put+0x22b/0x480 lib/kobject.c:737
+ hci_conn_cleanup net/bluetooth/hci_conn.c:175 [inline]
+ hci_conn_del+0x8ff/0xcb0 net/bluetooth/hci_conn.c:1173
+ hci_conn_complete_evt+0x3c7/0x1040 net/bluetooth/hci_event.c:3199
+ hci_event_func net/bluetooth/hci_event.c:7477 [inline]
+ hci_event_packet+0x7e0/0x1200 net/bluetooth/hci_event.c:7531
+ hci_rx_work+0x46a/0xe80 net/bluetooth/hci_core.c:4070
+ process_one_work kernel/workqueue.c:3238 [inline]
+ process_scheduled_works+0xae1/0x17b0 kernel/workqueue.c:3321
+ worker_thread+0x8a0/0xda0 kernel/workqueue.c:3402
+ kthread+0x70e/0x8a0 kernel/kthread.c:464
+ ret_from_fork+0x3fc/0x770 arch/x86/kernel/process.c:148
+ ret_from_fork_asm+0x1a/0x30 home/kwqcheii/source/fuzzing/kernel/kasan/linux-6.16-rc7/arch/x86/entry/entry_64.S:245
+
+Last potentially related work creation:
+ kasan_save_stack+0x3e/0x60 mm/kasan/common.c:47
+ kasan_record_aux_stack+0xbd/0xd0 mm/kasan/generic.c:548
+ insert_work+0x3d/0x330 kernel/workqueue.c:2183
+ __queue_work+0xbd9/0xfe0 kernel/workqueue.c:2345
+ queue_delayed_work_on+0x18b/0x280 kernel/workqueue.c:2561
+ pairing_complete+0x1e7/0x2b0 net/bluetooth/mgmt.c:3451
+ pairing_complete_cb+0x1ac/0x230 net/bluetooth/mgmt.c:3487
+ hci_connect_cfm include/net/bluetooth/hci_core.h:2064 [inline]
+ hci_conn_failed+0x24d/0x310 net/bluetooth/hci_conn.c:1275
+ hci_conn_complete_evt+0x3c7/0x1040 net/bluetooth/hci_event.c:3199
+ hci_event_func net/bluetooth/hci_event.c:7477 [inline]
+ hci_event_packet+0x7e0/0x1200 net/bluetooth/hci_event.c:7531
+ hci_rx_work+0x46a/0xe80 net/bluetooth/hci_core.c:4070
+ process_one_work kernel/workqueue.c:3238 [inline]
+ process_scheduled_works+0xae1/0x17b0 kernel/workqueue.c:3321
+ worker_thread+0x8a0/0xda0 kernel/workqueue.c:3402
+ kthread+0x70e/0x8a0 kernel/kthread.c:464
+ ret_from_fork+0x3fc/0x770 arch/x86/kernel/process.c:148
+ ret_from_fork_asm+0x1a/0x30 home/kwqcheii/source/fuzzing/kernel/kasan/linux-6.16-rc7/arch/x86/entry/entry_64.S:245
+
+Fixes: aef2aa4fa98e ("Bluetooth: hci_event: Fix creating hci_conn object on error status")
+Reported-by: Junvyyang, Tencent Zhuque Lab <zhuque@tencent.com>
+Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ include/net/bluetooth/hci_core.h | 21 +++++++++++++++++++++
+ net/bluetooth/hci_event.c | 26 +++++++++++++++++++++++---
+ 2 files changed, 44 insertions(+), 3 deletions(-)
+
+diff --git a/include/net/bluetooth/hci_core.h b/include/net/bluetooth/hci_core.h
+index 97cde23f56ecd..4a1faf11785f4 100644
+--- a/include/net/bluetooth/hci_core.h
++++ b/include/net/bluetooth/hci_core.h
+@@ -1140,6 +1140,27 @@ static inline struct hci_conn *hci_conn_hash_lookup_ba(struct hci_dev *hdev,
+ return NULL;
+ }
+
++static inline struct hci_conn *hci_conn_hash_lookup_role(struct hci_dev *hdev,
++ __u8 type, __u8 role,
++ bdaddr_t *ba)
++{
++ struct hci_conn_hash *h = &hdev->conn_hash;
++ struct hci_conn *c;
++
++ rcu_read_lock();
++
++ list_for_each_entry_rcu(c, &h->list, list) {
++ if (c->type == type && c->role == role && !bacmp(&c->dst, ba)) {
++ rcu_read_unlock();
++ return c;
++ }
++ }
++
++ rcu_read_unlock();
++
++ return NULL;
++}
++
+ static inline struct hci_conn *hci_conn_hash_lookup_le(struct hci_dev *hdev,
+ bdaddr_t *ba,
+ __u8 ba_type)
+diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c
+index 3d81afcccff8b..a0ce0a1e3258e 100644
+--- a/net/bluetooth/hci_event.c
++++ b/net/bluetooth/hci_event.c
+@@ -3125,8 +3125,18 @@ static void hci_conn_complete_evt(struct hci_dev *hdev, void *data,
+
+ hci_dev_lock(hdev);
+
++ /* Check for existing connection:
++ *
++ * 1. If it doesn't exist then it must be receiver/slave role.
++ * 2. If it does exist confirm that it is connecting/BT_CONNECT in case
++ * of initiator/master role since there could be a collision where
++ * either side is attempting to connect or something like a fuzzing
++ * testing is trying to play tricks to destroy the hcon object before
++ * it even attempts to connect (e.g. hcon->state == BT_OPEN).
++ */
+ conn = hci_conn_hash_lookup_ba(hdev, ev->link_type, &ev->bdaddr);
+- if (!conn) {
++ if (!conn ||
++ (conn->role == HCI_ROLE_MASTER && conn->state != BT_CONNECT)) {
+ /* In case of error status and there is no connection pending
+ * just unlock as there is nothing to cleanup.
+ */
+@@ -5706,8 +5716,18 @@ static void le_conn_complete_evt(struct hci_dev *hdev, u8 status,
+ */
+ hci_dev_clear_flag(hdev, HCI_LE_ADV);
+
+- conn = hci_conn_hash_lookup_ba(hdev, LE_LINK, bdaddr);
+- if (!conn) {
++ /* Check for existing connection:
++ *
++ * 1. If it doesn't exist then use the role to create a new object.
++ * 2. If it does exist confirm that it is connecting/BT_CONNECT in case
++ * of initiator/master role since there could be a collision where
++ * either side is attempting to connect or something like a fuzzing
++ * testing is trying to play tricks to destroy the hcon object before
++ * it even attempts to connect (e.g. hcon->state == BT_OPEN).
++ */
++ conn = hci_conn_hash_lookup_role(hdev, LE_LINK, role, bdaddr);
++ if (!conn ||
++ (conn->role == HCI_ROLE_MASTER && conn->state != BT_CONNECT)) {
+ /* In case of error status and there is no connection pending
+ * just unlock as there is nothing to cleanup.
+ */
+--
+2.51.0
+
--- /dev/null
+From bbce37af004ee9478b66fb32695533e239dedd96 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 5 Sep 2025 10:29:18 -0400
+Subject: Bluetooth: hci_sync: Fix hci_resume_advertising_sync
+
+From: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
+
+[ Upstream commit 1488af7b8b5f9896ea88ee35aa3301713f72737c ]
+
+hci_resume_advertising_sync is suppose to resume all instance paused by
+hci_pause_advertising_sync, this logic is used for procedures are only
+allowed when not advertising, but instance 0x00 was not being
+re-enabled.
+
+Fixes: ad383c2c65a5 ("Bluetooth: hci_sync: Enable advertising when LL privacy is enabled")
+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 | 7 +++++++
+ 1 file changed, 7 insertions(+)
+
+diff --git a/net/bluetooth/hci_sync.c b/net/bluetooth/hci_sync.c
+index a2c3b58db54c2..4c1b2468989a8 100644
+--- a/net/bluetooth/hci_sync.c
++++ b/net/bluetooth/hci_sync.c
+@@ -2595,6 +2595,13 @@ static int hci_resume_advertising_sync(struct hci_dev *hdev)
+ hci_remove_ext_adv_instance_sync(hdev, adv->instance,
+ NULL);
+ }
++
++ /* If current advertising instance is set to instance 0x00
++ * then we need to re-enable it.
++ */
++ if (!hdev->cur_adv_instance)
++ err = hci_enable_ext_advertising_sync(hdev,
++ hdev->cur_adv_instance);
+ } else {
+ /* Schedule for most recent instance to be restarted and begin
+ * the software rotation loop
+--
+2.51.0
+
--- /dev/null
+From b8f6b9924181e51b90c01a8a4cc2925b16e7e098 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Sat, 20 Sep 2025 05:11:17 -0700
+Subject: bnxt_en: correct offset handling for IPv6 destination address
+
+From: Alok Tiwari <alok.a.tiwari@oracle.com>
+
+[ Upstream commit 3d3aa9472c6dd0704e9961ed4769caac5b1c8d52 ]
+
+In bnxt_tc_parse_pedit(), the code incorrectly writes IPv6
+destination values to the source address field (saddr) when
+processing pedit offsets within the destination address range.
+
+This patch corrects the assignment to use daddr instead of saddr,
+ensuring that pedit operations on IPv6 destination addresses are
+applied correctly.
+
+Fixes: 9b9eb518e338 ("bnxt_en: Add support for NAT(L3/L4 rewrite)")
+Signed-off-by: Alok Tiwari <alok.a.tiwari@oracle.com>
+Reviewed-by: Somnath Kotur <somnath.kotur@broadcom.com>
+Link: https://patch.msgid.link/20250920121157.351921-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/broadcom/bnxt/bnxt_tc.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt_tc.c b/drivers/net/ethernet/broadcom/bnxt/bnxt_tc.c
+index 4d6663ff84722..72677d140a888 100644
+--- a/drivers/net/ethernet/broadcom/bnxt/bnxt_tc.c
++++ b/drivers/net/ethernet/broadcom/bnxt/bnxt_tc.c
+@@ -244,7 +244,7 @@ bnxt_tc_parse_pedit(struct bnxt *bp, struct bnxt_tc_actions *actions,
+ offset < offset_of_ip6_daddr + 16) {
+ actions->nat.src_xlate = false;
+ idx = (offset - offset_of_ip6_daddr) / 4;
+- actions->nat.l3.ipv6.saddr.s6_addr32[idx] = htonl(val);
++ actions->nat.l3.ipv6.daddr.s6_addr32[idx] = htonl(val);
+ } else {
+ netdev_err(bp->dev,
+ "%s: IPv6_hdr: Invalid pedit field\n",
+--
+2.51.0
+
--- /dev/null
+From af28760a2bd3c0a0ae36947153007964faaa4c4b Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 18 Sep 2025 18:00:24 +0900
+Subject: can: etas_es58x: populate ndo_change_mtu() to prevent buffer overflow
+
+From: Vincent Mailhol <mailhol@kernel.org>
+
+[ Upstream commit 38c0abad45b190a30d8284a37264d2127a6ec303 ]
+
+Sending an PF_PACKET allows to bypass the CAN framework logic and to
+directly reach the xmit() function of a CAN driver. The only check
+which is performed by the PF_PACKET framework is to make sure that
+skb->len fits the interface's MTU.
+
+Unfortunately, because the etas_es58x driver does not populate its
+net_device_ops->ndo_change_mtu(), it is possible for an attacker to
+configure an invalid MTU by doing, for example:
+
+ $ ip link set can0 mtu 9999
+
+After doing so, the attacker could open a PF_PACKET socket using the
+ETH_P_CANXL protocol:
+
+ socket(PF_PACKET, SOCK_RAW, htons(ETH_P_CANXL));
+
+to inject a malicious CAN XL frames. For example:
+
+ struct canxl_frame frame = {
+ .flags = 0xff,
+ .len = 2048,
+ };
+
+The CAN drivers' xmit() function are calling can_dev_dropped_skb() to
+check that the skb is valid, unfortunately under above conditions, the
+malicious packet is able to go through can_dev_dropped_skb() checks:
+
+ 1. the skb->protocol is set to ETH_P_CANXL which is valid (the
+ function does not check the actual device capabilities).
+
+ 2. the length is a valid CAN XL length.
+
+And so, es58x_start_xmit() receives a CAN XL frame which it is not
+able to correctly handle and will thus misinterpret it as a CAN(FD)
+frame.
+
+This can result in a buffer overflow. For example, using the es581.4
+variant, the frame will be dispatched to es581_4_tx_can_msg(), go
+through the last check at the beginning of this function:
+
+ if (can_is_canfd_skb(skb))
+ return -EMSGSIZE;
+
+and reach this line:
+
+ memcpy(tx_can_msg->data, cf->data, cf->len);
+
+Here, cf->len corresponds to the flags field of the CAN XL frame. In
+our previous example, we set canxl_frame->flags to 0xff. Because the
+maximum expected length is 8, a buffer overflow of 247 bytes occurs!
+
+Populate net_device_ops->ndo_change_mtu() to ensure that the
+interface's MTU can not be set to anything bigger than CAN_MTU or
+CANFD_MTU (depending on the device capabilities). By fixing the root
+cause, this prevents the buffer overflow.
+
+Fixes: 8537257874e9 ("can: etas_es58x: add core support for ETAS ES58X CAN USB interfaces")
+Signed-off-by: Vincent Mailhol <mailhol@kernel.org>
+Link: https://patch.msgid.link/20250918-can-fix-mtu-v1-1-0d1cada9393b@kernel.org
+Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/can/usb/etas_es58x/es58x_core.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+diff --git a/drivers/net/can/usb/etas_es58x/es58x_core.c b/drivers/net/can/usb/etas_es58x/es58x_core.c
+index 5aba168496037..41bea531234db 100644
+--- a/drivers/net/can/usb/etas_es58x/es58x_core.c
++++ b/drivers/net/can/usb/etas_es58x/es58x_core.c
+@@ -7,7 +7,7 @@
+ *
+ * Copyright (c) 2019 Robert Bosch Engineering and Business Solutions. All rights reserved.
+ * Copyright (c) 2020 ETAS K.K.. All rights reserved.
+- * Copyright (c) 2020-2022 Vincent Mailhol <mailhol.vincent@wanadoo.fr>
++ * Copyright (c) 2020-2025 Vincent Mailhol <mailhol@kernel.org>
+ */
+
+ #include <asm/unaligned.h>
+@@ -1976,6 +1976,7 @@ static const struct net_device_ops es58x_netdev_ops = {
+ .ndo_stop = es58x_stop,
+ .ndo_start_xmit = es58x_start_xmit,
+ .ndo_eth_ioctl = can_eth_ioctl_hwts,
++ .ndo_change_mtu = can_change_mtu,
+ };
+
+ static const struct ethtool_ops es58x_ethtool_ops = {
+--
+2.51.0
+
--- /dev/null
+From 467f8f397356ad7b6b4916400ef8af77cf678395 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Sun, 27 Nov 2022 01:05:25 +0900
+Subject: can: etas_es58x: sort the includes by alphabetic order
+
+From: Vincent Mailhol <mailhol.vincent@wanadoo.fr>
+
+[ Upstream commit 8fd9323ef7210b90d1d209dd4f0d65a8411b60e1 ]
+
+Follow the best practices, reorder the includes.
+
+While doing so, bump up copyright year of each modified files.
+
+Signed-off-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr>
+Link: https://lore.kernel.org/all/20221126160525.87036-1-mailhol.vincent@wanadoo.fr
+Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
+Stable-dep-of: 38c0abad45b1 ("can: etas_es58x: populate ndo_change_mtu() to prevent buffer overflow")
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/can/usb/etas_es58x/es581_4.c | 4 ++--
+ drivers/net/can/usb/etas_es58x/es58x_core.c | 6 +++---
+ drivers/net/can/usb/etas_es58x/es58x_core.h | 8 ++++----
+ drivers/net/can/usb/etas_es58x/es58x_fd.c | 4 ++--
+ 4 files changed, 11 insertions(+), 11 deletions(-)
+
+diff --git a/drivers/net/can/usb/etas_es58x/es581_4.c b/drivers/net/can/usb/etas_es58x/es581_4.c
+index 1bcdcece5ec72..4151b18fd045d 100644
+--- a/drivers/net/can/usb/etas_es58x/es581_4.c
++++ b/drivers/net/can/usb/etas_es58x/es581_4.c
+@@ -6,12 +6,12 @@
+ *
+ * Copyright (c) 2019 Robert Bosch Engineering and Business Solutions. All rights reserved.
+ * Copyright (c) 2020 ETAS K.K.. All rights reserved.
+- * Copyright (c) 2020, 2021 Vincent Mailhol <mailhol.vincent@wanadoo.fr>
++ * Copyright (c) 2020-2022 Vincent Mailhol <mailhol.vincent@wanadoo.fr>
+ */
+
++#include <asm/unaligned.h>
+ #include <linux/kernel.h>
+ #include <linux/units.h>
+-#include <asm/unaligned.h>
+
+ #include "es58x_core.h"
+ #include "es581_4.h"
+diff --git a/drivers/net/can/usb/etas_es58x/es58x_core.c b/drivers/net/can/usb/etas_es58x/es58x_core.c
+index ddb7c5735c9ac..5aba168496037 100644
+--- a/drivers/net/can/usb/etas_es58x/es58x_core.c
++++ b/drivers/net/can/usb/etas_es58x/es58x_core.c
+@@ -7,15 +7,15 @@
+ *
+ * Copyright (c) 2019 Robert Bosch Engineering and Business Solutions. All rights reserved.
+ * Copyright (c) 2020 ETAS K.K.. All rights reserved.
+- * Copyright (c) 2020, 2021 Vincent Mailhol <mailhol.vincent@wanadoo.fr>
++ * Copyright (c) 2020-2022 Vincent Mailhol <mailhol.vincent@wanadoo.fr>
+ */
+
++#include <asm/unaligned.h>
++#include <linux/crc16.h>
+ #include <linux/ethtool.h>
+ #include <linux/kernel.h>
+ #include <linux/module.h>
+ #include <linux/usb.h>
+-#include <linux/crc16.h>
+-#include <asm/unaligned.h>
+
+ #include "es58x_core.h"
+
+diff --git a/drivers/net/can/usb/etas_es58x/es58x_core.h b/drivers/net/can/usb/etas_es58x/es58x_core.h
+index 640fe0a1df636..4a082fd69e6ff 100644
+--- a/drivers/net/can/usb/etas_es58x/es58x_core.h
++++ b/drivers/net/can/usb/etas_es58x/es58x_core.h
+@@ -6,17 +6,17 @@
+ *
+ * Copyright (c) 2019 Robert Bosch Engineering and Business Solutions. All rights reserved.
+ * Copyright (c) 2020 ETAS K.K.. All rights reserved.
+- * Copyright (c) 2020, 2021 Vincent Mailhol <mailhol.vincent@wanadoo.fr>
++ * Copyright (c) 2020-2022 Vincent Mailhol <mailhol.vincent@wanadoo.fr>
+ */
+
+ #ifndef __ES58X_COMMON_H__
+ #define __ES58X_COMMON_H__
+
+-#include <linux/types.h>
+-#include <linux/usb.h>
+-#include <linux/netdevice.h>
+ #include <linux/can.h>
+ #include <linux/can/dev.h>
++#include <linux/netdevice.h>
++#include <linux/types.h>
++#include <linux/usb.h>
+
+ #include "es581_4.h"
+ #include "es58x_fd.h"
+diff --git a/drivers/net/can/usb/etas_es58x/es58x_fd.c b/drivers/net/can/usb/etas_es58x/es58x_fd.c
+index c97ffa71fd758..fa87b0b78e3eb 100644
+--- a/drivers/net/can/usb/etas_es58x/es58x_fd.c
++++ b/drivers/net/can/usb/etas_es58x/es58x_fd.c
+@@ -8,12 +8,12 @@
+ *
+ * Copyright (c) 2019 Robert Bosch Engineering and Business Solutions. All rights reserved.
+ * Copyright (c) 2020 ETAS K.K.. All rights reserved.
+- * Copyright (c) 2020, 2021 Vincent Mailhol <mailhol.vincent@wanadoo.fr>
++ * Copyright (c) 2020-2022 Vincent Mailhol <mailhol.vincent@wanadoo.fr>
+ */
+
++#include <asm/unaligned.h>
+ #include <linux/kernel.h>
+ #include <linux/units.h>
+-#include <asm/unaligned.h>
+
+ #include "es58x_core.h"
+ #include "es58x_fd.h"
+--
+2.51.0
+
--- /dev/null
+From 8c15656bf34d9126734798f02ea6efe6f5c72d33 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 18 Sep 2025 18:00:25 +0900
+Subject: can: hi311x: populate ndo_change_mtu() to prevent buffer overflow
+
+From: Vincent Mailhol <mailhol@kernel.org>
+
+[ Upstream commit ac1c7656fa717f29fac3ea073af63f0b9919ec9a ]
+
+Sending an PF_PACKET allows to bypass the CAN framework logic and to
+directly reach the xmit() function of a CAN driver. The only check
+which is performed by the PF_PACKET framework is to make sure that
+skb->len fits the interface's MTU.
+
+Unfortunately, because the sun4i_can driver does not populate its
+net_device_ops->ndo_change_mtu(), it is possible for an attacker to
+configure an invalid MTU by doing, for example:
+
+ $ ip link set can0 mtu 9999
+
+After doing so, the attacker could open a PF_PACKET socket using the
+ETH_P_CANXL protocol:
+
+ socket(PF_PACKET, SOCK_RAW, htons(ETH_P_CANXL))
+
+to inject a malicious CAN XL frames. For example:
+
+ struct canxl_frame frame = {
+ .flags = 0xff,
+ .len = 2048,
+ };
+
+The CAN drivers' xmit() function are calling can_dev_dropped_skb() to
+check that the skb is valid, unfortunately under above conditions, the
+malicious packet is able to go through can_dev_dropped_skb() checks:
+
+ 1. the skb->protocol is set to ETH_P_CANXL which is valid (the
+ function does not check the actual device capabilities).
+
+ 2. the length is a valid CAN XL length.
+
+And so, hi3110_hard_start_xmit() receives a CAN XL frame which it is
+not able to correctly handle and will thus misinterpret it as a CAN
+frame. The driver will consume frame->len as-is with no further
+checks.
+
+This can result in a buffer overflow later on in hi3110_hw_tx() on
+this line:
+
+ memcpy(buf + HI3110_FIFO_EXT_DATA_OFF,
+ frame->data, frame->len);
+
+Here, frame->len corresponds to the flags field of the CAN XL frame.
+In our previous example, we set canxl_frame->flags to 0xff. Because
+the maximum expected length is 8, a buffer overflow of 247 bytes
+occurs!
+
+Populate net_device_ops->ndo_change_mtu() to ensure that the
+interface's MTU can not be set to anything bigger than CAN_MTU. By
+fixing the root cause, this prevents the buffer overflow.
+
+Fixes: 57e83fb9b746 ("can: hi311x: Add Holt HI-311x CAN driver")
+Signed-off-by: Vincent Mailhol <mailhol@kernel.org>
+Link: https://patch.msgid.link/20250918-can-fix-mtu-v1-2-0d1cada9393b@kernel.org
+Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/can/spi/hi311x.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/drivers/net/can/spi/hi311x.c b/drivers/net/can/spi/hi311x.c
+index b757555ed4c4f..57ea7dfe8a596 100644
+--- a/drivers/net/can/spi/hi311x.c
++++ b/drivers/net/can/spi/hi311x.c
+@@ -813,6 +813,7 @@ static const struct net_device_ops hi3110_netdev_ops = {
+ .ndo_open = hi3110_open,
+ .ndo_stop = hi3110_stop,
+ .ndo_start_xmit = hi3110_hard_start_xmit,
++ .ndo_change_mtu = can_change_mtu,
+ };
+
+ static const struct ethtool_ops hi3110_ethtool_ops = {
+--
+2.51.0
+
--- /dev/null
+From 60c20f5be63bbc5110046406eb1012c67b5255d5 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 18 Sep 2025 18:00:27 +0900
+Subject: can: mcba_usb: populate ndo_change_mtu() to prevent buffer overflow
+
+From: Vincent Mailhol <mailhol@kernel.org>
+
+[ Upstream commit 17c8d794527f01def0d1c8b7dc2d7b8d34fed0e6 ]
+
+Sending an PF_PACKET allows to bypass the CAN framework logic and to
+directly reach the xmit() function of a CAN driver. The only check
+which is performed by the PF_PACKET framework is to make sure that
+skb->len fits the interface's MTU.
+
+Unfortunately, because the mcba_usb driver does not populate its
+net_device_ops->ndo_change_mtu(), it is possible for an attacker to
+configure an invalid MTU by doing, for example:
+
+ $ ip link set can0 mtu 9999
+
+After doing so, the attacker could open a PF_PACKET socket using the
+ETH_P_CANXL protocol:
+
+ socket(PF_PACKET, SOCK_RAW, htons(ETH_P_CANXL))
+
+to inject a malicious CAN XL frames. For example:
+
+ struct canxl_frame frame = {
+ .flags = 0xff,
+ .len = 2048,
+ };
+
+The CAN drivers' xmit() function are calling can_dev_dropped_skb() to
+check that the skb is valid, unfortunately under above conditions, the
+malicious packet is able to go through can_dev_dropped_skb() checks:
+
+ 1. the skb->protocol is set to ETH_P_CANXL which is valid (the
+ function does not check the actual device capabilities).
+
+ 2. the length is a valid CAN XL length.
+
+And so, mcba_usb_start_xmit() receives a CAN XL frame which it is not
+able to correctly handle and will thus misinterpret it as a CAN frame.
+
+This can result in a buffer overflow. The driver will consume cf->len
+as-is with no further checks on these lines:
+
+ usb_msg.dlc = cf->len;
+
+ memcpy(usb_msg.data, cf->data, usb_msg.dlc);
+
+Here, cf->len corresponds to the flags field of the CAN XL frame. In
+our previous example, we set canxl_frame->flags to 0xff. Because the
+maximum expected length is 8, a buffer overflow of 247 bytes occurs!
+
+Populate net_device_ops->ndo_change_mtu() to ensure that the
+interface's MTU can not be set to anything bigger than CAN_MTU. By
+fixing the root cause, this prevents the buffer overflow.
+
+Fixes: 51f3baad7de9 ("can: mcba_usb: Add support for Microchip CAN BUS Analyzer")
+Signed-off-by: Vincent Mailhol <mailhol@kernel.org>
+Link: https://patch.msgid.link/20250918-can-fix-mtu-v1-4-0d1cada9393b@kernel.org
+Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/can/usb/mcba_usb.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/drivers/net/can/usb/mcba_usb.c b/drivers/net/can/usb/mcba_usb.c
+index 47619e9cb0055..ecc489afb8416 100644
+--- a/drivers/net/can/usb/mcba_usb.c
++++ b/drivers/net/can/usb/mcba_usb.c
+@@ -761,6 +761,7 @@ static const struct net_device_ops mcba_netdev_ops = {
+ .ndo_open = mcba_usb_open,
+ .ndo_stop = mcba_usb_close,
+ .ndo_start_xmit = mcba_usb_start_xmit,
++ .ndo_change_mtu = can_change_mtu,
+ };
+
+ static const struct ethtool_ops mcba_ethtool_ops = {
+--
+2.51.0
+
--- /dev/null
+From ad08e25df5dc9bb13ca97b9257af9d083f445afa Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 18 Sep 2025 15:23:57 +0200
+Subject: can: peak_usb: fix shift-out-of-bounds issue
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Stéphane Grosjean <stephane.grosjean@hms-networks.com>
+
+[ Upstream commit c443be70aaee42c2d1d251e0329e0a69dd96ae54 ]
+
+Explicitly uses a 64-bit constant when the number of bits used for its
+shifting is 32 (which is the case for PC CAN FD interfaces supported by
+this driver).
+
+Signed-off-by: Stéphane Grosjean <stephane.grosjean@hms-networks.com>
+Link: https://patch.msgid.link/20250918132413.30071-1-stephane.grosjean@free.fr
+Reported-by: Marc Kleine-Budde <mkl@pengutronix.de>
+Closes: https://lore.kernel.org/20250917-aboriginal-refined-honeybee-82b1aa-mkl@pengutronix.de
+Fixes: bb4785551f64 ("can: usb: PEAK-System Technik USB adapters driver core")
+[mkl: update subject, apply manually]
+Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/can/usb/peak_usb/pcan_usb_core.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/drivers/net/can/usb/peak_usb/pcan_usb_core.c b/drivers/net/can/usb/peak_usb/pcan_usb_core.c
+index 1d996d3320fef..928a78947cb0b 100644
+--- a/drivers/net/can/usb/peak_usb/pcan_usb_core.c
++++ b/drivers/net/can/usb/peak_usb/pcan_usb_core.c
+@@ -89,7 +89,7 @@ void peak_usb_update_ts_now(struct peak_time_ref *time_ref, u32 ts_now)
+ u32 delta_ts = time_ref->ts_dev_2 - time_ref->ts_dev_1;
+
+ if (time_ref->ts_dev_2 < time_ref->ts_dev_1)
+- delta_ts &= (1 << time_ref->adapter->ts_used_bits) - 1;
++ delta_ts &= (1ULL << time_ref->adapter->ts_used_bits) - 1;
+
+ time_ref->ts_total += delta_ts;
+ }
+--
+2.51.0
+
--- /dev/null
+From 7f7d35e2de10e274da581bced68635968d6240d1 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 18 Sep 2025 18:00:26 +0900
+Subject: can: sun4i_can: populate ndo_change_mtu() to prevent buffer overflow
+
+From: Vincent Mailhol <mailhol@kernel.org>
+
+[ Upstream commit 61da0bd4102c459823fbe6b8b43b01fb6ace4a22 ]
+
+Sending an PF_PACKET allows to bypass the CAN framework logic and to
+directly reach the xmit() function of a CAN driver. The only check
+which is performed by the PF_PACKET framework is to make sure that
+skb->len fits the interface's MTU.
+
+Unfortunately, because the sun4i_can driver does not populate its
+net_device_ops->ndo_change_mtu(), it is possible for an attacker to
+configure an invalid MTU by doing, for example:
+
+ $ ip link set can0 mtu 9999
+
+After doing so, the attacker could open a PF_PACKET socket using the
+ETH_P_CANXL protocol:
+
+ socket(PF_PACKET, SOCK_RAW, htons(ETH_P_CANXL))
+
+to inject a malicious CAN XL frames. For example:
+
+ struct canxl_frame frame = {
+ .flags = 0xff,
+ .len = 2048,
+ };
+
+The CAN drivers' xmit() function are calling can_dev_dropped_skb() to
+check that the skb is valid, unfortunately under above conditions, the
+malicious packet is able to go through can_dev_dropped_skb() checks:
+
+ 1. the skb->protocol is set to ETH_P_CANXL which is valid (the
+ function does not check the actual device capabilities).
+
+ 2. the length is a valid CAN XL length.
+
+And so, sun4ican_start_xmit() receives a CAN XL frame which it is not
+able to correctly handle and will thus misinterpret it as a CAN frame.
+
+This can result in a buffer overflow. The driver will consume cf->len
+as-is with no further checks on this line:
+
+ dlc = cf->len;
+
+Here, cf->len corresponds to the flags field of the CAN XL frame. In
+our previous example, we set canxl_frame->flags to 0xff. Because the
+maximum expected length is 8, a buffer overflow of 247 bytes occurs a
+couple line below when doing:
+
+ for (i = 0; i < dlc; i++)
+ writel(cf->data[i], priv->base + (dreg + i * 4));
+
+Populate net_device_ops->ndo_change_mtu() to ensure that the
+interface's MTU can not be set to anything bigger than CAN_MTU. By
+fixing the root cause, this prevents the buffer overflow.
+
+Fixes: 0738eff14d81 ("can: Allwinner A10/A20 CAN Controller support - Kernel module")
+Signed-off-by: Vincent Mailhol <mailhol@kernel.org>
+Link: https://patch.msgid.link/20250918-can-fix-mtu-v1-3-0d1cada9393b@kernel.org
+Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/can/sun4i_can.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/drivers/net/can/sun4i_can.c b/drivers/net/can/sun4i_can.c
+index 4bec1e7e7b3e3..380f90bc7a422 100644
+--- a/drivers/net/can/sun4i_can.c
++++ b/drivers/net/can/sun4i_can.c
+@@ -769,6 +769,7 @@ static const struct net_device_ops sun4ican_netdev_ops = {
+ .ndo_open = sun4ican_open,
+ .ndo_stop = sun4ican_close,
+ .ndo_start_xmit = sun4ican_start_xmit,
++ .ndo_change_mtu = can_change_mtu,
+ };
+
+ static const struct ethtool_ops sun4ican_ethtool_ops = {
+--
+2.51.0
+
--- /dev/null
+From cd194d6d842ae3a166d0b14f4758a8b8c4b7bed9 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 18 Sep 2025 17:21:07 +0200
+Subject: ethernet: rvu-af: Remove slash from the driver name
+
+From: Petr Malat <oss@malat.biz>
+
+[ Upstream commit b65678cacc030efd53c38c089fb9b741a2ee34c8 ]
+
+Having a slash in the driver name leads to EIO being returned while
+reading /sys/module/rvu_af/drivers content.
+
+Remove DRV_STRING as it's not used anywhere.
+
+Fixes: 91c6945ea1f9 ("octeontx2-af: cn10k: Add RPM MAC support")
+Signed-off-by: Petr Malat <oss@malat.biz>
+Reviewed-by: Simon Horman <horms@kernel.org>
+Link: https://patch.msgid.link/20250918152106.1798299-1-oss@malat.biz
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/ethernet/marvell/octeontx2/af/cgx.c | 3 +--
+ 1 file changed, 1 insertion(+), 2 deletions(-)
+
+diff --git a/drivers/net/ethernet/marvell/octeontx2/af/cgx.c b/drivers/net/ethernet/marvell/octeontx2/af/cgx.c
+index 254cad45a555f..2fe633be06bf9 100644
+--- a/drivers/net/ethernet/marvell/octeontx2/af/cgx.c
++++ b/drivers/net/ethernet/marvell/octeontx2/af/cgx.c
+@@ -21,8 +21,7 @@
+ #include "rvu.h"
+ #include "lmac_common.h"
+
+-#define DRV_NAME "Marvell-CGX/RPM"
+-#define DRV_STRING "Marvell CGX/RPM Driver"
++#define DRV_NAME "Marvell-CGX-RPM"
+
+ static LIST_HEAD(cgx_list);
+
+--
+2.51.0
+
--- /dev/null
+From be2293ece965e1e88f545ba1da81ddd2e0ac182a Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 11 Jun 2024 15:54:28 +0200
+Subject: net: dsa: lantiq_gswip: do also enable or disable cpu port
+
+From: Martin Schiller <ms@dev.tdt.de>
+
+[ Upstream commit 86b9ea6412af41914ef6549f85a849c3b987f4f3 ]
+
+Before commit 74be4babe72f ("net: dsa: do not enable or disable non user
+ports"), gswip_port_enable/disable() were also executed for the cpu port
+in gswip_setup() which disabled the cpu port during initialization.
+
+Let's restore this by removing the dsa_is_user_port checks. Also, let's
+clean up the gswip_port_enable() function so that we only have to check
+for the cpu port once. The operation reordering done here is safe.
+
+Signed-off-by: Martin Schiller <ms@dev.tdt.de>
+Acked-by: Hauke Mehrtens <hauke@hauke-m.de>
+Reviewed-by: Vladimir Oltean <olteanv@gmail.com>
+Link: https://lore.kernel.org/r/20240611135434.3180973-7-ms@dev.tdt.de
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Stable-dep-of: c0054b25e2f1 ("net: dsa: lantiq_gswip: move gswip_add_single_port_br() call to port_setup()")
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/dsa/lantiq_gswip.c | 24 ++++++++----------------
+ 1 file changed, 8 insertions(+), 16 deletions(-)
+
+diff --git a/drivers/net/dsa/lantiq_gswip.c b/drivers/net/dsa/lantiq_gswip.c
+index 05ecaa007ab18..ee80446802af4 100644
+--- a/drivers/net/dsa/lantiq_gswip.c
++++ b/drivers/net/dsa/lantiq_gswip.c
+@@ -688,13 +688,18 @@ static int gswip_port_enable(struct dsa_switch *ds, int port,
+ struct gswip_priv *priv = ds->priv;
+ int err;
+
+- if (!dsa_is_user_port(ds, port))
+- return 0;
+-
+ if (!dsa_is_cpu_port(ds, port)) {
++ u32 mdio_phy = 0;
++
+ err = gswip_add_single_port_br(priv, port, true);
+ if (err)
+ return err;
++
++ if (phydev)
++ mdio_phy = phydev->mdio.addr & GSWIP_MDIO_PHY_ADDR_MASK;
++
++ gswip_mdio_mask(priv, GSWIP_MDIO_PHY_ADDR_MASK, mdio_phy,
++ GSWIP_MDIO_PHYp(port));
+ }
+
+ /* RMON Counter Enable for port */
+@@ -707,16 +712,6 @@ static int gswip_port_enable(struct dsa_switch *ds, int port,
+ gswip_switch_mask(priv, 0, GSWIP_SDMA_PCTRL_EN,
+ GSWIP_SDMA_PCTRLp(port));
+
+- if (!dsa_is_cpu_port(ds, port)) {
+- u32 mdio_phy = 0;
+-
+- if (phydev)
+- mdio_phy = phydev->mdio.addr & GSWIP_MDIO_PHY_ADDR_MASK;
+-
+- gswip_mdio_mask(priv, GSWIP_MDIO_PHY_ADDR_MASK, mdio_phy,
+- GSWIP_MDIO_PHYp(port));
+- }
+-
+ return 0;
+ }
+
+@@ -724,9 +719,6 @@ static void gswip_port_disable(struct dsa_switch *ds, int port)
+ {
+ struct gswip_priv *priv = ds->priv;
+
+- if (!dsa_is_user_port(ds, port))
+- return;
+-
+ gswip_switch_mask(priv, GSWIP_FDMA_PCTRL_EN, 0,
+ GSWIP_FDMA_PCTRLp(port));
+ gswip_switch_mask(priv, GSWIP_SDMA_PCTRL_EN, 0,
+--
+2.51.0
+
--- /dev/null
+From 14441f1c039927c4cb9ef52fa29977ed1d2b34ab Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 18 Sep 2025 10:21:41 +0300
+Subject: net: dsa: lantiq_gswip: move gswip_add_single_port_br() call to
+ port_setup()
+
+From: Vladimir Oltean <vladimir.oltean@nxp.com>
+
+[ Upstream commit c0054b25e2f1045f47b4954cf13a539e5e6047df ]
+
+A port added to a "single port bridge" operates as standalone, and this
+is mutually exclusive to being part of a Linux bridge. In fact,
+gswip_port_bridge_join() calls gswip_add_single_port_br() with
+add=false, i.e. removes the port from the "single port bridge" to enable
+autonomous forwarding.
+
+The blamed commit seems to have incorrectly thought that ds->ops->port_enable()
+is called one time per port, during the setup phase of the switch.
+
+However, it is actually called during the ndo_open() implementation of
+DSA user ports, which is to say that this sequence of events:
+
+1. ip link set swp0 down
+2. ip link add br0 type bridge
+3. ip link set swp0 master br0
+4. ip link set swp0 up
+
+would cause swp0 to join back the "single port bridge" which step 3 had
+just removed it from.
+
+The correct DSA hook for one-time actions per port at switch init time
+is ds->ops->port_setup(). This is what seems to match the coder's
+intention; also see the comment at the beginning of the file:
+
+ * At the initialization the driver allocates one bridge table entry for
+ ~~~~~~~~~~~~~~~~~~~~~
+ * each switch port which is used when the port is used without an
+ * explicit bridge.
+
+Fixes: 8206e0ce96b3 ("net: dsa: lantiq: Add VLAN unaware bridge offloading")
+Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
+Link: https://patch.msgid.link/20250918072142.894692-2-vladimir.oltean@nxp.com
+Tested-by: Daniel Golle <daniel@makrotopia.org>
+Reviewed-by: Daniel Golle <daniel@makrotopia.org>
+Signed-off-by: Paolo Abeni <pabeni@redhat.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/dsa/lantiq_gswip.c | 18 ++++++++++++++----
+ 1 file changed, 14 insertions(+), 4 deletions(-)
+
+diff --git a/drivers/net/dsa/lantiq_gswip.c b/drivers/net/dsa/lantiq_gswip.c
+index ee80446802af4..dd01470cd5dde 100644
+--- a/drivers/net/dsa/lantiq_gswip.c
++++ b/drivers/net/dsa/lantiq_gswip.c
+@@ -682,18 +682,27 @@ static int gswip_add_single_port_br(struct gswip_priv *priv, int port, bool add)
+ return 0;
+ }
+
+-static int gswip_port_enable(struct dsa_switch *ds, int port,
+- struct phy_device *phydev)
++static int gswip_port_setup(struct dsa_switch *ds, int port)
+ {
+ struct gswip_priv *priv = ds->priv;
+ int err;
+
+ if (!dsa_is_cpu_port(ds, port)) {
+- u32 mdio_phy = 0;
+-
+ err = gswip_add_single_port_br(priv, port, true);
+ if (err)
+ return err;
++ }
++
++ return 0;
++}
++
++static int gswip_port_enable(struct dsa_switch *ds, int port,
++ struct phy_device *phydev)
++{
++ struct gswip_priv *priv = ds->priv;
++
++ if (!dsa_is_cpu_port(ds, port)) {
++ u32 mdio_phy = 0;
+
+ if (phydev)
+ mdio_phy = phydev->mdio.addr & GSWIP_MDIO_PHY_ADDR_MASK;
+@@ -1813,6 +1822,7 @@ static int gswip_get_sset_count(struct dsa_switch *ds, int port, int sset)
+ static const struct dsa_switch_ops gswip_xrx200_switch_ops = {
+ .get_tag_protocol = gswip_get_tag_protocol,
+ .setup = gswip_setup,
++ .port_setup = gswip_port_setup,
+ .port_enable = gswip_port_enable,
+ .port_disable = gswip_port_disable,
+ .port_bridge_join = gswip_port_bridge_join,
+--
+2.51.0
+
--- /dev/null
+From 3b77a20721f385d3acb5d189d2646087eb615f0b Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 18 Sep 2025 10:21:42 +0300
+Subject: net: dsa: lantiq_gswip: suppress -EINVAL errors for bridge FDB
+ entries added to the CPU port
+
+From: Vladimir Oltean <vladimir.oltean@nxp.com>
+
+[ Upstream commit 987afe147965ef7a8e7d144ffef0d70af14bb1d4 ]
+
+The blamed commit and others in that patch set started the trend
+of reusing existing DSA driver API for a new purpose: calling
+ds->ops->port_fdb_add() on the CPU port.
+
+The lantiq_gswip driver was not prepared to handle that, as can be seen
+from the many errors that Daniel presents in the logs:
+
+[ 174.050000] gswip 1e108000.switch: port 2 failed to add fa:aa:72:f4:8b:1e vid 1 to fdb: -22
+[ 174.060000] gswip 1e108000.switch lan2: entered promiscuous mode
+[ 174.070000] gswip 1e108000.switch: port 2 failed to add 00:01:02:03:04:02 vid 0 to fdb: -22
+[ 174.090000] gswip 1e108000.switch: port 2 failed to add 00:01:02:03:04:02 vid 1 to fdb: -22
+[ 174.090000] gswip 1e108000.switch: port 2 failed to delete fa:aa:72:f4:8b:1e vid 1 from fdb: -2
+
+The errors are because gswip_port_fdb() wants to get a handle to the
+bridge that originated these FDB events, to associate it with a FID.
+Absolutely honourable purpose, however this only works for user ports.
+
+To get the bridge that generated an FDB entry for the CPU port, one
+would need to look at the db.bridge.dev argument. But this was
+introduced in commit c26933639b54 ("net: dsa: request drivers to perform
+FDB isolation"), first appeared in v5.18, and when the blamed commit was
+introduced in v5.14, no such API existed.
+
+So the core DSA feature was introduced way too soon for lantiq_gswip.
+Not acting on these host FDB entries and suppressing any errors has no
+other negative effect, and practically returns us to not supporting the
+host filtering feature at all - peacefully, this time.
+
+Fixes: 10fae4ac89ce ("net: dsa: include bridge addresses which are local in the host fdb list")
+Reported-by: Daniel Golle <daniel@makrotopia.org>
+Closes: https://lore.kernel.org/netdev/aJfNMLNoi1VOsPrN@pidgin.makrotopia.org/
+Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
+Link: https://patch.msgid.link/20250918072142.894692-3-vladimir.oltean@nxp.com
+Tested-by: Daniel Golle <daniel@makrotopia.org>
+Reviewed-by: Daniel Golle <daniel@makrotopia.org>
+Signed-off-by: Paolo Abeni <pabeni@redhat.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/dsa/lantiq_gswip.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+diff --git a/drivers/net/dsa/lantiq_gswip.c b/drivers/net/dsa/lantiq_gswip.c
+index dd01470cd5dde..d899ebb902a0c 100644
+--- a/drivers/net/dsa/lantiq_gswip.c
++++ b/drivers/net/dsa/lantiq_gswip.c
+@@ -1366,8 +1366,9 @@ static int gswip_port_fdb(struct dsa_switch *ds, int port,
+ int i;
+ int err;
+
++ /* Operation not supported on the CPU port, don't throw errors */
+ if (!bridge)
+- return -EINVAL;
++ return 0;
+
+ for (i = max_ports; i < ARRAY_SIZE(priv->vlans); i++) {
+ if (priv->vlans[i].bridge == bridge) {
+--
+2.51.0
+
--- /dev/null
+From 6113c5ed958f34c0f65aec9dbd174de33428936e Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Sun, 21 Sep 2025 18:08:22 +0300
+Subject: nexthop: Forbid FDB status change while nexthop is in a group
+
+From: Ido Schimmel <idosch@nvidia.com>
+
+[ Upstream commit 390b3a300d7872cef9588f003b204398be69ce08 ]
+
+The kernel forbids the creation of non-FDB nexthop groups with FDB
+nexthops:
+
+ # ip nexthop add id 1 via 192.0.2.1 fdb
+ # ip nexthop add id 2 group 1
+ Error: Non FDB nexthop group cannot have fdb nexthops.
+
+And vice versa:
+
+ # ip nexthop add id 3 via 192.0.2.2 dev dummy1
+ # ip nexthop add id 4 group 3 fdb
+ Error: FDB nexthop group can only have fdb nexthops.
+
+However, as long as no routes are pointing to a non-FDB nexthop group,
+the kernel allows changing the type of a nexthop from FDB to non-FDB and
+vice versa:
+
+ # ip nexthop add id 5 via 192.0.2.2 dev dummy1
+ # ip nexthop add id 6 group 5
+ # ip nexthop replace id 5 via 192.0.2.2 fdb
+ # echo $?
+ 0
+
+This configuration is invalid and can result in a NPD [1] since FDB
+nexthops are not associated with a nexthop device:
+
+ # ip route add 198.51.100.1/32 nhid 6
+ # ping 198.51.100.1
+
+Fix by preventing nexthop FDB status change while the nexthop is in a
+group:
+
+ # ip nexthop add id 7 via 192.0.2.2 dev dummy1
+ # ip nexthop add id 8 group 7
+ # ip nexthop replace id 7 via 192.0.2.2 fdb
+ Error: Cannot change nexthop FDB status while in a group.
+
+[1]
+BUG: kernel NULL pointer dereference, address: 00000000000003c0
+[...]
+Oops: Oops: 0000 [#1] SMP
+CPU: 6 UID: 0 PID: 367 Comm: ping Not tainted 6.17.0-rc6-virtme-gb65678cacc03 #1 PREEMPT(voluntary)
+Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-4.fc41 04/01/2014
+RIP: 0010:fib_lookup_good_nhc+0x1e/0x80
+[...]
+Call Trace:
+ <TASK>
+ fib_table_lookup+0x541/0x650
+ ip_route_output_key_hash_rcu+0x2ea/0x970
+ ip_route_output_key_hash+0x55/0x80
+ __ip4_datagram_connect+0x250/0x330
+ udp_connect+0x2b/0x60
+ __sys_connect+0x9c/0xd0
+ __x64_sys_connect+0x18/0x20
+ do_syscall_64+0xa4/0x2a0
+ entry_SYSCALL_64_after_hwframe+0x4b/0x53
+
+Fixes: 38428d68719c ("nexthop: support for fdb ecmp nexthops")
+Reported-by: syzbot+6596516dd2b635ba2350@syzkaller.appspotmail.com
+Closes: https://lore.kernel.org/netdev/68c9a4d2.050a0220.3c6139.0e63.GAE@google.com/
+Tested-by: syzbot+6596516dd2b635ba2350@syzkaller.appspotmail.com
+Signed-off-by: Ido Schimmel <idosch@nvidia.com>
+Reviewed-by: David Ahern <dsahern@kernel.org>
+Link: https://patch.msgid.link/20250921150824.149157-2-idosch@nvidia.com
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ net/ipv4/nexthop.c | 7 +++++++
+ 1 file changed, 7 insertions(+)
+
+diff --git a/net/ipv4/nexthop.c b/net/ipv4/nexthop.c
+index bba955d82f723..c0f9d125f401c 100644
+--- a/net/ipv4/nexthop.c
++++ b/net/ipv4/nexthop.c
+@@ -2113,6 +2113,13 @@ static int replace_nexthop_single(struct net *net, struct nexthop *old,
+ return -EINVAL;
+ }
+
++ if (!list_empty(&old->grp_list) &&
++ rtnl_dereference(new->nh_info)->fdb_nh !=
++ rtnl_dereference(old->nh_info)->fdb_nh) {
++ NL_SET_ERR_MSG(extack, "Cannot change nexthop FDB status while in a group");
++ return -EINVAL;
++ }
++
+ err = call_nexthop_notifiers(net, NEXTHOP_EVENT_REPLACE, new, extack);
+ if (err)
+ return err;
+--
+2.51.0
+
--- /dev/null
+From a865d5ca46dc08146c0a96d596d191fcd09ce490 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 23 Sep 2025 14:19:11 +0300
+Subject: octeontx2-pf: Fix potential use after free in otx2_tc_add_flow()
+
+From: Dan Carpenter <dan.carpenter@linaro.org>
+
+[ Upstream commit d9c70e93ec5988ab07ad2a92d9f9d12867f02c56 ]
+
+This code calls kfree_rcu(new_node, rcu) and then dereferences "new_node"
+and then dereferences it on the next line. Two lines later, we take
+a mutex so I don't think this is an RCU safe region. Re-order it to do
+the dereferences before queuing up the free.
+
+Fixes: 68fbff68dbea ("octeontx2-pf: Add police action for TC flower")
+Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
+Reviewed-by: Vadim Fedorenko <vadim.fedorenko@linux.dev>
+Link: https://patch.msgid.link/aNKCL1jKwK8GRJHh@stanley.mountain
+Signed-off-by: Paolo Abeni <pabeni@redhat.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/ethernet/marvell/octeontx2/nic/otx2_tc.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/drivers/net/ethernet/marvell/octeontx2/nic/otx2_tc.c b/drivers/net/ethernet/marvell/octeontx2/nic/otx2_tc.c
+index bb77ab7ddfefd..6833cbf853445 100644
+--- a/drivers/net/ethernet/marvell/octeontx2/nic/otx2_tc.c
++++ b/drivers/net/ethernet/marvell/octeontx2/nic/otx2_tc.c
+@@ -1039,7 +1039,6 @@ static int otx2_tc_add_flow(struct otx2_nic *nic,
+
+ free_leaf:
+ otx2_tc_del_from_flow_list(flow_cfg, new_node);
+- kfree_rcu(new_node, rcu);
+ if (new_node->is_act_police) {
+ mutex_lock(&nic->mbox.lock);
+
+@@ -1059,6 +1058,7 @@ static int otx2_tc_add_flow(struct otx2_nic *nic,
+
+ mutex_unlock(&nic->mbox.lock);
+ }
++ kfree_rcu(new_node, rcu);
+
+ return rc;
+ }
+--
+2.51.0
+
--- /dev/null
+From 3784c94c702ee5d791758756cec6d6bff5d47b6d Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Sun, 21 Sep 2025 18:08:23 +0300
+Subject: selftests: fib_nexthops: Fix creation of non-FDB nexthops
+
+From: Ido Schimmel <idosch@nvidia.com>
+
+[ Upstream commit c29913109c70383cdf90b6fc792353e1009f24f5 ]
+
+The test creates non-FDB nexthops without a nexthop device which leads
+to the expected failure, but for the wrong reason:
+
+ # ./fib_nexthops.sh -t "ipv6_fdb_grp_fcnal ipv4_fdb_grp_fcnal" -v
+
+ IPv6 fdb groups functional
+ --------------------------
+ [...]
+ COMMAND: ip -netns me-nRsN3E nexthop add id 63 via 2001:db8:91::4
+ Error: Device attribute required for non-blackhole and non-fdb nexthops.
+ COMMAND: ip -netns me-nRsN3E nexthop add id 64 via 2001:db8:91::5
+ Error: Device attribute required for non-blackhole and non-fdb nexthops.
+ COMMAND: ip -netns me-nRsN3E nexthop add id 103 group 63/64 fdb
+ Error: Invalid nexthop id.
+ TEST: Fdb Nexthop group with non-fdb nexthops [ OK ]
+ [...]
+
+ IPv4 fdb groups functional
+ --------------------------
+ [...]
+ COMMAND: ip -netns me-nRsN3E nexthop add id 14 via 172.16.1.2
+ Error: Device attribute required for non-blackhole and non-fdb nexthops.
+ COMMAND: ip -netns me-nRsN3E nexthop add id 15 via 172.16.1.3
+ Error: Device attribute required for non-blackhole and non-fdb nexthops.
+ COMMAND: ip -netns me-nRsN3E nexthop add id 103 group 14/15 fdb
+ Error: Invalid nexthop id.
+ TEST: Fdb Nexthop group with non-fdb nexthops [ OK ]
+
+ COMMAND: ip -netns me-nRsN3E nexthop add id 16 via 172.16.1.2 fdb
+ COMMAND: ip -netns me-nRsN3E nexthop add id 17 via 172.16.1.3 fdb
+ COMMAND: ip -netns me-nRsN3E nexthop add id 104 group 14/15
+ Error: Invalid nexthop id.
+ TEST: Non-Fdb Nexthop group with fdb nexthops [ OK ]
+ [...]
+ COMMAND: ip -netns me-0dlhyd ro add 172.16.0.0/22 nhid 15
+ Error: Nexthop id does not exist.
+ TEST: Route add with fdb nexthop [ OK ]
+
+In addition, as can be seen in the above output, a couple of IPv4 test
+cases used the non-FDB nexthops (14 and 15) when they intended to use
+the FDB nexthops (16 and 17). These test cases only passed because
+failure was expected, but they failed for the wrong reason.
+
+Fix the test to create the non-FDB nexthops with a nexthop device and
+adjust the IPv4 test cases to use the FDB nexthops instead of the
+non-FDB nexthops.
+
+Output after the fix:
+
+ # ./fib_nexthops.sh -t "ipv6_fdb_grp_fcnal ipv4_fdb_grp_fcnal" -v
+
+ IPv6 fdb groups functional
+ --------------------------
+ [...]
+ COMMAND: ip -netns me-lNzfHP nexthop add id 63 via 2001:db8:91::4 dev veth1
+ COMMAND: ip -netns me-lNzfHP nexthop add id 64 via 2001:db8:91::5 dev veth1
+ COMMAND: ip -netns me-lNzfHP nexthop add id 103 group 63/64 fdb
+ Error: FDB nexthop group can only have fdb nexthops.
+ TEST: Fdb Nexthop group with non-fdb nexthops [ OK ]
+ [...]
+
+ IPv4 fdb groups functional
+ --------------------------
+ [...]
+ COMMAND: ip -netns me-lNzfHP nexthop add id 14 via 172.16.1.2 dev veth1
+ COMMAND: ip -netns me-lNzfHP nexthop add id 15 via 172.16.1.3 dev veth1
+ COMMAND: ip -netns me-lNzfHP nexthop add id 103 group 14/15 fdb
+ Error: FDB nexthop group can only have fdb nexthops.
+ TEST: Fdb Nexthop group with non-fdb nexthops [ OK ]
+
+ COMMAND: ip -netns me-lNzfHP nexthop add id 16 via 172.16.1.2 fdb
+ COMMAND: ip -netns me-lNzfHP nexthop add id 17 via 172.16.1.3 fdb
+ COMMAND: ip -netns me-lNzfHP nexthop add id 104 group 16/17
+ Error: Non FDB nexthop group cannot have fdb nexthops.
+ TEST: Non-Fdb Nexthop group with fdb nexthops [ OK ]
+ [...]
+ COMMAND: ip -netns me-lNzfHP ro add 172.16.0.0/22 nhid 16
+ Error: Route cannot point to a fdb nexthop.
+ TEST: Route add with fdb nexthop [ OK ]
+ [...]
+ Tests passed: 30
+ Tests failed: 0
+ Tests skipped: 0
+
+Fixes: 0534c5489c11 ("selftests: net: add fdb nexthop tests")
+Signed-off-by: Ido Schimmel <idosch@nvidia.com>
+Reviewed-by: David Ahern <dsahern@kernel.org>
+Link: https://patch.msgid.link/20250921150824.149157-3-idosch@nvidia.com
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ tools/testing/selftests/net/fib_nexthops.sh | 12 ++++++------
+ 1 file changed, 6 insertions(+), 6 deletions(-)
+
+diff --git a/tools/testing/selftests/net/fib_nexthops.sh b/tools/testing/selftests/net/fib_nexthops.sh
+index df8d90b51867a..543a35e5c9dfe 100755
+--- a/tools/testing/selftests/net/fib_nexthops.sh
++++ b/tools/testing/selftests/net/fib_nexthops.sh
+@@ -441,8 +441,8 @@ ipv6_fdb_grp_fcnal()
+ log_test $? 0 "Get Fdb nexthop group by id"
+
+ # fdb nexthop group can only contain fdb nexthops
+- run_cmd "$IP nexthop add id 63 via 2001:db8:91::4"
+- run_cmd "$IP nexthop add id 64 via 2001:db8:91::5"
++ run_cmd "$IP nexthop add id 63 via 2001:db8:91::4 dev veth1"
++ run_cmd "$IP nexthop add id 64 via 2001:db8:91::5 dev veth1"
+ run_cmd "$IP nexthop add id 103 group 63/64 fdb"
+ log_test $? 2 "Fdb Nexthop group with non-fdb nexthops"
+
+@@ -521,15 +521,15 @@ ipv4_fdb_grp_fcnal()
+ log_test $? 0 "Get Fdb nexthop group by id"
+
+ # fdb nexthop group can only contain fdb nexthops
+- run_cmd "$IP nexthop add id 14 via 172.16.1.2"
+- run_cmd "$IP nexthop add id 15 via 172.16.1.3"
++ run_cmd "$IP nexthop add id 14 via 172.16.1.2 dev veth1"
++ run_cmd "$IP nexthop add id 15 via 172.16.1.3 dev veth1"
+ run_cmd "$IP nexthop add id 103 group 14/15 fdb"
+ log_test $? 2 "Fdb Nexthop group with non-fdb nexthops"
+
+ # Non fdb nexthop group can not contain fdb nexthops
+ run_cmd "$IP nexthop add id 16 via 172.16.1.2 fdb"
+ run_cmd "$IP nexthop add id 17 via 172.16.1.3 fdb"
+- run_cmd "$IP nexthop add id 104 group 14/15"
++ run_cmd "$IP nexthop add id 104 group 16/17"
+ log_test $? 2 "Non-Fdb Nexthop group with fdb nexthops"
+
+ # fdb nexthop cannot have blackhole
+@@ -556,7 +556,7 @@ ipv4_fdb_grp_fcnal()
+ run_cmd "$BRIDGE fdb add 02:02:00:00:00:14 dev vx10 nhid 12 self"
+ log_test $? 255 "Fdb mac add with nexthop"
+
+- run_cmd "$IP ro add 172.16.0.0/22 nhid 15"
++ run_cmd "$IP ro add 172.16.0.0/22 nhid 16"
+ log_test $? 2 "Route add with fdb nexthop"
+
+ run_cmd "$IP ro add 172.16.0.0/22 nhid 103"
+--
+2.51.0
+
smb-server-don-t-use-delayed_work-for-post_recv_cred.patch
can-rcar_can-rcar_can_resume-fix-s2ram-with-psci.patch
bpf-reject-bpf_timer-for-preempt_rt.patch
+can-etas_es58x-sort-the-includes-by-alphabetic-order.patch
+can-etas_es58x-populate-ndo_change_mtu-to-prevent-bu.patch
+can-hi311x-populate-ndo_change_mtu-to-prevent-buffer.patch
+can-sun4i_can-populate-ndo_change_mtu-to-prevent-buf.patch
+can-mcba_usb-populate-ndo_change_mtu-to-prevent-buff.patch
+can-peak_usb-fix-shift-out-of-bounds-issue.patch
+ethernet-rvu-af-remove-slash-from-the-driver-name.patch
+bluetooth-hci_sync-fix-hci_resume_advertising_sync.patch
+bluetooth-hci_event-fix-uaf-in-hci_acl_create_conn_s.patch
+bnxt_en-correct-offset-handling-for-ipv6-destination.patch
+nexthop-forbid-fdb-status-change-while-nexthop-is-in.patch
+selftests-fib_nexthops-fix-creation-of-non-fdb-nexth.patch
+net-dsa-lantiq_gswip-do-also-enable-or-disable-cpu-p.patch
+net-dsa-lantiq_gswip-move-gswip_add_single_port_br-c.patch
+net-dsa-lantiq_gswip-suppress-einval-errors-for-brid.patch
+octeontx2-pf-fix-potential-use-after-free-in-otx2_tc.patch
--- /dev/null
+From 69d376ca92d6f8fe5b6e56e96ec9d66d03bbff01 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Mon, 25 Aug 2025 11:10:20 -0400
+Subject: Bluetooth: hci_event: Fix UAF in hci_acl_create_conn_sync
+
+From: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
+
+[ Upstream commit 9e622804d57e2d08f0271200606bd1270f75126f ]
+
+This fixes the following UFA in hci_acl_create_conn_sync where a
+connection still pending is command submission (conn->state == BT_OPEN)
+maybe freed, also since this also can happen with the likes of
+hci_le_create_conn_sync fix it as well:
+
+BUG: KASAN: slab-use-after-free in hci_acl_create_conn_sync+0x5ef/0x790 net/bluetooth/hci_sync.c:6861
+Write of size 2 at addr ffff88805ffcc038 by task kworker/u11:2/9541
+
+CPU: 1 UID: 0 PID: 9541 Comm: kworker/u11:2 Not tainted 6.16.0-rc7 #3 PREEMPT(full)
+Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014
+Workqueue: hci3 hci_cmd_sync_work
+Call Trace:
+ <TASK>
+ dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120
+ print_address_description mm/kasan/report.c:378 [inline]
+ print_report+0xca/0x230 mm/kasan/report.c:480
+ kasan_report+0x118/0x150 mm/kasan/report.c:593
+ hci_acl_create_conn_sync+0x5ef/0x790 net/bluetooth/hci_sync.c:6861
+ hci_cmd_sync_work+0x210/0x3a0 net/bluetooth/hci_sync.c:332
+ process_one_work kernel/workqueue.c:3238 [inline]
+ process_scheduled_works+0xae1/0x17b0 kernel/workqueue.c:3321
+ worker_thread+0x8a0/0xda0 kernel/workqueue.c:3402
+ kthread+0x70e/0x8a0 kernel/kthread.c:464
+ ret_from_fork+0x3fc/0x770 arch/x86/kernel/process.c:148
+ ret_from_fork_asm+0x1a/0x30 home/kwqcheii/source/fuzzing/kernel/kasan/linux-6.16-rc7/arch/x86/entry/entry_64.S:245
+ </TASK>
+
+Allocated by task 123736:
+ kasan_save_stack mm/kasan/common.c:47 [inline]
+ kasan_save_track+0x3e/0x80 mm/kasan/common.c:68
+ poison_kmalloc_redzone mm/kasan/common.c:377 [inline]
+ __kasan_kmalloc+0x93/0xb0 mm/kasan/common.c:394
+ kasan_kmalloc include/linux/kasan.h:260 [inline]
+ __kmalloc_cache_noprof+0x230/0x3d0 mm/slub.c:4359
+ kmalloc_noprof include/linux/slab.h:905 [inline]
+ kzalloc_noprof include/linux/slab.h:1039 [inline]
+ __hci_conn_add+0x233/0x1b30 net/bluetooth/hci_conn.c:939
+ hci_conn_add_unset net/bluetooth/hci_conn.c:1051 [inline]
+ hci_connect_acl+0x16c/0x4e0 net/bluetooth/hci_conn.c:1634
+ pair_device+0x418/0xa70 net/bluetooth/mgmt.c:3556
+ hci_mgmt_cmd+0x9c9/0xef0 net/bluetooth/hci_sock.c:1719
+ hci_sock_sendmsg+0x6ca/0xef0 net/bluetooth/hci_sock.c:1839
+ sock_sendmsg_nosec net/socket.c:712 [inline]
+ __sock_sendmsg+0x219/0x270 net/socket.c:727
+ sock_write_iter+0x258/0x330 net/socket.c:1131
+ new_sync_write fs/read_write.c:593 [inline]
+ vfs_write+0x54b/0xa90 fs/read_write.c:686
+ ksys_write+0x145/0x250 fs/read_write.c:738
+ do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
+ do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94
+ entry_SYSCALL_64_after_hwframe+0x77/0x7f
+
+Freed by task 103680:
+ kasan_save_stack mm/kasan/common.c:47 [inline]
+ kasan_save_track+0x3e/0x80 mm/kasan/common.c:68
+ kasan_save_free_info+0x46/0x50 mm/kasan/generic.c:576
+ poison_slab_object mm/kasan/common.c:247 [inline]
+ __kasan_slab_free+0x62/0x70 mm/kasan/common.c:264
+ kasan_slab_free include/linux/kasan.h:233 [inline]
+ slab_free_hook mm/slub.c:2381 [inline]
+ slab_free mm/slub.c:4643 [inline]
+ kfree+0x18e/0x440 mm/slub.c:4842
+ device_release+0x9c/0x1c0
+ kobject_cleanup lib/kobject.c:689 [inline]
+ kobject_release lib/kobject.c:720 [inline]
+ kref_put include/linux/kref.h:65 [inline]
+ kobject_put+0x22b/0x480 lib/kobject.c:737
+ hci_conn_cleanup net/bluetooth/hci_conn.c:175 [inline]
+ hci_conn_del+0x8ff/0xcb0 net/bluetooth/hci_conn.c:1173
+ hci_conn_complete_evt+0x3c7/0x1040 net/bluetooth/hci_event.c:3199
+ hci_event_func net/bluetooth/hci_event.c:7477 [inline]
+ hci_event_packet+0x7e0/0x1200 net/bluetooth/hci_event.c:7531
+ hci_rx_work+0x46a/0xe80 net/bluetooth/hci_core.c:4070
+ process_one_work kernel/workqueue.c:3238 [inline]
+ process_scheduled_works+0xae1/0x17b0 kernel/workqueue.c:3321
+ worker_thread+0x8a0/0xda0 kernel/workqueue.c:3402
+ kthread+0x70e/0x8a0 kernel/kthread.c:464
+ ret_from_fork+0x3fc/0x770 arch/x86/kernel/process.c:148
+ ret_from_fork_asm+0x1a/0x30 home/kwqcheii/source/fuzzing/kernel/kasan/linux-6.16-rc7/arch/x86/entry/entry_64.S:245
+
+Last potentially related work creation:
+ kasan_save_stack+0x3e/0x60 mm/kasan/common.c:47
+ kasan_record_aux_stack+0xbd/0xd0 mm/kasan/generic.c:548
+ insert_work+0x3d/0x330 kernel/workqueue.c:2183
+ __queue_work+0xbd9/0xfe0 kernel/workqueue.c:2345
+ queue_delayed_work_on+0x18b/0x280 kernel/workqueue.c:2561
+ pairing_complete+0x1e7/0x2b0 net/bluetooth/mgmt.c:3451
+ pairing_complete_cb+0x1ac/0x230 net/bluetooth/mgmt.c:3487
+ hci_connect_cfm include/net/bluetooth/hci_core.h:2064 [inline]
+ hci_conn_failed+0x24d/0x310 net/bluetooth/hci_conn.c:1275
+ hci_conn_complete_evt+0x3c7/0x1040 net/bluetooth/hci_event.c:3199
+ hci_event_func net/bluetooth/hci_event.c:7477 [inline]
+ hci_event_packet+0x7e0/0x1200 net/bluetooth/hci_event.c:7531
+ hci_rx_work+0x46a/0xe80 net/bluetooth/hci_core.c:4070
+ process_one_work kernel/workqueue.c:3238 [inline]
+ process_scheduled_works+0xae1/0x17b0 kernel/workqueue.c:3321
+ worker_thread+0x8a0/0xda0 kernel/workqueue.c:3402
+ kthread+0x70e/0x8a0 kernel/kthread.c:464
+ ret_from_fork+0x3fc/0x770 arch/x86/kernel/process.c:148
+ ret_from_fork_asm+0x1a/0x30 home/kwqcheii/source/fuzzing/kernel/kasan/linux-6.16-rc7/arch/x86/entry/entry_64.S:245
+
+Fixes: aef2aa4fa98e ("Bluetooth: hci_event: Fix creating hci_conn object on error status")
+Reported-by: Junvyyang, Tencent Zhuque Lab <zhuque@tencent.com>
+Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ include/net/bluetooth/hci_core.h | 21 +++++++++++++++++++++
+ net/bluetooth/hci_event.c | 26 +++++++++++++++++++++++---
+ 2 files changed, 44 insertions(+), 3 deletions(-)
+
+diff --git a/include/net/bluetooth/hci_core.h b/include/net/bluetooth/hci_core.h
+index df4af45f8603c..69a1d8b12beff 100644
+--- a/include/net/bluetooth/hci_core.h
++++ b/include/net/bluetooth/hci_core.h
+@@ -1203,6 +1203,27 @@ static inline struct hci_conn *hci_conn_hash_lookup_ba(struct hci_dev *hdev,
+ return NULL;
+ }
+
++static inline struct hci_conn *hci_conn_hash_lookup_role(struct hci_dev *hdev,
++ __u8 type, __u8 role,
++ bdaddr_t *ba)
++{
++ struct hci_conn_hash *h = &hdev->conn_hash;
++ struct hci_conn *c;
++
++ rcu_read_lock();
++
++ list_for_each_entry_rcu(c, &h->list, list) {
++ if (c->type == type && c->role == role && !bacmp(&c->dst, ba)) {
++ rcu_read_unlock();
++ return c;
++ }
++ }
++
++ rcu_read_unlock();
++
++ return NULL;
++}
++
+ static inline struct hci_conn *hci_conn_hash_lookup_le(struct hci_dev *hdev,
+ bdaddr_t *ba,
+ __u8 ba_type)
+diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c
+index 262ff30261d67..1e537ed83ba4b 100644
+--- a/net/bluetooth/hci_event.c
++++ b/net/bluetooth/hci_event.c
+@@ -3050,8 +3050,18 @@ static void hci_conn_complete_evt(struct hci_dev *hdev, void *data,
+
+ hci_dev_lock(hdev);
+
++ /* Check for existing connection:
++ *
++ * 1. If it doesn't exist then it must be receiver/slave role.
++ * 2. If it does exist confirm that it is connecting/BT_CONNECT in case
++ * of initiator/master role since there could be a collision where
++ * either side is attempting to connect or something like a fuzzing
++ * testing is trying to play tricks to destroy the hcon object before
++ * it even attempts to connect (e.g. hcon->state == BT_OPEN).
++ */
+ conn = hci_conn_hash_lookup_ba(hdev, ev->link_type, &ev->bdaddr);
+- if (!conn) {
++ if (!conn ||
++ (conn->role == HCI_ROLE_MASTER && conn->state != BT_CONNECT)) {
+ /* In case of error status and there is no connection pending
+ * just unlock as there is nothing to cleanup.
+ */
+@@ -5618,8 +5628,18 @@ static void le_conn_complete_evt(struct hci_dev *hdev, u8 status,
+ */
+ hci_dev_clear_flag(hdev, HCI_LE_ADV);
+
+- conn = hci_conn_hash_lookup_ba(hdev, LE_LINK, bdaddr);
+- if (!conn) {
++ /* Check for existing connection:
++ *
++ * 1. If it doesn't exist then use the role to create a new object.
++ * 2. If it does exist confirm that it is connecting/BT_CONNECT in case
++ * of initiator/master role since there could be a collision where
++ * either side is attempting to connect or something like a fuzzing
++ * testing is trying to play tricks to destroy the hcon object before
++ * it even attempts to connect (e.g. hcon->state == BT_OPEN).
++ */
++ conn = hci_conn_hash_lookup_role(hdev, LE_LINK, role, bdaddr);
++ if (!conn ||
++ (conn->role == HCI_ROLE_MASTER && conn->state != BT_CONNECT)) {
+ /* In case of error status and there is no connection pending
+ * just unlock as there is nothing to cleanup.
+ */
+--
+2.51.0
+
--- /dev/null
+From 7f0ad8c4c294f19390b56ea2bc6d3eecdcde3715 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 5 Sep 2025 10:29:18 -0400
+Subject: Bluetooth: hci_sync: Fix hci_resume_advertising_sync
+
+From: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
+
+[ Upstream commit 1488af7b8b5f9896ea88ee35aa3301713f72737c ]
+
+hci_resume_advertising_sync is suppose to resume all instance paused by
+hci_pause_advertising_sync, this logic is used for procedures are only
+allowed when not advertising, but instance 0x00 was not being
+re-enabled.
+
+Fixes: ad383c2c65a5 ("Bluetooth: hci_sync: Enable advertising when LL privacy is enabled")
+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 | 7 +++++++
+ 1 file changed, 7 insertions(+)
+
+diff --git a/net/bluetooth/hci_sync.c b/net/bluetooth/hci_sync.c
+index 5f5137764b80a..333f32a9fd219 100644
+--- a/net/bluetooth/hci_sync.c
++++ b/net/bluetooth/hci_sync.c
+@@ -2604,6 +2604,13 @@ static int hci_resume_advertising_sync(struct hci_dev *hdev)
+ hci_remove_ext_adv_instance_sync(hdev, adv->instance,
+ NULL);
+ }
++
++ /* If current advertising instance is set to instance 0x00
++ * then we need to re-enable it.
++ */
++ if (!hdev->cur_adv_instance)
++ err = hci_enable_ext_advertising_sync(hdev,
++ hdev->cur_adv_instance);
+ } else {
+ /* Schedule for most recent instance to be restarted and begin
+ * the software rotation loop
+--
+2.51.0
+
--- /dev/null
+From 345d4a67afc7c44edbf59e54d13983ca493f0761 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Sat, 20 Sep 2025 05:11:17 -0700
+Subject: bnxt_en: correct offset handling for IPv6 destination address
+
+From: Alok Tiwari <alok.a.tiwari@oracle.com>
+
+[ Upstream commit 3d3aa9472c6dd0704e9961ed4769caac5b1c8d52 ]
+
+In bnxt_tc_parse_pedit(), the code incorrectly writes IPv6
+destination values to the source address field (saddr) when
+processing pedit offsets within the destination address range.
+
+This patch corrects the assignment to use daddr instead of saddr,
+ensuring that pedit operations on IPv6 destination addresses are
+applied correctly.
+
+Fixes: 9b9eb518e338 ("bnxt_en: Add support for NAT(L3/L4 rewrite)")
+Signed-off-by: Alok Tiwari <alok.a.tiwari@oracle.com>
+Reviewed-by: Somnath Kotur <somnath.kotur@broadcom.com>
+Link: https://patch.msgid.link/20250920121157.351921-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/broadcom/bnxt/bnxt_tc.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt_tc.c b/drivers/net/ethernet/broadcom/bnxt/bnxt_tc.c
+index d2ca90407cce7..8057350236c5e 100644
+--- a/drivers/net/ethernet/broadcom/bnxt/bnxt_tc.c
++++ b/drivers/net/ethernet/broadcom/bnxt/bnxt_tc.c
+@@ -244,7 +244,7 @@ bnxt_tc_parse_pedit(struct bnxt *bp, struct bnxt_tc_actions *actions,
+ offset < offset_of_ip6_daddr + 16) {
+ actions->nat.src_xlate = false;
+ idx = (offset - offset_of_ip6_daddr) / 4;
+- actions->nat.l3.ipv6.saddr.s6_addr32[idx] = htonl(val);
++ actions->nat.l3.ipv6.daddr.s6_addr32[idx] = htonl(val);
+ } else {
+ netdev_err(bp->dev,
+ "%s: IPv6_hdr: Invalid pedit field\n",
+--
+2.51.0
+
--- /dev/null
+From a4b3f0773485ffc88d71da04f33de53eca1180e1 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 18 Sep 2025 18:00:24 +0900
+Subject: can: etas_es58x: populate ndo_change_mtu() to prevent buffer overflow
+
+From: Vincent Mailhol <mailhol@kernel.org>
+
+[ Upstream commit 38c0abad45b190a30d8284a37264d2127a6ec303 ]
+
+Sending an PF_PACKET allows to bypass the CAN framework logic and to
+directly reach the xmit() function of a CAN driver. The only check
+which is performed by the PF_PACKET framework is to make sure that
+skb->len fits the interface's MTU.
+
+Unfortunately, because the etas_es58x driver does not populate its
+net_device_ops->ndo_change_mtu(), it is possible for an attacker to
+configure an invalid MTU by doing, for example:
+
+ $ ip link set can0 mtu 9999
+
+After doing so, the attacker could open a PF_PACKET socket using the
+ETH_P_CANXL protocol:
+
+ socket(PF_PACKET, SOCK_RAW, htons(ETH_P_CANXL));
+
+to inject a malicious CAN XL frames. For example:
+
+ struct canxl_frame frame = {
+ .flags = 0xff,
+ .len = 2048,
+ };
+
+The CAN drivers' xmit() function are calling can_dev_dropped_skb() to
+check that the skb is valid, unfortunately under above conditions, the
+malicious packet is able to go through can_dev_dropped_skb() checks:
+
+ 1. the skb->protocol is set to ETH_P_CANXL which is valid (the
+ function does not check the actual device capabilities).
+
+ 2. the length is a valid CAN XL length.
+
+And so, es58x_start_xmit() receives a CAN XL frame which it is not
+able to correctly handle and will thus misinterpret it as a CAN(FD)
+frame.
+
+This can result in a buffer overflow. For example, using the es581.4
+variant, the frame will be dispatched to es581_4_tx_can_msg(), go
+through the last check at the beginning of this function:
+
+ if (can_is_canfd_skb(skb))
+ return -EMSGSIZE;
+
+and reach this line:
+
+ memcpy(tx_can_msg->data, cf->data, cf->len);
+
+Here, cf->len corresponds to the flags field of the CAN XL frame. In
+our previous example, we set canxl_frame->flags to 0xff. Because the
+maximum expected length is 8, a buffer overflow of 247 bytes occurs!
+
+Populate net_device_ops->ndo_change_mtu() to ensure that the
+interface's MTU can not be set to anything bigger than CAN_MTU or
+CANFD_MTU (depending on the device capabilities). By fixing the root
+cause, this prevents the buffer overflow.
+
+Fixes: 8537257874e9 ("can: etas_es58x: add core support for ETAS ES58X CAN USB interfaces")
+Signed-off-by: Vincent Mailhol <mailhol@kernel.org>
+Link: https://patch.msgid.link/20250918-can-fix-mtu-v1-1-0d1cada9393b@kernel.org
+Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/can/usb/etas_es58x/es58x_core.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+diff --git a/drivers/net/can/usb/etas_es58x/es58x_core.c b/drivers/net/can/usb/etas_es58x/es58x_core.c
+index 71f24dc0a9271..4fc9bed0d2e1e 100644
+--- a/drivers/net/can/usb/etas_es58x/es58x_core.c
++++ b/drivers/net/can/usb/etas_es58x/es58x_core.c
+@@ -7,7 +7,7 @@
+ *
+ * Copyright (c) 2019 Robert Bosch Engineering and Business Solutions. All rights reserved.
+ * Copyright (c) 2020 ETAS K.K.. All rights reserved.
+- * Copyright (c) 2020-2022 Vincent Mailhol <mailhol.vincent@wanadoo.fr>
++ * Copyright (c) 2020-2025 Vincent Mailhol <mailhol@kernel.org>
+ */
+
+ #include <linux/unaligned.h>
+@@ -1977,6 +1977,7 @@ static const struct net_device_ops es58x_netdev_ops = {
+ .ndo_stop = es58x_stop,
+ .ndo_start_xmit = es58x_start_xmit,
+ .ndo_eth_ioctl = can_eth_ioctl_hwts,
++ .ndo_change_mtu = can_change_mtu,
+ };
+
+ static const struct ethtool_ops es58x_ethtool_ops = {
+--
+2.51.0
+
--- /dev/null
+From f3576255319dc2cc29483e2d251d7a242c29671a Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 18 Sep 2025 18:00:25 +0900
+Subject: can: hi311x: populate ndo_change_mtu() to prevent buffer overflow
+
+From: Vincent Mailhol <mailhol@kernel.org>
+
+[ Upstream commit ac1c7656fa717f29fac3ea073af63f0b9919ec9a ]
+
+Sending an PF_PACKET allows to bypass the CAN framework logic and to
+directly reach the xmit() function of a CAN driver. The only check
+which is performed by the PF_PACKET framework is to make sure that
+skb->len fits the interface's MTU.
+
+Unfortunately, because the sun4i_can driver does not populate its
+net_device_ops->ndo_change_mtu(), it is possible for an attacker to
+configure an invalid MTU by doing, for example:
+
+ $ ip link set can0 mtu 9999
+
+After doing so, the attacker could open a PF_PACKET socket using the
+ETH_P_CANXL protocol:
+
+ socket(PF_PACKET, SOCK_RAW, htons(ETH_P_CANXL))
+
+to inject a malicious CAN XL frames. For example:
+
+ struct canxl_frame frame = {
+ .flags = 0xff,
+ .len = 2048,
+ };
+
+The CAN drivers' xmit() function are calling can_dev_dropped_skb() to
+check that the skb is valid, unfortunately under above conditions, the
+malicious packet is able to go through can_dev_dropped_skb() checks:
+
+ 1. the skb->protocol is set to ETH_P_CANXL which is valid (the
+ function does not check the actual device capabilities).
+
+ 2. the length is a valid CAN XL length.
+
+And so, hi3110_hard_start_xmit() receives a CAN XL frame which it is
+not able to correctly handle and will thus misinterpret it as a CAN
+frame. The driver will consume frame->len as-is with no further
+checks.
+
+This can result in a buffer overflow later on in hi3110_hw_tx() on
+this line:
+
+ memcpy(buf + HI3110_FIFO_EXT_DATA_OFF,
+ frame->data, frame->len);
+
+Here, frame->len corresponds to the flags field of the CAN XL frame.
+In our previous example, we set canxl_frame->flags to 0xff. Because
+the maximum expected length is 8, a buffer overflow of 247 bytes
+occurs!
+
+Populate net_device_ops->ndo_change_mtu() to ensure that the
+interface's MTU can not be set to anything bigger than CAN_MTU. By
+fixing the root cause, this prevents the buffer overflow.
+
+Fixes: 57e83fb9b746 ("can: hi311x: Add Holt HI-311x CAN driver")
+Signed-off-by: Vincent Mailhol <mailhol@kernel.org>
+Link: https://patch.msgid.link/20250918-can-fix-mtu-v1-2-0d1cada9393b@kernel.org
+Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/can/spi/hi311x.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/drivers/net/can/spi/hi311x.c b/drivers/net/can/spi/hi311x.c
+index 1b9501ee10deb..ff39afc77d7d2 100644
+--- a/drivers/net/can/spi/hi311x.c
++++ b/drivers/net/can/spi/hi311x.c
+@@ -813,6 +813,7 @@ static const struct net_device_ops hi3110_netdev_ops = {
+ .ndo_open = hi3110_open,
+ .ndo_stop = hi3110_stop,
+ .ndo_start_xmit = hi3110_hard_start_xmit,
++ .ndo_change_mtu = can_change_mtu,
+ };
+
+ static const struct ethtool_ops hi3110_ethtool_ops = {
+--
+2.51.0
+
--- /dev/null
+From 21d8defca18e22b01765ffa92b9a17bad88f82f7 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 18 Sep 2025 18:00:27 +0900
+Subject: can: mcba_usb: populate ndo_change_mtu() to prevent buffer overflow
+
+From: Vincent Mailhol <mailhol@kernel.org>
+
+[ Upstream commit 17c8d794527f01def0d1c8b7dc2d7b8d34fed0e6 ]
+
+Sending an PF_PACKET allows to bypass the CAN framework logic and to
+directly reach the xmit() function of a CAN driver. The only check
+which is performed by the PF_PACKET framework is to make sure that
+skb->len fits the interface's MTU.
+
+Unfortunately, because the mcba_usb driver does not populate its
+net_device_ops->ndo_change_mtu(), it is possible for an attacker to
+configure an invalid MTU by doing, for example:
+
+ $ ip link set can0 mtu 9999
+
+After doing so, the attacker could open a PF_PACKET socket using the
+ETH_P_CANXL protocol:
+
+ socket(PF_PACKET, SOCK_RAW, htons(ETH_P_CANXL))
+
+to inject a malicious CAN XL frames. For example:
+
+ struct canxl_frame frame = {
+ .flags = 0xff,
+ .len = 2048,
+ };
+
+The CAN drivers' xmit() function are calling can_dev_dropped_skb() to
+check that the skb is valid, unfortunately under above conditions, the
+malicious packet is able to go through can_dev_dropped_skb() checks:
+
+ 1. the skb->protocol is set to ETH_P_CANXL which is valid (the
+ function does not check the actual device capabilities).
+
+ 2. the length is a valid CAN XL length.
+
+And so, mcba_usb_start_xmit() receives a CAN XL frame which it is not
+able to correctly handle and will thus misinterpret it as a CAN frame.
+
+This can result in a buffer overflow. The driver will consume cf->len
+as-is with no further checks on these lines:
+
+ usb_msg.dlc = cf->len;
+
+ memcpy(usb_msg.data, cf->data, usb_msg.dlc);
+
+Here, cf->len corresponds to the flags field of the CAN XL frame. In
+our previous example, we set canxl_frame->flags to 0xff. Because the
+maximum expected length is 8, a buffer overflow of 247 bytes occurs!
+
+Populate net_device_ops->ndo_change_mtu() to ensure that the
+interface's MTU can not be set to anything bigger than CAN_MTU. By
+fixing the root cause, this prevents the buffer overflow.
+
+Fixes: 51f3baad7de9 ("can: mcba_usb: Add support for Microchip CAN BUS Analyzer")
+Signed-off-by: Vincent Mailhol <mailhol@kernel.org>
+Link: https://patch.msgid.link/20250918-can-fix-mtu-v1-4-0d1cada9393b@kernel.org
+Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/can/usb/mcba_usb.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/drivers/net/can/usb/mcba_usb.c b/drivers/net/can/usb/mcba_usb.c
+index 41c0a1c399bf3..1f9b915094e64 100644
+--- a/drivers/net/can/usb/mcba_usb.c
++++ b/drivers/net/can/usb/mcba_usb.c
+@@ -761,6 +761,7 @@ static const struct net_device_ops mcba_netdev_ops = {
+ .ndo_open = mcba_usb_open,
+ .ndo_stop = mcba_usb_close,
+ .ndo_start_xmit = mcba_usb_start_xmit,
++ .ndo_change_mtu = can_change_mtu,
+ };
+
+ static const struct ethtool_ops mcba_ethtool_ops = {
+--
+2.51.0
+
--- /dev/null
+From f14b2e4414669bfe93f1699535857ddef1fc75ef Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 18 Sep 2025 15:23:57 +0200
+Subject: can: peak_usb: fix shift-out-of-bounds issue
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Stéphane Grosjean <stephane.grosjean@hms-networks.com>
+
+[ Upstream commit c443be70aaee42c2d1d251e0329e0a69dd96ae54 ]
+
+Explicitly uses a 64-bit constant when the number of bits used for its
+shifting is 32 (which is the case for PC CAN FD interfaces supported by
+this driver).
+
+Signed-off-by: Stéphane Grosjean <stephane.grosjean@hms-networks.com>
+Link: https://patch.msgid.link/20250918132413.30071-1-stephane.grosjean@free.fr
+Reported-by: Marc Kleine-Budde <mkl@pengutronix.de>
+Closes: https://lore.kernel.org/20250917-aboriginal-refined-honeybee-82b1aa-mkl@pengutronix.de
+Fixes: bb4785551f64 ("can: usb: PEAK-System Technik USB adapters driver core")
+[mkl: update subject, apply manually]
+Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/can/usb/peak_usb/pcan_usb_core.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/drivers/net/can/usb/peak_usb/pcan_usb_core.c b/drivers/net/can/usb/peak_usb/pcan_usb_core.c
+index 59f7cd8ceb397..69c44f675ff1c 100644
+--- a/drivers/net/can/usb/peak_usb/pcan_usb_core.c
++++ b/drivers/net/can/usb/peak_usb/pcan_usb_core.c
+@@ -111,7 +111,7 @@ void peak_usb_update_ts_now(struct peak_time_ref *time_ref, u32 ts_now)
+ u32 delta_ts = time_ref->ts_dev_2 - time_ref->ts_dev_1;
+
+ if (time_ref->ts_dev_2 < time_ref->ts_dev_1)
+- delta_ts &= (1 << time_ref->adapter->ts_used_bits) - 1;
++ delta_ts &= (1ULL << time_ref->adapter->ts_used_bits) - 1;
+
+ time_ref->ts_total += delta_ts;
+ }
+--
+2.51.0
+
--- /dev/null
+From db5168e12436386af699ab1139e3ea3bfe114a82 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 18 Sep 2025 18:00:26 +0900
+Subject: can: sun4i_can: populate ndo_change_mtu() to prevent buffer overflow
+
+From: Vincent Mailhol <mailhol@kernel.org>
+
+[ Upstream commit 61da0bd4102c459823fbe6b8b43b01fb6ace4a22 ]
+
+Sending an PF_PACKET allows to bypass the CAN framework logic and to
+directly reach the xmit() function of a CAN driver. The only check
+which is performed by the PF_PACKET framework is to make sure that
+skb->len fits the interface's MTU.
+
+Unfortunately, because the sun4i_can driver does not populate its
+net_device_ops->ndo_change_mtu(), it is possible for an attacker to
+configure an invalid MTU by doing, for example:
+
+ $ ip link set can0 mtu 9999
+
+After doing so, the attacker could open a PF_PACKET socket using the
+ETH_P_CANXL protocol:
+
+ socket(PF_PACKET, SOCK_RAW, htons(ETH_P_CANXL))
+
+to inject a malicious CAN XL frames. For example:
+
+ struct canxl_frame frame = {
+ .flags = 0xff,
+ .len = 2048,
+ };
+
+The CAN drivers' xmit() function are calling can_dev_dropped_skb() to
+check that the skb is valid, unfortunately under above conditions, the
+malicious packet is able to go through can_dev_dropped_skb() checks:
+
+ 1. the skb->protocol is set to ETH_P_CANXL which is valid (the
+ function does not check the actual device capabilities).
+
+ 2. the length is a valid CAN XL length.
+
+And so, sun4ican_start_xmit() receives a CAN XL frame which it is not
+able to correctly handle and will thus misinterpret it as a CAN frame.
+
+This can result in a buffer overflow. The driver will consume cf->len
+as-is with no further checks on this line:
+
+ dlc = cf->len;
+
+Here, cf->len corresponds to the flags field of the CAN XL frame. In
+our previous example, we set canxl_frame->flags to 0xff. Because the
+maximum expected length is 8, a buffer overflow of 247 bytes occurs a
+couple line below when doing:
+
+ for (i = 0; i < dlc; i++)
+ writel(cf->data[i], priv->base + (dreg + i * 4));
+
+Populate net_device_ops->ndo_change_mtu() to ensure that the
+interface's MTU can not be set to anything bigger than CAN_MTU. By
+fixing the root cause, this prevents the buffer overflow.
+
+Fixes: 0738eff14d81 ("can: Allwinner A10/A20 CAN Controller support - Kernel module")
+Signed-off-by: Vincent Mailhol <mailhol@kernel.org>
+Link: https://patch.msgid.link/20250918-can-fix-mtu-v1-3-0d1cada9393b@kernel.org
+Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/can/sun4i_can.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/drivers/net/can/sun4i_can.c b/drivers/net/can/sun4i_can.c
+index 4311c1f0eafd8..30b30fdbcae9c 100644
+--- a/drivers/net/can/sun4i_can.c
++++ b/drivers/net/can/sun4i_can.c
+@@ -768,6 +768,7 @@ static const struct net_device_ops sun4ican_netdev_ops = {
+ .ndo_open = sun4ican_open,
+ .ndo_stop = sun4ican_close,
+ .ndo_start_xmit = sun4ican_start_xmit,
++ .ndo_change_mtu = can_change_mtu,
+ };
+
+ static const struct ethtool_ops sun4ican_ethtool_ops = {
+--
+2.51.0
+
--- /dev/null
+From 569cef8e5c3bcbb5a06716dce4267af12bacfdcf Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 18 Sep 2025 17:21:07 +0200
+Subject: ethernet: rvu-af: Remove slash from the driver name
+
+From: Petr Malat <oss@malat.biz>
+
+[ Upstream commit b65678cacc030efd53c38c089fb9b741a2ee34c8 ]
+
+Having a slash in the driver name leads to EIO being returned while
+reading /sys/module/rvu_af/drivers content.
+
+Remove DRV_STRING as it's not used anywhere.
+
+Fixes: 91c6945ea1f9 ("octeontx2-af: cn10k: Add RPM MAC support")
+Signed-off-by: Petr Malat <oss@malat.biz>
+Reviewed-by: Simon Horman <horms@kernel.org>
+Link: https://patch.msgid.link/20250918152106.1798299-1-oss@malat.biz
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/ethernet/marvell/octeontx2/af/cgx.c | 3 +--
+ 1 file changed, 1 insertion(+), 2 deletions(-)
+
+diff --git a/drivers/net/ethernet/marvell/octeontx2/af/cgx.c b/drivers/net/ethernet/marvell/octeontx2/af/cgx.c
+index 971993586fb49..ca74bf6843369 100644
+--- a/drivers/net/ethernet/marvell/octeontx2/af/cgx.c
++++ b/drivers/net/ethernet/marvell/octeontx2/af/cgx.c
+@@ -21,8 +21,7 @@
+ #include "rvu.h"
+ #include "lmac_common.h"
+
+-#define DRV_NAME "Marvell-CGX/RPM"
+-#define DRV_STRING "Marvell CGX/RPM Driver"
++#define DRV_NAME "Marvell-CGX-RPM"
+
+ #define CGX_RX_STAT_GLOBAL_INDEX 9
+
+--
+2.51.0
+
--- /dev/null
+From 661428c0ce427b8b1a1de386e3ff3d18967e94bb Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Mon, 8 Sep 2025 15:23:15 -0700
+Subject: mm: folio_may_be_lru_cached() unless folio_test_large()
+
+From: Hugh Dickins <hughd@google.com>
+
+[ Upstream commit 2da6de30e60dd9bb14600eff1cc99df2fa2ddae3 ]
+
+mm/swap.c and mm/mlock.c agree to drain any per-CPU batch as soon as a
+large folio is added: so collect_longterm_unpinnable_folios() just wastes
+effort when calling lru_add_drain[_all]() on a large folio.
+
+But although there is good reason not to batch up PMD-sized folios, we
+might well benefit from batching a small number of low-order mTHPs (though
+unclear how that "small number" limitation will be implemented).
+
+So ask if folio_may_be_lru_cached() rather than !folio_test_large(), to
+insulate those particular checks from future change. Name preferred to
+"folio_is_batchable" because large folios can well be put on a batch: it's
+just the per-CPU LRU caches, drained much later, which need care.
+
+Marked for stable, to counter the increase in lru_add_drain_all()s from
+"mm/gup: check ref_count instead of lru before migration".
+
+Link: https://lkml.kernel.org/r/57d2eaf8-3607-f318-e0c5-be02dce61ad0@google.com
+Fixes: 9a4e9f3b2d73 ("mm: update get_user_pages_longterm to migrate pages allocated from CMA region")
+Signed-off-by: Hugh Dickins <hughd@google.com>
+Suggested-by: David Hildenbrand <david@redhat.com>
+Acked-by: David Hildenbrand <david@redhat.com>
+Cc: "Aneesh Kumar K.V" <aneesh.kumar@kernel.org>
+Cc: Axel Rasmussen <axelrasmussen@google.com>
+Cc: Chris Li <chrisl@kernel.org>
+Cc: Christoph Hellwig <hch@infradead.org>
+Cc: Jason Gunthorpe <jgg@ziepe.ca>
+Cc: Johannes Weiner <hannes@cmpxchg.org>
+Cc: John Hubbard <jhubbard@nvidia.com>
+Cc: Keir Fraser <keirf@google.com>
+Cc: Konstantin Khlebnikov <koct9i@gmail.com>
+Cc: Li Zhe <lizhe.67@bytedance.com>
+Cc: Matthew Wilcox (Oracle) <willy@infradead.org>
+Cc: Peter Xu <peterx@redhat.com>
+Cc: Rik van Riel <riel@surriel.com>
+Cc: Shivank Garg <shivankg@amd.com>
+Cc: Vlastimil Babka <vbabka@suse.cz>
+Cc: Wei Xu <weixugc@google.com>
+Cc: Will Deacon <will@kernel.org>
+Cc: yangge <yangge1116@126.com>
+Cc: Yuanchu Xie <yuanchu@google.com>
+Cc: Yu Zhao <yuzhao@google.com>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+[ Clean cherry-pick now into this tree ]
+Signed-off-by: Hugh Dickins <hughd@google.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ include/linux/swap.h | 10 ++++++++++
+ mm/gup.c | 4 ++--
+ mm/mlock.c | 6 +++---
+ mm/swap.c | 2 +-
+ 4 files changed, 16 insertions(+), 6 deletions(-)
+
+diff --git a/include/linux/swap.h b/include/linux/swap.h
+index f3e0ac20c2e8c..63f85b3fee238 100644
+--- a/include/linux/swap.h
++++ b/include/linux/swap.h
+@@ -382,6 +382,16 @@ void folio_add_lru_vma(struct folio *, struct vm_area_struct *);
+ void mark_page_accessed(struct page *);
+ void folio_mark_accessed(struct folio *);
+
++static inline bool folio_may_be_lru_cached(struct folio *folio)
++{
++ /*
++ * Holding PMD-sized folios in per-CPU LRU cache unbalances accounting.
++ * Holding small numbers of low-order mTHP folios in per-CPU LRU cache
++ * will be sensible, but nobody has implemented and tested that yet.
++ */
++ return !folio_test_large(folio);
++}
++
+ extern atomic_t lru_disable_count;
+
+ static inline bool lru_cache_disabled(void)
+diff --git a/mm/gup.c b/mm/gup.c
+index 4dd0eb70988b2..d105817a0c9aa 100644
+--- a/mm/gup.c
++++ b/mm/gup.c
+@@ -2376,13 +2376,13 @@ static unsigned long collect_longterm_unpinnable_folios(
+ continue;
+ }
+
+- if (drained == 0 &&
++ if (drained == 0 && folio_may_be_lru_cached(folio) &&
+ folio_ref_count(folio) !=
+ folio_expected_ref_count(folio) + 1) {
+ lru_add_drain();
+ drained = 1;
+ }
+- if (drained == 1 &&
++ if (drained == 1 && folio_may_be_lru_cached(folio) &&
+ folio_ref_count(folio) !=
+ folio_expected_ref_count(folio) + 1) {
+ lru_add_drain_all();
+diff --git a/mm/mlock.c b/mm/mlock.c
+index cde076fa7d5e5..8c8d522efdd59 100644
+--- a/mm/mlock.c
++++ b/mm/mlock.c
+@@ -255,7 +255,7 @@ void mlock_folio(struct folio *folio)
+
+ folio_get(folio);
+ if (!folio_batch_add(fbatch, mlock_lru(folio)) ||
+- folio_test_large(folio) || lru_cache_disabled())
++ !folio_may_be_lru_cached(folio) || lru_cache_disabled())
+ mlock_folio_batch(fbatch);
+ local_unlock(&mlock_fbatch.lock);
+ }
+@@ -278,7 +278,7 @@ void mlock_new_folio(struct folio *folio)
+
+ folio_get(folio);
+ if (!folio_batch_add(fbatch, mlock_new(folio)) ||
+- folio_test_large(folio) || lru_cache_disabled())
++ !folio_may_be_lru_cached(folio) || lru_cache_disabled())
+ mlock_folio_batch(fbatch);
+ local_unlock(&mlock_fbatch.lock);
+ }
+@@ -299,7 +299,7 @@ void munlock_folio(struct folio *folio)
+ */
+ folio_get(folio);
+ if (!folio_batch_add(fbatch, folio) ||
+- folio_test_large(folio) || lru_cache_disabled())
++ !folio_may_be_lru_cached(folio) || lru_cache_disabled())
+ mlock_folio_batch(fbatch);
+ local_unlock(&mlock_fbatch.lock);
+ }
+diff --git a/mm/swap.c b/mm/swap.c
+index d4cb4898f573e..ff846915db454 100644
+--- a/mm/swap.c
++++ b/mm/swap.c
+@@ -223,7 +223,7 @@ static void __folio_batch_add_and_move(struct folio_batch __percpu *fbatch,
+ local_lock(&cpu_fbatches.lock);
+
+ if (!folio_batch_add(this_cpu_ptr(fbatch), folio) ||
+- folio_test_large(folio) || lru_cache_disabled())
++ !folio_may_be_lru_cached(folio) || lru_cache_disabled())
+ folio_batch_move_lru(this_cpu_ptr(fbatch), move_fn);
+
+ if (disable_irq)
+--
+2.51.0
+
--- /dev/null
+From ece92a6bbb4712c913d932af786546450f485247 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Mon, 8 Sep 2025 15:16:53 -0700
+Subject: mm/gup: local lru_add_drain() to avoid lru_add_drain_all()
+
+From: Hugh Dickins <hughd@google.com>
+
+[ Upstream commit a09a8a1fbb374e0053b97306da9dbc05bd384685 ]
+
+In many cases, if collect_longterm_unpinnable_folios() does need to drain
+the LRU cache to release a reference, the cache in question is on this
+same CPU, and much more efficiently drained by a preliminary local
+lru_add_drain(), than the later cross-CPU lru_add_drain_all().
+
+Marked for stable, to counter the increase in lru_add_drain_all()s from
+"mm/gup: check ref_count instead of lru before migration". Note for clean
+backports: can take 6.16 commit a03db236aebf ("gup: optimize longterm
+pin_user_pages() for large folio") first.
+
+Link: https://lkml.kernel.org/r/66f2751f-283e-816d-9530-765db7edc465@google.com
+Signed-off-by: Hugh Dickins <hughd@google.com>
+Acked-by: David Hildenbrand <david@redhat.com>
+Cc: "Aneesh Kumar K.V" <aneesh.kumar@kernel.org>
+Cc: Axel Rasmussen <axelrasmussen@google.com>
+Cc: Chris Li <chrisl@kernel.org>
+Cc: Christoph Hellwig <hch@infradead.org>
+Cc: Jason Gunthorpe <jgg@ziepe.ca>
+Cc: Johannes Weiner <hannes@cmpxchg.org>
+Cc: John Hubbard <jhubbard@nvidia.com>
+Cc: Keir Fraser <keirf@google.com>
+Cc: Konstantin Khlebnikov <koct9i@gmail.com>
+Cc: Li Zhe <lizhe.67@bytedance.com>
+Cc: Matthew Wilcox (Oracle) <willy@infradead.org>
+Cc: Peter Xu <peterx@redhat.com>
+Cc: Rik van Riel <riel@surriel.com>
+Cc: Shivank Garg <shivankg@amd.com>
+Cc: Vlastimil Babka <vbabka@suse.cz>
+Cc: Wei Xu <weixugc@google.com>
+Cc: Will Deacon <will@kernel.org>
+Cc: yangge <yangge1116@126.com>
+Cc: Yuanchu Xie <yuanchu@google.com>
+Cc: Yu Zhao <yuzhao@google.com>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+[ Clean cherry-pick now into this tree ]
+Signed-off-by: Hugh Dickins <hughd@google.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ mm/gup.c | 15 +++++++++++----
+ 1 file changed, 11 insertions(+), 4 deletions(-)
+
+diff --git a/mm/gup.c b/mm/gup.c
+index e9be7c49542a0..4dd0eb70988b2 100644
+--- a/mm/gup.c
++++ b/mm/gup.c
+@@ -2356,8 +2356,8 @@ static unsigned long collect_longterm_unpinnable_folios(
+ struct pages_or_folios *pofs)
+ {
+ unsigned long collected = 0;
+- bool drain_allow = true;
+ struct folio *folio;
++ int drained = 0;
+ long i = 0;
+
+ for (folio = pofs_get_folio(pofs, i); folio;
+@@ -2376,10 +2376,17 @@ static unsigned long collect_longterm_unpinnable_folios(
+ continue;
+ }
+
+- if (drain_allow && folio_ref_count(folio) !=
+- folio_expected_ref_count(folio) + 1) {
++ if (drained == 0 &&
++ folio_ref_count(folio) !=
++ folio_expected_ref_count(folio) + 1) {
++ lru_add_drain();
++ drained = 1;
++ }
++ if (drained == 1 &&
++ folio_ref_count(folio) !=
++ folio_expected_ref_count(folio) + 1) {
+ lru_add_drain_all();
+- drain_allow = false;
++ drained = 2;
+ }
+
+ if (!folio_isolate_lru(folio))
+--
+2.51.0
+
--- /dev/null
+From b78af0a74f449bbfcd16afbdfb9766fed548f23d Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Mon, 8 Sep 2025 15:19:17 -0700
+Subject: mm: revert "mm/gup: clear the LRU flag of a page before adding to LRU
+ batch"
+
+From: Hugh Dickins <hughd@google.com>
+
+[ Upstream commit afb99e9f500485160f34b8cad6d3763ada3e80e8 ]
+
+This reverts commit 33dfe9204f29: now that
+collect_longterm_unpinnable_folios() is checking ref_count instead of lru,
+and mlock/munlock do not participate in the revised LRU flag clearing,
+those changes are misleading, and enlarge the window during which
+mlock/munlock may miss an mlock_count update.
+
+It is possible (I'd hesitate to claim probable) that the greater
+likelihood of missed mlock_count updates would explain the "Realtime
+threads delayed due to kcompactd0" observed on 6.12 in the Link below. If
+that is the case, this reversion will help; but a complete solution needs
+also a further patch, beyond the scope of this series.
+
+Included some 80-column cleanup around folio_batch_add_and_move().
+
+The role of folio_test_clear_lru() (before taking per-memcg lru_lock) is
+questionable since 6.13 removed mem_cgroup_move_account() etc; but perhaps
+there are still some races which need it - not examined here.
+
+Link: https://lore.kernel.org/linux-mm/DU0PR01MB10385345F7153F334100981888259A@DU0PR01MB10385.eurprd01.prod.exchangelabs.com/
+Link: https://lkml.kernel.org/r/05905d7b-ed14-68b1-79d8-bdec30367eba@google.com
+Signed-off-by: Hugh Dickins <hughd@google.com>
+Acked-by: David Hildenbrand <david@redhat.com>
+Cc: "Aneesh Kumar K.V" <aneesh.kumar@kernel.org>
+Cc: Axel Rasmussen <axelrasmussen@google.com>
+Cc: Chris Li <chrisl@kernel.org>
+Cc: Christoph Hellwig <hch@infradead.org>
+Cc: Jason Gunthorpe <jgg@ziepe.ca>
+Cc: Johannes Weiner <hannes@cmpxchg.org>
+Cc: John Hubbard <jhubbard@nvidia.com>
+Cc: Keir Fraser <keirf@google.com>
+Cc: Konstantin Khlebnikov <koct9i@gmail.com>
+Cc: Li Zhe <lizhe.67@bytedance.com>
+Cc: Matthew Wilcox (Oracle) <willy@infradead.org>
+Cc: Peter Xu <peterx@redhat.com>
+Cc: Rik van Riel <riel@surriel.com>
+Cc: Shivank Garg <shivankg@amd.com>
+Cc: Vlastimil Babka <vbabka@suse.cz>
+Cc: Wei Xu <weixugc@google.com>
+Cc: Will Deacon <will@kernel.org>
+Cc: yangge <yangge1116@126.com>
+Cc: Yuanchu Xie <yuanchu@google.com>
+Cc: Yu Zhao <yuzhao@google.com>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+[ Resolved conflicts in applying the revert to this tree ]
+Signed-off-by: Hugh Dickins <hughd@google.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ mm/swap.c | 51 +++++++++++++++++++++++++++------------------------
+ 1 file changed, 27 insertions(+), 24 deletions(-)
+
+diff --git a/mm/swap.c b/mm/swap.c
+index 59f30a981c6f9..d4cb4898f573e 100644
+--- a/mm/swap.c
++++ b/mm/swap.c
+@@ -195,6 +195,10 @@ static void folio_batch_move_lru(struct folio_batch *fbatch, move_fn_t move_fn)
+ for (i = 0; i < folio_batch_count(fbatch); i++) {
+ struct folio *folio = fbatch->folios[i];
+
++ /* block memcg migration while the folio moves between lru */
++ if (move_fn != lru_add && !folio_test_clear_lru(folio))
++ continue;
++
+ folio_lruvec_relock_irqsave(folio, &lruvec, &flags);
+ move_fn(lruvec, folio);
+
+@@ -207,14 +211,10 @@ static void folio_batch_move_lru(struct folio_batch *fbatch, move_fn_t move_fn)
+ }
+
+ static void __folio_batch_add_and_move(struct folio_batch __percpu *fbatch,
+- struct folio *folio, move_fn_t move_fn,
+- bool on_lru, bool disable_irq)
++ struct folio *folio, move_fn_t move_fn, bool disable_irq)
+ {
+ unsigned long flags;
+
+- if (on_lru && !folio_test_clear_lru(folio))
+- return;
+-
+ folio_get(folio);
+
+ if (disable_irq)
+@@ -222,8 +222,8 @@ static void __folio_batch_add_and_move(struct folio_batch __percpu *fbatch,
+ else
+ local_lock(&cpu_fbatches.lock);
+
+- if (!folio_batch_add(this_cpu_ptr(fbatch), folio) || folio_test_large(folio) ||
+- lru_cache_disabled())
++ if (!folio_batch_add(this_cpu_ptr(fbatch), folio) ||
++ folio_test_large(folio) || lru_cache_disabled())
+ folio_batch_move_lru(this_cpu_ptr(fbatch), move_fn);
+
+ if (disable_irq)
+@@ -232,13 +232,13 @@ static void __folio_batch_add_and_move(struct folio_batch __percpu *fbatch,
+ local_unlock(&cpu_fbatches.lock);
+ }
+
+-#define folio_batch_add_and_move(folio, op, on_lru) \
+- __folio_batch_add_and_move( \
+- &cpu_fbatches.op, \
+- folio, \
+- op, \
+- on_lru, \
+- offsetof(struct cpu_fbatches, op) >= offsetof(struct cpu_fbatches, lock_irq) \
++#define folio_batch_add_and_move(folio, op) \
++ __folio_batch_add_and_move( \
++ &cpu_fbatches.op, \
++ folio, \
++ op, \
++ offsetof(struct cpu_fbatches, op) >= \
++ offsetof(struct cpu_fbatches, lock_irq) \
+ )
+
+ static void lru_move_tail(struct lruvec *lruvec, struct folio *folio)
+@@ -262,10 +262,10 @@ static void lru_move_tail(struct lruvec *lruvec, struct folio *folio)
+ void folio_rotate_reclaimable(struct folio *folio)
+ {
+ if (folio_test_locked(folio) || folio_test_dirty(folio) ||
+- folio_test_unevictable(folio))
++ folio_test_unevictable(folio) || !folio_test_lru(folio))
+ return;
+
+- folio_batch_add_and_move(folio, lru_move_tail, true);
++ folio_batch_add_and_move(folio, lru_move_tail);
+ }
+
+ void lru_note_cost(struct lruvec *lruvec, bool file,
+@@ -354,10 +354,11 @@ static void folio_activate_drain(int cpu)
+
+ void folio_activate(struct folio *folio)
+ {
+- if (folio_test_active(folio) || folio_test_unevictable(folio))
++ if (folio_test_active(folio) || folio_test_unevictable(folio) ||
++ !folio_test_lru(folio))
+ return;
+
+- folio_batch_add_and_move(folio, lru_activate, true);
++ folio_batch_add_and_move(folio, lru_activate);
+ }
+
+ #else
+@@ -510,7 +511,7 @@ void folio_add_lru(struct folio *folio)
+ lru_gen_in_fault() && !(current->flags & PF_MEMALLOC))
+ folio_set_active(folio);
+
+- folio_batch_add_and_move(folio, lru_add, false);
++ folio_batch_add_and_move(folio, lru_add);
+ }
+ EXPORT_SYMBOL(folio_add_lru);
+
+@@ -685,10 +686,10 @@ void lru_add_drain_cpu(int cpu)
+ void deactivate_file_folio(struct folio *folio)
+ {
+ /* Deactivating an unevictable folio will not accelerate reclaim */
+- if (folio_test_unevictable(folio))
++ if (folio_test_unevictable(folio) || !folio_test_lru(folio))
+ return;
+
+- folio_batch_add_and_move(folio, lru_deactivate_file, true);
++ folio_batch_add_and_move(folio, lru_deactivate_file);
+ }
+
+ /*
+@@ -701,10 +702,11 @@ void deactivate_file_folio(struct folio *folio)
+ */
+ void folio_deactivate(struct folio *folio)
+ {
+- if (folio_test_unevictable(folio) || !(folio_test_active(folio) || lru_gen_enabled()))
++ if (folio_test_unevictable(folio) || !folio_test_lru(folio) ||
++ !(folio_test_active(folio) || lru_gen_enabled()))
+ return;
+
+- folio_batch_add_and_move(folio, lru_deactivate, true);
++ folio_batch_add_and_move(folio, lru_deactivate);
+ }
+
+ /**
+@@ -717,10 +719,11 @@ void folio_deactivate(struct folio *folio)
+ void folio_mark_lazyfree(struct folio *folio)
+ {
+ if (!folio_test_anon(folio) || !folio_test_swapbacked(folio) ||
++ !folio_test_lru(folio) ||
+ folio_test_swapcache(folio) || folio_test_unevictable(folio))
+ return;
+
+- folio_batch_add_and_move(folio, lru_lazyfree, true);
++ folio_batch_add_and_move(folio, lru_lazyfree);
+ }
+
+ void lru_add_drain(void)
+--
+2.51.0
+
--- /dev/null
+From 84e91666c16616f8b5cf0eb55483936ec225da07 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Mon, 22 Sep 2025 15:19:57 -0400
+Subject: net: allow alloc_skb_with_frags() to use MAX_SKB_FRAGS
+
+From: Jason Baron <jbaron@akamai.com>
+
+[ Upstream commit ca9f9cdc4de97d0221100b11224738416696163c ]
+
+Currently, alloc_skb_with_frags() will only fill (MAX_SKB_FRAGS - 1)
+slots. I think it should use all MAX_SKB_FRAGS slots, as callers of
+alloc_skb_with_frags() will size their allocation of frags based
+on MAX_SKB_FRAGS.
+
+This issue was discovered via a test patch that sets 'order' to 0
+in alloc_skb_with_frags(), which effectively tests/simulates high
+fragmentation. In this case sendmsg() on unix sockets will fail every
+time for large allocations. If the PAGE_SIZE is 4K, then data_len will
+request 68K or 17 pages, but alloc_skb_with_frags() can only allocate
+64K in this case or 16 pages.
+
+Fixes: 09c2c90705bb ("net: allow alloc_skb_with_frags() to allocate bigger packets")
+Signed-off-by: Jason Baron <jbaron@akamai.com>
+Reviewed-by: Eric Dumazet <edumazet@google.com>
+Link: https://patch.msgid.link/20250922191957.2855612-1-jbaron@akamai.com
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ net/core/skbuff.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/net/core/skbuff.c b/net/core/skbuff.c
+index cf54593149cce..6a92c03ee6f42 100644
+--- a/net/core/skbuff.c
++++ b/net/core/skbuff.c
+@@ -6603,7 +6603,7 @@ struct sk_buff *alloc_skb_with_frags(unsigned long header_len,
+ return NULL;
+
+ while (data_len) {
+- if (nr_frags == MAX_SKB_FRAGS - 1)
++ if (nr_frags == MAX_SKB_FRAGS)
+ goto failure;
+ while (order && PAGE_ALIGN(data_len) < (PAGE_SIZE << order))
+ order--;
+--
+2.51.0
+
--- /dev/null
+From 1a3ef6f203a2e4ed289c86b6f2fb7ce85868e01e Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 18 Sep 2025 10:21:41 +0300
+Subject: net: dsa: lantiq_gswip: move gswip_add_single_port_br() call to
+ port_setup()
+
+From: Vladimir Oltean <vladimir.oltean@nxp.com>
+
+[ Upstream commit c0054b25e2f1045f47b4954cf13a539e5e6047df ]
+
+A port added to a "single port bridge" operates as standalone, and this
+is mutually exclusive to being part of a Linux bridge. In fact,
+gswip_port_bridge_join() calls gswip_add_single_port_br() with
+add=false, i.e. removes the port from the "single port bridge" to enable
+autonomous forwarding.
+
+The blamed commit seems to have incorrectly thought that ds->ops->port_enable()
+is called one time per port, during the setup phase of the switch.
+
+However, it is actually called during the ndo_open() implementation of
+DSA user ports, which is to say that this sequence of events:
+
+1. ip link set swp0 down
+2. ip link add br0 type bridge
+3. ip link set swp0 master br0
+4. ip link set swp0 up
+
+would cause swp0 to join back the "single port bridge" which step 3 had
+just removed it from.
+
+The correct DSA hook for one-time actions per port at switch init time
+is ds->ops->port_setup(). This is what seems to match the coder's
+intention; also see the comment at the beginning of the file:
+
+ * At the initialization the driver allocates one bridge table entry for
+ ~~~~~~~~~~~~~~~~~~~~~
+ * each switch port which is used when the port is used without an
+ * explicit bridge.
+
+Fixes: 8206e0ce96b3 ("net: dsa: lantiq: Add VLAN unaware bridge offloading")
+Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
+Link: https://patch.msgid.link/20250918072142.894692-2-vladimir.oltean@nxp.com
+Tested-by: Daniel Golle <daniel@makrotopia.org>
+Reviewed-by: Daniel Golle <daniel@makrotopia.org>
+Signed-off-by: Paolo Abeni <pabeni@redhat.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/dsa/lantiq_gswip.c | 18 ++++++++++++++----
+ 1 file changed, 14 insertions(+), 4 deletions(-)
+
+diff --git a/drivers/net/dsa/lantiq_gswip.c b/drivers/net/dsa/lantiq_gswip.c
+index fcd4505f49252..497964a5174bf 100644
+--- a/drivers/net/dsa/lantiq_gswip.c
++++ b/drivers/net/dsa/lantiq_gswip.c
+@@ -685,18 +685,27 @@ static int gswip_add_single_port_br(struct gswip_priv *priv, int port, bool add)
+ return 0;
+ }
+
+-static int gswip_port_enable(struct dsa_switch *ds, int port,
+- struct phy_device *phydev)
++static int gswip_port_setup(struct dsa_switch *ds, int port)
+ {
+ struct gswip_priv *priv = ds->priv;
+ int err;
+
+ if (!dsa_is_cpu_port(ds, port)) {
+- u32 mdio_phy = 0;
+-
+ err = gswip_add_single_port_br(priv, port, true);
+ if (err)
+ return err;
++ }
++
++ return 0;
++}
++
++static int gswip_port_enable(struct dsa_switch *ds, int port,
++ struct phy_device *phydev)
++{
++ struct gswip_priv *priv = ds->priv;
++
++ if (!dsa_is_cpu_port(ds, port)) {
++ u32 mdio_phy = 0;
+
+ if (phydev)
+ mdio_phy = phydev->mdio.addr & GSWIP_MDIO_PHY_ADDR_MASK;
+@@ -1829,6 +1838,7 @@ static const struct phylink_mac_ops gswip_phylink_mac_ops = {
+ static const struct dsa_switch_ops gswip_xrx200_switch_ops = {
+ .get_tag_protocol = gswip_get_tag_protocol,
+ .setup = gswip_setup,
++ .port_setup = gswip_port_setup,
+ .port_enable = gswip_port_enable,
+ .port_disable = gswip_port_disable,
+ .port_bridge_join = gswip_port_bridge_join,
+--
+2.51.0
+
--- /dev/null
+From 42c738b785be79cde81909bdd4338f2c72179f13 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 18 Sep 2025 10:21:42 +0300
+Subject: net: dsa: lantiq_gswip: suppress -EINVAL errors for bridge FDB
+ entries added to the CPU port
+
+From: Vladimir Oltean <vladimir.oltean@nxp.com>
+
+[ Upstream commit 987afe147965ef7a8e7d144ffef0d70af14bb1d4 ]
+
+The blamed commit and others in that patch set started the trend
+of reusing existing DSA driver API for a new purpose: calling
+ds->ops->port_fdb_add() on the CPU port.
+
+The lantiq_gswip driver was not prepared to handle that, as can be seen
+from the many errors that Daniel presents in the logs:
+
+[ 174.050000] gswip 1e108000.switch: port 2 failed to add fa:aa:72:f4:8b:1e vid 1 to fdb: -22
+[ 174.060000] gswip 1e108000.switch lan2: entered promiscuous mode
+[ 174.070000] gswip 1e108000.switch: port 2 failed to add 00:01:02:03:04:02 vid 0 to fdb: -22
+[ 174.090000] gswip 1e108000.switch: port 2 failed to add 00:01:02:03:04:02 vid 1 to fdb: -22
+[ 174.090000] gswip 1e108000.switch: port 2 failed to delete fa:aa:72:f4:8b:1e vid 1 from fdb: -2
+
+The errors are because gswip_port_fdb() wants to get a handle to the
+bridge that originated these FDB events, to associate it with a FID.
+Absolutely honourable purpose, however this only works for user ports.
+
+To get the bridge that generated an FDB entry for the CPU port, one
+would need to look at the db.bridge.dev argument. But this was
+introduced in commit c26933639b54 ("net: dsa: request drivers to perform
+FDB isolation"), first appeared in v5.18, and when the blamed commit was
+introduced in v5.14, no such API existed.
+
+So the core DSA feature was introduced way too soon for lantiq_gswip.
+Not acting on these host FDB entries and suppressing any errors has no
+other negative effect, and practically returns us to not supporting the
+host filtering feature at all - peacefully, this time.
+
+Fixes: 10fae4ac89ce ("net: dsa: include bridge addresses which are local in the host fdb list")
+Reported-by: Daniel Golle <daniel@makrotopia.org>
+Closes: https://lore.kernel.org/netdev/aJfNMLNoi1VOsPrN@pidgin.makrotopia.org/
+Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
+Link: https://patch.msgid.link/20250918072142.894692-3-vladimir.oltean@nxp.com
+Tested-by: Daniel Golle <daniel@makrotopia.org>
+Reviewed-by: Daniel Golle <daniel@makrotopia.org>
+Signed-off-by: Paolo Abeni <pabeni@redhat.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/dsa/lantiq_gswip.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+diff --git a/drivers/net/dsa/lantiq_gswip.c b/drivers/net/dsa/lantiq_gswip.c
+index 497964a5174bf..b1f18a840da77 100644
+--- a/drivers/net/dsa/lantiq_gswip.c
++++ b/drivers/net/dsa/lantiq_gswip.c
+@@ -1368,8 +1368,9 @@ static int gswip_port_fdb(struct dsa_switch *ds, int port,
+ int i;
+ int err;
+
++ /* Operation not supported on the CPU port, don't throw errors */
+ if (!bridge)
+- return -EINVAL;
++ return 0;
+
+ for (i = max_ports; i < ARRAY_SIZE(priv->vlans); i++) {
+ if (priv->vlans[i].bridge == bridge) {
+--
+2.51.0
+
--- /dev/null
+From 10a00703e836cb9b62db85ebdb834a4a93ccab65 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 17 Sep 2025 20:42:20 +0200
+Subject: net/smc: fix warning in smc_rx_splice() when calling get_page()
+
+From: Sidraya Jayagond <sidraya@linux.ibm.com>
+
+[ Upstream commit a35c04de2565db191726b5741e6b66a35002c652 ]
+
+smc_lo_register_dmb() allocates DMB buffers with kzalloc(), which are
+later passed to get_page() in smc_rx_splice(). Since kmalloc memory is
+not page-backed, this triggers WARN_ON_ONCE() in get_page() and prevents
+holding a refcount on the buffer. This can lead to use-after-free if
+the memory is released before splice_to_pipe() completes.
+
+Use folio_alloc() instead, ensuring DMBs are page-backed and safe for
+get_page().
+
+WARNING: CPU: 18 PID: 12152 at ./include/linux/mm.h:1330 smc_rx_splice+0xaf8/0xe20 [smc]
+CPU: 18 UID: 0 PID: 12152 Comm: smcapp Kdump: loaded Not tainted 6.17.0-rc3-11705-g9cf4672ecfee #10 NONE
+Hardware name: IBM 3931 A01 704 (z/VM 7.4.0)
+Krnl PSW : 0704e00180000000 000793161032696c (smc_rx_splice+0xafc/0xe20 [smc])
+ R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:2 PM:0 RI:0 EA:3
+Krnl GPRS: 0000000000000000 001cee80007d3001 00077400000000f8 0000000000000005
+ 0000000000000001 001cee80007d3006 0007740000001000 001c000000000000
+ 000000009b0c99e0 0000000000001000 001c0000000000f8 001c000000000000
+ 000003ffcc6f7c88 0007740003e98000 0007931600000005 000792969b2ff7b8
+Krnl Code: 0007931610326960: af000000 mc 0,0
+ 0007931610326964: a7f4ff43 brc 15,00079316103267ea
+ #0007931610326968: af000000 mc 0,0
+ >000793161032696c: a7f4ff3f brc 15,00079316103267ea
+ 0007931610326970: e320f1000004 lg %r2,256(%r15)
+ 0007931610326976: c0e53fd1b5f5 brasl %r14,000793168fd5d560
+ 000793161032697c: a7f4fbb5 brc 15,00079316103260e6
+ 0007931610326980: b904002b lgr %r2,%r11
+Call Trace:
+ smc_rx_splice+0xafc/0xe20 [smc]
+ smc_rx_splice+0x756/0xe20 [smc])
+ smc_rx_recvmsg+0xa74/0xe00 [smc]
+ smc_splice_read+0x1ce/0x3b0 [smc]
+ sock_splice_read+0xa2/0xf0
+ do_splice_read+0x198/0x240
+ splice_file_to_pipe+0x7e/0x110
+ do_splice+0x59e/0xde0
+ __do_splice+0x11a/0x2d0
+ __s390x_sys_splice+0x140/0x1f0
+ __do_syscall+0x122/0x280
+ system_call+0x6e/0x90
+Last Breaking-Event-Address:
+smc_rx_splice+0x960/0xe20 [smc]
+---[ end trace 0000000000000000 ]---
+
+Fixes: f7a22071dbf3 ("net/smc: implement DMB-related operations of loopback-ism")
+Reviewed-by: Mahanta Jambigi <mjambigi@linux.ibm.com>
+Signed-off-by: Sidraya Jayagond <sidraya@linux.ibm.com>
+Link: https://patch.msgid.link/20250917184220.801066-1-sidraya@linux.ibm.com
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ net/smc/smc_loopback.c | 14 +++++++++-----
+ 1 file changed, 9 insertions(+), 5 deletions(-)
+
+diff --git a/net/smc/smc_loopback.c b/net/smc/smc_loopback.c
+index 3c5f64ca41153..85f0b7853b173 100644
+--- a/net/smc/smc_loopback.c
++++ b/net/smc/smc_loopback.c
+@@ -56,6 +56,7 @@ static int smc_lo_register_dmb(struct smcd_dev *smcd, struct smcd_dmb *dmb,
+ {
+ struct smc_lo_dmb_node *dmb_node, *tmp_node;
+ struct smc_lo_dev *ldev = smcd->priv;
++ struct folio *folio;
+ int sba_idx, rc;
+
+ /* check space for new dmb */
+@@ -74,13 +75,16 @@ static int smc_lo_register_dmb(struct smcd_dev *smcd, struct smcd_dmb *dmb,
+
+ dmb_node->sba_idx = sba_idx;
+ dmb_node->len = dmb->dmb_len;
+- dmb_node->cpu_addr = kzalloc(dmb_node->len, GFP_KERNEL |
+- __GFP_NOWARN | __GFP_NORETRY |
+- __GFP_NOMEMALLOC);
+- if (!dmb_node->cpu_addr) {
++
++ /* not critical; fail under memory pressure and fallback to TCP */
++ folio = folio_alloc(GFP_KERNEL | __GFP_NOWARN | __GFP_NOMEMALLOC |
++ __GFP_NORETRY | __GFP_ZERO,
++ get_order(dmb_node->len));
++ if (!folio) {
+ rc = -ENOMEM;
+ goto err_node;
+ }
++ dmb_node->cpu_addr = folio_address(folio);
+ dmb_node->dma_addr = SMC_DMA_ADDR_INVALID;
+ refcount_set(&dmb_node->refcnt, 1);
+
+@@ -122,7 +126,7 @@ static void __smc_lo_unregister_dmb(struct smc_lo_dev *ldev,
+ write_unlock_bh(&ldev->dmb_ht_lock);
+
+ clear_bit(dmb_node->sba_idx, ldev->sba_idx_mask);
+- kvfree(dmb_node->cpu_addr);
++ folio_put(virt_to_folio(dmb_node->cpu_addr));
+ kfree(dmb_node);
+
+ if (atomic_dec_and_test(&ldev->dmb_cnt))
+--
+2.51.0
+
--- /dev/null
+From fcd92562db4890d3507c441524034cfebae713fb Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 17 Sep 2025 19:39:19 +0800
+Subject: net: tun: Update napi->skb after XDP process
+
+From: Wang Liang <wangliang74@huawei.com>
+
+[ Upstream commit 1091860a16a86ccdd77c09f2b21a5f634f5ab9ec ]
+
+The syzbot report a UAF issue:
+
+ BUG: KASAN: slab-use-after-free in skb_reset_mac_header include/linux/skbuff.h:3150 [inline]
+ BUG: KASAN: slab-use-after-free in napi_frags_skb net/core/gro.c:723 [inline]
+ BUG: KASAN: slab-use-after-free in napi_gro_frags+0x6e/0x1030 net/core/gro.c:758
+ Read of size 8 at addr ffff88802ef22c18 by task syz.0.17/6079
+ CPU: 0 UID: 0 PID: 6079 Comm: syz.0.17 Not tainted syzkaller #0 PREEMPT(full)
+ Call Trace:
+ <TASK>
+ dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120
+ print_address_description mm/kasan/report.c:378 [inline]
+ print_report+0xca/0x240 mm/kasan/report.c:482
+ kasan_report+0x118/0x150 mm/kasan/report.c:595
+ skb_reset_mac_header include/linux/skbuff.h:3150 [inline]
+ napi_frags_skb net/core/gro.c:723 [inline]
+ napi_gro_frags+0x6e/0x1030 net/core/gro.c:758
+ tun_get_user+0x28cb/0x3e20 drivers/net/tun.c:1920
+ tun_chr_write_iter+0x113/0x200 drivers/net/tun.c:1996
+ new_sync_write fs/read_write.c:593 [inline]
+ vfs_write+0x5c9/0xb30 fs/read_write.c:686
+ ksys_write+0x145/0x250 fs/read_write.c:738
+ do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
+ do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94
+ entry_SYSCALL_64_after_hwframe+0x77/0x7f
+ </TASK>
+
+ Allocated by task 6079:
+ kasan_save_stack mm/kasan/common.c:47 [inline]
+ kasan_save_track+0x3e/0x80 mm/kasan/common.c:68
+ unpoison_slab_object mm/kasan/common.c:330 [inline]
+ __kasan_mempool_unpoison_object+0xa0/0x170 mm/kasan/common.c:558
+ kasan_mempool_unpoison_object include/linux/kasan.h:388 [inline]
+ napi_skb_cache_get+0x37b/0x6d0 net/core/skbuff.c:295
+ __alloc_skb+0x11e/0x2d0 net/core/skbuff.c:657
+ napi_alloc_skb+0x84/0x7d0 net/core/skbuff.c:811
+ napi_get_frags+0x69/0x140 net/core/gro.c:673
+ tun_napi_alloc_frags drivers/net/tun.c:1404 [inline]
+ tun_get_user+0x77c/0x3e20 drivers/net/tun.c:1784
+ tun_chr_write_iter+0x113/0x200 drivers/net/tun.c:1996
+ new_sync_write fs/read_write.c:593 [inline]
+ vfs_write+0x5c9/0xb30 fs/read_write.c:686
+ ksys_write+0x145/0x250 fs/read_write.c:738
+ do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
+ do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94
+ entry_SYSCALL_64_after_hwframe+0x77/0x7f
+
+ Freed by task 6079:
+ kasan_save_stack mm/kasan/common.c:47 [inline]
+ kasan_save_track+0x3e/0x80 mm/kasan/common.c:68
+ kasan_save_free_info+0x46/0x50 mm/kasan/generic.c:576
+ poison_slab_object mm/kasan/common.c:243 [inline]
+ __kasan_slab_free+0x5b/0x80 mm/kasan/common.c:275
+ kasan_slab_free include/linux/kasan.h:233 [inline]
+ slab_free_hook mm/slub.c:2422 [inline]
+ slab_free mm/slub.c:4695 [inline]
+ kmem_cache_free+0x18f/0x400 mm/slub.c:4797
+ skb_pp_cow_data+0xdd8/0x13e0 net/core/skbuff.c:969
+ netif_skb_check_for_xdp net/core/dev.c:5390 [inline]
+ netif_receive_generic_xdp net/core/dev.c:5431 [inline]
+ do_xdp_generic+0x699/0x11a0 net/core/dev.c:5499
+ tun_get_user+0x2523/0x3e20 drivers/net/tun.c:1872
+ tun_chr_write_iter+0x113/0x200 drivers/net/tun.c:1996
+ new_sync_write fs/read_write.c:593 [inline]
+ vfs_write+0x5c9/0xb30 fs/read_write.c:686
+ ksys_write+0x145/0x250 fs/read_write.c:738
+ do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
+ do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94
+ entry_SYSCALL_64_after_hwframe+0x77/0x7f
+
+After commit e6d5dbdd20aa ("xdp: add multi-buff support for xdp running in
+generic mode"), the original skb may be freed in skb_pp_cow_data() when
+XDP program was attached, which was allocated in tun_napi_alloc_frags().
+However, the napi->skb still point to the original skb, update it after
+XDP process.
+
+Reported-by: syzbot+64e24275ad95a915a313@syzkaller.appspotmail.com
+Closes: https://syzkaller.appspot.com/bug?extid=64e24275ad95a915a313
+Fixes: e6d5dbdd20aa ("xdp: add multi-buff support for xdp running in generic mode")
+Signed-off-by: Wang Liang <wangliang74@huawei.com>
+Reviewed-by: Willem de Bruijn <willemb@google.com>
+Link: https://patch.msgid.link/20250917113919.3991267-1-wangliang74@huawei.com
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/tun.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+diff --git a/drivers/net/tun.c b/drivers/net/tun.c
+index fae1a0ab36bdf..fb9d425eff8c1 100644
+--- a/drivers/net/tun.c
++++ b/drivers/net/tun.c
+@@ -1932,6 +1932,9 @@ static ssize_t tun_get_user(struct tun_struct *tun, struct tun_file *tfile,
+ local_bh_enable();
+ goto unlock_frags;
+ }
++
++ if (frags && skb != tfile->napi.skb)
++ tfile->napi.skb = skb;
+ }
+ rcu_read_unlock();
+ local_bh_enable();
+--
+2.51.0
+
--- /dev/null
+From dc8a0270bd68654b34d73a485ad803a2f367c1b4 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Sun, 21 Sep 2025 18:08:22 +0300
+Subject: nexthop: Forbid FDB status change while nexthop is in a group
+
+From: Ido Schimmel <idosch@nvidia.com>
+
+[ Upstream commit 390b3a300d7872cef9588f003b204398be69ce08 ]
+
+The kernel forbids the creation of non-FDB nexthop groups with FDB
+nexthops:
+
+ # ip nexthop add id 1 via 192.0.2.1 fdb
+ # ip nexthop add id 2 group 1
+ Error: Non FDB nexthop group cannot have fdb nexthops.
+
+And vice versa:
+
+ # ip nexthop add id 3 via 192.0.2.2 dev dummy1
+ # ip nexthop add id 4 group 3 fdb
+ Error: FDB nexthop group can only have fdb nexthops.
+
+However, as long as no routes are pointing to a non-FDB nexthop group,
+the kernel allows changing the type of a nexthop from FDB to non-FDB and
+vice versa:
+
+ # ip nexthop add id 5 via 192.0.2.2 dev dummy1
+ # ip nexthop add id 6 group 5
+ # ip nexthop replace id 5 via 192.0.2.2 fdb
+ # echo $?
+ 0
+
+This configuration is invalid and can result in a NPD [1] since FDB
+nexthops are not associated with a nexthop device:
+
+ # ip route add 198.51.100.1/32 nhid 6
+ # ping 198.51.100.1
+
+Fix by preventing nexthop FDB status change while the nexthop is in a
+group:
+
+ # ip nexthop add id 7 via 192.0.2.2 dev dummy1
+ # ip nexthop add id 8 group 7
+ # ip nexthop replace id 7 via 192.0.2.2 fdb
+ Error: Cannot change nexthop FDB status while in a group.
+
+[1]
+BUG: kernel NULL pointer dereference, address: 00000000000003c0
+[...]
+Oops: Oops: 0000 [#1] SMP
+CPU: 6 UID: 0 PID: 367 Comm: ping Not tainted 6.17.0-rc6-virtme-gb65678cacc03 #1 PREEMPT(voluntary)
+Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-4.fc41 04/01/2014
+RIP: 0010:fib_lookup_good_nhc+0x1e/0x80
+[...]
+Call Trace:
+ <TASK>
+ fib_table_lookup+0x541/0x650
+ ip_route_output_key_hash_rcu+0x2ea/0x970
+ ip_route_output_key_hash+0x55/0x80
+ __ip4_datagram_connect+0x250/0x330
+ udp_connect+0x2b/0x60
+ __sys_connect+0x9c/0xd0
+ __x64_sys_connect+0x18/0x20
+ do_syscall_64+0xa4/0x2a0
+ entry_SYSCALL_64_after_hwframe+0x4b/0x53
+
+Fixes: 38428d68719c ("nexthop: support for fdb ecmp nexthops")
+Reported-by: syzbot+6596516dd2b635ba2350@syzkaller.appspotmail.com
+Closes: https://lore.kernel.org/netdev/68c9a4d2.050a0220.3c6139.0e63.GAE@google.com/
+Tested-by: syzbot+6596516dd2b635ba2350@syzkaller.appspotmail.com
+Signed-off-by: Ido Schimmel <idosch@nvidia.com>
+Reviewed-by: David Ahern <dsahern@kernel.org>
+Link: https://patch.msgid.link/20250921150824.149157-2-idosch@nvidia.com
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ net/ipv4/nexthop.c | 7 +++++++
+ 1 file changed, 7 insertions(+)
+
+diff --git a/net/ipv4/nexthop.c b/net/ipv4/nexthop.c
+index 93aaea0006ba7..c52ff9364ae8d 100644
+--- a/net/ipv4/nexthop.c
++++ b/net/ipv4/nexthop.c
+@@ -2375,6 +2375,13 @@ static int replace_nexthop_single(struct net *net, struct nexthop *old,
+ return -EINVAL;
+ }
+
++ if (!list_empty(&old->grp_list) &&
++ rtnl_dereference(new->nh_info)->fdb_nh !=
++ rtnl_dereference(old->nh_info)->fdb_nh) {
++ NL_SET_ERR_MSG(extack, "Cannot change nexthop FDB status while in a group");
++ return -EINVAL;
++ }
++
+ err = call_nexthop_notifiers(net, NEXTHOP_EVENT_REPLACE, new, extack);
+ if (err)
+ return err;
+--
+2.51.0
+
--- /dev/null
+From c6c67f9d5cf852fdd464dc1b974e66a8056cc2d3 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 23 Sep 2025 14:19:11 +0300
+Subject: octeontx2-pf: Fix potential use after free in otx2_tc_add_flow()
+
+From: Dan Carpenter <dan.carpenter@linaro.org>
+
+[ Upstream commit d9c70e93ec5988ab07ad2a92d9f9d12867f02c56 ]
+
+This code calls kfree_rcu(new_node, rcu) and then dereferences "new_node"
+and then dereferences it on the next line. Two lines later, we take
+a mutex so I don't think this is an RCU safe region. Re-order it to do
+the dereferences before queuing up the free.
+
+Fixes: 68fbff68dbea ("octeontx2-pf: Add police action for TC flower")
+Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
+Reviewed-by: Vadim Fedorenko <vadim.fedorenko@linux.dev>
+Link: https://patch.msgid.link/aNKCL1jKwK8GRJHh@stanley.mountain
+Signed-off-by: Paolo Abeni <pabeni@redhat.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/ethernet/marvell/octeontx2/nic/otx2_tc.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/drivers/net/ethernet/marvell/octeontx2/nic/otx2_tc.c b/drivers/net/ethernet/marvell/octeontx2/nic/otx2_tc.c
+index e63cc1eb6d891..ed041c3f714f2 100644
+--- a/drivers/net/ethernet/marvell/octeontx2/nic/otx2_tc.c
++++ b/drivers/net/ethernet/marvell/octeontx2/nic/otx2_tc.c
+@@ -1319,7 +1319,6 @@ static int otx2_tc_add_flow(struct otx2_nic *nic,
+
+ free_leaf:
+ otx2_tc_del_from_flow_list(flow_cfg, new_node);
+- kfree_rcu(new_node, rcu);
+ if (new_node->is_act_police) {
+ mutex_lock(&nic->mbox.lock);
+
+@@ -1339,6 +1338,7 @@ static int otx2_tc_add_flow(struct otx2_nic *nic,
+
+ mutex_unlock(&nic->mbox.lock);
+ }
++ kfree_rcu(new_node, rcu);
+
+ return rc;
+ }
+--
+2.51.0
+
--- /dev/null
+From 6a82371a116c64cb2ff68030b4aa3dd93d8049b7 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Sun, 21 Sep 2025 18:08:23 +0300
+Subject: selftests: fib_nexthops: Fix creation of non-FDB nexthops
+
+From: Ido Schimmel <idosch@nvidia.com>
+
+[ Upstream commit c29913109c70383cdf90b6fc792353e1009f24f5 ]
+
+The test creates non-FDB nexthops without a nexthop device which leads
+to the expected failure, but for the wrong reason:
+
+ # ./fib_nexthops.sh -t "ipv6_fdb_grp_fcnal ipv4_fdb_grp_fcnal" -v
+
+ IPv6 fdb groups functional
+ --------------------------
+ [...]
+ COMMAND: ip -netns me-nRsN3E nexthop add id 63 via 2001:db8:91::4
+ Error: Device attribute required for non-blackhole and non-fdb nexthops.
+ COMMAND: ip -netns me-nRsN3E nexthop add id 64 via 2001:db8:91::5
+ Error: Device attribute required for non-blackhole and non-fdb nexthops.
+ COMMAND: ip -netns me-nRsN3E nexthop add id 103 group 63/64 fdb
+ Error: Invalid nexthop id.
+ TEST: Fdb Nexthop group with non-fdb nexthops [ OK ]
+ [...]
+
+ IPv4 fdb groups functional
+ --------------------------
+ [...]
+ COMMAND: ip -netns me-nRsN3E nexthop add id 14 via 172.16.1.2
+ Error: Device attribute required for non-blackhole and non-fdb nexthops.
+ COMMAND: ip -netns me-nRsN3E nexthop add id 15 via 172.16.1.3
+ Error: Device attribute required for non-blackhole and non-fdb nexthops.
+ COMMAND: ip -netns me-nRsN3E nexthop add id 103 group 14/15 fdb
+ Error: Invalid nexthop id.
+ TEST: Fdb Nexthop group with non-fdb nexthops [ OK ]
+
+ COMMAND: ip -netns me-nRsN3E nexthop add id 16 via 172.16.1.2 fdb
+ COMMAND: ip -netns me-nRsN3E nexthop add id 17 via 172.16.1.3 fdb
+ COMMAND: ip -netns me-nRsN3E nexthop add id 104 group 14/15
+ Error: Invalid nexthop id.
+ TEST: Non-Fdb Nexthop group with fdb nexthops [ OK ]
+ [...]
+ COMMAND: ip -netns me-0dlhyd ro add 172.16.0.0/22 nhid 15
+ Error: Nexthop id does not exist.
+ TEST: Route add with fdb nexthop [ OK ]
+
+In addition, as can be seen in the above output, a couple of IPv4 test
+cases used the non-FDB nexthops (14 and 15) when they intended to use
+the FDB nexthops (16 and 17). These test cases only passed because
+failure was expected, but they failed for the wrong reason.
+
+Fix the test to create the non-FDB nexthops with a nexthop device and
+adjust the IPv4 test cases to use the FDB nexthops instead of the
+non-FDB nexthops.
+
+Output after the fix:
+
+ # ./fib_nexthops.sh -t "ipv6_fdb_grp_fcnal ipv4_fdb_grp_fcnal" -v
+
+ IPv6 fdb groups functional
+ --------------------------
+ [...]
+ COMMAND: ip -netns me-lNzfHP nexthop add id 63 via 2001:db8:91::4 dev veth1
+ COMMAND: ip -netns me-lNzfHP nexthop add id 64 via 2001:db8:91::5 dev veth1
+ COMMAND: ip -netns me-lNzfHP nexthop add id 103 group 63/64 fdb
+ Error: FDB nexthop group can only have fdb nexthops.
+ TEST: Fdb Nexthop group with non-fdb nexthops [ OK ]
+ [...]
+
+ IPv4 fdb groups functional
+ --------------------------
+ [...]
+ COMMAND: ip -netns me-lNzfHP nexthop add id 14 via 172.16.1.2 dev veth1
+ COMMAND: ip -netns me-lNzfHP nexthop add id 15 via 172.16.1.3 dev veth1
+ COMMAND: ip -netns me-lNzfHP nexthop add id 103 group 14/15 fdb
+ Error: FDB nexthop group can only have fdb nexthops.
+ TEST: Fdb Nexthop group with non-fdb nexthops [ OK ]
+
+ COMMAND: ip -netns me-lNzfHP nexthop add id 16 via 172.16.1.2 fdb
+ COMMAND: ip -netns me-lNzfHP nexthop add id 17 via 172.16.1.3 fdb
+ COMMAND: ip -netns me-lNzfHP nexthop add id 104 group 16/17
+ Error: Non FDB nexthop group cannot have fdb nexthops.
+ TEST: Non-Fdb Nexthop group with fdb nexthops [ OK ]
+ [...]
+ COMMAND: ip -netns me-lNzfHP ro add 172.16.0.0/22 nhid 16
+ Error: Route cannot point to a fdb nexthop.
+ TEST: Route add with fdb nexthop [ OK ]
+ [...]
+ Tests passed: 30
+ Tests failed: 0
+ Tests skipped: 0
+
+Fixes: 0534c5489c11 ("selftests: net: add fdb nexthop tests")
+Signed-off-by: Ido Schimmel <idosch@nvidia.com>
+Reviewed-by: David Ahern <dsahern@kernel.org>
+Link: https://patch.msgid.link/20250921150824.149157-3-idosch@nvidia.com
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ tools/testing/selftests/net/fib_nexthops.sh | 12 ++++++------
+ 1 file changed, 6 insertions(+), 6 deletions(-)
+
+diff --git a/tools/testing/selftests/net/fib_nexthops.sh b/tools/testing/selftests/net/fib_nexthops.sh
+index 77c83d9508d3b..6845da9902818 100755
+--- a/tools/testing/selftests/net/fib_nexthops.sh
++++ b/tools/testing/selftests/net/fib_nexthops.sh
+@@ -465,8 +465,8 @@ ipv6_fdb_grp_fcnal()
+ log_test $? 0 "Get Fdb nexthop group by id"
+
+ # fdb nexthop group can only contain fdb nexthops
+- run_cmd "$IP nexthop add id 63 via 2001:db8:91::4"
+- run_cmd "$IP nexthop add id 64 via 2001:db8:91::5"
++ run_cmd "$IP nexthop add id 63 via 2001:db8:91::4 dev veth1"
++ run_cmd "$IP nexthop add id 64 via 2001:db8:91::5 dev veth1"
+ run_cmd "$IP nexthop add id 103 group 63/64 fdb"
+ log_test $? 2 "Fdb Nexthop group with non-fdb nexthops"
+
+@@ -545,15 +545,15 @@ ipv4_fdb_grp_fcnal()
+ log_test $? 0 "Get Fdb nexthop group by id"
+
+ # fdb nexthop group can only contain fdb nexthops
+- run_cmd "$IP nexthop add id 14 via 172.16.1.2"
+- run_cmd "$IP nexthop add id 15 via 172.16.1.3"
++ run_cmd "$IP nexthop add id 14 via 172.16.1.2 dev veth1"
++ run_cmd "$IP nexthop add id 15 via 172.16.1.3 dev veth1"
+ run_cmd "$IP nexthop add id 103 group 14/15 fdb"
+ log_test $? 2 "Fdb Nexthop group with non-fdb nexthops"
+
+ # Non fdb nexthop group can not contain fdb nexthops
+ run_cmd "$IP nexthop add id 16 via 172.16.1.2 fdb"
+ run_cmd "$IP nexthop add id 17 via 172.16.1.3 fdb"
+- run_cmd "$IP nexthop add id 104 group 14/15"
++ run_cmd "$IP nexthop add id 104 group 16/17"
+ log_test $? 2 "Non-Fdb Nexthop group with fdb nexthops"
+
+ # fdb nexthop cannot have blackhole
+@@ -580,7 +580,7 @@ ipv4_fdb_grp_fcnal()
+ run_cmd "$BRIDGE fdb add 02:02:00:00:00:14 dev vx10 nhid 12 self"
+ log_test $? 255 "Fdb mac add with nexthop"
+
+- run_cmd "$IP ro add 172.16.0.0/22 nhid 15"
++ run_cmd "$IP ro add 172.16.0.0/22 nhid 16"
+ log_test $? 2 "Route add with fdb nexthop"
+
+ run_cmd "$IP ro add 172.16.0.0/22 nhid 103"
+--
+2.51.0
+
wifi-virt_wifi-fix-page-fault-on-connect.patch
can-rcar_can-rcar_can_resume-fix-s2ram-with-psci.patch
bpf-reject-bpf_timer-for-preempt_rt.patch
+xfrm-xfrm_alloc_spi-shouldn-t-use-0-as-spi.patch
+can-etas_es58x-populate-ndo_change_mtu-to-prevent-bu.patch
+can-hi311x-populate-ndo_change_mtu-to-prevent-buffer.patch
+can-sun4i_can-populate-ndo_change_mtu-to-prevent-buf.patch
+can-mcba_usb-populate-ndo_change_mtu-to-prevent-buff.patch
+can-peak_usb-fix-shift-out-of-bounds-issue.patch
+net-tun-update-napi-skb-after-xdp-process.patch
+net-smc-fix-warning-in-smc_rx_splice-when-calling-ge.patch
+ethernet-rvu-af-remove-slash-from-the-driver-name.patch
+bluetooth-hci_sync-fix-hci_resume_advertising_sync.patch
+bluetooth-hci_event-fix-uaf-in-hci_acl_create_conn_s.patch
+vhost-take-a-reference-on-the-task-in-struct-vhost_t.patch
+bnxt_en-correct-offset-handling-for-ipv6-destination.patch
+net-allow-alloc_skb_with_frags-to-use-max_skb_frags.patch
+nexthop-forbid-fdb-status-change-while-nexthop-is-in.patch
+selftests-fib_nexthops-fix-creation-of-non-fdb-nexth.patch
+net-dsa-lantiq_gswip-move-gswip_add_single_port_br-c.patch
+net-dsa-lantiq_gswip-suppress-einval-errors-for-brid.patch
+octeontx2-pf-fix-potential-use-after-free-in-otx2_tc.patch
+mm-gup-local-lru_add_drain-to-avoid-lru_add_drain_al.patch
+mm-revert-mm-gup-clear-the-lru-flag-of-a-page-before.patch
+mm-folio_may_be_lru_cached-unless-folio_test_large.patch
--- /dev/null
+From 328e23e36c2a38619af38d11ef2c764daff74018 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 18 Sep 2025 20:11:44 +0200
+Subject: vhost: Take a reference on the task in struct vhost_task.
+
+From: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
+
+[ Upstream commit afe16653e05db07d658b55245c7a2e0603f136c0 ]
+
+vhost_task_create() creates a task and keeps a reference to its
+task_struct. That task may exit early via a signal and its task_struct
+will be released.
+A pending vhost_task_wake() will then attempt to wake the task and
+access a task_struct which is no longer there.
+
+Acquire a reference on the task_struct while creating the thread and
+release the reference while the struct vhost_task itself is removed.
+If the task exits early due to a signal, then the vhost_task_wake() will
+still access a valid task_struct. The wake is safe and will be skipped
+in this case.
+
+Fixes: f9010dbdce911 ("fork, vhost: Use CLONE_THREAD to fix freezer/ps regression")
+Reported-by: Sean Christopherson <seanjc@google.com>
+Closes: https://lore.kernel.org/all/aKkLEtoDXKxAAWju@google.com/
+Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
+Message-Id: <20250918181144.Ygo8BZ-R@linutronix.de>
+Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
+Tested-by: Sean Christopherson <seanjc@google.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ kernel/vhost_task.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+diff --git a/kernel/vhost_task.c b/kernel/vhost_task.c
+index 2f844c279a3e0..7f24ccc896c64 100644
+--- a/kernel/vhost_task.c
++++ b/kernel/vhost_task.c
+@@ -100,6 +100,7 @@ void vhost_task_stop(struct vhost_task *vtsk)
+ * freeing it below.
+ */
+ wait_for_completion(&vtsk->exited);
++ put_task_struct(vtsk->task);
+ kfree(vtsk);
+ }
+ EXPORT_SYMBOL_GPL(vhost_task_stop);
+@@ -148,7 +149,7 @@ struct vhost_task *vhost_task_create(bool (*fn)(void *),
+ return ERR_PTR(PTR_ERR(tsk));
+ }
+
+- vtsk->task = tsk;
++ vtsk->task = get_task_struct(tsk);
+ return vtsk;
+ }
+ EXPORT_SYMBOL_GPL(vhost_task_create);
+--
+2.51.0
+
--- /dev/null
+From 5cb58e600b044801b11c92e37c76ca7879894501 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 29 Aug 2025 10:54:15 +0200
+Subject: xfrm: xfrm_alloc_spi shouldn't use 0 as SPI
+
+From: Sabrina Dubroca <sd@queasysnail.net>
+
+[ Upstream commit cd8ae32e4e4652db55bce6b9c79267d8946765a9 ]
+
+x->id.spi == 0 means "no SPI assigned", but since commit
+94f39804d891 ("xfrm: Duplicate SPI Handling"), we now create states
+and add them to the byspi list with this value.
+
+__xfrm_state_delete doesn't remove those states from the byspi list,
+since they shouldn't be there, and this shows up as a UAF the next
+time we go through the byspi list.
+
+Reported-by: syzbot+a25ee9d20d31e483ba7b@syzkaller.appspotmail.com
+Closes: https://syzkaller.appspot.com/bug?extid=a25ee9d20d31e483ba7b
+Fixes: 94f39804d891 ("xfrm: Duplicate SPI Handling")
+Signed-off-by: Sabrina Dubroca <sd@queasysnail.net>
+Reviewed-by: Simon Horman <horms@kernel.org>
+Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ net/xfrm/xfrm_state.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+diff --git a/net/xfrm/xfrm_state.c b/net/xfrm/xfrm_state.c
+index 6f99fd2d966c6..1e2f5ecd63248 100644
+--- a/net/xfrm/xfrm_state.c
++++ b/net/xfrm/xfrm_state.c
+@@ -2502,6 +2502,8 @@ int xfrm_alloc_spi(struct xfrm_state *x, u32 low, u32 high,
+
+ for (h = 0; h < range; h++) {
+ u32 spi = (low == high) ? low : get_random_u32_inclusive(low, high);
++ if (spi == 0)
++ goto next;
+ newspi = htonl(spi);
+
+ spin_lock_bh(&net->xfrm.xfrm_state_lock);
+@@ -2517,6 +2519,7 @@ int xfrm_alloc_spi(struct xfrm_state *x, u32 low, u32 high,
+ xfrm_state_put(x0);
+ spin_unlock_bh(&net->xfrm.xfrm_state_lock);
+
++next:
+ if (signal_pending(current)) {
+ err = -ERESTARTSYS;
+ goto unlock;
+--
+2.51.0
+
--- /dev/null
+From 850f143e559c5372be6480dcb379eeaab0339e07 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Mon, 25 Aug 2025 11:10:20 -0400
+Subject: Bluetooth: hci_event: Fix UAF in hci_acl_create_conn_sync
+
+From: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
+
+[ Upstream commit 9e622804d57e2d08f0271200606bd1270f75126f ]
+
+This fixes the following UFA in hci_acl_create_conn_sync where a
+connection still pending is command submission (conn->state == BT_OPEN)
+maybe freed, also since this also can happen with the likes of
+hci_le_create_conn_sync fix it as well:
+
+BUG: KASAN: slab-use-after-free in hci_acl_create_conn_sync+0x5ef/0x790 net/bluetooth/hci_sync.c:6861
+Write of size 2 at addr ffff88805ffcc038 by task kworker/u11:2/9541
+
+CPU: 1 UID: 0 PID: 9541 Comm: kworker/u11:2 Not tainted 6.16.0-rc7 #3 PREEMPT(full)
+Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014
+Workqueue: hci3 hci_cmd_sync_work
+Call Trace:
+ <TASK>
+ dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120
+ print_address_description mm/kasan/report.c:378 [inline]
+ print_report+0xca/0x230 mm/kasan/report.c:480
+ kasan_report+0x118/0x150 mm/kasan/report.c:593
+ hci_acl_create_conn_sync+0x5ef/0x790 net/bluetooth/hci_sync.c:6861
+ hci_cmd_sync_work+0x210/0x3a0 net/bluetooth/hci_sync.c:332
+ process_one_work kernel/workqueue.c:3238 [inline]
+ process_scheduled_works+0xae1/0x17b0 kernel/workqueue.c:3321
+ worker_thread+0x8a0/0xda0 kernel/workqueue.c:3402
+ kthread+0x70e/0x8a0 kernel/kthread.c:464
+ ret_from_fork+0x3fc/0x770 arch/x86/kernel/process.c:148
+ ret_from_fork_asm+0x1a/0x30 home/kwqcheii/source/fuzzing/kernel/kasan/linux-6.16-rc7/arch/x86/entry/entry_64.S:245
+ </TASK>
+
+Allocated by task 123736:
+ kasan_save_stack mm/kasan/common.c:47 [inline]
+ kasan_save_track+0x3e/0x80 mm/kasan/common.c:68
+ poison_kmalloc_redzone mm/kasan/common.c:377 [inline]
+ __kasan_kmalloc+0x93/0xb0 mm/kasan/common.c:394
+ kasan_kmalloc include/linux/kasan.h:260 [inline]
+ __kmalloc_cache_noprof+0x230/0x3d0 mm/slub.c:4359
+ kmalloc_noprof include/linux/slab.h:905 [inline]
+ kzalloc_noprof include/linux/slab.h:1039 [inline]
+ __hci_conn_add+0x233/0x1b30 net/bluetooth/hci_conn.c:939
+ hci_conn_add_unset net/bluetooth/hci_conn.c:1051 [inline]
+ hci_connect_acl+0x16c/0x4e0 net/bluetooth/hci_conn.c:1634
+ pair_device+0x418/0xa70 net/bluetooth/mgmt.c:3556
+ hci_mgmt_cmd+0x9c9/0xef0 net/bluetooth/hci_sock.c:1719
+ hci_sock_sendmsg+0x6ca/0xef0 net/bluetooth/hci_sock.c:1839
+ sock_sendmsg_nosec net/socket.c:712 [inline]
+ __sock_sendmsg+0x219/0x270 net/socket.c:727
+ sock_write_iter+0x258/0x330 net/socket.c:1131
+ new_sync_write fs/read_write.c:593 [inline]
+ vfs_write+0x54b/0xa90 fs/read_write.c:686
+ ksys_write+0x145/0x250 fs/read_write.c:738
+ do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
+ do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94
+ entry_SYSCALL_64_after_hwframe+0x77/0x7f
+
+Freed by task 103680:
+ kasan_save_stack mm/kasan/common.c:47 [inline]
+ kasan_save_track+0x3e/0x80 mm/kasan/common.c:68
+ kasan_save_free_info+0x46/0x50 mm/kasan/generic.c:576
+ poison_slab_object mm/kasan/common.c:247 [inline]
+ __kasan_slab_free+0x62/0x70 mm/kasan/common.c:264
+ kasan_slab_free include/linux/kasan.h:233 [inline]
+ slab_free_hook mm/slub.c:2381 [inline]
+ slab_free mm/slub.c:4643 [inline]
+ kfree+0x18e/0x440 mm/slub.c:4842
+ device_release+0x9c/0x1c0
+ kobject_cleanup lib/kobject.c:689 [inline]
+ kobject_release lib/kobject.c:720 [inline]
+ kref_put include/linux/kref.h:65 [inline]
+ kobject_put+0x22b/0x480 lib/kobject.c:737
+ hci_conn_cleanup net/bluetooth/hci_conn.c:175 [inline]
+ hci_conn_del+0x8ff/0xcb0 net/bluetooth/hci_conn.c:1173
+ hci_conn_complete_evt+0x3c7/0x1040 net/bluetooth/hci_event.c:3199
+ hci_event_func net/bluetooth/hci_event.c:7477 [inline]
+ hci_event_packet+0x7e0/0x1200 net/bluetooth/hci_event.c:7531
+ hci_rx_work+0x46a/0xe80 net/bluetooth/hci_core.c:4070
+ process_one_work kernel/workqueue.c:3238 [inline]
+ process_scheduled_works+0xae1/0x17b0 kernel/workqueue.c:3321
+ worker_thread+0x8a0/0xda0 kernel/workqueue.c:3402
+ kthread+0x70e/0x8a0 kernel/kthread.c:464
+ ret_from_fork+0x3fc/0x770 arch/x86/kernel/process.c:148
+ ret_from_fork_asm+0x1a/0x30 home/kwqcheii/source/fuzzing/kernel/kasan/linux-6.16-rc7/arch/x86/entry/entry_64.S:245
+
+Last potentially related work creation:
+ kasan_save_stack+0x3e/0x60 mm/kasan/common.c:47
+ kasan_record_aux_stack+0xbd/0xd0 mm/kasan/generic.c:548
+ insert_work+0x3d/0x330 kernel/workqueue.c:2183
+ __queue_work+0xbd9/0xfe0 kernel/workqueue.c:2345
+ queue_delayed_work_on+0x18b/0x280 kernel/workqueue.c:2561
+ pairing_complete+0x1e7/0x2b0 net/bluetooth/mgmt.c:3451
+ pairing_complete_cb+0x1ac/0x230 net/bluetooth/mgmt.c:3487
+ hci_connect_cfm include/net/bluetooth/hci_core.h:2064 [inline]
+ hci_conn_failed+0x24d/0x310 net/bluetooth/hci_conn.c:1275
+ hci_conn_complete_evt+0x3c7/0x1040 net/bluetooth/hci_event.c:3199
+ hci_event_func net/bluetooth/hci_event.c:7477 [inline]
+ hci_event_packet+0x7e0/0x1200 net/bluetooth/hci_event.c:7531
+ hci_rx_work+0x46a/0xe80 net/bluetooth/hci_core.c:4070
+ process_one_work kernel/workqueue.c:3238 [inline]
+ process_scheduled_works+0xae1/0x17b0 kernel/workqueue.c:3321
+ worker_thread+0x8a0/0xda0 kernel/workqueue.c:3402
+ kthread+0x70e/0x8a0 kernel/kthread.c:464
+ ret_from_fork+0x3fc/0x770 arch/x86/kernel/process.c:148
+ ret_from_fork_asm+0x1a/0x30 home/kwqcheii/source/fuzzing/kernel/kasan/linux-6.16-rc7/arch/x86/entry/entry_64.S:245
+
+Fixes: aef2aa4fa98e ("Bluetooth: hci_event: Fix creating hci_conn object on error status")
+Reported-by: Junvyyang, Tencent Zhuque Lab <zhuque@tencent.com>
+Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ include/net/bluetooth/hci_core.h | 21 +++++++++++++++++++++
+ net/bluetooth/hci_event.c | 26 +++++++++++++++++++++++---
+ 2 files changed, 44 insertions(+), 3 deletions(-)
+
+diff --git a/include/net/bluetooth/hci_core.h b/include/net/bluetooth/hci_core.h
+index 439bc124ce709..1347ae13dd0a1 100644
+--- a/include/net/bluetooth/hci_core.h
++++ b/include/net/bluetooth/hci_core.h
+@@ -1245,6 +1245,27 @@ static inline struct hci_conn *hci_conn_hash_lookup_ba(struct hci_dev *hdev,
+ return NULL;
+ }
+
++static inline struct hci_conn *hci_conn_hash_lookup_role(struct hci_dev *hdev,
++ __u8 type, __u8 role,
++ bdaddr_t *ba)
++{
++ struct hci_conn_hash *h = &hdev->conn_hash;
++ struct hci_conn *c;
++
++ rcu_read_lock();
++
++ list_for_each_entry_rcu(c, &h->list, list) {
++ if (c->type == type && c->role == role && !bacmp(&c->dst, ba)) {
++ rcu_read_unlock();
++ return c;
++ }
++ }
++
++ rcu_read_unlock();
++
++ return NULL;
++}
++
+ static inline struct hci_conn *hci_conn_hash_lookup_le(struct hci_dev *hdev,
+ bdaddr_t *ba,
+ __u8 ba_type)
+diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c
+index d3d9c3cbd9293..2ef5b3004197b 100644
+--- a/net/bluetooth/hci_event.c
++++ b/net/bluetooth/hci_event.c
+@@ -3087,8 +3087,18 @@ static void hci_conn_complete_evt(struct hci_dev *hdev, void *data,
+
+ hci_dev_lock(hdev);
+
++ /* Check for existing connection:
++ *
++ * 1. If it doesn't exist then it must be receiver/slave role.
++ * 2. If it does exist confirm that it is connecting/BT_CONNECT in case
++ * of initiator/master role since there could be a collision where
++ * either side is attempting to connect or something like a fuzzing
++ * testing is trying to play tricks to destroy the hcon object before
++ * it even attempts to connect (e.g. hcon->state == BT_OPEN).
++ */
+ conn = hci_conn_hash_lookup_ba(hdev, ev->link_type, &ev->bdaddr);
+- if (!conn) {
++ if (!conn ||
++ (conn->role == HCI_ROLE_MASTER && conn->state != BT_CONNECT)) {
+ /* In case of error status and there is no connection pending
+ * just unlock as there is nothing to cleanup.
+ */
+@@ -5638,8 +5648,18 @@ static void le_conn_complete_evt(struct hci_dev *hdev, u8 status,
+ */
+ hci_dev_clear_flag(hdev, HCI_LE_ADV);
+
+- conn = hci_conn_hash_lookup_ba(hdev, LE_LINK, bdaddr);
+- if (!conn) {
++ /* Check for existing connection:
++ *
++ * 1. If it doesn't exist then use the role to create a new object.
++ * 2. If it does exist confirm that it is connecting/BT_CONNECT in case
++ * of initiator/master role since there could be a collision where
++ * either side is attempting to connect or something like a fuzzing
++ * testing is trying to play tricks to destroy the hcon object before
++ * it even attempts to connect (e.g. hcon->state == BT_OPEN).
++ */
++ conn = hci_conn_hash_lookup_role(hdev, LE_LINK, role, bdaddr);
++ if (!conn ||
++ (conn->role == HCI_ROLE_MASTER && conn->state != BT_CONNECT)) {
+ /* In case of error status and there is no connection pending
+ * just unlock as there is nothing to cleanup.
+ */
+--
+2.51.0
+
--- /dev/null
+From 1e86283a5a47fc5f952038b743d7f331625815a5 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Mon, 25 Aug 2025 10:27:29 -0400
+Subject: Bluetooth: hci_event: Fix UAF in hci_conn_tx_dequeue
+
+From: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
+
+[ Upstream commit 2e128683176a56459cef8705fc7c35f438f88abd ]
+
+This fixes the following UAF caused by not properly locking hdev when
+processing HCI_EV_NUM_COMP_PKTS:
+
+BUG: KASAN: slab-use-after-free in hci_conn_tx_dequeue+0x1be/0x220 net/bluetooth/hci_conn.c:3036
+Read of size 4 at addr ffff8880740f0940 by task kworker/u11:0/54
+
+CPU: 1 UID: 0 PID: 54 Comm: kworker/u11:0 Not tainted 6.16.0-rc7 #3 PREEMPT(full)
+Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014
+Workqueue: hci1 hci_rx_work
+Call Trace:
+ <TASK>
+ dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120
+ print_address_description mm/kasan/report.c:378 [inline]
+ print_report+0xca/0x230 mm/kasan/report.c:480
+ kasan_report+0x118/0x150 mm/kasan/report.c:593
+ hci_conn_tx_dequeue+0x1be/0x220 net/bluetooth/hci_conn.c:3036
+ hci_num_comp_pkts_evt+0x1c8/0xa50 net/bluetooth/hci_event.c:4404
+ hci_event_func net/bluetooth/hci_event.c:7477 [inline]
+ hci_event_packet+0x7e0/0x1200 net/bluetooth/hci_event.c:7531
+ hci_rx_work+0x46a/0xe80 net/bluetooth/hci_core.c:4070
+ process_one_work kernel/workqueue.c:3238 [inline]
+ process_scheduled_works+0xae1/0x17b0 kernel/workqueue.c:3321
+ worker_thread+0x8a0/0xda0 kernel/workqueue.c:3402
+ kthread+0x70e/0x8a0 kernel/kthread.c:464
+ ret_from_fork+0x3fc/0x770 arch/x86/kernel/process.c:148
+ ret_from_fork_asm+0x1a/0x30 home/kwqcheii/source/fuzzing/kernel/kasan/linux-6.16-rc7/arch/x86/entry/entry_64.S:245
+ </TASK>
+
+Allocated by task 54:
+ kasan_save_stack mm/kasan/common.c:47 [inline]
+ kasan_save_track+0x3e/0x80 mm/kasan/common.c:68
+ poison_kmalloc_redzone mm/kasan/common.c:377 [inline]
+ __kasan_kmalloc+0x93/0xb0 mm/kasan/common.c:394
+ kasan_kmalloc include/linux/kasan.h:260 [inline]
+ __kmalloc_cache_noprof+0x230/0x3d0 mm/slub.c:4359
+ kmalloc_noprof include/linux/slab.h:905 [inline]
+ kzalloc_noprof include/linux/slab.h:1039 [inline]
+ __hci_conn_add+0x233/0x1b30 net/bluetooth/hci_conn.c:939
+ le_conn_complete_evt+0x3d6/0x1220 net/bluetooth/hci_event.c:5628
+ hci_le_enh_conn_complete_evt+0x189/0x470 net/bluetooth/hci_event.c:5794
+ hci_event_func net/bluetooth/hci_event.c:7474 [inline]
+ hci_event_packet+0x78c/0x1200 net/bluetooth/hci_event.c:7531
+ hci_rx_work+0x46a/0xe80 net/bluetooth/hci_core.c:4070
+ process_one_work kernel/workqueue.c:3238 [inline]
+ process_scheduled_works+0xae1/0x17b0 kernel/workqueue.c:3321
+ worker_thread+0x8a0/0xda0 kernel/workqueue.c:3402
+ kthread+0x70e/0x8a0 kernel/kthread.c:464
+ ret_from_fork+0x3fc/0x770 arch/x86/kernel/process.c:148
+ ret_from_fork_asm+0x1a/0x30 home/kwqcheii/source/fuzzing/kernel/kasan/linux-6.16-rc7/arch/x86/entry/entry_64.S:245
+
+Freed by task 9572:
+ kasan_save_stack mm/kasan/common.c:47 [inline]
+ kasan_save_track+0x3e/0x80 mm/kasan/common.c:68
+ kasan_save_free_info+0x46/0x50 mm/kasan/generic.c:576
+ poison_slab_object mm/kasan/common.c:247 [inline]
+ __kasan_slab_free+0x62/0x70 mm/kasan/common.c:264
+ kasan_slab_free include/linux/kasan.h:233 [inline]
+ slab_free_hook mm/slub.c:2381 [inline]
+ slab_free mm/slub.c:4643 [inline]
+ kfree+0x18e/0x440 mm/slub.c:4842
+ device_release+0x9c/0x1c0
+ kobject_cleanup lib/kobject.c:689 [inline]
+ kobject_release lib/kobject.c:720 [inline]
+ kref_put include/linux/kref.h:65 [inline]
+ kobject_put+0x22b/0x480 lib/kobject.c:737
+ hci_conn_cleanup net/bluetooth/hci_conn.c:175 [inline]
+ hci_conn_del+0x8ff/0xcb0 net/bluetooth/hci_conn.c:1173
+ hci_abort_conn_sync+0x5d1/0xdf0 net/bluetooth/hci_sync.c:5689
+ hci_cmd_sync_work+0x210/0x3a0 net/bluetooth/hci_sync.c:332
+ process_one_work kernel/workqueue.c:3238 [inline]
+ process_scheduled_works+0xae1/0x17b0 kernel/workqueue.c:3321
+ worker_thread+0x8a0/0xda0 kernel/workqueue.c:3402
+ kthread+0x70e/0x8a0 kernel/kthread.c:464
+ ret_from_fork+0x3fc/0x770 arch/x86/kernel/process.c:148
+ ret_from_fork_asm+0x1a/0x30 home/kwqcheii/source/fuzzing/kernel/kasan/linux-6.16-rc7/arch/x86/entry/entry_64.S:245
+
+Fixes: 134f4b39df7b ("Bluetooth: add support for skb TX SND/COMPLETION timestamping")
+Reported-by: Junvyyang, Tencent Zhuque Lab <zhuque@tencent.com>
+Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ net/bluetooth/hci_event.c | 4 ++++
+ 1 file changed, 4 insertions(+)
+
+diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c
+index 090c7ffa51525..d3d9c3cbd9293 100644
+--- a/net/bluetooth/hci_event.c
++++ b/net/bluetooth/hci_event.c
+@@ -4391,6 +4391,8 @@ static void hci_num_comp_pkts_evt(struct hci_dev *hdev, void *data,
+
+ bt_dev_dbg(hdev, "num %d", ev->num);
+
++ hci_dev_lock(hdev);
++
+ for (i = 0; i < ev->num; i++) {
+ struct hci_comp_pkts_info *info = &ev->handles[i];
+ struct hci_conn *conn;
+@@ -4472,6 +4474,8 @@ static void hci_num_comp_pkts_evt(struct hci_dev *hdev, void *data,
+ }
+
+ queue_work(hdev->workqueue, &hdev->tx_work);
++
++ hci_dev_unlock(hdev);
+ }
+
+ static void hci_mode_change_evt(struct hci_dev *hdev, void *data,
+--
+2.51.0
+
--- /dev/null
+From 6c4fd30021a152fee4429a5be02936b620ebbe9b Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 5 Sep 2025 10:29:18 -0400
+Subject: Bluetooth: hci_sync: Fix hci_resume_advertising_sync
+
+From: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
+
+[ Upstream commit 1488af7b8b5f9896ea88ee35aa3301713f72737c ]
+
+hci_resume_advertising_sync is suppose to resume all instance paused by
+hci_pause_advertising_sync, this logic is used for procedures are only
+allowed when not advertising, but instance 0x00 was not being
+re-enabled.
+
+Fixes: ad383c2c65a5 ("Bluetooth: hci_sync: Enable advertising when LL privacy is enabled")
+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 | 7 +++++++
+ 1 file changed, 7 insertions(+)
+
+diff --git a/net/bluetooth/hci_sync.c b/net/bluetooth/hci_sync.c
+index a25439f1eeac2..7ca544d7791f4 100644
+--- a/net/bluetooth/hci_sync.c
++++ b/net/bluetooth/hci_sync.c
+@@ -2594,6 +2594,13 @@ static int hci_resume_advertising_sync(struct hci_dev *hdev)
+ hci_remove_ext_adv_instance_sync(hdev, adv->instance,
+ NULL);
+ }
++
++ /* If current advertising instance is set to instance 0x00
++ * then we need to re-enable it.
++ */
++ if (!hdev->cur_adv_instance)
++ err = hci_enable_ext_advertising_sync(hdev,
++ hdev->cur_adv_instance);
+ } else {
+ /* Schedule for most recent instance to be restarted and begin
+ * the software rotation loop
+--
+2.51.0
+
--- /dev/null
+From a9e0b5d32726bef20a40eebfdef20f44ffb57d7f Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Mon, 25 Aug 2025 10:03:07 -0400
+Subject: Bluetooth: MGMT: Fix possible UAFs
+
+From: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
+
+[ Upstream commit 302a1f674c00dd5581ab8e493ef44767c5101aab ]
+
+This attemps to fix possible UAFs caused by struct mgmt_pending being
+freed while still being processed like in the following trace, in order
+to fix mgmt_pending_valid is introduce and use to check if the
+mgmt_pending hasn't been removed from the pending list, on the complete
+callbacks it is used to check and in addtion remove the cmd from the list
+while holding mgmt_pending_lock to avoid TOCTOU problems since if the cmd
+is left on the list it can still be accessed and freed.
+
+BUG: KASAN: slab-use-after-free in mgmt_add_adv_patterns_monitor_sync+0x35/0x50 net/bluetooth/mgmt.c:5223
+Read of size 8 at addr ffff8880709d4dc0 by task kworker/u11:0/55
+
+CPU: 0 UID: 0 PID: 55 Comm: kworker/u11:0 Not tainted 6.16.4 #2 PREEMPT(full)
+Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014
+Workqueue: hci0 hci_cmd_sync_work
+Call Trace:
+ <TASK>
+ dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120
+ print_address_description mm/kasan/report.c:378 [inline]
+ print_report+0xca/0x240 mm/kasan/report.c:482
+ kasan_report+0x118/0x150 mm/kasan/report.c:595
+ mgmt_add_adv_patterns_monitor_sync+0x35/0x50 net/bluetooth/mgmt.c:5223
+ hci_cmd_sync_work+0x210/0x3a0 net/bluetooth/hci_sync.c:332
+ process_one_work kernel/workqueue.c:3238 [inline]
+ process_scheduled_works+0xade/0x17b0 kernel/workqueue.c:3321
+ worker_thread+0x8a0/0xda0 kernel/workqueue.c:3402
+ kthread+0x711/0x8a0 kernel/kthread.c:464
+ ret_from_fork+0x3fc/0x770 arch/x86/kernel/process.c:148
+ ret_from_fork_asm+0x1a/0x30 home/kwqcheii/source/fuzzing/kernel/kasan/linux-6.16.4/arch/x86/entry/entry_64.S:245
+ </TASK>
+
+Allocated by task 12210:
+ kasan_save_stack mm/kasan/common.c:47 [inline]
+ kasan_save_track+0x3e/0x80 mm/kasan/common.c:68
+ poison_kmalloc_redzone mm/kasan/common.c:377 [inline]
+ __kasan_kmalloc+0x93/0xb0 mm/kasan/common.c:394
+ kasan_kmalloc include/linux/kasan.h:260 [inline]
+ __kmalloc_cache_noprof+0x230/0x3d0 mm/slub.c:4364
+ kmalloc_noprof include/linux/slab.h:905 [inline]
+ kzalloc_noprof include/linux/slab.h:1039 [inline]
+ mgmt_pending_new+0x65/0x1e0 net/bluetooth/mgmt_util.c:269
+ mgmt_pending_add+0x35/0x140 net/bluetooth/mgmt_util.c:296
+ __add_adv_patterns_monitor+0x130/0x200 net/bluetooth/mgmt.c:5247
+ add_adv_patterns_monitor+0x214/0x360 net/bluetooth/mgmt.c:5364
+ hci_mgmt_cmd+0x9c9/0xef0 net/bluetooth/hci_sock.c:1719
+ hci_sock_sendmsg+0x6ca/0xef0 net/bluetooth/hci_sock.c:1839
+ sock_sendmsg_nosec net/socket.c:714 [inline]
+ __sock_sendmsg+0x219/0x270 net/socket.c:729
+ sock_write_iter+0x258/0x330 net/socket.c:1133
+ new_sync_write fs/read_write.c:593 [inline]
+ vfs_write+0x5c9/0xb30 fs/read_write.c:686
+ ksys_write+0x145/0x250 fs/read_write.c:738
+ do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
+ do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94
+ entry_SYSCALL_64_after_hwframe+0x77/0x7f
+
+Freed by task 12221:
+ kasan_save_stack mm/kasan/common.c:47 [inline]
+ kasan_save_track+0x3e/0x80 mm/kasan/common.c:68
+ kasan_save_free_info+0x46/0x50 mm/kasan/generic.c:576
+ poison_slab_object mm/kasan/common.c:247 [inline]
+ __kasan_slab_free+0x62/0x70 mm/kasan/common.c:264
+ kasan_slab_free include/linux/kasan.h:233 [inline]
+ slab_free_hook mm/slub.c:2381 [inline]
+ slab_free mm/slub.c:4648 [inline]
+ kfree+0x18e/0x440 mm/slub.c:4847
+ mgmt_pending_free net/bluetooth/mgmt_util.c:311 [inline]
+ mgmt_pending_foreach+0x30d/0x380 net/bluetooth/mgmt_util.c:257
+ __mgmt_power_off+0x169/0x350 net/bluetooth/mgmt.c:9444
+ hci_dev_close_sync+0x754/0x1330 net/bluetooth/hci_sync.c:5290
+ hci_dev_do_close net/bluetooth/hci_core.c:501 [inline]
+ hci_dev_close+0x108/0x200 net/bluetooth/hci_core.c:526
+ sock_do_ioctl+0xd9/0x300 net/socket.c:1192
+ sock_ioctl+0x576/0x790 net/socket.c:1313
+ vfs_ioctl fs/ioctl.c:51 [inline]
+ __do_sys_ioctl fs/ioctl.c:907 [inline]
+ __se_sys_ioctl+0xf9/0x170 fs/ioctl.c:893
+ do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
+ do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94
+ entry_SYSCALL_64_after_hwframe+0x77/0x7f
+
+Fixes: cf75ad8b41d2 ("Bluetooth: hci_sync: Convert MGMT_SET_POWERED")
+Fixes: 2bd1b237616b ("Bluetooth: hci_sync: Convert MGMT_OP_SET_DISCOVERABLE to use cmd_sync")
+Fixes: f056a65783cc ("Bluetooth: hci_sync: Convert MGMT_OP_SET_CONNECTABLE to use cmd_sync")
+Fixes: 3244845c6307 ("Bluetooth: hci_sync: Convert MGMT_OP_SSP")
+Fixes: d81a494c43df ("Bluetooth: hci_sync: Convert MGMT_OP_SET_LE")
+Fixes: b338d91703fa ("Bluetooth: Implement support for Mesh")
+Fixes: 6f6ff38a1e14 ("Bluetooth: hci_sync: Convert MGMT_OP_SET_LOCAL_NAME")
+Fixes: 71efbb08b538 ("Bluetooth: hci_sync: Convert MGMT_OP_SET_PHY_CONFIGURATION")
+Fixes: b747a83690c8 ("Bluetooth: hci_sync: Refactor add Adv Monitor")
+Fixes: abfeea476c68 ("Bluetooth: hci_sync: Convert MGMT_OP_START_DISCOVERY")
+Fixes: 26ac4c56f03f ("Bluetooth: hci_sync: Convert MGMT_OP_SET_ADVERTISING")
+Reported-by: cen zhang <zzzccc427@gmail.com>
+Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ net/bluetooth/mgmt.c | 259 ++++++++++++++++++++++++++------------
+ net/bluetooth/mgmt_util.c | 46 +++++++
+ net/bluetooth/mgmt_util.h | 3 +
+ 3 files changed, 231 insertions(+), 77 deletions(-)
+
+diff --git a/net/bluetooth/mgmt.c b/net/bluetooth/mgmt.c
+index 50634ef5c8b70..225140fcb3d6c 100644
+--- a/net/bluetooth/mgmt.c
++++ b/net/bluetooth/mgmt.c
+@@ -1323,8 +1323,7 @@ static void mgmt_set_powered_complete(struct hci_dev *hdev, void *data, int err)
+ struct mgmt_mode *cp;
+
+ /* Make sure cmd still outstanding. */
+- if (err == -ECANCELED ||
+- cmd != pending_find(MGMT_OP_SET_POWERED, hdev))
++ if (err == -ECANCELED || !mgmt_pending_valid(hdev, cmd))
+ return;
+
+ cp = cmd->param;
+@@ -1351,23 +1350,29 @@ static void mgmt_set_powered_complete(struct hci_dev *hdev, void *data, int err)
+ mgmt_status(err));
+ }
+
+- mgmt_pending_remove(cmd);
++ mgmt_pending_free(cmd);
+ }
+
+ static int set_powered_sync(struct hci_dev *hdev, void *data)
+ {
+ struct mgmt_pending_cmd *cmd = data;
+- struct mgmt_mode *cp;
++ struct mgmt_mode cp;
++
++ mutex_lock(&hdev->mgmt_pending_lock);
+
+ /* Make sure cmd still outstanding. */
+- if (cmd != pending_find(MGMT_OP_SET_POWERED, hdev))
++ if (!__mgmt_pending_listed(hdev, cmd)) {
++ mutex_unlock(&hdev->mgmt_pending_lock);
+ return -ECANCELED;
++ }
+
+- cp = cmd->param;
++ memcpy(&cp, cmd->param, sizeof(cp));
++
++ mutex_unlock(&hdev->mgmt_pending_lock);
+
+ BT_DBG("%s", hdev->name);
+
+- return hci_set_powered_sync(hdev, cp->val);
++ return hci_set_powered_sync(hdev, cp.val);
+ }
+
+ static int set_powered(struct sock *sk, struct hci_dev *hdev, void *data,
+@@ -1516,8 +1521,7 @@ static void mgmt_set_discoverable_complete(struct hci_dev *hdev, void *data,
+ bt_dev_dbg(hdev, "err %d", err);
+
+ /* Make sure cmd still outstanding. */
+- if (err == -ECANCELED ||
+- cmd != pending_find(MGMT_OP_SET_DISCOVERABLE, hdev))
++ if (err == -ECANCELED || !mgmt_pending_valid(hdev, cmd))
+ return;
+
+ hci_dev_lock(hdev);
+@@ -1539,12 +1543,15 @@ static void mgmt_set_discoverable_complete(struct hci_dev *hdev, void *data,
+ new_settings(hdev, cmd->sk);
+
+ done:
+- mgmt_pending_remove(cmd);
++ mgmt_pending_free(cmd);
+ hci_dev_unlock(hdev);
+ }
+
+ static int set_discoverable_sync(struct hci_dev *hdev, void *data)
+ {
++ if (!mgmt_pending_listed(hdev, data))
++ return -ECANCELED;
++
+ BT_DBG("%s", hdev->name);
+
+ return hci_update_discoverable_sync(hdev);
+@@ -1691,8 +1698,7 @@ static void mgmt_set_connectable_complete(struct hci_dev *hdev, void *data,
+ bt_dev_dbg(hdev, "err %d", err);
+
+ /* Make sure cmd still outstanding. */
+- if (err == -ECANCELED ||
+- cmd != pending_find(MGMT_OP_SET_CONNECTABLE, hdev))
++ if (err == -ECANCELED || !mgmt_pending_valid(hdev, cmd))
+ return;
+
+ hci_dev_lock(hdev);
+@@ -1707,7 +1713,7 @@ static void mgmt_set_connectable_complete(struct hci_dev *hdev, void *data,
+ new_settings(hdev, cmd->sk);
+
+ done:
+- mgmt_pending_remove(cmd);
++ mgmt_pending_free(cmd);
+
+ hci_dev_unlock(hdev);
+ }
+@@ -1743,6 +1749,9 @@ static int set_connectable_update_settings(struct hci_dev *hdev,
+
+ static int set_connectable_sync(struct hci_dev *hdev, void *data)
+ {
++ if (!mgmt_pending_listed(hdev, data))
++ return -ECANCELED;
++
+ BT_DBG("%s", hdev->name);
+
+ return hci_update_connectable_sync(hdev);
+@@ -1919,14 +1928,17 @@ static void set_ssp_complete(struct hci_dev *hdev, void *data, int err)
+ {
+ struct cmd_lookup match = { NULL, hdev };
+ struct mgmt_pending_cmd *cmd = data;
+- struct mgmt_mode *cp = cmd->param;
+- u8 enable = cp->val;
++ struct mgmt_mode *cp;
++ u8 enable;
+ bool changed;
+
+ /* Make sure cmd still outstanding. */
+- if (err == -ECANCELED || cmd != pending_find(MGMT_OP_SET_SSP, hdev))
++ if (err == -ECANCELED || !mgmt_pending_valid(hdev, cmd))
+ return;
+
++ cp = cmd->param;
++ enable = cp->val;
++
+ if (err) {
+ u8 mgmt_err = mgmt_status(err);
+
+@@ -1935,8 +1947,7 @@ static void set_ssp_complete(struct hci_dev *hdev, void *data, int err)
+ new_settings(hdev, NULL);
+ }
+
+- mgmt_pending_foreach(MGMT_OP_SET_SSP, hdev, true,
+- cmd_status_rsp, &mgmt_err);
++ mgmt_cmd_status(cmd->sk, cmd->hdev->id, cmd->opcode, mgmt_err);
+ return;
+ }
+
+@@ -1946,7 +1957,7 @@ static void set_ssp_complete(struct hci_dev *hdev, void *data, int err)
+ changed = hci_dev_test_and_clear_flag(hdev, HCI_SSP_ENABLED);
+ }
+
+- mgmt_pending_foreach(MGMT_OP_SET_SSP, hdev, true, settings_rsp, &match);
++ settings_rsp(cmd, &match);
+
+ if (changed)
+ new_settings(hdev, match.sk);
+@@ -1960,14 +1971,25 @@ static void set_ssp_complete(struct hci_dev *hdev, void *data, int err)
+ static int set_ssp_sync(struct hci_dev *hdev, void *data)
+ {
+ struct mgmt_pending_cmd *cmd = data;
+- struct mgmt_mode *cp = cmd->param;
++ struct mgmt_mode cp;
+ bool changed = false;
+ int err;
+
+- if (cp->val)
++ mutex_lock(&hdev->mgmt_pending_lock);
++
++ if (!__mgmt_pending_listed(hdev, cmd)) {
++ mutex_unlock(&hdev->mgmt_pending_lock);
++ return -ECANCELED;
++ }
++
++ memcpy(&cp, cmd->param, sizeof(cp));
++
++ mutex_unlock(&hdev->mgmt_pending_lock);
++
++ if (cp.val)
+ changed = !hci_dev_test_and_set_flag(hdev, HCI_SSP_ENABLED);
+
+- err = hci_write_ssp_mode_sync(hdev, cp->val);
++ err = hci_write_ssp_mode_sync(hdev, cp.val);
+
+ if (!err && changed)
+ hci_dev_clear_flag(hdev, HCI_SSP_ENABLED);
+@@ -2060,32 +2082,50 @@ static int set_hs(struct sock *sk, struct hci_dev *hdev, void *data, u16 len)
+
+ static void set_le_complete(struct hci_dev *hdev, void *data, int err)
+ {
++ struct mgmt_pending_cmd *cmd = data;
+ struct cmd_lookup match = { NULL, hdev };
+ u8 status = mgmt_status(err);
+
+ bt_dev_dbg(hdev, "err %d", err);
+
+- if (status) {
+- mgmt_pending_foreach(MGMT_OP_SET_LE, hdev, true, cmd_status_rsp,
+- &status);
++ if (err == -ECANCELED || !mgmt_pending_valid(hdev, data))
+ return;
++
++ if (status) {
++ mgmt_cmd_status(cmd->sk, cmd->hdev->id, cmd->opcode, status);
++ goto done;
+ }
+
+- mgmt_pending_foreach(MGMT_OP_SET_LE, hdev, true, settings_rsp, &match);
++ settings_rsp(cmd, &match);
+
+ new_settings(hdev, match.sk);
+
+ if (match.sk)
+ sock_put(match.sk);
++
++done:
++ mgmt_pending_free(cmd);
+ }
+
+ static int set_le_sync(struct hci_dev *hdev, void *data)
+ {
+ struct mgmt_pending_cmd *cmd = data;
+- struct mgmt_mode *cp = cmd->param;
+- u8 val = !!cp->val;
++ struct mgmt_mode cp;
++ u8 val;
+ int err;
+
++ mutex_lock(&hdev->mgmt_pending_lock);
++
++ if (!__mgmt_pending_listed(hdev, cmd)) {
++ mutex_unlock(&hdev->mgmt_pending_lock);
++ return -ECANCELED;
++ }
++
++ memcpy(&cp, cmd->param, sizeof(cp));
++ val = !!cp.val;
++
++ mutex_unlock(&hdev->mgmt_pending_lock);
++
+ if (!val) {
+ hci_clear_adv_instance_sync(hdev, NULL, 0x00, true);
+
+@@ -2127,7 +2167,12 @@ static void set_mesh_complete(struct hci_dev *hdev, void *data, int err)
+ {
+ struct mgmt_pending_cmd *cmd = data;
+ u8 status = mgmt_status(err);
+- struct sock *sk = cmd->sk;
++ struct sock *sk;
++
++ if (err == -ECANCELED || !mgmt_pending_valid(hdev, cmd))
++ return;
++
++ sk = cmd->sk;
+
+ if (status) {
+ mgmt_pending_foreach(MGMT_OP_SET_MESH_RECEIVER, hdev, true,
+@@ -2142,24 +2187,37 @@ static void set_mesh_complete(struct hci_dev *hdev, void *data, int err)
+ static int set_mesh_sync(struct hci_dev *hdev, void *data)
+ {
+ struct mgmt_pending_cmd *cmd = data;
+- struct mgmt_cp_set_mesh *cp = cmd->param;
+- size_t len = cmd->param_len;
++ struct mgmt_cp_set_mesh cp;
++ size_t len;
++
++ mutex_lock(&hdev->mgmt_pending_lock);
++
++ if (!__mgmt_pending_listed(hdev, cmd)) {
++ mutex_unlock(&hdev->mgmt_pending_lock);
++ return -ECANCELED;
++ }
++
++ memcpy(&cp, cmd->param, sizeof(cp));
++
++ mutex_unlock(&hdev->mgmt_pending_lock);
++
++ len = cmd->param_len;
+
+ memset(hdev->mesh_ad_types, 0, sizeof(hdev->mesh_ad_types));
+
+- if (cp->enable)
++ if (cp.enable)
+ hci_dev_set_flag(hdev, HCI_MESH);
+ else
+ hci_dev_clear_flag(hdev, HCI_MESH);
+
+- hdev->le_scan_interval = __le16_to_cpu(cp->period);
+- hdev->le_scan_window = __le16_to_cpu(cp->window);
++ hdev->le_scan_interval = __le16_to_cpu(cp.period);
++ hdev->le_scan_window = __le16_to_cpu(cp.window);
+
+- len -= sizeof(*cp);
++ len -= sizeof(cp);
+
+ /* If filters don't fit, forward all adv pkts */
+ if (len <= sizeof(hdev->mesh_ad_types))
+- memcpy(hdev->mesh_ad_types, cp->ad_types, len);
++ memcpy(hdev->mesh_ad_types, cp.ad_types, len);
+
+ hci_update_passive_scan_sync(hdev);
+ return 0;
+@@ -3867,15 +3925,16 @@ static int name_changed_sync(struct hci_dev *hdev, void *data)
+ static void set_name_complete(struct hci_dev *hdev, void *data, int err)
+ {
+ struct mgmt_pending_cmd *cmd = data;
+- struct mgmt_cp_set_local_name *cp = cmd->param;
++ struct mgmt_cp_set_local_name *cp;
+ u8 status = mgmt_status(err);
+
+ bt_dev_dbg(hdev, "err %d", err);
+
+- if (err == -ECANCELED ||
+- cmd != pending_find(MGMT_OP_SET_LOCAL_NAME, hdev))
++ if (err == -ECANCELED || !mgmt_pending_valid(hdev, cmd))
+ return;
+
++ cp = cmd->param;
++
+ if (status) {
+ mgmt_cmd_status(cmd->sk, hdev->id, MGMT_OP_SET_LOCAL_NAME,
+ status);
+@@ -3887,16 +3946,27 @@ static void set_name_complete(struct hci_dev *hdev, void *data, int err)
+ hci_cmd_sync_queue(hdev, name_changed_sync, NULL, NULL);
+ }
+
+- mgmt_pending_remove(cmd);
++ mgmt_pending_free(cmd);
+ }
+
+ static int set_name_sync(struct hci_dev *hdev, void *data)
+ {
+ struct mgmt_pending_cmd *cmd = data;
+- struct mgmt_cp_set_local_name *cp = cmd->param;
++ struct mgmt_cp_set_local_name cp;
++
++ mutex_lock(&hdev->mgmt_pending_lock);
++
++ if (!__mgmt_pending_listed(hdev, cmd)) {
++ mutex_unlock(&hdev->mgmt_pending_lock);
++ return -ECANCELED;
++ }
++
++ memcpy(&cp, cmd->param, sizeof(cp));
++
++ mutex_unlock(&hdev->mgmt_pending_lock);
+
+ if (lmp_bredr_capable(hdev)) {
+- hci_update_name_sync(hdev, cp->name);
++ hci_update_name_sync(hdev, cp.name);
+ hci_update_eir_sync(hdev);
+ }
+
+@@ -4048,12 +4118,10 @@ int mgmt_phy_configuration_changed(struct hci_dev *hdev, struct sock *skip)
+ static void set_default_phy_complete(struct hci_dev *hdev, void *data, int err)
+ {
+ struct mgmt_pending_cmd *cmd = data;
+- struct sk_buff *skb = cmd->skb;
++ struct sk_buff *skb;
+ u8 status = mgmt_status(err);
+
+- if (err == -ECANCELED ||
+- cmd != pending_find(MGMT_OP_SET_PHY_CONFIGURATION, hdev))
+- return;
++ skb = cmd->skb;
+
+ if (!status) {
+ if (!skb)
+@@ -4080,7 +4148,7 @@ static void set_default_phy_complete(struct hci_dev *hdev, void *data, int err)
+ if (skb && !IS_ERR(skb))
+ kfree_skb(skb);
+
+- mgmt_pending_remove(cmd);
++ mgmt_pending_free(cmd);
+ }
+
+ static int set_default_phy_sync(struct hci_dev *hdev, void *data)
+@@ -4088,7 +4156,9 @@ static int set_default_phy_sync(struct hci_dev *hdev, void *data)
+ struct mgmt_pending_cmd *cmd = data;
+ struct mgmt_cp_set_phy_configuration *cp = cmd->param;
+ struct hci_cp_le_set_default_phy cp_phy;
+- u32 selected_phys = __le32_to_cpu(cp->selected_phys);
++ u32 selected_phys;
++
++ selected_phys = __le32_to_cpu(cp->selected_phys);
+
+ memset(&cp_phy, 0, sizeof(cp_phy));
+
+@@ -4228,7 +4298,7 @@ static int set_phy_configuration(struct sock *sk, struct hci_dev *hdev,
+ goto unlock;
+ }
+
+- cmd = mgmt_pending_add(sk, MGMT_OP_SET_PHY_CONFIGURATION, hdev, data,
++ cmd = mgmt_pending_new(sk, MGMT_OP_SET_PHY_CONFIGURATION, hdev, data,
+ len);
+ if (!cmd)
+ err = -ENOMEM;
+@@ -5189,7 +5259,17 @@ static void mgmt_add_adv_patterns_monitor_complete(struct hci_dev *hdev,
+ {
+ struct mgmt_rp_add_adv_patterns_monitor rp;
+ struct mgmt_pending_cmd *cmd = data;
+- struct adv_monitor *monitor = cmd->user_data;
++ struct adv_monitor *monitor;
++
++ /* This is likely the result of hdev being closed and mgmt_index_removed
++ * is attempting to clean up any pending command so
++ * hci_adv_monitors_clear is about to be called which will take care of
++ * freeing the adv_monitor instances.
++ */
++ if (status == -ECANCELED && !mgmt_pending_valid(hdev, cmd))
++ return;
++
++ monitor = cmd->user_data;
+
+ hci_dev_lock(hdev);
+
+@@ -5215,9 +5295,20 @@ static void mgmt_add_adv_patterns_monitor_complete(struct hci_dev *hdev,
+ static int mgmt_add_adv_patterns_monitor_sync(struct hci_dev *hdev, void *data)
+ {
+ struct mgmt_pending_cmd *cmd = data;
+- struct adv_monitor *monitor = cmd->user_data;
++ struct adv_monitor *mon;
++
++ mutex_lock(&hdev->mgmt_pending_lock);
++
++ if (!__mgmt_pending_listed(hdev, cmd)) {
++ mutex_unlock(&hdev->mgmt_pending_lock);
++ return -ECANCELED;
++ }
++
++ mon = cmd->user_data;
++
++ mutex_unlock(&hdev->mgmt_pending_lock);
+
+- return hci_add_adv_monitor(hdev, monitor);
++ return hci_add_adv_monitor(hdev, mon);
+ }
+
+ static int __add_adv_patterns_monitor(struct sock *sk, struct hci_dev *hdev,
+@@ -5484,7 +5575,8 @@ static int remove_adv_monitor(struct sock *sk, struct hci_dev *hdev,
+ status);
+ }
+
+-static void read_local_oob_data_complete(struct hci_dev *hdev, void *data, int err)
++static void read_local_oob_data_complete(struct hci_dev *hdev, void *data,
++ int err)
+ {
+ struct mgmt_rp_read_local_oob_data mgmt_rp;
+ size_t rp_size = sizeof(mgmt_rp);
+@@ -5504,7 +5596,8 @@ static void read_local_oob_data_complete(struct hci_dev *hdev, void *data, int e
+ bt_dev_dbg(hdev, "status %d", status);
+
+ if (status) {
+- mgmt_cmd_status(cmd->sk, hdev->id, MGMT_OP_READ_LOCAL_OOB_DATA, status);
++ mgmt_cmd_status(cmd->sk, hdev->id, MGMT_OP_READ_LOCAL_OOB_DATA,
++ status);
+ goto remove;
+ }
+
+@@ -5786,17 +5879,12 @@ static void start_discovery_complete(struct hci_dev *hdev, void *data, int err)
+
+ bt_dev_dbg(hdev, "err %d", err);
+
+- if (err == -ECANCELED)
+- return;
+-
+- if (cmd != pending_find(MGMT_OP_START_DISCOVERY, hdev) &&
+- cmd != pending_find(MGMT_OP_START_LIMITED_DISCOVERY, hdev) &&
+- cmd != pending_find(MGMT_OP_START_SERVICE_DISCOVERY, hdev))
++ if (err == -ECANCELED || !mgmt_pending_valid(hdev, cmd))
+ return;
+
+ mgmt_cmd_complete(cmd->sk, cmd->hdev->id, cmd->opcode, mgmt_status(err),
+ cmd->param, 1);
+- mgmt_pending_remove(cmd);
++ mgmt_pending_free(cmd);
+
+ hci_discovery_set_state(hdev, err ? DISCOVERY_STOPPED:
+ DISCOVERY_FINDING);
+@@ -5804,6 +5892,9 @@ static void start_discovery_complete(struct hci_dev *hdev, void *data, int err)
+
+ static int start_discovery_sync(struct hci_dev *hdev, void *data)
+ {
++ if (!mgmt_pending_listed(hdev, data))
++ return -ECANCELED;
++
+ return hci_start_discovery_sync(hdev);
+ }
+
+@@ -6009,15 +6100,14 @@ static void stop_discovery_complete(struct hci_dev *hdev, void *data, int err)
+ {
+ struct mgmt_pending_cmd *cmd = data;
+
+- if (err == -ECANCELED ||
+- cmd != pending_find(MGMT_OP_STOP_DISCOVERY, hdev))
++ if (err == -ECANCELED || !mgmt_pending_valid(hdev, cmd))
+ return;
+
+ bt_dev_dbg(hdev, "err %d", err);
+
+ mgmt_cmd_complete(cmd->sk, cmd->hdev->id, cmd->opcode, mgmt_status(err),
+ cmd->param, 1);
+- mgmt_pending_remove(cmd);
++ mgmt_pending_free(cmd);
+
+ if (!err)
+ hci_discovery_set_state(hdev, DISCOVERY_STOPPED);
+@@ -6025,6 +6115,9 @@ static void stop_discovery_complete(struct hci_dev *hdev, void *data, int err)
+
+ static int stop_discovery_sync(struct hci_dev *hdev, void *data)
+ {
++ if (!mgmt_pending_listed(hdev, data))
++ return -ECANCELED;
++
+ return hci_stop_discovery_sync(hdev);
+ }
+
+@@ -6234,14 +6327,18 @@ static void enable_advertising_instance(struct hci_dev *hdev, int err)
+
+ static void set_advertising_complete(struct hci_dev *hdev, void *data, int err)
+ {
++ struct mgmt_pending_cmd *cmd = data;
+ struct cmd_lookup match = { NULL, hdev };
+ u8 instance;
+ struct adv_info *adv_instance;
+ u8 status = mgmt_status(err);
+
++ if (err == -ECANCELED || !mgmt_pending_valid(hdev, data))
++ return;
++
+ if (status) {
+- mgmt_pending_foreach(MGMT_OP_SET_ADVERTISING, hdev, true,
+- cmd_status_rsp, &status);
++ mgmt_cmd_status(cmd->sk, cmd->hdev->id, cmd->opcode, status);
++ mgmt_pending_free(cmd);
+ return;
+ }
+
+@@ -6250,8 +6347,7 @@ static void set_advertising_complete(struct hci_dev *hdev, void *data, int err)
+ else
+ hci_dev_clear_flag(hdev, HCI_ADVERTISING);
+
+- mgmt_pending_foreach(MGMT_OP_SET_ADVERTISING, hdev, true, settings_rsp,
+- &match);
++ settings_rsp(cmd, &match);
+
+ new_settings(hdev, match.sk);
+
+@@ -6283,10 +6379,23 @@ static void set_advertising_complete(struct hci_dev *hdev, void *data, int err)
+ static int set_adv_sync(struct hci_dev *hdev, void *data)
+ {
+ struct mgmt_pending_cmd *cmd = data;
+- struct mgmt_mode *cp = cmd->param;
+- u8 val = !!cp->val;
++ struct mgmt_mode cp;
++ u8 val;
+
+- if (cp->val == 0x02)
++ mutex_lock(&hdev->mgmt_pending_lock);
++
++ if (!__mgmt_pending_listed(hdev, cmd)) {
++ mutex_unlock(&hdev->mgmt_pending_lock);
++ return -ECANCELED;
++ }
++
++ memcpy(&cp, cmd->param, sizeof(cp));
++
++ mutex_unlock(&hdev->mgmt_pending_lock);
++
++ val = !!cp.val;
++
++ if (cp.val == 0x02)
+ hci_dev_set_flag(hdev, HCI_ADVERTISING_CONNECTABLE);
+ else
+ hci_dev_clear_flag(hdev, HCI_ADVERTISING_CONNECTABLE);
+@@ -8039,10 +8148,6 @@ static void read_local_oob_ext_data_complete(struct hci_dev *hdev, void *data,
+ u8 status = mgmt_status(err);
+ u16 eir_len;
+
+- if (err == -ECANCELED ||
+- cmd != pending_find(MGMT_OP_READ_LOCAL_OOB_EXT_DATA, hdev))
+- return;
+-
+ if (!status) {
+ if (!skb)
+ status = MGMT_STATUS_FAILED;
+@@ -8149,7 +8254,7 @@ static void read_local_oob_ext_data_complete(struct hci_dev *hdev, void *data,
+ kfree_skb(skb);
+
+ kfree(mgmt_rp);
+- mgmt_pending_remove(cmd);
++ mgmt_pending_free(cmd);
+ }
+
+ static int read_local_ssp_oob_req(struct hci_dev *hdev, struct sock *sk,
+@@ -8158,7 +8263,7 @@ static int read_local_ssp_oob_req(struct hci_dev *hdev, struct sock *sk,
+ struct mgmt_pending_cmd *cmd;
+ int err;
+
+- cmd = mgmt_pending_add(sk, MGMT_OP_READ_LOCAL_OOB_EXT_DATA, hdev,
++ cmd = mgmt_pending_new(sk, MGMT_OP_READ_LOCAL_OOB_EXT_DATA, hdev,
+ cp, sizeof(*cp));
+ if (!cmd)
+ return -ENOMEM;
+diff --git a/net/bluetooth/mgmt_util.c b/net/bluetooth/mgmt_util.c
+index a88a07da39473..aa7b5585cb268 100644
+--- a/net/bluetooth/mgmt_util.c
++++ b/net/bluetooth/mgmt_util.c
+@@ -320,6 +320,52 @@ void mgmt_pending_remove(struct mgmt_pending_cmd *cmd)
+ mgmt_pending_free(cmd);
+ }
+
++bool __mgmt_pending_listed(struct hci_dev *hdev, struct mgmt_pending_cmd *cmd)
++{
++ struct mgmt_pending_cmd *tmp;
++
++ lockdep_assert_held(&hdev->mgmt_pending_lock);
++
++ if (!cmd)
++ return false;
++
++ list_for_each_entry(tmp, &hdev->mgmt_pending, list) {
++ if (cmd == tmp)
++ return true;
++ }
++
++ return false;
++}
++
++bool mgmt_pending_listed(struct hci_dev *hdev, struct mgmt_pending_cmd *cmd)
++{
++ bool listed;
++
++ mutex_lock(&hdev->mgmt_pending_lock);
++ listed = __mgmt_pending_listed(hdev, cmd);
++ mutex_unlock(&hdev->mgmt_pending_lock);
++
++ return listed;
++}
++
++bool mgmt_pending_valid(struct hci_dev *hdev, struct mgmt_pending_cmd *cmd)
++{
++ bool listed;
++
++ if (!cmd)
++ return false;
++
++ mutex_lock(&hdev->mgmt_pending_lock);
++
++ listed = __mgmt_pending_listed(hdev, cmd);
++ if (listed)
++ list_del(&cmd->list);
++
++ mutex_unlock(&hdev->mgmt_pending_lock);
++
++ return listed;
++}
++
+ void mgmt_mesh_foreach(struct hci_dev *hdev,
+ void (*cb)(struct mgmt_mesh_tx *mesh_tx, void *data),
+ void *data, struct sock *sk)
+diff --git a/net/bluetooth/mgmt_util.h b/net/bluetooth/mgmt_util.h
+index 024e51dd69375..bcba8c9d89528 100644
+--- a/net/bluetooth/mgmt_util.h
++++ b/net/bluetooth/mgmt_util.h
+@@ -65,6 +65,9 @@ struct mgmt_pending_cmd *mgmt_pending_new(struct sock *sk, u16 opcode,
+ void *data, u16 len);
+ void mgmt_pending_free(struct mgmt_pending_cmd *cmd);
+ void mgmt_pending_remove(struct mgmt_pending_cmd *cmd);
++bool __mgmt_pending_listed(struct hci_dev *hdev, struct mgmt_pending_cmd *cmd);
++bool mgmt_pending_listed(struct hci_dev *hdev, struct mgmt_pending_cmd *cmd);
++bool mgmt_pending_valid(struct hci_dev *hdev, struct mgmt_pending_cmd *cmd);
+ void mgmt_mesh_foreach(struct hci_dev *hdev,
+ void (*cb)(struct mgmt_mesh_tx *mesh_tx, void *data),
+ void *data, struct sock *sk);
+--
+2.51.0
+
--- /dev/null
+From 1a24d35cca6849cd87a14e21bc89175d1033b610 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Sat, 20 Sep 2025 05:11:17 -0700
+Subject: bnxt_en: correct offset handling for IPv6 destination address
+
+From: Alok Tiwari <alok.a.tiwari@oracle.com>
+
+[ Upstream commit 3d3aa9472c6dd0704e9961ed4769caac5b1c8d52 ]
+
+In bnxt_tc_parse_pedit(), the code incorrectly writes IPv6
+destination values to the source address field (saddr) when
+processing pedit offsets within the destination address range.
+
+This patch corrects the assignment to use daddr instead of saddr,
+ensuring that pedit operations on IPv6 destination addresses are
+applied correctly.
+
+Fixes: 9b9eb518e338 ("bnxt_en: Add support for NAT(L3/L4 rewrite)")
+Signed-off-by: Alok Tiwari <alok.a.tiwari@oracle.com>
+Reviewed-by: Somnath Kotur <somnath.kotur@broadcom.com>
+Link: https://patch.msgid.link/20250920121157.351921-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/broadcom/bnxt/bnxt_tc.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt_tc.c b/drivers/net/ethernet/broadcom/bnxt/bnxt_tc.c
+index d2ca90407cce7..8057350236c5e 100644
+--- a/drivers/net/ethernet/broadcom/bnxt/bnxt_tc.c
++++ b/drivers/net/ethernet/broadcom/bnxt/bnxt_tc.c
+@@ -244,7 +244,7 @@ bnxt_tc_parse_pedit(struct bnxt *bp, struct bnxt_tc_actions *actions,
+ offset < offset_of_ip6_daddr + 16) {
+ actions->nat.src_xlate = false;
+ idx = (offset - offset_of_ip6_daddr) / 4;
+- actions->nat.l3.ipv6.saddr.s6_addr32[idx] = htonl(val);
++ actions->nat.l3.ipv6.daddr.s6_addr32[idx] = htonl(val);
+ } else {
+ netdev_err(bp->dev,
+ "%s: IPv6_hdr: Invalid pedit field\n",
+--
+2.51.0
+
--- /dev/null
+From 0a2e4690626c5005e0623e1a1f5e5dbd3b27f73d Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 18 Sep 2025 17:33:17 -0700
+Subject: broadcom: fix support for PTP_EXTTS_REQUEST2 ioctl
+
+From: Jacob Keller <jacob.e.keller@intel.com>
+
+[ Upstream commit 3200fdd4021de1d182fa3b6db5ad936d519f3848 ]
+
+Commit 7c571ac57d9d ("net: ptp: introduce .supported_extts_flags to
+ptp_clock_info") modified the PTP core kernel logic to validate the
+supported flags for the PTP_EXTTS_REQUEST ioctls, rather than relying on
+each individual driver correctly checking its flags.
+
+The bcm_ptp_enable() function implements support for PTP_CLK_REQ_EXTTS, but
+does not check the flags, and does not forward the request structure into
+bcm_ptp_extts_locked().
+
+When originally converting the bcm-phy-ptp.c code, it was unclear what
+edges the hardware actually timestamped. Thus, no flags were initialized in
+the .supported_extts_flags field. This results in the kernel automatically
+rejecting all userspace requests for the PTP_EXTTS_REQUEST2 ioctl.
+
+This occurs because the PTP_STRICT_FLAGS is always assumed when operating
+under PTP_EXTTS_REQUEST2. This has been the case since the flags
+introduction by commit 6138e687c7b6 ("ptp: Introduce strict checking of
+external time stamp options.").
+
+The bcm-phy-ptp.c logic never properly supported strict flag validation,
+as it previously ignored all flags including both PTP_STRICT_FLAGS and the
+PTP_FALLING_EDGE and PTP_RISING_EDGE flags.
+
+Reports from users in the field prove that the hardware timestamps the
+rising edge. Encode this in the .supported_extts_flags field. This
+re-enables support for the PTP_EXTTS_REQUEST2 ioctl.
+
+Reported-by: James Clark <jjc@jclark.com>
+Fixes: 7c571ac57d9d ("net: ptp: introduce .supported_extts_flags to ptp_clock_info")
+Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
+Reviewed-by: Vadim Fedorenko <vadim.fedorenko@linux.dev>
+Acked-by: Richard Cochran <richardcochran@gmail.com>
+Reviewed-by: Kory Maincent <kory.maincent@bootlin.com>
+Tested-by: James Clark <jjc@jclark.com>
+Link: https://patch.msgid.link/20250918-jk-fix-bcm-phy-supported-flags-v1-2-747b60407c9c@intel.com
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/phy/bcm-phy-ptp.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/drivers/net/phy/bcm-phy-ptp.c b/drivers/net/phy/bcm-phy-ptp.c
+index 1cf695ac73cc5..d3501f8487d96 100644
+--- a/drivers/net/phy/bcm-phy-ptp.c
++++ b/drivers/net/phy/bcm-phy-ptp.c
+@@ -738,6 +738,7 @@ static const struct ptp_clock_info bcm_ptp_clock_info = {
+ .n_per_out = 1,
+ .n_ext_ts = 1,
+ .supported_perout_flags = PTP_PEROUT_DUTY_CYCLE,
++ .supported_extts_flags = PTP_STRICT_FLAGS | PTP_RISING_EDGE,
+ };
+
+ static void bcm_ptp_txtstamp(struct mii_timestamper *mii_ts,
+--
+2.51.0
+
--- /dev/null
+From a1c60257dd3f0c355e7ae7e02f597810932a6e1f Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 18 Sep 2025 17:33:16 -0700
+Subject: broadcom: fix support for PTP_PEROUT_DUTY_CYCLE
+
+From: Jacob Keller <jacob.e.keller@intel.com>
+
+[ Upstream commit 6e6c88d85623dc0c5c3faf185c12bd723efde5ee ]
+
+The bcm_ptp_perout_locked() function has support for handling
+PTP_PEROUT_DUTY_CYCLE, but its not listed in the supported_perout_flags.
+Attempts to use the duty cycle support will be rejected since commit
+d9f3e9ecc456 ("net: ptp: introduce .supported_perout_flags to
+ptp_clock_info"), as this flag accidentally missed while doing the
+conversion.
+
+Drop the unnecessary supported flags check from the bcm_ptp_perout_locked()
+function and correctly set the supported_perout_flags. This fixes use of
+the PTP_PEROUT_DUTY_CYCLE support for the broadcom driver.
+
+Reported-by: James Clark <jjc@jclark.com>
+Fixes: d9f3e9ecc456 ("net: ptp: introduce .supported_perout_flags to ptp_clock_info")
+Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
+Reviewed-by: Vadim Fedorenko <vadim.fedorenko@linux.dev>
+Acked-by: Richard Cochran <richardcochran@gmail.com>
+Reviewed-by: Kory Maincent <kory.maincent@bootlin.com>
+Tested-by: James Clark <jjc@jclark.com>
+Link: https://patch.msgid.link/20250918-jk-fix-bcm-phy-supported-flags-v1-1-747b60407c9c@intel.com
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/phy/bcm-phy-ptp.c | 5 +----
+ 1 file changed, 1 insertion(+), 4 deletions(-)
+
+diff --git a/drivers/net/phy/bcm-phy-ptp.c b/drivers/net/phy/bcm-phy-ptp.c
+index eba8b5fb1365f..1cf695ac73cc5 100644
+--- a/drivers/net/phy/bcm-phy-ptp.c
++++ b/drivers/net/phy/bcm-phy-ptp.c
+@@ -597,10 +597,6 @@ static int bcm_ptp_perout_locked(struct bcm_ptp_private *priv,
+
+ period = BCM_MAX_PERIOD_8NS; /* write nonzero value */
+
+- /* Reject unsupported flags */
+- if (req->flags & ~PTP_PEROUT_DUTY_CYCLE)
+- return -EOPNOTSUPP;
+-
+ if (req->flags & PTP_PEROUT_DUTY_CYCLE)
+ pulse = ktime_to_ns(ktime_set(req->on.sec, req->on.nsec));
+ else
+@@ -741,6 +737,7 @@ static const struct ptp_clock_info bcm_ptp_clock_info = {
+ .n_pins = 1,
+ .n_per_out = 1,
+ .n_ext_ts = 1,
++ .supported_perout_flags = PTP_PEROUT_DUTY_CYCLE,
+ };
+
+ static void bcm_ptp_txtstamp(struct mii_timestamper *mii_ts,
+--
+2.51.0
+
--- /dev/null
+From cd821d3410bdd7de2399ff7a9b0aa7c008fb56bf Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 18 Sep 2025 18:00:24 +0900
+Subject: can: etas_es58x: populate ndo_change_mtu() to prevent buffer overflow
+
+From: Vincent Mailhol <mailhol@kernel.org>
+
+[ Upstream commit 38c0abad45b190a30d8284a37264d2127a6ec303 ]
+
+Sending an PF_PACKET allows to bypass the CAN framework logic and to
+directly reach the xmit() function of a CAN driver. The only check
+which is performed by the PF_PACKET framework is to make sure that
+skb->len fits the interface's MTU.
+
+Unfortunately, because the etas_es58x driver does not populate its
+net_device_ops->ndo_change_mtu(), it is possible for an attacker to
+configure an invalid MTU by doing, for example:
+
+ $ ip link set can0 mtu 9999
+
+After doing so, the attacker could open a PF_PACKET socket using the
+ETH_P_CANXL protocol:
+
+ socket(PF_PACKET, SOCK_RAW, htons(ETH_P_CANXL));
+
+to inject a malicious CAN XL frames. For example:
+
+ struct canxl_frame frame = {
+ .flags = 0xff,
+ .len = 2048,
+ };
+
+The CAN drivers' xmit() function are calling can_dev_dropped_skb() to
+check that the skb is valid, unfortunately under above conditions, the
+malicious packet is able to go through can_dev_dropped_skb() checks:
+
+ 1. the skb->protocol is set to ETH_P_CANXL which is valid (the
+ function does not check the actual device capabilities).
+
+ 2. the length is a valid CAN XL length.
+
+And so, es58x_start_xmit() receives a CAN XL frame which it is not
+able to correctly handle and will thus misinterpret it as a CAN(FD)
+frame.
+
+This can result in a buffer overflow. For example, using the es581.4
+variant, the frame will be dispatched to es581_4_tx_can_msg(), go
+through the last check at the beginning of this function:
+
+ if (can_is_canfd_skb(skb))
+ return -EMSGSIZE;
+
+and reach this line:
+
+ memcpy(tx_can_msg->data, cf->data, cf->len);
+
+Here, cf->len corresponds to the flags field of the CAN XL frame. In
+our previous example, we set canxl_frame->flags to 0xff. Because the
+maximum expected length is 8, a buffer overflow of 247 bytes occurs!
+
+Populate net_device_ops->ndo_change_mtu() to ensure that the
+interface's MTU can not be set to anything bigger than CAN_MTU or
+CANFD_MTU (depending on the device capabilities). By fixing the root
+cause, this prevents the buffer overflow.
+
+Fixes: 8537257874e9 ("can: etas_es58x: add core support for ETAS ES58X CAN USB interfaces")
+Signed-off-by: Vincent Mailhol <mailhol@kernel.org>
+Link: https://patch.msgid.link/20250918-can-fix-mtu-v1-1-0d1cada9393b@kernel.org
+Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/can/usb/etas_es58x/es58x_core.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+diff --git a/drivers/net/can/usb/etas_es58x/es58x_core.c b/drivers/net/can/usb/etas_es58x/es58x_core.c
+index db1acf6d504cf..adc91873c083f 100644
+--- a/drivers/net/can/usb/etas_es58x/es58x_core.c
++++ b/drivers/net/can/usb/etas_es58x/es58x_core.c
+@@ -7,7 +7,7 @@
+ *
+ * Copyright (c) 2019 Robert Bosch Engineering and Business Solutions. All rights reserved.
+ * Copyright (c) 2020 ETAS K.K.. All rights reserved.
+- * Copyright (c) 2020-2022 Vincent Mailhol <mailhol.vincent@wanadoo.fr>
++ * Copyright (c) 2020-2025 Vincent Mailhol <mailhol@kernel.org>
+ */
+
+ #include <linux/unaligned.h>
+@@ -1977,6 +1977,7 @@ static const struct net_device_ops es58x_netdev_ops = {
+ .ndo_stop = es58x_stop,
+ .ndo_start_xmit = es58x_start_xmit,
+ .ndo_eth_ioctl = can_eth_ioctl_hwts,
++ .ndo_change_mtu = can_change_mtu,
+ };
+
+ static const struct ethtool_ops es58x_ethtool_ops = {
+--
+2.51.0
+
--- /dev/null
+From 70e45cf7b2da9d02e2e1ffc989e091d66bcef6ba Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 18 Sep 2025 18:00:25 +0900
+Subject: can: hi311x: populate ndo_change_mtu() to prevent buffer overflow
+
+From: Vincent Mailhol <mailhol@kernel.org>
+
+[ Upstream commit ac1c7656fa717f29fac3ea073af63f0b9919ec9a ]
+
+Sending an PF_PACKET allows to bypass the CAN framework logic and to
+directly reach the xmit() function of a CAN driver. The only check
+which is performed by the PF_PACKET framework is to make sure that
+skb->len fits the interface's MTU.
+
+Unfortunately, because the sun4i_can driver does not populate its
+net_device_ops->ndo_change_mtu(), it is possible for an attacker to
+configure an invalid MTU by doing, for example:
+
+ $ ip link set can0 mtu 9999
+
+After doing so, the attacker could open a PF_PACKET socket using the
+ETH_P_CANXL protocol:
+
+ socket(PF_PACKET, SOCK_RAW, htons(ETH_P_CANXL))
+
+to inject a malicious CAN XL frames. For example:
+
+ struct canxl_frame frame = {
+ .flags = 0xff,
+ .len = 2048,
+ };
+
+The CAN drivers' xmit() function are calling can_dev_dropped_skb() to
+check that the skb is valid, unfortunately under above conditions, the
+malicious packet is able to go through can_dev_dropped_skb() checks:
+
+ 1. the skb->protocol is set to ETH_P_CANXL which is valid (the
+ function does not check the actual device capabilities).
+
+ 2. the length is a valid CAN XL length.
+
+And so, hi3110_hard_start_xmit() receives a CAN XL frame which it is
+not able to correctly handle and will thus misinterpret it as a CAN
+frame. The driver will consume frame->len as-is with no further
+checks.
+
+This can result in a buffer overflow later on in hi3110_hw_tx() on
+this line:
+
+ memcpy(buf + HI3110_FIFO_EXT_DATA_OFF,
+ frame->data, frame->len);
+
+Here, frame->len corresponds to the flags field of the CAN XL frame.
+In our previous example, we set canxl_frame->flags to 0xff. Because
+the maximum expected length is 8, a buffer overflow of 247 bytes
+occurs!
+
+Populate net_device_ops->ndo_change_mtu() to ensure that the
+interface's MTU can not be set to anything bigger than CAN_MTU. By
+fixing the root cause, this prevents the buffer overflow.
+
+Fixes: 57e83fb9b746 ("can: hi311x: Add Holt HI-311x CAN driver")
+Signed-off-by: Vincent Mailhol <mailhol@kernel.org>
+Link: https://patch.msgid.link/20250918-can-fix-mtu-v1-2-0d1cada9393b@kernel.org
+Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/can/spi/hi311x.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/drivers/net/can/spi/hi311x.c b/drivers/net/can/spi/hi311x.c
+index 09ae218315d73..6441ff3b41987 100644
+--- a/drivers/net/can/spi/hi311x.c
++++ b/drivers/net/can/spi/hi311x.c
+@@ -812,6 +812,7 @@ static const struct net_device_ops hi3110_netdev_ops = {
+ .ndo_open = hi3110_open,
+ .ndo_stop = hi3110_stop,
+ .ndo_start_xmit = hi3110_hard_start_xmit,
++ .ndo_change_mtu = can_change_mtu,
+ };
+
+ static const struct ethtool_ops hi3110_ethtool_ops = {
+--
+2.51.0
+
--- /dev/null
+From 04fb35b72d572a437a1d5b0560c65d52c0fb9974 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 18 Sep 2025 18:00:27 +0900
+Subject: can: mcba_usb: populate ndo_change_mtu() to prevent buffer overflow
+
+From: Vincent Mailhol <mailhol@kernel.org>
+
+[ Upstream commit 17c8d794527f01def0d1c8b7dc2d7b8d34fed0e6 ]
+
+Sending an PF_PACKET allows to bypass the CAN framework logic and to
+directly reach the xmit() function of a CAN driver. The only check
+which is performed by the PF_PACKET framework is to make sure that
+skb->len fits the interface's MTU.
+
+Unfortunately, because the mcba_usb driver does not populate its
+net_device_ops->ndo_change_mtu(), it is possible for an attacker to
+configure an invalid MTU by doing, for example:
+
+ $ ip link set can0 mtu 9999
+
+After doing so, the attacker could open a PF_PACKET socket using the
+ETH_P_CANXL protocol:
+
+ socket(PF_PACKET, SOCK_RAW, htons(ETH_P_CANXL))
+
+to inject a malicious CAN XL frames. For example:
+
+ struct canxl_frame frame = {
+ .flags = 0xff,
+ .len = 2048,
+ };
+
+The CAN drivers' xmit() function are calling can_dev_dropped_skb() to
+check that the skb is valid, unfortunately under above conditions, the
+malicious packet is able to go through can_dev_dropped_skb() checks:
+
+ 1. the skb->protocol is set to ETH_P_CANXL which is valid (the
+ function does not check the actual device capabilities).
+
+ 2. the length is a valid CAN XL length.
+
+And so, mcba_usb_start_xmit() receives a CAN XL frame which it is not
+able to correctly handle and will thus misinterpret it as a CAN frame.
+
+This can result in a buffer overflow. The driver will consume cf->len
+as-is with no further checks on these lines:
+
+ usb_msg.dlc = cf->len;
+
+ memcpy(usb_msg.data, cf->data, usb_msg.dlc);
+
+Here, cf->len corresponds to the flags field of the CAN XL frame. In
+our previous example, we set canxl_frame->flags to 0xff. Because the
+maximum expected length is 8, a buffer overflow of 247 bytes occurs!
+
+Populate net_device_ops->ndo_change_mtu() to ensure that the
+interface's MTU can not be set to anything bigger than CAN_MTU. By
+fixing the root cause, this prevents the buffer overflow.
+
+Fixes: 51f3baad7de9 ("can: mcba_usb: Add support for Microchip CAN BUS Analyzer")
+Signed-off-by: Vincent Mailhol <mailhol@kernel.org>
+Link: https://patch.msgid.link/20250918-can-fix-mtu-v1-4-0d1cada9393b@kernel.org
+Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/can/usb/mcba_usb.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/drivers/net/can/usb/mcba_usb.c b/drivers/net/can/usb/mcba_usb.c
+index 41c0a1c399bf3..1f9b915094e64 100644
+--- a/drivers/net/can/usb/mcba_usb.c
++++ b/drivers/net/can/usb/mcba_usb.c
+@@ -761,6 +761,7 @@ static const struct net_device_ops mcba_netdev_ops = {
+ .ndo_open = mcba_usb_open,
+ .ndo_stop = mcba_usb_close,
+ .ndo_start_xmit = mcba_usb_start_xmit,
++ .ndo_change_mtu = can_change_mtu,
+ };
+
+ static const struct ethtool_ops mcba_ethtool_ops = {
+--
+2.51.0
+
--- /dev/null
+From 5c8a3d1cb36b88492adf6cc2b7c7fc62f64ce28d Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 18 Sep 2025 15:23:57 +0200
+Subject: can: peak_usb: fix shift-out-of-bounds issue
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Stéphane Grosjean <stephane.grosjean@hms-networks.com>
+
+[ Upstream commit c443be70aaee42c2d1d251e0329e0a69dd96ae54 ]
+
+Explicitly uses a 64-bit constant when the number of bits used for its
+shifting is 32 (which is the case for PC CAN FD interfaces supported by
+this driver).
+
+Signed-off-by: Stéphane Grosjean <stephane.grosjean@hms-networks.com>
+Link: https://patch.msgid.link/20250918132413.30071-1-stephane.grosjean@free.fr
+Reported-by: Marc Kleine-Budde <mkl@pengutronix.de>
+Closes: https://lore.kernel.org/20250917-aboriginal-refined-honeybee-82b1aa-mkl@pengutronix.de
+Fixes: bb4785551f64 ("can: usb: PEAK-System Technik USB adapters driver core")
+[mkl: update subject, apply manually]
+Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/can/usb/peak_usb/pcan_usb_core.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/drivers/net/can/usb/peak_usb/pcan_usb_core.c b/drivers/net/can/usb/peak_usb/pcan_usb_core.c
+index 117637b9b995b..dd5caa1c302b9 100644
+--- a/drivers/net/can/usb/peak_usb/pcan_usb_core.c
++++ b/drivers/net/can/usb/peak_usb/pcan_usb_core.c
+@@ -111,7 +111,7 @@ void peak_usb_update_ts_now(struct peak_time_ref *time_ref, u32 ts_now)
+ u32 delta_ts = time_ref->ts_dev_2 - time_ref->ts_dev_1;
+
+ if (time_ref->ts_dev_2 < time_ref->ts_dev_1)
+- delta_ts &= (1 << time_ref->adapter->ts_used_bits) - 1;
++ delta_ts &= (1ULL << time_ref->adapter->ts_used_bits) - 1;
+
+ time_ref->ts_total += delta_ts;
+ }
+--
+2.51.0
+
--- /dev/null
+From 34f0fdf7bcb9e34fc5672cc8f13e3e18f309c41c Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 18 Sep 2025 18:00:26 +0900
+Subject: can: sun4i_can: populate ndo_change_mtu() to prevent buffer overflow
+
+From: Vincent Mailhol <mailhol@kernel.org>
+
+[ Upstream commit 61da0bd4102c459823fbe6b8b43b01fb6ace4a22 ]
+
+Sending an PF_PACKET allows to bypass the CAN framework logic and to
+directly reach the xmit() function of a CAN driver. The only check
+which is performed by the PF_PACKET framework is to make sure that
+skb->len fits the interface's MTU.
+
+Unfortunately, because the sun4i_can driver does not populate its
+net_device_ops->ndo_change_mtu(), it is possible for an attacker to
+configure an invalid MTU by doing, for example:
+
+ $ ip link set can0 mtu 9999
+
+After doing so, the attacker could open a PF_PACKET socket using the
+ETH_P_CANXL protocol:
+
+ socket(PF_PACKET, SOCK_RAW, htons(ETH_P_CANXL))
+
+to inject a malicious CAN XL frames. For example:
+
+ struct canxl_frame frame = {
+ .flags = 0xff,
+ .len = 2048,
+ };
+
+The CAN drivers' xmit() function are calling can_dev_dropped_skb() to
+check that the skb is valid, unfortunately under above conditions, the
+malicious packet is able to go through can_dev_dropped_skb() checks:
+
+ 1. the skb->protocol is set to ETH_P_CANXL which is valid (the
+ function does not check the actual device capabilities).
+
+ 2. the length is a valid CAN XL length.
+
+And so, sun4ican_start_xmit() receives a CAN XL frame which it is not
+able to correctly handle and will thus misinterpret it as a CAN frame.
+
+This can result in a buffer overflow. The driver will consume cf->len
+as-is with no further checks on this line:
+
+ dlc = cf->len;
+
+Here, cf->len corresponds to the flags field of the CAN XL frame. In
+our previous example, we set canxl_frame->flags to 0xff. Because the
+maximum expected length is 8, a buffer overflow of 247 bytes occurs a
+couple line below when doing:
+
+ for (i = 0; i < dlc; i++)
+ writel(cf->data[i], priv->base + (dreg + i * 4));
+
+Populate net_device_ops->ndo_change_mtu() to ensure that the
+interface's MTU can not be set to anything bigger than CAN_MTU. By
+fixing the root cause, this prevents the buffer overflow.
+
+Fixes: 0738eff14d81 ("can: Allwinner A10/A20 CAN Controller support - Kernel module")
+Signed-off-by: Vincent Mailhol <mailhol@kernel.org>
+Link: https://patch.msgid.link/20250918-can-fix-mtu-v1-3-0d1cada9393b@kernel.org
+Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/can/sun4i_can.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/drivers/net/can/sun4i_can.c b/drivers/net/can/sun4i_can.c
+index 6fcb301ef611d..53bfd873de9bd 100644
+--- a/drivers/net/can/sun4i_can.c
++++ b/drivers/net/can/sun4i_can.c
+@@ -768,6 +768,7 @@ static const struct net_device_ops sun4ican_netdev_ops = {
+ .ndo_open = sun4ican_open,
+ .ndo_stop = sun4ican_close,
+ .ndo_start_xmit = sun4ican_start_xmit,
++ .ndo_change_mtu = can_change_mtu,
+ };
+
+ static const struct ethtool_ops sun4ican_ethtool_ops = {
+--
+2.51.0
+
--- /dev/null
+From 9f390b0f717af67aaff259e8ace7847e0ad3af13 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 18 Sep 2025 17:21:07 +0200
+Subject: ethernet: rvu-af: Remove slash from the driver name
+
+From: Petr Malat <oss@malat.biz>
+
+[ Upstream commit b65678cacc030efd53c38c089fb9b741a2ee34c8 ]
+
+Having a slash in the driver name leads to EIO being returned while
+reading /sys/module/rvu_af/drivers content.
+
+Remove DRV_STRING as it's not used anywhere.
+
+Fixes: 91c6945ea1f9 ("octeontx2-af: cn10k: Add RPM MAC support")
+Signed-off-by: Petr Malat <oss@malat.biz>
+Reviewed-by: Simon Horman <horms@kernel.org>
+Link: https://patch.msgid.link/20250918152106.1798299-1-oss@malat.biz
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/ethernet/marvell/octeontx2/af/cgx.c | 3 +--
+ 1 file changed, 1 insertion(+), 2 deletions(-)
+
+diff --git a/drivers/net/ethernet/marvell/octeontx2/af/cgx.c b/drivers/net/ethernet/marvell/octeontx2/af/cgx.c
+index 442305463cc0a..21161711c579f 100644
+--- a/drivers/net/ethernet/marvell/octeontx2/af/cgx.c
++++ b/drivers/net/ethernet/marvell/octeontx2/af/cgx.c
+@@ -21,8 +21,7 @@
+ #include "rvu.h"
+ #include "lmac_common.h"
+
+-#define DRV_NAME "Marvell-CGX/RPM"
+-#define DRV_STRING "Marvell CGX/RPM Driver"
++#define DRV_NAME "Marvell-CGX-RPM"
+
+ #define CGX_RX_STAT_GLOBAL_INDEX 9
+
+--
+2.51.0
+
--- /dev/null
+From 8879e9b4a2079b0b02e7eafd3fd14b4fba276fd0 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Mon, 22 Sep 2025 15:19:57 -0400
+Subject: net: allow alloc_skb_with_frags() to use MAX_SKB_FRAGS
+
+From: Jason Baron <jbaron@akamai.com>
+
+[ Upstream commit ca9f9cdc4de97d0221100b11224738416696163c ]
+
+Currently, alloc_skb_with_frags() will only fill (MAX_SKB_FRAGS - 1)
+slots. I think it should use all MAX_SKB_FRAGS slots, as callers of
+alloc_skb_with_frags() will size their allocation of frags based
+on MAX_SKB_FRAGS.
+
+This issue was discovered via a test patch that sets 'order' to 0
+in alloc_skb_with_frags(), which effectively tests/simulates high
+fragmentation. In this case sendmsg() on unix sockets will fail every
+time for large allocations. If the PAGE_SIZE is 4K, then data_len will
+request 68K or 17 pages, but alloc_skb_with_frags() can only allocate
+64K in this case or 16 pages.
+
+Fixes: 09c2c90705bb ("net: allow alloc_skb_with_frags() to allocate bigger packets")
+Signed-off-by: Jason Baron <jbaron@akamai.com>
+Reviewed-by: Eric Dumazet <edumazet@google.com>
+Link: https://patch.msgid.link/20250922191957.2855612-1-jbaron@akamai.com
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ net/core/skbuff.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/net/core/skbuff.c b/net/core/skbuff.c
+index d6420b74ea9c6..cb77bb84371bd 100644
+--- a/net/core/skbuff.c
++++ b/net/core/skbuff.c
+@@ -6667,7 +6667,7 @@ struct sk_buff *alloc_skb_with_frags(unsigned long header_len,
+ return NULL;
+
+ while (data_len) {
+- if (nr_frags == MAX_SKB_FRAGS - 1)
++ if (nr_frags == MAX_SKB_FRAGS)
+ goto failure;
+ while (order && PAGE_ALIGN(data_len) < (PAGE_SIZE << order))
+ order--;
+--
+2.51.0
+
--- /dev/null
+From b5fe9d9862922c64e25b82237888dedd9e9658b4 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 18 Sep 2025 10:21:41 +0300
+Subject: net: dsa: lantiq_gswip: move gswip_add_single_port_br() call to
+ port_setup()
+
+From: Vladimir Oltean <vladimir.oltean@nxp.com>
+
+[ Upstream commit c0054b25e2f1045f47b4954cf13a539e5e6047df ]
+
+A port added to a "single port bridge" operates as standalone, and this
+is mutually exclusive to being part of a Linux bridge. In fact,
+gswip_port_bridge_join() calls gswip_add_single_port_br() with
+add=false, i.e. removes the port from the "single port bridge" to enable
+autonomous forwarding.
+
+The blamed commit seems to have incorrectly thought that ds->ops->port_enable()
+is called one time per port, during the setup phase of the switch.
+
+However, it is actually called during the ndo_open() implementation of
+DSA user ports, which is to say that this sequence of events:
+
+1. ip link set swp0 down
+2. ip link add br0 type bridge
+3. ip link set swp0 master br0
+4. ip link set swp0 up
+
+would cause swp0 to join back the "single port bridge" which step 3 had
+just removed it from.
+
+The correct DSA hook for one-time actions per port at switch init time
+is ds->ops->port_setup(). This is what seems to match the coder's
+intention; also see the comment at the beginning of the file:
+
+ * At the initialization the driver allocates one bridge table entry for
+ ~~~~~~~~~~~~~~~~~~~~~
+ * each switch port which is used when the port is used without an
+ * explicit bridge.
+
+Fixes: 8206e0ce96b3 ("net: dsa: lantiq: Add VLAN unaware bridge offloading")
+Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
+Link: https://patch.msgid.link/20250918072142.894692-2-vladimir.oltean@nxp.com
+Tested-by: Daniel Golle <daniel@makrotopia.org>
+Reviewed-by: Daniel Golle <daniel@makrotopia.org>
+Signed-off-by: Paolo Abeni <pabeni@redhat.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/dsa/lantiq_gswip.c | 18 ++++++++++++++----
+ 1 file changed, 14 insertions(+), 4 deletions(-)
+
+diff --git a/drivers/net/dsa/lantiq_gswip.c b/drivers/net/dsa/lantiq_gswip.c
+index 6eb3140d40444..d416c072dd28c 100644
+--- a/drivers/net/dsa/lantiq_gswip.c
++++ b/drivers/net/dsa/lantiq_gswip.c
+@@ -685,18 +685,27 @@ static int gswip_add_single_port_br(struct gswip_priv *priv, int port, bool add)
+ return 0;
+ }
+
+-static int gswip_port_enable(struct dsa_switch *ds, int port,
+- struct phy_device *phydev)
++static int gswip_port_setup(struct dsa_switch *ds, int port)
+ {
+ struct gswip_priv *priv = ds->priv;
+ int err;
+
+ if (!dsa_is_cpu_port(ds, port)) {
+- u32 mdio_phy = 0;
+-
+ err = gswip_add_single_port_br(priv, port, true);
+ if (err)
+ return err;
++ }
++
++ return 0;
++}
++
++static int gswip_port_enable(struct dsa_switch *ds, int port,
++ struct phy_device *phydev)
++{
++ struct gswip_priv *priv = ds->priv;
++
++ if (!dsa_is_cpu_port(ds, port)) {
++ u32 mdio_phy = 0;
+
+ if (phydev)
+ mdio_phy = phydev->mdio.addr & GSWIP_MDIO_PHY_ADDR_MASK;
+@@ -1829,6 +1838,7 @@ static const struct phylink_mac_ops gswip_phylink_mac_ops = {
+ static const struct dsa_switch_ops gswip_xrx200_switch_ops = {
+ .get_tag_protocol = gswip_get_tag_protocol,
+ .setup = gswip_setup,
++ .port_setup = gswip_port_setup,
+ .port_enable = gswip_port_enable,
+ .port_disable = gswip_port_disable,
+ .port_bridge_join = gswip_port_bridge_join,
+--
+2.51.0
+
--- /dev/null
+From dbed9fba3f6daf036bdc645b8a6d9782acec16f6 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 18 Sep 2025 10:21:42 +0300
+Subject: net: dsa: lantiq_gswip: suppress -EINVAL errors for bridge FDB
+ entries added to the CPU port
+
+From: Vladimir Oltean <vladimir.oltean@nxp.com>
+
+[ Upstream commit 987afe147965ef7a8e7d144ffef0d70af14bb1d4 ]
+
+The blamed commit and others in that patch set started the trend
+of reusing existing DSA driver API for a new purpose: calling
+ds->ops->port_fdb_add() on the CPU port.
+
+The lantiq_gswip driver was not prepared to handle that, as can be seen
+from the many errors that Daniel presents in the logs:
+
+[ 174.050000] gswip 1e108000.switch: port 2 failed to add fa:aa:72:f4:8b:1e vid 1 to fdb: -22
+[ 174.060000] gswip 1e108000.switch lan2: entered promiscuous mode
+[ 174.070000] gswip 1e108000.switch: port 2 failed to add 00:01:02:03:04:02 vid 0 to fdb: -22
+[ 174.090000] gswip 1e108000.switch: port 2 failed to add 00:01:02:03:04:02 vid 1 to fdb: -22
+[ 174.090000] gswip 1e108000.switch: port 2 failed to delete fa:aa:72:f4:8b:1e vid 1 from fdb: -2
+
+The errors are because gswip_port_fdb() wants to get a handle to the
+bridge that originated these FDB events, to associate it with a FID.
+Absolutely honourable purpose, however this only works for user ports.
+
+To get the bridge that generated an FDB entry for the CPU port, one
+would need to look at the db.bridge.dev argument. But this was
+introduced in commit c26933639b54 ("net: dsa: request drivers to perform
+FDB isolation"), first appeared in v5.18, and when the blamed commit was
+introduced in v5.14, no such API existed.
+
+So the core DSA feature was introduced way too soon for lantiq_gswip.
+Not acting on these host FDB entries and suppressing any errors has no
+other negative effect, and practically returns us to not supporting the
+host filtering feature at all - peacefully, this time.
+
+Fixes: 10fae4ac89ce ("net: dsa: include bridge addresses which are local in the host fdb list")
+Reported-by: Daniel Golle <daniel@makrotopia.org>
+Closes: https://lore.kernel.org/netdev/aJfNMLNoi1VOsPrN@pidgin.makrotopia.org/
+Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
+Link: https://patch.msgid.link/20250918072142.894692-3-vladimir.oltean@nxp.com
+Tested-by: Daniel Golle <daniel@makrotopia.org>
+Reviewed-by: Daniel Golle <daniel@makrotopia.org>
+Signed-off-by: Paolo Abeni <pabeni@redhat.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/dsa/lantiq_gswip.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+diff --git a/drivers/net/dsa/lantiq_gswip.c b/drivers/net/dsa/lantiq_gswip.c
+index d416c072dd28c..84dc6e517acf9 100644
+--- a/drivers/net/dsa/lantiq_gswip.c
++++ b/drivers/net/dsa/lantiq_gswip.c
+@@ -1368,8 +1368,9 @@ static int gswip_port_fdb(struct dsa_switch *ds, int port,
+ int i;
+ int err;
+
++ /* Operation not supported on the CPU port, don't throw errors */
+ if (!bridge)
+- return -EINVAL;
++ return 0;
+
+ for (i = max_ports; i < ARRAY_SIZE(priv->vlans); i++) {
+ if (priv->vlans[i].bridge == bridge) {
+--
+2.51.0
+
--- /dev/null
+From f34b6120dbb964ba7554418fb669118143b7f576 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Mon, 22 Sep 2025 10:11:32 +0300
+Subject: net/mlx5: fs, fix UAF in flow counter release
+
+From: Moshe Shemesh <moshe@nvidia.com>
+
+[ Upstream commit 6043819e707cefb1c9e59d6e431dcfa735c4f975 ]
+
+Fix a kernel trace [1] caused by releasing an HWS action of a local flow
+counter in mlx5_cmd_hws_delete_fte(), where the HWS action refcount and
+mutex were not initialized and the counter struct could already be freed
+when deleting the rule.
+
+Fix it by adding the missing initializations and adding refcount for the
+local flow counter struct.
+
+[1] Kernel log:
+ Call Trace:
+ <TASK>
+ dump_stack_lvl+0x34/0x48
+ mlx5_fs_put_hws_action.part.0.cold+0x21/0x94 [mlx5_core]
+ mlx5_fc_put_hws_action+0x96/0xad [mlx5_core]
+ mlx5_fs_destroy_fs_actions+0x8b/0x152 [mlx5_core]
+ mlx5_cmd_hws_delete_fte+0x5a/0xa0 [mlx5_core]
+ del_hw_fte+0x1ce/0x260 [mlx5_core]
+ mlx5_del_flow_rules+0x12d/0x240 [mlx5_core]
+ ? ttwu_queue_wakelist+0xf4/0x110
+ mlx5_ib_destroy_flow+0x103/0x1b0 [mlx5_ib]
+ uverbs_free_flow+0x20/0x50 [ib_uverbs]
+ destroy_hw_idr_uobject+0x1b/0x50 [ib_uverbs]
+ uverbs_destroy_uobject+0x34/0x1a0 [ib_uverbs]
+ uobj_destroy+0x3c/0x80 [ib_uverbs]
+ ib_uverbs_run_method+0x23e/0x360 [ib_uverbs]
+ ? uverbs_finalize_object+0x60/0x60 [ib_uverbs]
+ ib_uverbs_cmd_verbs+0x14f/0x2c0 [ib_uverbs]
+ ? do_tty_write+0x1a9/0x270
+ ? file_tty_write.constprop.0+0x98/0xc0
+ ? new_sync_write+0xfc/0x190
+ ib_uverbs_ioctl+0xd7/0x160 [ib_uverbs]
+ __x64_sys_ioctl+0x87/0xc0
+ do_syscall_64+0x59/0x90
+
+Fixes: b581f4266928 ("net/mlx5: fs, manage flow counters HWS action sharing by refcount")
+Signed-off-by: Moshe Shemesh <moshe@nvidia.com>
+Reviewed-by: Yevgeny Kliteynik <kliteyn@nvidia.com>
+Reviewed-by: Mark Bloch <mbloch@nvidia.com>
+Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
+Link: https://patch.msgid.link/1758525094-816583-2-git-send-email-tariqt@nvidia.com
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ .../net/ethernet/mellanox/mlx5/core/fs_core.c | 2 +-
+ .../net/ethernet/mellanox/mlx5/core/fs_core.h | 1 +
+ .../ethernet/mellanox/mlx5/core/fs_counters.c | 25 ++++++++++++++++---
+ .../mlx5/core/steering/hws/fs_hws_pools.c | 8 +++++-
+ include/linux/mlx5/fs.h | 2 ++
+ 5 files changed, 33 insertions(+), 5 deletions(-)
+
+diff --git a/drivers/net/ethernet/mellanox/mlx5/core/fs_core.c b/drivers/net/ethernet/mellanox/mlx5/core/fs_core.c
+index 3b57ef6b3de38..93fb4e861b691 100644
+--- a/drivers/net/ethernet/mellanox/mlx5/core/fs_core.c
++++ b/drivers/net/ethernet/mellanox/mlx5/core/fs_core.c
+@@ -663,7 +663,7 @@ static void del_sw_hw_rule(struct fs_node *node)
+ BIT(MLX5_SET_FTE_MODIFY_ENABLE_MASK_ACTION) |
+ BIT(MLX5_SET_FTE_MODIFY_ENABLE_MASK_FLOW_COUNTERS);
+ fte->act_dests.action.action &= ~MLX5_FLOW_CONTEXT_ACTION_COUNT;
+- mlx5_fc_local_destroy(rule->dest_attr.counter);
++ mlx5_fc_local_put(rule->dest_attr.counter);
+ goto out;
+ }
+
+diff --git a/drivers/net/ethernet/mellanox/mlx5/core/fs_core.h b/drivers/net/ethernet/mellanox/mlx5/core/fs_core.h
+index 500826229b0be..e6a95b310b555 100644
+--- a/drivers/net/ethernet/mellanox/mlx5/core/fs_core.h
++++ b/drivers/net/ethernet/mellanox/mlx5/core/fs_core.h
+@@ -343,6 +343,7 @@ struct mlx5_fc {
+ enum mlx5_fc_type type;
+ struct mlx5_fc_bulk *bulk;
+ struct mlx5_fc_cache cache;
++ refcount_t fc_local_refcount;
+ /* last{packets,bytes} are used for calculating deltas since last reading. */
+ u64 lastpackets;
+ u64 lastbytes;
+diff --git a/drivers/net/ethernet/mellanox/mlx5/core/fs_counters.c b/drivers/net/ethernet/mellanox/mlx5/core/fs_counters.c
+index 492775d3d193a..83001eda38842 100644
+--- a/drivers/net/ethernet/mellanox/mlx5/core/fs_counters.c
++++ b/drivers/net/ethernet/mellanox/mlx5/core/fs_counters.c
+@@ -562,17 +562,36 @@ mlx5_fc_local_create(u32 counter_id, u32 offset, u32 bulk_size)
+ counter->id = counter_id;
+ fc_bulk->base_id = counter_id - offset;
+ fc_bulk->fs_bulk.bulk_len = bulk_size;
++ refcount_set(&fc_bulk->hws_data.hws_action_refcount, 0);
++ mutex_init(&fc_bulk->hws_data.lock);
+ counter->bulk = fc_bulk;
++ refcount_set(&counter->fc_local_refcount, 1);
+ return counter;
+ }
+ EXPORT_SYMBOL(mlx5_fc_local_create);
+
+ void mlx5_fc_local_destroy(struct mlx5_fc *counter)
+ {
+- if (!counter || counter->type != MLX5_FC_TYPE_LOCAL)
+- return;
+-
+ kfree(counter->bulk);
+ kfree(counter);
+ }
+ EXPORT_SYMBOL(mlx5_fc_local_destroy);
++
++void mlx5_fc_local_get(struct mlx5_fc *counter)
++{
++ if (!counter || counter->type != MLX5_FC_TYPE_LOCAL)
++ return;
++
++ refcount_inc(&counter->fc_local_refcount);
++}
++
++void mlx5_fc_local_put(struct mlx5_fc *counter)
++{
++ if (!counter || counter->type != MLX5_FC_TYPE_LOCAL)
++ return;
++
++ if (!refcount_dec_and_test(&counter->fc_local_refcount))
++ return;
++
++ mlx5_fc_local_destroy(counter);
++}
+diff --git a/drivers/net/ethernet/mellanox/mlx5/core/steering/hws/fs_hws_pools.c b/drivers/net/ethernet/mellanox/mlx5/core/steering/hws/fs_hws_pools.c
+index f1ecdba74e1f4..839d71bd42164 100644
+--- a/drivers/net/ethernet/mellanox/mlx5/core/steering/hws/fs_hws_pools.c
++++ b/drivers/net/ethernet/mellanox/mlx5/core/steering/hws/fs_hws_pools.c
+@@ -407,15 +407,21 @@ struct mlx5hws_action *mlx5_fc_get_hws_action(struct mlx5hws_context *ctx,
+ {
+ struct mlx5_fs_hws_create_action_ctx create_ctx;
+ struct mlx5_fc_bulk *fc_bulk = counter->bulk;
++ struct mlx5hws_action *hws_action;
+
+ create_ctx.hws_ctx = ctx;
+ create_ctx.id = fc_bulk->base_id;
+ create_ctx.actions_type = MLX5HWS_ACTION_TYP_CTR;
+
+- return mlx5_fs_get_hws_action(&fc_bulk->hws_data, &create_ctx);
++ mlx5_fc_local_get(counter);
++ hws_action = mlx5_fs_get_hws_action(&fc_bulk->hws_data, &create_ctx);
++ if (!hws_action)
++ mlx5_fc_local_put(counter);
++ return hws_action;
+ }
+
+ void mlx5_fc_put_hws_action(struct mlx5_fc *counter)
+ {
+ mlx5_fs_put_hws_action(&counter->bulk->hws_data);
++ mlx5_fc_local_put(counter);
+ }
+diff --git a/include/linux/mlx5/fs.h b/include/linux/mlx5/fs.h
+index 939e58c2f3865..fb5f98fcc7269 100644
+--- a/include/linux/mlx5/fs.h
++++ b/include/linux/mlx5/fs.h
+@@ -308,6 +308,8 @@ struct mlx5_fc *mlx5_fc_create(struct mlx5_core_dev *dev, bool aging);
+ void mlx5_fc_destroy(struct mlx5_core_dev *dev, struct mlx5_fc *counter);
+ struct mlx5_fc *mlx5_fc_local_create(u32 counter_id, u32 offset, u32 bulk_size);
+ void mlx5_fc_local_destroy(struct mlx5_fc *counter);
++void mlx5_fc_local_get(struct mlx5_fc *counter);
++void mlx5_fc_local_put(struct mlx5_fc *counter);
+ u64 mlx5_fc_query_lastuse(struct mlx5_fc *counter);
+ void mlx5_fc_query_cached(struct mlx5_fc *counter,
+ u64 *bytes, u64 *packets, u64 *lastuse);
+--
+2.51.0
+
--- /dev/null
+From 38842c949d2d11fc84748c1933dc1c2be1ad8d6f Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Mon, 22 Sep 2025 10:11:33 +0300
+Subject: net/mlx5: HWS, ignore flow level for multi-dest table
+
+From: Yevgeny Kliteynik <kliteyn@nvidia.com>
+
+[ Upstream commit efb877cf27e300e47e1c051f4e8fd80fc42325d5 ]
+
+When HWS creates multi-dest FW table and adds rules to
+forward to other tables, ignore the flow level enforcement
+in FW, because HWS is responsible for table levels.
+
+This fixes the following error:
+
+ mlx5_core 0000:08:00.0: mlx5_cmd_out_err:818:(pid 192306):
+ SET_FLOW_TABLE_ENTRY(0x936) op_mod(0x0) failed,
+ status bad parameter(0x3), syndrome (0x6ae84c), err(-22)
+
+Fixes: 504e536d9010 ("net/mlx5: HWS, added actions handling")
+Signed-off-by: Yevgeny Kliteynik <kliteyn@nvidia.com>
+Reviewed-by: Moshe Shemesh <moshe@nvidia.com>
+Reviewed-by: Mark Bloch <mbloch@nvidia.com>
+Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
+Link: https://patch.msgid.link/1758525094-816583-3-git-send-email-tariqt@nvidia.com
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ .../ethernet/mellanox/mlx5/core/steering/hws/action.c | 4 ++--
+ .../ethernet/mellanox/mlx5/core/steering/hws/fs_hws.c | 11 +++--------
+ .../mellanox/mlx5/core/steering/hws/mlx5hws.h | 3 +--
+ 3 files changed, 6 insertions(+), 12 deletions(-)
+
+diff --git a/drivers/net/ethernet/mellanox/mlx5/core/steering/hws/action.c b/drivers/net/ethernet/mellanox/mlx5/core/steering/hws/action.c
+index 6b36a4a7d895f..fe56b59e24c59 100644
+--- a/drivers/net/ethernet/mellanox/mlx5/core/steering/hws/action.c
++++ b/drivers/net/ethernet/mellanox/mlx5/core/steering/hws/action.c
+@@ -1360,7 +1360,7 @@ mlx5hws_action_create_modify_header(struct mlx5hws_context *ctx,
+ struct mlx5hws_action *
+ mlx5hws_action_create_dest_array(struct mlx5hws_context *ctx, size_t num_dest,
+ struct mlx5hws_action_dest_attr *dests,
+- bool ignore_flow_level, u32 flags)
++ u32 flags)
+ {
+ struct mlx5hws_cmd_set_fte_dest *dest_list = NULL;
+ struct mlx5hws_cmd_ft_create_attr ft_attr = {0};
+@@ -1397,7 +1397,7 @@ mlx5hws_action_create_dest_array(struct mlx5hws_context *ctx, size_t num_dest,
+ MLX5_FLOW_DESTINATION_TYPE_FLOW_TABLE;
+ dest_list[i].destination_id = dests[i].dest->dest_obj.obj_id;
+ fte_attr.action_flags |= MLX5_FLOW_CONTEXT_ACTION_FWD_DEST;
+- fte_attr.ignore_flow_level = ignore_flow_level;
++ fte_attr.ignore_flow_level = 1;
+ if (dests[i].is_wire_ft)
+ last_dest_idx = i;
+ break;
+diff --git a/drivers/net/ethernet/mellanox/mlx5/core/steering/hws/fs_hws.c b/drivers/net/ethernet/mellanox/mlx5/core/steering/hws/fs_hws.c
+index 131e74b2b7743..6a4c4cccd6434 100644
+--- a/drivers/net/ethernet/mellanox/mlx5/core/steering/hws/fs_hws.c
++++ b/drivers/net/ethernet/mellanox/mlx5/core/steering/hws/fs_hws.c
+@@ -572,12 +572,12 @@ static void mlx5_fs_put_dest_action_sampler(struct mlx5_fs_hws_context *fs_ctx,
+ static struct mlx5hws_action *
+ mlx5_fs_create_action_dest_array(struct mlx5hws_context *ctx,
+ struct mlx5hws_action_dest_attr *dests,
+- u32 num_of_dests, bool ignore_flow_level)
++ u32 num_of_dests)
+ {
+ u32 flags = MLX5HWS_ACTION_FLAG_HWS_FDB | MLX5HWS_ACTION_FLAG_SHARED;
+
+ return mlx5hws_action_create_dest_array(ctx, num_of_dests, dests,
+- ignore_flow_level, flags);
++ flags);
+ }
+
+ static struct mlx5hws_action *
+@@ -1014,19 +1014,14 @@ static int mlx5_fs_fte_get_hws_actions(struct mlx5_flow_root_namespace *ns,
+ }
+ (*ractions)[num_actions++].action = dest_actions->dest;
+ } else if (num_dest_actions > 1) {
+- bool ignore_flow_level;
+-
+ if (num_actions == MLX5_FLOW_CONTEXT_ACTION_MAX ||
+ num_fs_actions == MLX5_FLOW_CONTEXT_ACTION_MAX) {
+ err = -EOPNOTSUPP;
+ goto free_actions;
+ }
+- ignore_flow_level =
+- !!(fte_action->flags & FLOW_ACT_IGNORE_FLOW_LEVEL);
+ tmp_action =
+ mlx5_fs_create_action_dest_array(ctx, dest_actions,
+- num_dest_actions,
+- ignore_flow_level);
++ num_dest_actions);
+ if (!tmp_action) {
+ err = -EOPNOTSUPP;
+ goto free_actions;
+diff --git a/drivers/net/ethernet/mellanox/mlx5/core/steering/hws/mlx5hws.h b/drivers/net/ethernet/mellanox/mlx5/core/steering/hws/mlx5hws.h
+index 32d7d75bc6daf..e6ba5a2129075 100644
+--- a/drivers/net/ethernet/mellanox/mlx5/core/steering/hws/mlx5hws.h
++++ b/drivers/net/ethernet/mellanox/mlx5/core/steering/hws/mlx5hws.h
+@@ -727,7 +727,6 @@ mlx5hws_action_create_push_vlan(struct mlx5hws_context *ctx, u32 flags);
+ * @num_dest: The number of dests attributes.
+ * @dests: The destination array. Each contains a destination action and can
+ * have additional actions.
+- * @ignore_flow_level: Whether to turn on 'ignore_flow_level' for this dest.
+ * @flags: Action creation flags (enum mlx5hws_action_flags).
+ *
+ * Return: pointer to mlx5hws_action on success NULL otherwise.
+@@ -735,7 +734,7 @@ mlx5hws_action_create_push_vlan(struct mlx5hws_context *ctx, u32 flags);
+ struct mlx5hws_action *
+ mlx5hws_action_create_dest_array(struct mlx5hws_context *ctx, size_t num_dest,
+ struct mlx5hws_action_dest_attr *dests,
+- bool ignore_flow_level, u32 flags);
++ u32 flags);
+
+ /**
+ * mlx5hws_action_create_insert_header - Create insert header action.
+--
+2.51.0
+
--- /dev/null
+From 4518a726465cae2d4ab0846f48109f9ef25079f2 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 3 Jul 2025 21:54:22 +0300
+Subject: net/mlx5: HWS, remove unused create_dest_array parameter
+
+From: Vlad Dogaru <vdogaru@nvidia.com>
+
+[ Upstream commit 60afb51c89414b3d0061226415651f29a7eaf932 ]
+
+`flow_source` is not used anywhere in mlx5hws_action_create_dest_array.
+
+Signed-off-by: Vlad Dogaru <vdogaru@nvidia.com>
+Signed-off-by: Yevgeny Kliteynik <kliteyn@nvidia.com>
+Reviewed-by: Simon Horman <horms@kernel.org>
+Signed-off-by: Mark Bloch <mbloch@nvidia.com>
+Link: https://patch.msgid.link/20250703185431.445571-2-mbloch@nvidia.com
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Stable-dep-of: efb877cf27e3 ("net/mlx5: HWS, ignore flow level for multi-dest table")
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ .../mellanox/mlx5/core/steering/hws/action.c | 7 ++-----
+ .../mellanox/mlx5/core/steering/hws/fs_hws.c | 15 ++++++---------
+ .../mellanox/mlx5/core/steering/hws/mlx5hws.h | 8 ++------
+ 3 files changed, 10 insertions(+), 20 deletions(-)
+
+diff --git a/drivers/net/ethernet/mellanox/mlx5/core/steering/hws/action.c b/drivers/net/ethernet/mellanox/mlx5/core/steering/hws/action.c
+index 8e4a085f4a2ec..6b36a4a7d895f 100644
+--- a/drivers/net/ethernet/mellanox/mlx5/core/steering/hws/action.c
++++ b/drivers/net/ethernet/mellanox/mlx5/core/steering/hws/action.c
+@@ -1358,12 +1358,9 @@ mlx5hws_action_create_modify_header(struct mlx5hws_context *ctx,
+ }
+
+ struct mlx5hws_action *
+-mlx5hws_action_create_dest_array(struct mlx5hws_context *ctx,
+- size_t num_dest,
++mlx5hws_action_create_dest_array(struct mlx5hws_context *ctx, size_t num_dest,
+ struct mlx5hws_action_dest_attr *dests,
+- bool ignore_flow_level,
+- u32 flow_source,
+- u32 flags)
++ bool ignore_flow_level, u32 flags)
+ {
+ struct mlx5hws_cmd_set_fte_dest *dest_list = NULL;
+ struct mlx5hws_cmd_ft_create_attr ft_attr = {0};
+diff --git a/drivers/net/ethernet/mellanox/mlx5/core/steering/hws/fs_hws.c b/drivers/net/ethernet/mellanox/mlx5/core/steering/hws/fs_hws.c
+index 47e3947e7b512..131e74b2b7743 100644
+--- a/drivers/net/ethernet/mellanox/mlx5/core/steering/hws/fs_hws.c
++++ b/drivers/net/ethernet/mellanox/mlx5/core/steering/hws/fs_hws.c
+@@ -572,14 +572,12 @@ static void mlx5_fs_put_dest_action_sampler(struct mlx5_fs_hws_context *fs_ctx,
+ static struct mlx5hws_action *
+ mlx5_fs_create_action_dest_array(struct mlx5hws_context *ctx,
+ struct mlx5hws_action_dest_attr *dests,
+- u32 num_of_dests, bool ignore_flow_level,
+- u32 flow_source)
++ u32 num_of_dests, bool ignore_flow_level)
+ {
+ u32 flags = MLX5HWS_ACTION_FLAG_HWS_FDB | MLX5HWS_ACTION_FLAG_SHARED;
+
+ return mlx5hws_action_create_dest_array(ctx, num_of_dests, dests,
+- ignore_flow_level,
+- flow_source, flags);
++ ignore_flow_level, flags);
+ }
+
+ static struct mlx5hws_action *
+@@ -1016,7 +1014,6 @@ static int mlx5_fs_fte_get_hws_actions(struct mlx5_flow_root_namespace *ns,
+ }
+ (*ractions)[num_actions++].action = dest_actions->dest;
+ } else if (num_dest_actions > 1) {
+- u32 flow_source = fte->act_dests.flow_context.flow_source;
+ bool ignore_flow_level;
+
+ if (num_actions == MLX5_FLOW_CONTEXT_ACTION_MAX ||
+@@ -1026,10 +1023,10 @@ static int mlx5_fs_fte_get_hws_actions(struct mlx5_flow_root_namespace *ns,
+ }
+ ignore_flow_level =
+ !!(fte_action->flags & FLOW_ACT_IGNORE_FLOW_LEVEL);
+- tmp_action = mlx5_fs_create_action_dest_array(ctx, dest_actions,
+- num_dest_actions,
+- ignore_flow_level,
+- flow_source);
++ tmp_action =
++ mlx5_fs_create_action_dest_array(ctx, dest_actions,
++ num_dest_actions,
++ ignore_flow_level);
+ if (!tmp_action) {
+ err = -EOPNOTSUPP;
+ goto free_actions;
+diff --git a/drivers/net/ethernet/mellanox/mlx5/core/steering/hws/mlx5hws.h b/drivers/net/ethernet/mellanox/mlx5/core/steering/hws/mlx5hws.h
+index a2fe2f9e832d2..32d7d75bc6daf 100644
+--- a/drivers/net/ethernet/mellanox/mlx5/core/steering/hws/mlx5hws.h
++++ b/drivers/net/ethernet/mellanox/mlx5/core/steering/hws/mlx5hws.h
+@@ -728,18 +728,14 @@ mlx5hws_action_create_push_vlan(struct mlx5hws_context *ctx, u32 flags);
+ * @dests: The destination array. Each contains a destination action and can
+ * have additional actions.
+ * @ignore_flow_level: Whether to turn on 'ignore_flow_level' for this dest.
+- * @flow_source: Source port of the traffic for this actions.
+ * @flags: Action creation flags (enum mlx5hws_action_flags).
+ *
+ * Return: pointer to mlx5hws_action on success NULL otherwise.
+ */
+ struct mlx5hws_action *
+-mlx5hws_action_create_dest_array(struct mlx5hws_context *ctx,
+- size_t num_dest,
++mlx5hws_action_create_dest_array(struct mlx5hws_context *ctx, size_t num_dest,
+ struct mlx5hws_action_dest_attr *dests,
+- bool ignore_flow_level,
+- u32 flow_source,
+- u32 flags);
++ bool ignore_flow_level, u32 flags);
+
+ /**
+ * mlx5hws_action_create_insert_header - Create insert header action.
+--
+2.51.0
+
--- /dev/null
+From 23f2d6f657aaec66e45180beee97f65e1a6cca13 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Mon, 22 Sep 2025 10:11:34 +0300
+Subject: net/mlx5e: Fix missing FEC RS stats for RS_544_514_INTERLEAVED_QUAD
+
+From: Carolina Jubran <cjubran@nvidia.com>
+
+[ Upstream commit 6d0477d0d067a53c1d48d0aff1fd52e151721871 ]
+
+Include MLX5E_FEC_RS_544_514_INTERLEAVED_QUAD in the FEC RS stats
+handling. This addresses a gap introduced when adding support for
+200G/lane link modes.
+
+Fixes: 4e343c11efbb ("net/mlx5e: Support FEC settings for 200G per lane link modes")
+Signed-off-by: Carolina Jubran <cjubran@nvidia.com>
+Reviewed-by: Dragos Tatulea <dtatulea@nvidia.com>
+Reviewed-by: Yael Chemla <ychemla@nvidia.com>
+Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
+Link: https://patch.msgid.link/1758525094-816583-4-git-send-email-tariqt@nvidia.com
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/ethernet/mellanox/mlx5/core/en_stats.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_stats.c b/drivers/net/ethernet/mellanox/mlx5/core/en_stats.c
+index 19664fa7f2171..46d6dd05fb814 100644
+--- a/drivers/net/ethernet/mellanox/mlx5/core/en_stats.c
++++ b/drivers/net/ethernet/mellanox/mlx5/core/en_stats.c
+@@ -1466,6 +1466,7 @@ static void fec_set_block_stats(struct mlx5e_priv *priv,
+ case MLX5E_FEC_RS_528_514:
+ case MLX5E_FEC_RS_544_514:
+ case MLX5E_FEC_LLRS_272_257_1:
++ case MLX5E_FEC_RS_544_514_INTERLEAVED_QUAD:
+ fec_set_rs_stats(fec_stats, out);
+ return;
+ case MLX5E_FEC_FIRECODE:
+--
+2.51.0
+
--- /dev/null
+From 8542c28d8a19b38cf4073187c98f7c5288d0460a Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 17 Sep 2025 20:42:20 +0200
+Subject: net/smc: fix warning in smc_rx_splice() when calling get_page()
+
+From: Sidraya Jayagond <sidraya@linux.ibm.com>
+
+[ Upstream commit a35c04de2565db191726b5741e6b66a35002c652 ]
+
+smc_lo_register_dmb() allocates DMB buffers with kzalloc(), which are
+later passed to get_page() in smc_rx_splice(). Since kmalloc memory is
+not page-backed, this triggers WARN_ON_ONCE() in get_page() and prevents
+holding a refcount on the buffer. This can lead to use-after-free if
+the memory is released before splice_to_pipe() completes.
+
+Use folio_alloc() instead, ensuring DMBs are page-backed and safe for
+get_page().
+
+WARNING: CPU: 18 PID: 12152 at ./include/linux/mm.h:1330 smc_rx_splice+0xaf8/0xe20 [smc]
+CPU: 18 UID: 0 PID: 12152 Comm: smcapp Kdump: loaded Not tainted 6.17.0-rc3-11705-g9cf4672ecfee #10 NONE
+Hardware name: IBM 3931 A01 704 (z/VM 7.4.0)
+Krnl PSW : 0704e00180000000 000793161032696c (smc_rx_splice+0xafc/0xe20 [smc])
+ R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:2 PM:0 RI:0 EA:3
+Krnl GPRS: 0000000000000000 001cee80007d3001 00077400000000f8 0000000000000005
+ 0000000000000001 001cee80007d3006 0007740000001000 001c000000000000
+ 000000009b0c99e0 0000000000001000 001c0000000000f8 001c000000000000
+ 000003ffcc6f7c88 0007740003e98000 0007931600000005 000792969b2ff7b8
+Krnl Code: 0007931610326960: af000000 mc 0,0
+ 0007931610326964: a7f4ff43 brc 15,00079316103267ea
+ #0007931610326968: af000000 mc 0,0
+ >000793161032696c: a7f4ff3f brc 15,00079316103267ea
+ 0007931610326970: e320f1000004 lg %r2,256(%r15)
+ 0007931610326976: c0e53fd1b5f5 brasl %r14,000793168fd5d560
+ 000793161032697c: a7f4fbb5 brc 15,00079316103260e6
+ 0007931610326980: b904002b lgr %r2,%r11
+Call Trace:
+ smc_rx_splice+0xafc/0xe20 [smc]
+ smc_rx_splice+0x756/0xe20 [smc])
+ smc_rx_recvmsg+0xa74/0xe00 [smc]
+ smc_splice_read+0x1ce/0x3b0 [smc]
+ sock_splice_read+0xa2/0xf0
+ do_splice_read+0x198/0x240
+ splice_file_to_pipe+0x7e/0x110
+ do_splice+0x59e/0xde0
+ __do_splice+0x11a/0x2d0
+ __s390x_sys_splice+0x140/0x1f0
+ __do_syscall+0x122/0x280
+ system_call+0x6e/0x90
+Last Breaking-Event-Address:
+smc_rx_splice+0x960/0xe20 [smc]
+---[ end trace 0000000000000000 ]---
+
+Fixes: f7a22071dbf3 ("net/smc: implement DMB-related operations of loopback-ism")
+Reviewed-by: Mahanta Jambigi <mjambigi@linux.ibm.com>
+Signed-off-by: Sidraya Jayagond <sidraya@linux.ibm.com>
+Link: https://patch.msgid.link/20250917184220.801066-1-sidraya@linux.ibm.com
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ net/smc/smc_loopback.c | 14 +++++++++-----
+ 1 file changed, 9 insertions(+), 5 deletions(-)
+
+diff --git a/net/smc/smc_loopback.c b/net/smc/smc_loopback.c
+index 3c5f64ca41153..85f0b7853b173 100644
+--- a/net/smc/smc_loopback.c
++++ b/net/smc/smc_loopback.c
+@@ -56,6 +56,7 @@ static int smc_lo_register_dmb(struct smcd_dev *smcd, struct smcd_dmb *dmb,
+ {
+ struct smc_lo_dmb_node *dmb_node, *tmp_node;
+ struct smc_lo_dev *ldev = smcd->priv;
++ struct folio *folio;
+ int sba_idx, rc;
+
+ /* check space for new dmb */
+@@ -74,13 +75,16 @@ static int smc_lo_register_dmb(struct smcd_dev *smcd, struct smcd_dmb *dmb,
+
+ dmb_node->sba_idx = sba_idx;
+ dmb_node->len = dmb->dmb_len;
+- dmb_node->cpu_addr = kzalloc(dmb_node->len, GFP_KERNEL |
+- __GFP_NOWARN | __GFP_NORETRY |
+- __GFP_NOMEMALLOC);
+- if (!dmb_node->cpu_addr) {
++
++ /* not critical; fail under memory pressure and fallback to TCP */
++ folio = folio_alloc(GFP_KERNEL | __GFP_NOWARN | __GFP_NOMEMALLOC |
++ __GFP_NORETRY | __GFP_ZERO,
++ get_order(dmb_node->len));
++ if (!folio) {
+ rc = -ENOMEM;
+ goto err_node;
+ }
++ dmb_node->cpu_addr = folio_address(folio);
+ dmb_node->dma_addr = SMC_DMA_ADDR_INVALID;
+ refcount_set(&dmb_node->refcnt, 1);
+
+@@ -122,7 +126,7 @@ static void __smc_lo_unregister_dmb(struct smc_lo_dev *ldev,
+ write_unlock_bh(&ldev->dmb_ht_lock);
+
+ clear_bit(dmb_node->sba_idx, ldev->sba_idx_mask);
+- kvfree(dmb_node->cpu_addr);
++ folio_put(virt_to_folio(dmb_node->cpu_addr));
+ kfree(dmb_node);
+
+ if (atomic_dec_and_test(&ldev->dmb_cnt))
+--
+2.51.0
+
--- /dev/null
+From 4c7837cdbd6477c762f9ab99b9c59d82580439d9 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 17 Sep 2025 19:39:19 +0800
+Subject: net: tun: Update napi->skb after XDP process
+
+From: Wang Liang <wangliang74@huawei.com>
+
+[ Upstream commit 1091860a16a86ccdd77c09f2b21a5f634f5ab9ec ]
+
+The syzbot report a UAF issue:
+
+ BUG: KASAN: slab-use-after-free in skb_reset_mac_header include/linux/skbuff.h:3150 [inline]
+ BUG: KASAN: slab-use-after-free in napi_frags_skb net/core/gro.c:723 [inline]
+ BUG: KASAN: slab-use-after-free in napi_gro_frags+0x6e/0x1030 net/core/gro.c:758
+ Read of size 8 at addr ffff88802ef22c18 by task syz.0.17/6079
+ CPU: 0 UID: 0 PID: 6079 Comm: syz.0.17 Not tainted syzkaller #0 PREEMPT(full)
+ Call Trace:
+ <TASK>
+ dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120
+ print_address_description mm/kasan/report.c:378 [inline]
+ print_report+0xca/0x240 mm/kasan/report.c:482
+ kasan_report+0x118/0x150 mm/kasan/report.c:595
+ skb_reset_mac_header include/linux/skbuff.h:3150 [inline]
+ napi_frags_skb net/core/gro.c:723 [inline]
+ napi_gro_frags+0x6e/0x1030 net/core/gro.c:758
+ tun_get_user+0x28cb/0x3e20 drivers/net/tun.c:1920
+ tun_chr_write_iter+0x113/0x200 drivers/net/tun.c:1996
+ new_sync_write fs/read_write.c:593 [inline]
+ vfs_write+0x5c9/0xb30 fs/read_write.c:686
+ ksys_write+0x145/0x250 fs/read_write.c:738
+ do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
+ do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94
+ entry_SYSCALL_64_after_hwframe+0x77/0x7f
+ </TASK>
+
+ Allocated by task 6079:
+ kasan_save_stack mm/kasan/common.c:47 [inline]
+ kasan_save_track+0x3e/0x80 mm/kasan/common.c:68
+ unpoison_slab_object mm/kasan/common.c:330 [inline]
+ __kasan_mempool_unpoison_object+0xa0/0x170 mm/kasan/common.c:558
+ kasan_mempool_unpoison_object include/linux/kasan.h:388 [inline]
+ napi_skb_cache_get+0x37b/0x6d0 net/core/skbuff.c:295
+ __alloc_skb+0x11e/0x2d0 net/core/skbuff.c:657
+ napi_alloc_skb+0x84/0x7d0 net/core/skbuff.c:811
+ napi_get_frags+0x69/0x140 net/core/gro.c:673
+ tun_napi_alloc_frags drivers/net/tun.c:1404 [inline]
+ tun_get_user+0x77c/0x3e20 drivers/net/tun.c:1784
+ tun_chr_write_iter+0x113/0x200 drivers/net/tun.c:1996
+ new_sync_write fs/read_write.c:593 [inline]
+ vfs_write+0x5c9/0xb30 fs/read_write.c:686
+ ksys_write+0x145/0x250 fs/read_write.c:738
+ do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
+ do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94
+ entry_SYSCALL_64_after_hwframe+0x77/0x7f
+
+ Freed by task 6079:
+ kasan_save_stack mm/kasan/common.c:47 [inline]
+ kasan_save_track+0x3e/0x80 mm/kasan/common.c:68
+ kasan_save_free_info+0x46/0x50 mm/kasan/generic.c:576
+ poison_slab_object mm/kasan/common.c:243 [inline]
+ __kasan_slab_free+0x5b/0x80 mm/kasan/common.c:275
+ kasan_slab_free include/linux/kasan.h:233 [inline]
+ slab_free_hook mm/slub.c:2422 [inline]
+ slab_free mm/slub.c:4695 [inline]
+ kmem_cache_free+0x18f/0x400 mm/slub.c:4797
+ skb_pp_cow_data+0xdd8/0x13e0 net/core/skbuff.c:969
+ netif_skb_check_for_xdp net/core/dev.c:5390 [inline]
+ netif_receive_generic_xdp net/core/dev.c:5431 [inline]
+ do_xdp_generic+0x699/0x11a0 net/core/dev.c:5499
+ tun_get_user+0x2523/0x3e20 drivers/net/tun.c:1872
+ tun_chr_write_iter+0x113/0x200 drivers/net/tun.c:1996
+ new_sync_write fs/read_write.c:593 [inline]
+ vfs_write+0x5c9/0xb30 fs/read_write.c:686
+ ksys_write+0x145/0x250 fs/read_write.c:738
+ do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
+ do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94
+ entry_SYSCALL_64_after_hwframe+0x77/0x7f
+
+After commit e6d5dbdd20aa ("xdp: add multi-buff support for xdp running in
+generic mode"), the original skb may be freed in skb_pp_cow_data() when
+XDP program was attached, which was allocated in tun_napi_alloc_frags().
+However, the napi->skb still point to the original skb, update it after
+XDP process.
+
+Reported-by: syzbot+64e24275ad95a915a313@syzkaller.appspotmail.com
+Closes: https://syzkaller.appspot.com/bug?extid=64e24275ad95a915a313
+Fixes: e6d5dbdd20aa ("xdp: add multi-buff support for xdp running in generic mode")
+Signed-off-by: Wang Liang <wangliang74@huawei.com>
+Reviewed-by: Willem de Bruijn <willemb@google.com>
+Link: https://patch.msgid.link/20250917113919.3991267-1-wangliang74@huawei.com
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/tun.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+diff --git a/drivers/net/tun.c b/drivers/net/tun.c
+index f8c5e2fd04dfa..0fffa023cb736 100644
+--- a/drivers/net/tun.c
++++ b/drivers/net/tun.c
+@@ -1863,6 +1863,9 @@ static ssize_t tun_get_user(struct tun_struct *tun, struct tun_file *tfile,
+ local_bh_enable();
+ goto unlock_frags;
+ }
++
++ if (frags && skb != tfile->napi.skb)
++ tfile->napi.skb = skb;
+ }
+ rcu_read_unlock();
+ local_bh_enable();
+--
+2.51.0
+
--- /dev/null
+From 0e0227167649de45dbd03a07a01449b728dfae28 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Sun, 21 Sep 2025 18:08:22 +0300
+Subject: nexthop: Forbid FDB status change while nexthop is in a group
+
+From: Ido Schimmel <idosch@nvidia.com>
+
+[ Upstream commit 390b3a300d7872cef9588f003b204398be69ce08 ]
+
+The kernel forbids the creation of non-FDB nexthop groups with FDB
+nexthops:
+
+ # ip nexthop add id 1 via 192.0.2.1 fdb
+ # ip nexthop add id 2 group 1
+ Error: Non FDB nexthop group cannot have fdb nexthops.
+
+And vice versa:
+
+ # ip nexthop add id 3 via 192.0.2.2 dev dummy1
+ # ip nexthop add id 4 group 3 fdb
+ Error: FDB nexthop group can only have fdb nexthops.
+
+However, as long as no routes are pointing to a non-FDB nexthop group,
+the kernel allows changing the type of a nexthop from FDB to non-FDB and
+vice versa:
+
+ # ip nexthop add id 5 via 192.0.2.2 dev dummy1
+ # ip nexthop add id 6 group 5
+ # ip nexthop replace id 5 via 192.0.2.2 fdb
+ # echo $?
+ 0
+
+This configuration is invalid and can result in a NPD [1] since FDB
+nexthops are not associated with a nexthop device:
+
+ # ip route add 198.51.100.1/32 nhid 6
+ # ping 198.51.100.1
+
+Fix by preventing nexthop FDB status change while the nexthop is in a
+group:
+
+ # ip nexthop add id 7 via 192.0.2.2 dev dummy1
+ # ip nexthop add id 8 group 7
+ # ip nexthop replace id 7 via 192.0.2.2 fdb
+ Error: Cannot change nexthop FDB status while in a group.
+
+[1]
+BUG: kernel NULL pointer dereference, address: 00000000000003c0
+[...]
+Oops: Oops: 0000 [#1] SMP
+CPU: 6 UID: 0 PID: 367 Comm: ping Not tainted 6.17.0-rc6-virtme-gb65678cacc03 #1 PREEMPT(voluntary)
+Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-4.fc41 04/01/2014
+RIP: 0010:fib_lookup_good_nhc+0x1e/0x80
+[...]
+Call Trace:
+ <TASK>
+ fib_table_lookup+0x541/0x650
+ ip_route_output_key_hash_rcu+0x2ea/0x970
+ ip_route_output_key_hash+0x55/0x80
+ __ip4_datagram_connect+0x250/0x330
+ udp_connect+0x2b/0x60
+ __sys_connect+0x9c/0xd0
+ __x64_sys_connect+0x18/0x20
+ do_syscall_64+0xa4/0x2a0
+ entry_SYSCALL_64_after_hwframe+0x4b/0x53
+
+Fixes: 38428d68719c ("nexthop: support for fdb ecmp nexthops")
+Reported-by: syzbot+6596516dd2b635ba2350@syzkaller.appspotmail.com
+Closes: https://lore.kernel.org/netdev/68c9a4d2.050a0220.3c6139.0e63.GAE@google.com/
+Tested-by: syzbot+6596516dd2b635ba2350@syzkaller.appspotmail.com
+Signed-off-by: Ido Schimmel <idosch@nvidia.com>
+Reviewed-by: David Ahern <dsahern@kernel.org>
+Link: https://patch.msgid.link/20250921150824.149157-2-idosch@nvidia.com
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ net/ipv4/nexthop.c | 7 +++++++
+ 1 file changed, 7 insertions(+)
+
+diff --git a/net/ipv4/nexthop.c b/net/ipv4/nexthop.c
+index 4397e89d3123a..423f876d14c6a 100644
+--- a/net/ipv4/nexthop.c
++++ b/net/ipv4/nexthop.c
+@@ -2400,6 +2400,13 @@ static int replace_nexthop_single(struct net *net, struct nexthop *old,
+ return -EINVAL;
+ }
+
++ if (!list_empty(&old->grp_list) &&
++ rtnl_dereference(new->nh_info)->fdb_nh !=
++ rtnl_dereference(old->nh_info)->fdb_nh) {
++ NL_SET_ERR_MSG(extack, "Cannot change nexthop FDB status while in a group");
++ return -EINVAL;
++ }
++
+ err = call_nexthop_notifiers(net, NEXTHOP_EVENT_REPLACE, new, extack);
+ if (err)
+ return err;
+--
+2.51.0
+
--- /dev/null
+From 1287c1287bf192e8492eb2add2f7b6cae3a95096 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 23 Sep 2025 14:19:11 +0300
+Subject: octeontx2-pf: Fix potential use after free in otx2_tc_add_flow()
+
+From: Dan Carpenter <dan.carpenter@linaro.org>
+
+[ Upstream commit d9c70e93ec5988ab07ad2a92d9f9d12867f02c56 ]
+
+This code calls kfree_rcu(new_node, rcu) and then dereferences "new_node"
+and then dereferences it on the next line. Two lines later, we take
+a mutex so I don't think this is an RCU safe region. Re-order it to do
+the dereferences before queuing up the free.
+
+Fixes: 68fbff68dbea ("octeontx2-pf: Add police action for TC flower")
+Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
+Reviewed-by: Vadim Fedorenko <vadim.fedorenko@linux.dev>
+Link: https://patch.msgid.link/aNKCL1jKwK8GRJHh@stanley.mountain
+Signed-off-by: Paolo Abeni <pabeni@redhat.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/ethernet/marvell/octeontx2/nic/otx2_tc.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/drivers/net/ethernet/marvell/octeontx2/nic/otx2_tc.c b/drivers/net/ethernet/marvell/octeontx2/nic/otx2_tc.c
+index 5f80b23c5335c..26a08d2cfbb1b 100644
+--- a/drivers/net/ethernet/marvell/octeontx2/nic/otx2_tc.c
++++ b/drivers/net/ethernet/marvell/octeontx2/nic/otx2_tc.c
+@@ -1326,7 +1326,6 @@ static int otx2_tc_add_flow(struct otx2_nic *nic,
+
+ free_leaf:
+ otx2_tc_del_from_flow_list(flow_cfg, new_node);
+- kfree_rcu(new_node, rcu);
+ if (new_node->is_act_police) {
+ mutex_lock(&nic->mbox.lock);
+
+@@ -1346,6 +1345,7 @@ static int otx2_tc_add_flow(struct otx2_nic *nic,
+
+ mutex_unlock(&nic->mbox.lock);
+ }
++ kfree_rcu(new_node, rcu);
+
+ return rc;
+ }
+--
+2.51.0
+
--- /dev/null
+From 04230642e7d9788e4638e9470dde553e7bd5cff0 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Sun, 21 Sep 2025 18:08:23 +0300
+Subject: selftests: fib_nexthops: Fix creation of non-FDB nexthops
+
+From: Ido Schimmel <idosch@nvidia.com>
+
+[ Upstream commit c29913109c70383cdf90b6fc792353e1009f24f5 ]
+
+The test creates non-FDB nexthops without a nexthop device which leads
+to the expected failure, but for the wrong reason:
+
+ # ./fib_nexthops.sh -t "ipv6_fdb_grp_fcnal ipv4_fdb_grp_fcnal" -v
+
+ IPv6 fdb groups functional
+ --------------------------
+ [...]
+ COMMAND: ip -netns me-nRsN3E nexthop add id 63 via 2001:db8:91::4
+ Error: Device attribute required for non-blackhole and non-fdb nexthops.
+ COMMAND: ip -netns me-nRsN3E nexthop add id 64 via 2001:db8:91::5
+ Error: Device attribute required for non-blackhole and non-fdb nexthops.
+ COMMAND: ip -netns me-nRsN3E nexthop add id 103 group 63/64 fdb
+ Error: Invalid nexthop id.
+ TEST: Fdb Nexthop group with non-fdb nexthops [ OK ]
+ [...]
+
+ IPv4 fdb groups functional
+ --------------------------
+ [...]
+ COMMAND: ip -netns me-nRsN3E nexthop add id 14 via 172.16.1.2
+ Error: Device attribute required for non-blackhole and non-fdb nexthops.
+ COMMAND: ip -netns me-nRsN3E nexthop add id 15 via 172.16.1.3
+ Error: Device attribute required for non-blackhole and non-fdb nexthops.
+ COMMAND: ip -netns me-nRsN3E nexthop add id 103 group 14/15 fdb
+ Error: Invalid nexthop id.
+ TEST: Fdb Nexthop group with non-fdb nexthops [ OK ]
+
+ COMMAND: ip -netns me-nRsN3E nexthop add id 16 via 172.16.1.2 fdb
+ COMMAND: ip -netns me-nRsN3E nexthop add id 17 via 172.16.1.3 fdb
+ COMMAND: ip -netns me-nRsN3E nexthop add id 104 group 14/15
+ Error: Invalid nexthop id.
+ TEST: Non-Fdb Nexthop group with fdb nexthops [ OK ]
+ [...]
+ COMMAND: ip -netns me-0dlhyd ro add 172.16.0.0/22 nhid 15
+ Error: Nexthop id does not exist.
+ TEST: Route add with fdb nexthop [ OK ]
+
+In addition, as can be seen in the above output, a couple of IPv4 test
+cases used the non-FDB nexthops (14 and 15) when they intended to use
+the FDB nexthops (16 and 17). These test cases only passed because
+failure was expected, but they failed for the wrong reason.
+
+Fix the test to create the non-FDB nexthops with a nexthop device and
+adjust the IPv4 test cases to use the FDB nexthops instead of the
+non-FDB nexthops.
+
+Output after the fix:
+
+ # ./fib_nexthops.sh -t "ipv6_fdb_grp_fcnal ipv4_fdb_grp_fcnal" -v
+
+ IPv6 fdb groups functional
+ --------------------------
+ [...]
+ COMMAND: ip -netns me-lNzfHP nexthop add id 63 via 2001:db8:91::4 dev veth1
+ COMMAND: ip -netns me-lNzfHP nexthop add id 64 via 2001:db8:91::5 dev veth1
+ COMMAND: ip -netns me-lNzfHP nexthop add id 103 group 63/64 fdb
+ Error: FDB nexthop group can only have fdb nexthops.
+ TEST: Fdb Nexthop group with non-fdb nexthops [ OK ]
+ [...]
+
+ IPv4 fdb groups functional
+ --------------------------
+ [...]
+ COMMAND: ip -netns me-lNzfHP nexthop add id 14 via 172.16.1.2 dev veth1
+ COMMAND: ip -netns me-lNzfHP nexthop add id 15 via 172.16.1.3 dev veth1
+ COMMAND: ip -netns me-lNzfHP nexthop add id 103 group 14/15 fdb
+ Error: FDB nexthop group can only have fdb nexthops.
+ TEST: Fdb Nexthop group with non-fdb nexthops [ OK ]
+
+ COMMAND: ip -netns me-lNzfHP nexthop add id 16 via 172.16.1.2 fdb
+ COMMAND: ip -netns me-lNzfHP nexthop add id 17 via 172.16.1.3 fdb
+ COMMAND: ip -netns me-lNzfHP nexthop add id 104 group 16/17
+ Error: Non FDB nexthop group cannot have fdb nexthops.
+ TEST: Non-Fdb Nexthop group with fdb nexthops [ OK ]
+ [...]
+ COMMAND: ip -netns me-lNzfHP ro add 172.16.0.0/22 nhid 16
+ Error: Route cannot point to a fdb nexthop.
+ TEST: Route add with fdb nexthop [ OK ]
+ [...]
+ Tests passed: 30
+ Tests failed: 0
+ Tests skipped: 0
+
+Fixes: 0534c5489c11 ("selftests: net: add fdb nexthop tests")
+Signed-off-by: Ido Schimmel <idosch@nvidia.com>
+Reviewed-by: David Ahern <dsahern@kernel.org>
+Link: https://patch.msgid.link/20250921150824.149157-3-idosch@nvidia.com
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ tools/testing/selftests/net/fib_nexthops.sh | 12 ++++++------
+ 1 file changed, 6 insertions(+), 6 deletions(-)
+
+diff --git a/tools/testing/selftests/net/fib_nexthops.sh b/tools/testing/selftests/net/fib_nexthops.sh
+index b39f748c25722..2ac394c99d018 100755
+--- a/tools/testing/selftests/net/fib_nexthops.sh
++++ b/tools/testing/selftests/net/fib_nexthops.sh
+@@ -467,8 +467,8 @@ ipv6_fdb_grp_fcnal()
+ log_test $? 0 "Get Fdb nexthop group by id"
+
+ # fdb nexthop group can only contain fdb nexthops
+- run_cmd "$IP nexthop add id 63 via 2001:db8:91::4"
+- run_cmd "$IP nexthop add id 64 via 2001:db8:91::5"
++ run_cmd "$IP nexthop add id 63 via 2001:db8:91::4 dev veth1"
++ run_cmd "$IP nexthop add id 64 via 2001:db8:91::5 dev veth1"
+ run_cmd "$IP nexthop add id 103 group 63/64 fdb"
+ log_test $? 2 "Fdb Nexthop group with non-fdb nexthops"
+
+@@ -547,15 +547,15 @@ ipv4_fdb_grp_fcnal()
+ log_test $? 0 "Get Fdb nexthop group by id"
+
+ # fdb nexthop group can only contain fdb nexthops
+- run_cmd "$IP nexthop add id 14 via 172.16.1.2"
+- run_cmd "$IP nexthop add id 15 via 172.16.1.3"
++ run_cmd "$IP nexthop add id 14 via 172.16.1.2 dev veth1"
++ run_cmd "$IP nexthop add id 15 via 172.16.1.3 dev veth1"
+ run_cmd "$IP nexthop add id 103 group 14/15 fdb"
+ log_test $? 2 "Fdb Nexthop group with non-fdb nexthops"
+
+ # Non fdb nexthop group can not contain fdb nexthops
+ run_cmd "$IP nexthop add id 16 via 172.16.1.2 fdb"
+ run_cmd "$IP nexthop add id 17 via 172.16.1.3 fdb"
+- run_cmd "$IP nexthop add id 104 group 14/15"
++ run_cmd "$IP nexthop add id 104 group 16/17"
+ log_test $? 2 "Non-Fdb Nexthop group with fdb nexthops"
+
+ # fdb nexthop cannot have blackhole
+@@ -582,7 +582,7 @@ ipv4_fdb_grp_fcnal()
+ run_cmd "$BRIDGE fdb add 02:02:00:00:00:14 dev vx10 nhid 12 self"
+ log_test $? 255 "Fdb mac add with nexthop"
+
+- run_cmd "$IP ro add 172.16.0.0/22 nhid 15"
++ run_cmd "$IP ro add 172.16.0.0/22 nhid 16"
+ log_test $? 2 "Route add with fdb nexthop"
+
+ run_cmd "$IP ro add 172.16.0.0/22 nhid 103"
+--
+2.51.0
+
can-rcar_can-rcar_can_resume-fix-s2ram-with-psci.patch
bpf-reject-bpf_timer-for-preempt_rt.patch
selftests-bpf-skip-timer-cases-when-bpf_timer-is-not.patch
+xfrm-xfrm_alloc_spi-shouldn-t-use-0-as-spi.patch
+xfrm-fix-offloading-of-cross-family-tunnels.patch
+can-etas_es58x-populate-ndo_change_mtu-to-prevent-bu.patch
+can-hi311x-populate-ndo_change_mtu-to-prevent-buffer.patch
+can-sun4i_can-populate-ndo_change_mtu-to-prevent-buf.patch
+can-mcba_usb-populate-ndo_change_mtu-to-prevent-buff.patch
+can-peak_usb-fix-shift-out-of-bounds-issue.patch
+net-tun-update-napi-skb-after-xdp-process.patch
+net-smc-fix-warning-in-smc_rx_splice-when-calling-ge.patch
+ethernet-rvu-af-remove-slash-from-the-driver-name.patch
+bluetooth-hci_sync-fix-hci_resume_advertising_sync.patch
+bluetooth-hci_event-fix-uaf-in-hci_conn_tx_dequeue.patch
+bluetooth-hci_event-fix-uaf-in-hci_acl_create_conn_s.patch
+vhost-take-a-reference-on-the-task-in-struct-vhost_t.patch
+bluetooth-mgmt-fix-possible-uafs.patch
+broadcom-fix-support-for-ptp_perout_duty_cycle.patch
+broadcom-fix-support-for-ptp_extts_request2-ioctl.patch
+bnxt_en-correct-offset-handling-for-ipv6-destination.patch
+net-allow-alloc_skb_with_frags-to-use-max_skb_frags.patch
+nexthop-forbid-fdb-status-change-while-nexthop-is-in.patch
+selftests-fib_nexthops-fix-creation-of-non-fdb-nexth.patch
+net-mlx5-fs-fix-uaf-in-flow-counter-release.patch
+net-mlx5-hws-remove-unused-create_dest_array-paramet.patch
+net-mlx5-hws-ignore-flow-level-for-multi-dest-table.patch
+net-mlx5e-fix-missing-fec-rs-stats-for-rs_544_514_in.patch
+net-dsa-lantiq_gswip-move-gswip_add_single_port_br-c.patch
+net-dsa-lantiq_gswip-suppress-einval-errors-for-brid.patch
+octeontx2-pf-fix-potential-use-after-free-in-otx2_tc.patch
--- /dev/null
+From 8c0180fc25fadbc83b653833f7b84245d4e0ff35 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 18 Sep 2025 20:11:44 +0200
+Subject: vhost: Take a reference on the task in struct vhost_task.
+
+From: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
+
+[ Upstream commit afe16653e05db07d658b55245c7a2e0603f136c0 ]
+
+vhost_task_create() creates a task and keeps a reference to its
+task_struct. That task may exit early via a signal and its task_struct
+will be released.
+A pending vhost_task_wake() will then attempt to wake the task and
+access a task_struct which is no longer there.
+
+Acquire a reference on the task_struct while creating the thread and
+release the reference while the struct vhost_task itself is removed.
+If the task exits early due to a signal, then the vhost_task_wake() will
+still access a valid task_struct. The wake is safe and will be skipped
+in this case.
+
+Fixes: f9010dbdce911 ("fork, vhost: Use CLONE_THREAD to fix freezer/ps regression")
+Reported-by: Sean Christopherson <seanjc@google.com>
+Closes: https://lore.kernel.org/all/aKkLEtoDXKxAAWju@google.com/
+Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
+Message-Id: <20250918181144.Ygo8BZ-R@linutronix.de>
+Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
+Tested-by: Sean Christopherson <seanjc@google.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ kernel/vhost_task.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+diff --git a/kernel/vhost_task.c b/kernel/vhost_task.c
+index 2f844c279a3e0..7f24ccc896c64 100644
+--- a/kernel/vhost_task.c
++++ b/kernel/vhost_task.c
+@@ -100,6 +100,7 @@ void vhost_task_stop(struct vhost_task *vtsk)
+ * freeing it below.
+ */
+ wait_for_completion(&vtsk->exited);
++ put_task_struct(vtsk->task);
+ kfree(vtsk);
+ }
+ EXPORT_SYMBOL_GPL(vhost_task_stop);
+@@ -148,7 +149,7 @@ struct vhost_task *vhost_task_create(bool (*fn)(void *),
+ return ERR_PTR(PTR_ERR(tsk));
+ }
+
+- vtsk->task = tsk;
++ vtsk->task = get_task_struct(tsk);
+ return vtsk;
+ }
+ EXPORT_SYMBOL_GPL(vhost_task_create);
+--
+2.51.0
+
--- /dev/null
+From 49f3b601e230ce6d16e86e81ea20577e0a630f1f Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 10 Sep 2025 17:22:13 +0200
+Subject: xfrm: fix offloading of cross-family tunnels
+
+From: Sabrina Dubroca <sd@queasysnail.net>
+
+[ Upstream commit 91d8a53db2199eefc73ecf3682e0665ea6895696 ]
+
+Xiumei reported a regression in IPsec offload tests over xfrmi, where
+the traffic for IPv6 over IPv4 tunnels is processed in SW instead of
+going through crypto offload, after commit
+cc18f482e8b6 ("xfrm: provide common xdo_dev_offload_ok callback
+implementation").
+
+Commit cc18f482e8b6 added a generic version of existing checks
+attempting to prevent packets with IPv4 options or IPv6 extension
+headers from being sent to HW that doesn't support offloading such
+packets. The check mistakenly uses x->props.family (the outer family)
+to determine the inner packet's family and verify if
+options/extensions are present.
+
+In the case of IPv6 over IPv4, the check compares some of the traffic
+class bits to the expected no-options ihl value (5). The original
+check was introduced in commit 2ac9cfe78223 ("net/mlx5e: IPSec, Add
+Innova IPSec offload TX data path"), and then duplicated in the other
+drivers. Before commit cc18f482e8b6, the loose check (ihl > 5) passed
+because those traffic class bits were not set to a value that
+triggered the no-offload codepath. Packets with options/extension
+headers that should have been handled in SW went through the offload
+path, and were likely dropped by the NIC or incorrectly
+processed. Since commit cc18f482e8b6, the check is now strict (ihl !=
+5), and in a basic setup (no traffic class configured), all packets go
+through the no-offload codepath.
+
+The commits that introduced the incorrect family checks in each driver
+are:
+2ac9cfe78223 ("net/mlx5e: IPSec, Add Innova IPSec offload TX data path")
+8362ea16f69f ("crypto: chcr - ESN for Inline IPSec Tx")
+859a497fe80c ("nfp: implement xfrm callbacks and expose ipsec offload feature to upper layer")
+32188be805d0 ("cn10k-ipsec: Allow ipsec crypto offload for skb with SA")
+[ixgbe/ixgbevf commits are ignored, as that HW does not support tunnel
+mode, thus no cross-family setups are possible]
+
+Fixes: cc18f482e8b6 ("xfrm: provide common xdo_dev_offload_ok callback implementation")
+Reported-by: Xiumei Mu <xmu@redhat.com>
+Signed-off-by: Sabrina Dubroca <sd@queasysnail.net>
+Reviewed-by: Leon Romanovsky <leonro@nvidia.com>
+Reviewed-by: Zhu Yanjun <yanjun.zhu@linux.dev>
+Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ net/xfrm/xfrm_device.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/net/xfrm/xfrm_device.c b/net/xfrm/xfrm_device.c
+index c7a1f080d2de3..44b9de6e4e778 100644
+--- a/net/xfrm/xfrm_device.c
++++ b/net/xfrm/xfrm_device.c
+@@ -438,7 +438,7 @@ bool xfrm_dev_offload_ok(struct sk_buff *skb, struct xfrm_state *x)
+
+ check_tunnel_size = x->xso.type == XFRM_DEV_OFFLOAD_PACKET &&
+ x->props.mode == XFRM_MODE_TUNNEL;
+- switch (x->props.family) {
++ switch (x->inner_mode.family) {
+ case AF_INET:
+ /* Check for IPv4 options */
+ if (ip_hdr(skb)->ihl != 5)
+--
+2.51.0
+
--- /dev/null
+From 86eef6dae59927a077a0fddbae5d4a15586e553b Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 29 Aug 2025 10:54:15 +0200
+Subject: xfrm: xfrm_alloc_spi shouldn't use 0 as SPI
+
+From: Sabrina Dubroca <sd@queasysnail.net>
+
+[ Upstream commit cd8ae32e4e4652db55bce6b9c79267d8946765a9 ]
+
+x->id.spi == 0 means "no SPI assigned", but since commit
+94f39804d891 ("xfrm: Duplicate SPI Handling"), we now create states
+and add them to the byspi list with this value.
+
+__xfrm_state_delete doesn't remove those states from the byspi list,
+since they shouldn't be there, and this shows up as a UAF the next
+time we go through the byspi list.
+
+Reported-by: syzbot+a25ee9d20d31e483ba7b@syzkaller.appspotmail.com
+Closes: https://syzkaller.appspot.com/bug?extid=a25ee9d20d31e483ba7b
+Fixes: 94f39804d891 ("xfrm: Duplicate SPI Handling")
+Signed-off-by: Sabrina Dubroca <sd@queasysnail.net>
+Reviewed-by: Simon Horman <horms@kernel.org>
+Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ net/xfrm/xfrm_state.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+diff --git a/net/xfrm/xfrm_state.c b/net/xfrm/xfrm_state.c
+index 86337453709ba..4b2eb260f5c2e 100644
+--- a/net/xfrm/xfrm_state.c
++++ b/net/xfrm/xfrm_state.c
+@@ -2578,6 +2578,8 @@ int xfrm_alloc_spi(struct xfrm_state *x, u32 low, u32 high,
+
+ for (h = 0; h < range; h++) {
+ u32 spi = (low == high) ? low : get_random_u32_inclusive(low, high);
++ if (spi == 0)
++ goto next;
+ newspi = htonl(spi);
+
+ spin_lock_bh(&net->xfrm.xfrm_state_lock);
+@@ -2593,6 +2595,7 @@ int xfrm_alloc_spi(struct xfrm_state *x, u32 low, u32 high,
+ xfrm_state_put(x0);
+ spin_unlock_bh(&net->xfrm.xfrm_state_lock);
+
++next:
+ if (signal_pending(current)) {
+ err = -ERESTARTSYS;
+ goto unlock;
+--
+2.51.0
+
--- /dev/null
+From 6763b962418f9068aafa88205268063fb93f47ea Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Mon, 25 Aug 2025 11:10:20 -0400
+Subject: Bluetooth: hci_event: Fix UAF in hci_acl_create_conn_sync
+
+From: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
+
+[ Upstream commit 9e622804d57e2d08f0271200606bd1270f75126f ]
+
+This fixes the following UFA in hci_acl_create_conn_sync where a
+connection still pending is command submission (conn->state == BT_OPEN)
+maybe freed, also since this also can happen with the likes of
+hci_le_create_conn_sync fix it as well:
+
+BUG: KASAN: slab-use-after-free in hci_acl_create_conn_sync+0x5ef/0x790 net/bluetooth/hci_sync.c:6861
+Write of size 2 at addr ffff88805ffcc038 by task kworker/u11:2/9541
+
+CPU: 1 UID: 0 PID: 9541 Comm: kworker/u11:2 Not tainted 6.16.0-rc7 #3 PREEMPT(full)
+Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014
+Workqueue: hci3 hci_cmd_sync_work
+Call Trace:
+ <TASK>
+ dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120
+ print_address_description mm/kasan/report.c:378 [inline]
+ print_report+0xca/0x230 mm/kasan/report.c:480
+ kasan_report+0x118/0x150 mm/kasan/report.c:593
+ hci_acl_create_conn_sync+0x5ef/0x790 net/bluetooth/hci_sync.c:6861
+ hci_cmd_sync_work+0x210/0x3a0 net/bluetooth/hci_sync.c:332
+ process_one_work kernel/workqueue.c:3238 [inline]
+ process_scheduled_works+0xae1/0x17b0 kernel/workqueue.c:3321
+ worker_thread+0x8a0/0xda0 kernel/workqueue.c:3402
+ kthread+0x70e/0x8a0 kernel/kthread.c:464
+ ret_from_fork+0x3fc/0x770 arch/x86/kernel/process.c:148
+ ret_from_fork_asm+0x1a/0x30 home/kwqcheii/source/fuzzing/kernel/kasan/linux-6.16-rc7/arch/x86/entry/entry_64.S:245
+ </TASK>
+
+Allocated by task 123736:
+ kasan_save_stack mm/kasan/common.c:47 [inline]
+ kasan_save_track+0x3e/0x80 mm/kasan/common.c:68
+ poison_kmalloc_redzone mm/kasan/common.c:377 [inline]
+ __kasan_kmalloc+0x93/0xb0 mm/kasan/common.c:394
+ kasan_kmalloc include/linux/kasan.h:260 [inline]
+ __kmalloc_cache_noprof+0x230/0x3d0 mm/slub.c:4359
+ kmalloc_noprof include/linux/slab.h:905 [inline]
+ kzalloc_noprof include/linux/slab.h:1039 [inline]
+ __hci_conn_add+0x233/0x1b30 net/bluetooth/hci_conn.c:939
+ hci_conn_add_unset net/bluetooth/hci_conn.c:1051 [inline]
+ hci_connect_acl+0x16c/0x4e0 net/bluetooth/hci_conn.c:1634
+ pair_device+0x418/0xa70 net/bluetooth/mgmt.c:3556
+ hci_mgmt_cmd+0x9c9/0xef0 net/bluetooth/hci_sock.c:1719
+ hci_sock_sendmsg+0x6ca/0xef0 net/bluetooth/hci_sock.c:1839
+ sock_sendmsg_nosec net/socket.c:712 [inline]
+ __sock_sendmsg+0x219/0x270 net/socket.c:727
+ sock_write_iter+0x258/0x330 net/socket.c:1131
+ new_sync_write fs/read_write.c:593 [inline]
+ vfs_write+0x54b/0xa90 fs/read_write.c:686
+ ksys_write+0x145/0x250 fs/read_write.c:738
+ do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
+ do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94
+ entry_SYSCALL_64_after_hwframe+0x77/0x7f
+
+Freed by task 103680:
+ kasan_save_stack mm/kasan/common.c:47 [inline]
+ kasan_save_track+0x3e/0x80 mm/kasan/common.c:68
+ kasan_save_free_info+0x46/0x50 mm/kasan/generic.c:576
+ poison_slab_object mm/kasan/common.c:247 [inline]
+ __kasan_slab_free+0x62/0x70 mm/kasan/common.c:264
+ kasan_slab_free include/linux/kasan.h:233 [inline]
+ slab_free_hook mm/slub.c:2381 [inline]
+ slab_free mm/slub.c:4643 [inline]
+ kfree+0x18e/0x440 mm/slub.c:4842
+ device_release+0x9c/0x1c0
+ kobject_cleanup lib/kobject.c:689 [inline]
+ kobject_release lib/kobject.c:720 [inline]
+ kref_put include/linux/kref.h:65 [inline]
+ kobject_put+0x22b/0x480 lib/kobject.c:737
+ hci_conn_cleanup net/bluetooth/hci_conn.c:175 [inline]
+ hci_conn_del+0x8ff/0xcb0 net/bluetooth/hci_conn.c:1173
+ hci_conn_complete_evt+0x3c7/0x1040 net/bluetooth/hci_event.c:3199
+ hci_event_func net/bluetooth/hci_event.c:7477 [inline]
+ hci_event_packet+0x7e0/0x1200 net/bluetooth/hci_event.c:7531
+ hci_rx_work+0x46a/0xe80 net/bluetooth/hci_core.c:4070
+ process_one_work kernel/workqueue.c:3238 [inline]
+ process_scheduled_works+0xae1/0x17b0 kernel/workqueue.c:3321
+ worker_thread+0x8a0/0xda0 kernel/workqueue.c:3402
+ kthread+0x70e/0x8a0 kernel/kthread.c:464
+ ret_from_fork+0x3fc/0x770 arch/x86/kernel/process.c:148
+ ret_from_fork_asm+0x1a/0x30 home/kwqcheii/source/fuzzing/kernel/kasan/linux-6.16-rc7/arch/x86/entry/entry_64.S:245
+
+Last potentially related work creation:
+ kasan_save_stack+0x3e/0x60 mm/kasan/common.c:47
+ kasan_record_aux_stack+0xbd/0xd0 mm/kasan/generic.c:548
+ insert_work+0x3d/0x330 kernel/workqueue.c:2183
+ __queue_work+0xbd9/0xfe0 kernel/workqueue.c:2345
+ queue_delayed_work_on+0x18b/0x280 kernel/workqueue.c:2561
+ pairing_complete+0x1e7/0x2b0 net/bluetooth/mgmt.c:3451
+ pairing_complete_cb+0x1ac/0x230 net/bluetooth/mgmt.c:3487
+ hci_connect_cfm include/net/bluetooth/hci_core.h:2064 [inline]
+ hci_conn_failed+0x24d/0x310 net/bluetooth/hci_conn.c:1275
+ hci_conn_complete_evt+0x3c7/0x1040 net/bluetooth/hci_event.c:3199
+ hci_event_func net/bluetooth/hci_event.c:7477 [inline]
+ hci_event_packet+0x7e0/0x1200 net/bluetooth/hci_event.c:7531
+ hci_rx_work+0x46a/0xe80 net/bluetooth/hci_core.c:4070
+ process_one_work kernel/workqueue.c:3238 [inline]
+ process_scheduled_works+0xae1/0x17b0 kernel/workqueue.c:3321
+ worker_thread+0x8a0/0xda0 kernel/workqueue.c:3402
+ kthread+0x70e/0x8a0 kernel/kthread.c:464
+ ret_from_fork+0x3fc/0x770 arch/x86/kernel/process.c:148
+ ret_from_fork_asm+0x1a/0x30 home/kwqcheii/source/fuzzing/kernel/kasan/linux-6.16-rc7/arch/x86/entry/entry_64.S:245
+
+Fixes: aef2aa4fa98e ("Bluetooth: hci_event: Fix creating hci_conn object on error status")
+Reported-by: Junvyyang, Tencent Zhuque Lab <zhuque@tencent.com>
+Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ include/net/bluetooth/hci_core.h | 21 +++++++++++++++++++++
+ net/bluetooth/hci_event.c | 26 +++++++++++++++++++++++---
+ 2 files changed, 44 insertions(+), 3 deletions(-)
+
+diff --git a/include/net/bluetooth/hci_core.h b/include/net/bluetooth/hci_core.h
+index 4f067599e6e9e..62135b7782f5b 100644
+--- a/include/net/bluetooth/hci_core.h
++++ b/include/net/bluetooth/hci_core.h
+@@ -1169,6 +1169,27 @@ static inline struct hci_conn *hci_conn_hash_lookup_ba(struct hci_dev *hdev,
+ return NULL;
+ }
+
++static inline struct hci_conn *hci_conn_hash_lookup_role(struct hci_dev *hdev,
++ __u8 type, __u8 role,
++ bdaddr_t *ba)
++{
++ struct hci_conn_hash *h = &hdev->conn_hash;
++ struct hci_conn *c;
++
++ rcu_read_lock();
++
++ list_for_each_entry_rcu(c, &h->list, list) {
++ if (c->type == type && c->role == role && !bacmp(&c->dst, ba)) {
++ rcu_read_unlock();
++ return c;
++ }
++ }
++
++ rcu_read_unlock();
++
++ return NULL;
++}
++
+ static inline struct hci_conn *hci_conn_hash_lookup_le(struct hci_dev *hdev,
+ bdaddr_t *ba,
+ __u8 ba_type)
+diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c
+index 5eed23b8d6c33..7bda00dcb0b2f 100644
+--- a/net/bluetooth/hci_event.c
++++ b/net/bluetooth/hci_event.c
+@@ -3048,8 +3048,18 @@ static void hci_conn_complete_evt(struct hci_dev *hdev, void *data,
+
+ hci_dev_lock(hdev);
+
++ /* Check for existing connection:
++ *
++ * 1. If it doesn't exist then it must be receiver/slave role.
++ * 2. If it does exist confirm that it is connecting/BT_CONNECT in case
++ * of initiator/master role since there could be a collision where
++ * either side is attempting to connect or something like a fuzzing
++ * testing is trying to play tricks to destroy the hcon object before
++ * it even attempts to connect (e.g. hcon->state == BT_OPEN).
++ */
+ conn = hci_conn_hash_lookup_ba(hdev, ev->link_type, &ev->bdaddr);
+- if (!conn) {
++ if (!conn ||
++ (conn->role == HCI_ROLE_MASTER && conn->state != BT_CONNECT)) {
+ /* In case of error status and there is no connection pending
+ * just unlock as there is nothing to cleanup.
+ */
+@@ -5615,8 +5625,18 @@ static void le_conn_complete_evt(struct hci_dev *hdev, u8 status,
+ */
+ hci_dev_clear_flag(hdev, HCI_LE_ADV);
+
+- conn = hci_conn_hash_lookup_ba(hdev, LE_LINK, bdaddr);
+- if (!conn) {
++ /* Check for existing connection:
++ *
++ * 1. If it doesn't exist then use the role to create a new object.
++ * 2. If it does exist confirm that it is connecting/BT_CONNECT in case
++ * of initiator/master role since there could be a collision where
++ * either side is attempting to connect or something like a fuzzing
++ * testing is trying to play tricks to destroy the hcon object before
++ * it even attempts to connect (e.g. hcon->state == BT_OPEN).
++ */
++ conn = hci_conn_hash_lookup_role(hdev, LE_LINK, role, bdaddr);
++ if (!conn ||
++ (conn->role == HCI_ROLE_MASTER && conn->state != BT_CONNECT)) {
+ /* In case of error status and there is no connection pending
+ * just unlock as there is nothing to cleanup.
+ */
+--
+2.51.0
+
--- /dev/null
+From 3d372877572520d9c420c4536304ab8e65679cf2 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 5 Sep 2025 10:29:18 -0400
+Subject: Bluetooth: hci_sync: Fix hci_resume_advertising_sync
+
+From: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
+
+[ Upstream commit 1488af7b8b5f9896ea88ee35aa3301713f72737c ]
+
+hci_resume_advertising_sync is suppose to resume all instance paused by
+hci_pause_advertising_sync, this logic is used for procedures are only
+allowed when not advertising, but instance 0x00 was not being
+re-enabled.
+
+Fixes: ad383c2c65a5 ("Bluetooth: hci_sync: Enable advertising when LL privacy is enabled")
+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 | 7 +++++++
+ 1 file changed, 7 insertions(+)
+
+diff --git a/net/bluetooth/hci_sync.c b/net/bluetooth/hci_sync.c
+index 7f3f700faebc2..dc9209f9f1a6a 100644
+--- a/net/bluetooth/hci_sync.c
++++ b/net/bluetooth/hci_sync.c
+@@ -2639,6 +2639,13 @@ static int hci_resume_advertising_sync(struct hci_dev *hdev)
+ hci_remove_ext_adv_instance_sync(hdev, adv->instance,
+ NULL);
+ }
++
++ /* If current advertising instance is set to instance 0x00
++ * then we need to re-enable it.
++ */
++ if (!hdev->cur_adv_instance)
++ err = hci_enable_ext_advertising_sync(hdev,
++ hdev->cur_adv_instance);
+ } else {
+ /* Schedule for most recent instance to be restarted and begin
+ * the software rotation loop
+--
+2.51.0
+
--- /dev/null
+From c5d6600b032bedb41764a3c9043345a0e7d8741f Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Sat, 20 Sep 2025 05:11:17 -0700
+Subject: bnxt_en: correct offset handling for IPv6 destination address
+
+From: Alok Tiwari <alok.a.tiwari@oracle.com>
+
+[ Upstream commit 3d3aa9472c6dd0704e9961ed4769caac5b1c8d52 ]
+
+In bnxt_tc_parse_pedit(), the code incorrectly writes IPv6
+destination values to the source address field (saddr) when
+processing pedit offsets within the destination address range.
+
+This patch corrects the assignment to use daddr instead of saddr,
+ensuring that pedit operations on IPv6 destination addresses are
+applied correctly.
+
+Fixes: 9b9eb518e338 ("bnxt_en: Add support for NAT(L3/L4 rewrite)")
+Signed-off-by: Alok Tiwari <alok.a.tiwari@oracle.com>
+Reviewed-by: Somnath Kotur <somnath.kotur@broadcom.com>
+Link: https://patch.msgid.link/20250920121157.351921-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/broadcom/bnxt/bnxt_tc.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt_tc.c b/drivers/net/ethernet/broadcom/bnxt/bnxt_tc.c
+index 273c9ba48f09a..b896f8d20ff33 100644
+--- a/drivers/net/ethernet/broadcom/bnxt/bnxt_tc.c
++++ b/drivers/net/ethernet/broadcom/bnxt/bnxt_tc.c
+@@ -244,7 +244,7 @@ bnxt_tc_parse_pedit(struct bnxt *bp, struct bnxt_tc_actions *actions,
+ offset < offset_of_ip6_daddr + 16) {
+ actions->nat.src_xlate = false;
+ idx = (offset - offset_of_ip6_daddr) / 4;
+- actions->nat.l3.ipv6.saddr.s6_addr32[idx] = htonl(val);
++ actions->nat.l3.ipv6.daddr.s6_addr32[idx] = htonl(val);
+ } else {
+ netdev_err(bp->dev,
+ "%s: IPv6_hdr: Invalid pedit field\n",
+--
+2.51.0
+
--- /dev/null
+From 2cc4d4163c0c166f10552081a448f623afc797d6 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 18 Sep 2025 18:00:24 +0900
+Subject: can: etas_es58x: populate ndo_change_mtu() to prevent buffer overflow
+
+From: Vincent Mailhol <mailhol@kernel.org>
+
+[ Upstream commit 38c0abad45b190a30d8284a37264d2127a6ec303 ]
+
+Sending an PF_PACKET allows to bypass the CAN framework logic and to
+directly reach the xmit() function of a CAN driver. The only check
+which is performed by the PF_PACKET framework is to make sure that
+skb->len fits the interface's MTU.
+
+Unfortunately, because the etas_es58x driver does not populate its
+net_device_ops->ndo_change_mtu(), it is possible for an attacker to
+configure an invalid MTU by doing, for example:
+
+ $ ip link set can0 mtu 9999
+
+After doing so, the attacker could open a PF_PACKET socket using the
+ETH_P_CANXL protocol:
+
+ socket(PF_PACKET, SOCK_RAW, htons(ETH_P_CANXL));
+
+to inject a malicious CAN XL frames. For example:
+
+ struct canxl_frame frame = {
+ .flags = 0xff,
+ .len = 2048,
+ };
+
+The CAN drivers' xmit() function are calling can_dev_dropped_skb() to
+check that the skb is valid, unfortunately under above conditions, the
+malicious packet is able to go through can_dev_dropped_skb() checks:
+
+ 1. the skb->protocol is set to ETH_P_CANXL which is valid (the
+ function does not check the actual device capabilities).
+
+ 2. the length is a valid CAN XL length.
+
+And so, es58x_start_xmit() receives a CAN XL frame which it is not
+able to correctly handle and will thus misinterpret it as a CAN(FD)
+frame.
+
+This can result in a buffer overflow. For example, using the es581.4
+variant, the frame will be dispatched to es581_4_tx_can_msg(), go
+through the last check at the beginning of this function:
+
+ if (can_is_canfd_skb(skb))
+ return -EMSGSIZE;
+
+and reach this line:
+
+ memcpy(tx_can_msg->data, cf->data, cf->len);
+
+Here, cf->len corresponds to the flags field of the CAN XL frame. In
+our previous example, we set canxl_frame->flags to 0xff. Because the
+maximum expected length is 8, a buffer overflow of 247 bytes occurs!
+
+Populate net_device_ops->ndo_change_mtu() to ensure that the
+interface's MTU can not be set to anything bigger than CAN_MTU or
+CANFD_MTU (depending on the device capabilities). By fixing the root
+cause, this prevents the buffer overflow.
+
+Fixes: 8537257874e9 ("can: etas_es58x: add core support for ETAS ES58X CAN USB interfaces")
+Signed-off-by: Vincent Mailhol <mailhol@kernel.org>
+Link: https://patch.msgid.link/20250918-can-fix-mtu-v1-1-0d1cada9393b@kernel.org
+Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/can/usb/etas_es58x/es58x_core.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+diff --git a/drivers/net/can/usb/etas_es58x/es58x_core.c b/drivers/net/can/usb/etas_es58x/es58x_core.c
+index 5e3a72b7c4691..bb49a2c0a9a5c 100644
+--- a/drivers/net/can/usb/etas_es58x/es58x_core.c
++++ b/drivers/net/can/usb/etas_es58x/es58x_core.c
+@@ -7,7 +7,7 @@
+ *
+ * Copyright (c) 2019 Robert Bosch Engineering and Business Solutions. All rights reserved.
+ * Copyright (c) 2020 ETAS K.K.. All rights reserved.
+- * Copyright (c) 2020-2022 Vincent Mailhol <mailhol.vincent@wanadoo.fr>
++ * Copyright (c) 2020-2025 Vincent Mailhol <mailhol@kernel.org>
+ */
+
+ #include <asm/unaligned.h>
+@@ -1977,6 +1977,7 @@ static const struct net_device_ops es58x_netdev_ops = {
+ .ndo_stop = es58x_stop,
+ .ndo_start_xmit = es58x_start_xmit,
+ .ndo_eth_ioctl = can_eth_ioctl_hwts,
++ .ndo_change_mtu = can_change_mtu,
+ };
+
+ static const struct ethtool_ops es58x_ethtool_ops = {
+--
+2.51.0
+
--- /dev/null
+From 2b9361019166335ceee9a8d0d2b5d14fd08abb84 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 18 Sep 2025 18:00:25 +0900
+Subject: can: hi311x: populate ndo_change_mtu() to prevent buffer overflow
+
+From: Vincent Mailhol <mailhol@kernel.org>
+
+[ Upstream commit ac1c7656fa717f29fac3ea073af63f0b9919ec9a ]
+
+Sending an PF_PACKET allows to bypass the CAN framework logic and to
+directly reach the xmit() function of a CAN driver. The only check
+which is performed by the PF_PACKET framework is to make sure that
+skb->len fits the interface's MTU.
+
+Unfortunately, because the sun4i_can driver does not populate its
+net_device_ops->ndo_change_mtu(), it is possible for an attacker to
+configure an invalid MTU by doing, for example:
+
+ $ ip link set can0 mtu 9999
+
+After doing so, the attacker could open a PF_PACKET socket using the
+ETH_P_CANXL protocol:
+
+ socket(PF_PACKET, SOCK_RAW, htons(ETH_P_CANXL))
+
+to inject a malicious CAN XL frames. For example:
+
+ struct canxl_frame frame = {
+ .flags = 0xff,
+ .len = 2048,
+ };
+
+The CAN drivers' xmit() function are calling can_dev_dropped_skb() to
+check that the skb is valid, unfortunately under above conditions, the
+malicious packet is able to go through can_dev_dropped_skb() checks:
+
+ 1. the skb->protocol is set to ETH_P_CANXL which is valid (the
+ function does not check the actual device capabilities).
+
+ 2. the length is a valid CAN XL length.
+
+And so, hi3110_hard_start_xmit() receives a CAN XL frame which it is
+not able to correctly handle and will thus misinterpret it as a CAN
+frame. The driver will consume frame->len as-is with no further
+checks.
+
+This can result in a buffer overflow later on in hi3110_hw_tx() on
+this line:
+
+ memcpy(buf + HI3110_FIFO_EXT_DATA_OFF,
+ frame->data, frame->len);
+
+Here, frame->len corresponds to the flags field of the CAN XL frame.
+In our previous example, we set canxl_frame->flags to 0xff. Because
+the maximum expected length is 8, a buffer overflow of 247 bytes
+occurs!
+
+Populate net_device_ops->ndo_change_mtu() to ensure that the
+interface's MTU can not be set to anything bigger than CAN_MTU. By
+fixing the root cause, this prevents the buffer overflow.
+
+Fixes: 57e83fb9b746 ("can: hi311x: Add Holt HI-311x CAN driver")
+Signed-off-by: Vincent Mailhol <mailhol@kernel.org>
+Link: https://patch.msgid.link/20250918-can-fix-mtu-v1-2-0d1cada9393b@kernel.org
+Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/can/spi/hi311x.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/drivers/net/can/spi/hi311x.c b/drivers/net/can/spi/hi311x.c
+index b757555ed4c4f..57ea7dfe8a596 100644
+--- a/drivers/net/can/spi/hi311x.c
++++ b/drivers/net/can/spi/hi311x.c
+@@ -813,6 +813,7 @@ static const struct net_device_ops hi3110_netdev_ops = {
+ .ndo_open = hi3110_open,
+ .ndo_stop = hi3110_stop,
+ .ndo_start_xmit = hi3110_hard_start_xmit,
++ .ndo_change_mtu = can_change_mtu,
+ };
+
+ static const struct ethtool_ops hi3110_ethtool_ops = {
+--
+2.51.0
+
--- /dev/null
+From e02ce26e497b5359bf7cb41f224f3afdb3a6a366 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 18 Sep 2025 18:00:27 +0900
+Subject: can: mcba_usb: populate ndo_change_mtu() to prevent buffer overflow
+
+From: Vincent Mailhol <mailhol@kernel.org>
+
+[ Upstream commit 17c8d794527f01def0d1c8b7dc2d7b8d34fed0e6 ]
+
+Sending an PF_PACKET allows to bypass the CAN framework logic and to
+directly reach the xmit() function of a CAN driver. The only check
+which is performed by the PF_PACKET framework is to make sure that
+skb->len fits the interface's MTU.
+
+Unfortunately, because the mcba_usb driver does not populate its
+net_device_ops->ndo_change_mtu(), it is possible for an attacker to
+configure an invalid MTU by doing, for example:
+
+ $ ip link set can0 mtu 9999
+
+After doing so, the attacker could open a PF_PACKET socket using the
+ETH_P_CANXL protocol:
+
+ socket(PF_PACKET, SOCK_RAW, htons(ETH_P_CANXL))
+
+to inject a malicious CAN XL frames. For example:
+
+ struct canxl_frame frame = {
+ .flags = 0xff,
+ .len = 2048,
+ };
+
+The CAN drivers' xmit() function are calling can_dev_dropped_skb() to
+check that the skb is valid, unfortunately under above conditions, the
+malicious packet is able to go through can_dev_dropped_skb() checks:
+
+ 1. the skb->protocol is set to ETH_P_CANXL which is valid (the
+ function does not check the actual device capabilities).
+
+ 2. the length is a valid CAN XL length.
+
+And so, mcba_usb_start_xmit() receives a CAN XL frame which it is not
+able to correctly handle and will thus misinterpret it as a CAN frame.
+
+This can result in a buffer overflow. The driver will consume cf->len
+as-is with no further checks on these lines:
+
+ usb_msg.dlc = cf->len;
+
+ memcpy(usb_msg.data, cf->data, usb_msg.dlc);
+
+Here, cf->len corresponds to the flags field of the CAN XL frame. In
+our previous example, we set canxl_frame->flags to 0xff. Because the
+maximum expected length is 8, a buffer overflow of 247 bytes occurs!
+
+Populate net_device_ops->ndo_change_mtu() to ensure that the
+interface's MTU can not be set to anything bigger than CAN_MTU. By
+fixing the root cause, this prevents the buffer overflow.
+
+Fixes: 51f3baad7de9 ("can: mcba_usb: Add support for Microchip CAN BUS Analyzer")
+Signed-off-by: Vincent Mailhol <mailhol@kernel.org>
+Link: https://patch.msgid.link/20250918-can-fix-mtu-v1-4-0d1cada9393b@kernel.org
+Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/can/usb/mcba_usb.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/drivers/net/can/usb/mcba_usb.c b/drivers/net/can/usb/mcba_usb.c
+index 47619e9cb0055..ecc489afb8416 100644
+--- a/drivers/net/can/usb/mcba_usb.c
++++ b/drivers/net/can/usb/mcba_usb.c
+@@ -761,6 +761,7 @@ static const struct net_device_ops mcba_netdev_ops = {
+ .ndo_open = mcba_usb_open,
+ .ndo_stop = mcba_usb_close,
+ .ndo_start_xmit = mcba_usb_start_xmit,
++ .ndo_change_mtu = can_change_mtu,
+ };
+
+ static const struct ethtool_ops mcba_ethtool_ops = {
+--
+2.51.0
+
--- /dev/null
+From 120468436b822eeca1211d3e639ee2a7f0b16416 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 18 Sep 2025 15:23:57 +0200
+Subject: can: peak_usb: fix shift-out-of-bounds issue
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Stéphane Grosjean <stephane.grosjean@hms-networks.com>
+
+[ Upstream commit c443be70aaee42c2d1d251e0329e0a69dd96ae54 ]
+
+Explicitly uses a 64-bit constant when the number of bits used for its
+shifting is 32 (which is the case for PC CAN FD interfaces supported by
+this driver).
+
+Signed-off-by: Stéphane Grosjean <stephane.grosjean@hms-networks.com>
+Link: https://patch.msgid.link/20250918132413.30071-1-stephane.grosjean@free.fr
+Reported-by: Marc Kleine-Budde <mkl@pengutronix.de>
+Closes: https://lore.kernel.org/20250917-aboriginal-refined-honeybee-82b1aa-mkl@pengutronix.de
+Fixes: bb4785551f64 ("can: usb: PEAK-System Technik USB adapters driver core")
+[mkl: update subject, apply manually]
+Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/can/usb/peak_usb/pcan_usb_core.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/drivers/net/can/usb/peak_usb/pcan_usb_core.c b/drivers/net/can/usb/peak_usb/pcan_usb_core.c
+index 24ad9f593a773..9d162d1004c26 100644
+--- a/drivers/net/can/usb/peak_usb/pcan_usb_core.c
++++ b/drivers/net/can/usb/peak_usb/pcan_usb_core.c
+@@ -111,7 +111,7 @@ void peak_usb_update_ts_now(struct peak_time_ref *time_ref, u32 ts_now)
+ u32 delta_ts = time_ref->ts_dev_2 - time_ref->ts_dev_1;
+
+ if (time_ref->ts_dev_2 < time_ref->ts_dev_1)
+- delta_ts &= (1 << time_ref->adapter->ts_used_bits) - 1;
++ delta_ts &= (1ULL << time_ref->adapter->ts_used_bits) - 1;
+
+ time_ref->ts_total += delta_ts;
+ }
+--
+2.51.0
+
--- /dev/null
+From b893f1c6d46c60dd463e7f7690f65984d26995fe Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 18 Sep 2025 18:00:26 +0900
+Subject: can: sun4i_can: populate ndo_change_mtu() to prevent buffer overflow
+
+From: Vincent Mailhol <mailhol@kernel.org>
+
+[ Upstream commit 61da0bd4102c459823fbe6b8b43b01fb6ace4a22 ]
+
+Sending an PF_PACKET allows to bypass the CAN framework logic and to
+directly reach the xmit() function of a CAN driver. The only check
+which is performed by the PF_PACKET framework is to make sure that
+skb->len fits the interface's MTU.
+
+Unfortunately, because the sun4i_can driver does not populate its
+net_device_ops->ndo_change_mtu(), it is possible for an attacker to
+configure an invalid MTU by doing, for example:
+
+ $ ip link set can0 mtu 9999
+
+After doing so, the attacker could open a PF_PACKET socket using the
+ETH_P_CANXL protocol:
+
+ socket(PF_PACKET, SOCK_RAW, htons(ETH_P_CANXL))
+
+to inject a malicious CAN XL frames. For example:
+
+ struct canxl_frame frame = {
+ .flags = 0xff,
+ .len = 2048,
+ };
+
+The CAN drivers' xmit() function are calling can_dev_dropped_skb() to
+check that the skb is valid, unfortunately under above conditions, the
+malicious packet is able to go through can_dev_dropped_skb() checks:
+
+ 1. the skb->protocol is set to ETH_P_CANXL which is valid (the
+ function does not check the actual device capabilities).
+
+ 2. the length is a valid CAN XL length.
+
+And so, sun4ican_start_xmit() receives a CAN XL frame which it is not
+able to correctly handle and will thus misinterpret it as a CAN frame.
+
+This can result in a buffer overflow. The driver will consume cf->len
+as-is with no further checks on this line:
+
+ dlc = cf->len;
+
+Here, cf->len corresponds to the flags field of the CAN XL frame. In
+our previous example, we set canxl_frame->flags to 0xff. Because the
+maximum expected length is 8, a buffer overflow of 247 bytes occurs a
+couple line below when doing:
+
+ for (i = 0; i < dlc; i++)
+ writel(cf->data[i], priv->base + (dreg + i * 4));
+
+Populate net_device_ops->ndo_change_mtu() to ensure that the
+interface's MTU can not be set to anything bigger than CAN_MTU. By
+fixing the root cause, this prevents the buffer overflow.
+
+Fixes: 0738eff14d81 ("can: Allwinner A10/A20 CAN Controller support - Kernel module")
+Signed-off-by: Vincent Mailhol <mailhol@kernel.org>
+Link: https://patch.msgid.link/20250918-can-fix-mtu-v1-3-0d1cada9393b@kernel.org
+Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/can/sun4i_can.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/drivers/net/can/sun4i_can.c b/drivers/net/can/sun4i_can.c
+index 283fbf59e66d5..5ab1f9c7288e5 100644
+--- a/drivers/net/can/sun4i_can.c
++++ b/drivers/net/can/sun4i_can.c
+@@ -768,6 +768,7 @@ static const struct net_device_ops sun4ican_netdev_ops = {
+ .ndo_open = sun4ican_open,
+ .ndo_stop = sun4ican_close,
+ .ndo_start_xmit = sun4ican_start_xmit,
++ .ndo_change_mtu = can_change_mtu,
+ };
+
+ static const struct ethtool_ops sun4ican_ethtool_ops = {
+--
+2.51.0
+
--- /dev/null
+From 7bd320b0a1307272adf423702b41c94d2f55d51b Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 18 Sep 2025 17:21:07 +0200
+Subject: ethernet: rvu-af: Remove slash from the driver name
+
+From: Petr Malat <oss@malat.biz>
+
+[ Upstream commit b65678cacc030efd53c38c089fb9b741a2ee34c8 ]
+
+Having a slash in the driver name leads to EIO being returned while
+reading /sys/module/rvu_af/drivers content.
+
+Remove DRV_STRING as it's not used anywhere.
+
+Fixes: 91c6945ea1f9 ("octeontx2-af: cn10k: Add RPM MAC support")
+Signed-off-by: Petr Malat <oss@malat.biz>
+Reviewed-by: Simon Horman <horms@kernel.org>
+Link: https://patch.msgid.link/20250918152106.1798299-1-oss@malat.biz
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/ethernet/marvell/octeontx2/af/cgx.c | 3 +--
+ 1 file changed, 1 insertion(+), 2 deletions(-)
+
+diff --git a/drivers/net/ethernet/marvell/octeontx2/af/cgx.c b/drivers/net/ethernet/marvell/octeontx2/af/cgx.c
+index 6302990e9a5ff..729d1833a829a 100644
+--- a/drivers/net/ethernet/marvell/octeontx2/af/cgx.c
++++ b/drivers/net/ethernet/marvell/octeontx2/af/cgx.c
+@@ -21,8 +21,7 @@
+ #include "rvu.h"
+ #include "lmac_common.h"
+
+-#define DRV_NAME "Marvell-CGX/RPM"
+-#define DRV_STRING "Marvell CGX/RPM Driver"
++#define DRV_NAME "Marvell-CGX-RPM"
+
+ #define CGX_RX_STAT_GLOBAL_INDEX 9
+
+--
+2.51.0
+
--- /dev/null
+From 47729e275d5f3470588c9345b1c2920039ca5c38 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Mon, 22 Sep 2025 15:19:57 -0400
+Subject: net: allow alloc_skb_with_frags() to use MAX_SKB_FRAGS
+
+From: Jason Baron <jbaron@akamai.com>
+
+[ Upstream commit ca9f9cdc4de97d0221100b11224738416696163c ]
+
+Currently, alloc_skb_with_frags() will only fill (MAX_SKB_FRAGS - 1)
+slots. I think it should use all MAX_SKB_FRAGS slots, as callers of
+alloc_skb_with_frags() will size their allocation of frags based
+on MAX_SKB_FRAGS.
+
+This issue was discovered via a test patch that sets 'order' to 0
+in alloc_skb_with_frags(), which effectively tests/simulates high
+fragmentation. In this case sendmsg() on unix sockets will fail every
+time for large allocations. If the PAGE_SIZE is 4K, then data_len will
+request 68K or 17 pages, but alloc_skb_with_frags() can only allocate
+64K in this case or 16 pages.
+
+Fixes: 09c2c90705bb ("net: allow alloc_skb_with_frags() to allocate bigger packets")
+Signed-off-by: Jason Baron <jbaron@akamai.com>
+Reviewed-by: Eric Dumazet <edumazet@google.com>
+Link: https://patch.msgid.link/20250922191957.2855612-1-jbaron@akamai.com
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ net/core/skbuff.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/net/core/skbuff.c b/net/core/skbuff.c
+index 21a83e26f004b..867832f8bbaea 100644
+--- a/net/core/skbuff.c
++++ b/net/core/skbuff.c
+@@ -6330,7 +6330,7 @@ struct sk_buff *alloc_skb_with_frags(unsigned long header_len,
+ return NULL;
+
+ while (data_len) {
+- if (nr_frags == MAX_SKB_FRAGS - 1)
++ if (nr_frags == MAX_SKB_FRAGS)
+ goto failure;
+ while (order && PAGE_ALIGN(data_len) < (PAGE_SIZE << order))
+ order--;
+--
+2.51.0
+
--- /dev/null
+From 8df00aceb3ee397e658ab05902b32ba55bbbbc9a Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 11 Jun 2024 15:54:28 +0200
+Subject: net: dsa: lantiq_gswip: do also enable or disable cpu port
+
+From: Martin Schiller <ms@dev.tdt.de>
+
+[ Upstream commit 86b9ea6412af41914ef6549f85a849c3b987f4f3 ]
+
+Before commit 74be4babe72f ("net: dsa: do not enable or disable non user
+ports"), gswip_port_enable/disable() were also executed for the cpu port
+in gswip_setup() which disabled the cpu port during initialization.
+
+Let's restore this by removing the dsa_is_user_port checks. Also, let's
+clean up the gswip_port_enable() function so that we only have to check
+for the cpu port once. The operation reordering done here is safe.
+
+Signed-off-by: Martin Schiller <ms@dev.tdt.de>
+Acked-by: Hauke Mehrtens <hauke@hauke-m.de>
+Reviewed-by: Vladimir Oltean <olteanv@gmail.com>
+Link: https://lore.kernel.org/r/20240611135434.3180973-7-ms@dev.tdt.de
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Stable-dep-of: c0054b25e2f1 ("net: dsa: lantiq_gswip: move gswip_add_single_port_br() call to port_setup()")
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/dsa/lantiq_gswip.c | 24 ++++++++----------------
+ 1 file changed, 8 insertions(+), 16 deletions(-)
+
+diff --git a/drivers/net/dsa/lantiq_gswip.c b/drivers/net/dsa/lantiq_gswip.c
+index 3c76a1a14aee3..a2b10b28c11fa 100644
+--- a/drivers/net/dsa/lantiq_gswip.c
++++ b/drivers/net/dsa/lantiq_gswip.c
+@@ -688,13 +688,18 @@ static int gswip_port_enable(struct dsa_switch *ds, int port,
+ struct gswip_priv *priv = ds->priv;
+ int err;
+
+- if (!dsa_is_user_port(ds, port))
+- return 0;
+-
+ if (!dsa_is_cpu_port(ds, port)) {
++ u32 mdio_phy = 0;
++
+ err = gswip_add_single_port_br(priv, port, true);
+ if (err)
+ return err;
++
++ if (phydev)
++ mdio_phy = phydev->mdio.addr & GSWIP_MDIO_PHY_ADDR_MASK;
++
++ gswip_mdio_mask(priv, GSWIP_MDIO_PHY_ADDR_MASK, mdio_phy,
++ GSWIP_MDIO_PHYp(port));
+ }
+
+ /* RMON Counter Enable for port */
+@@ -707,16 +712,6 @@ static int gswip_port_enable(struct dsa_switch *ds, int port,
+ gswip_switch_mask(priv, 0, GSWIP_SDMA_PCTRL_EN,
+ GSWIP_SDMA_PCTRLp(port));
+
+- if (!dsa_is_cpu_port(ds, port)) {
+- u32 mdio_phy = 0;
+-
+- if (phydev)
+- mdio_phy = phydev->mdio.addr & GSWIP_MDIO_PHY_ADDR_MASK;
+-
+- gswip_mdio_mask(priv, GSWIP_MDIO_PHY_ADDR_MASK, mdio_phy,
+- GSWIP_MDIO_PHYp(port));
+- }
+-
+ return 0;
+ }
+
+@@ -724,9 +719,6 @@ static void gswip_port_disable(struct dsa_switch *ds, int port)
+ {
+ struct gswip_priv *priv = ds->priv;
+
+- if (!dsa_is_user_port(ds, port))
+- return;
+-
+ gswip_switch_mask(priv, GSWIP_FDMA_PCTRL_EN, 0,
+ GSWIP_FDMA_PCTRLp(port));
+ gswip_switch_mask(priv, GSWIP_SDMA_PCTRL_EN, 0,
+--
+2.51.0
+
--- /dev/null
+From 1ce2accf518c84f5c8c781dbbc4ef872f3f0a48e Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 18 Sep 2025 10:21:41 +0300
+Subject: net: dsa: lantiq_gswip: move gswip_add_single_port_br() call to
+ port_setup()
+
+From: Vladimir Oltean <vladimir.oltean@nxp.com>
+
+[ Upstream commit c0054b25e2f1045f47b4954cf13a539e5e6047df ]
+
+A port added to a "single port bridge" operates as standalone, and this
+is mutually exclusive to being part of a Linux bridge. In fact,
+gswip_port_bridge_join() calls gswip_add_single_port_br() with
+add=false, i.e. removes the port from the "single port bridge" to enable
+autonomous forwarding.
+
+The blamed commit seems to have incorrectly thought that ds->ops->port_enable()
+is called one time per port, during the setup phase of the switch.
+
+However, it is actually called during the ndo_open() implementation of
+DSA user ports, which is to say that this sequence of events:
+
+1. ip link set swp0 down
+2. ip link add br0 type bridge
+3. ip link set swp0 master br0
+4. ip link set swp0 up
+
+would cause swp0 to join back the "single port bridge" which step 3 had
+just removed it from.
+
+The correct DSA hook for one-time actions per port at switch init time
+is ds->ops->port_setup(). This is what seems to match the coder's
+intention; also see the comment at the beginning of the file:
+
+ * At the initialization the driver allocates one bridge table entry for
+ ~~~~~~~~~~~~~~~~~~~~~
+ * each switch port which is used when the port is used without an
+ * explicit bridge.
+
+Fixes: 8206e0ce96b3 ("net: dsa: lantiq: Add VLAN unaware bridge offloading")
+Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
+Link: https://patch.msgid.link/20250918072142.894692-2-vladimir.oltean@nxp.com
+Tested-by: Daniel Golle <daniel@makrotopia.org>
+Reviewed-by: Daniel Golle <daniel@makrotopia.org>
+Signed-off-by: Paolo Abeni <pabeni@redhat.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/dsa/lantiq_gswip.c | 18 ++++++++++++++----
+ 1 file changed, 14 insertions(+), 4 deletions(-)
+
+diff --git a/drivers/net/dsa/lantiq_gswip.c b/drivers/net/dsa/lantiq_gswip.c
+index a2b10b28c11fa..054548294f039 100644
+--- a/drivers/net/dsa/lantiq_gswip.c
++++ b/drivers/net/dsa/lantiq_gswip.c
+@@ -682,18 +682,27 @@ static int gswip_add_single_port_br(struct gswip_priv *priv, int port, bool add)
+ return 0;
+ }
+
+-static int gswip_port_enable(struct dsa_switch *ds, int port,
+- struct phy_device *phydev)
++static int gswip_port_setup(struct dsa_switch *ds, int port)
+ {
+ struct gswip_priv *priv = ds->priv;
+ int err;
+
+ if (!dsa_is_cpu_port(ds, port)) {
+- u32 mdio_phy = 0;
+-
+ err = gswip_add_single_port_br(priv, port, true);
+ if (err)
+ return err;
++ }
++
++ return 0;
++}
++
++static int gswip_port_enable(struct dsa_switch *ds, int port,
++ struct phy_device *phydev)
++{
++ struct gswip_priv *priv = ds->priv;
++
++ if (!dsa_is_cpu_port(ds, port)) {
++ u32 mdio_phy = 0;
+
+ if (phydev)
+ mdio_phy = phydev->mdio.addr & GSWIP_MDIO_PHY_ADDR_MASK;
+@@ -1813,6 +1822,7 @@ static int gswip_get_sset_count(struct dsa_switch *ds, int port, int sset)
+ static const struct dsa_switch_ops gswip_xrx200_switch_ops = {
+ .get_tag_protocol = gswip_get_tag_protocol,
+ .setup = gswip_setup,
++ .port_setup = gswip_port_setup,
+ .port_enable = gswip_port_enable,
+ .port_disable = gswip_port_disable,
+ .port_bridge_join = gswip_port_bridge_join,
+--
+2.51.0
+
--- /dev/null
+From 039cbaa910a396ad366de633398c083f88b41ca8 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 18 Sep 2025 10:21:42 +0300
+Subject: net: dsa: lantiq_gswip: suppress -EINVAL errors for bridge FDB
+ entries added to the CPU port
+
+From: Vladimir Oltean <vladimir.oltean@nxp.com>
+
+[ Upstream commit 987afe147965ef7a8e7d144ffef0d70af14bb1d4 ]
+
+The blamed commit and others in that patch set started the trend
+of reusing existing DSA driver API for a new purpose: calling
+ds->ops->port_fdb_add() on the CPU port.
+
+The lantiq_gswip driver was not prepared to handle that, as can be seen
+from the many errors that Daniel presents in the logs:
+
+[ 174.050000] gswip 1e108000.switch: port 2 failed to add fa:aa:72:f4:8b:1e vid 1 to fdb: -22
+[ 174.060000] gswip 1e108000.switch lan2: entered promiscuous mode
+[ 174.070000] gswip 1e108000.switch: port 2 failed to add 00:01:02:03:04:02 vid 0 to fdb: -22
+[ 174.090000] gswip 1e108000.switch: port 2 failed to add 00:01:02:03:04:02 vid 1 to fdb: -22
+[ 174.090000] gswip 1e108000.switch: port 2 failed to delete fa:aa:72:f4:8b:1e vid 1 from fdb: -2
+
+The errors are because gswip_port_fdb() wants to get a handle to the
+bridge that originated these FDB events, to associate it with a FID.
+Absolutely honourable purpose, however this only works for user ports.
+
+To get the bridge that generated an FDB entry for the CPU port, one
+would need to look at the db.bridge.dev argument. But this was
+introduced in commit c26933639b54 ("net: dsa: request drivers to perform
+FDB isolation"), first appeared in v5.18, and when the blamed commit was
+introduced in v5.14, no such API existed.
+
+So the core DSA feature was introduced way too soon for lantiq_gswip.
+Not acting on these host FDB entries and suppressing any errors has no
+other negative effect, and practically returns us to not supporting the
+host filtering feature at all - peacefully, this time.
+
+Fixes: 10fae4ac89ce ("net: dsa: include bridge addresses which are local in the host fdb list")
+Reported-by: Daniel Golle <daniel@makrotopia.org>
+Closes: https://lore.kernel.org/netdev/aJfNMLNoi1VOsPrN@pidgin.makrotopia.org/
+Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
+Link: https://patch.msgid.link/20250918072142.894692-3-vladimir.oltean@nxp.com
+Tested-by: Daniel Golle <daniel@makrotopia.org>
+Reviewed-by: Daniel Golle <daniel@makrotopia.org>
+Signed-off-by: Paolo Abeni <pabeni@redhat.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/dsa/lantiq_gswip.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+diff --git a/drivers/net/dsa/lantiq_gswip.c b/drivers/net/dsa/lantiq_gswip.c
+index 054548294f039..c1a9ab9259768 100644
+--- a/drivers/net/dsa/lantiq_gswip.c
++++ b/drivers/net/dsa/lantiq_gswip.c
+@@ -1366,8 +1366,9 @@ static int gswip_port_fdb(struct dsa_switch *ds, int port,
+ int i;
+ int err;
+
++ /* Operation not supported on the CPU port, don't throw errors */
+ if (!bridge)
+- return -EINVAL;
++ return 0;
+
+ for (i = max_ports; i < ARRAY_SIZE(priv->vlans); i++) {
+ if (priv->vlans[i].bridge == bridge) {
+--
+2.51.0
+
--- /dev/null
+From 85ee291f485d3ea514069e7a3ebc1c58d7cad5c3 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Sun, 21 Sep 2025 18:08:22 +0300
+Subject: nexthop: Forbid FDB status change while nexthop is in a group
+
+From: Ido Schimmel <idosch@nvidia.com>
+
+[ Upstream commit 390b3a300d7872cef9588f003b204398be69ce08 ]
+
+The kernel forbids the creation of non-FDB nexthop groups with FDB
+nexthops:
+
+ # ip nexthop add id 1 via 192.0.2.1 fdb
+ # ip nexthop add id 2 group 1
+ Error: Non FDB nexthop group cannot have fdb nexthops.
+
+And vice versa:
+
+ # ip nexthop add id 3 via 192.0.2.2 dev dummy1
+ # ip nexthop add id 4 group 3 fdb
+ Error: FDB nexthop group can only have fdb nexthops.
+
+However, as long as no routes are pointing to a non-FDB nexthop group,
+the kernel allows changing the type of a nexthop from FDB to non-FDB and
+vice versa:
+
+ # ip nexthop add id 5 via 192.0.2.2 dev dummy1
+ # ip nexthop add id 6 group 5
+ # ip nexthop replace id 5 via 192.0.2.2 fdb
+ # echo $?
+ 0
+
+This configuration is invalid and can result in a NPD [1] since FDB
+nexthops are not associated with a nexthop device:
+
+ # ip route add 198.51.100.1/32 nhid 6
+ # ping 198.51.100.1
+
+Fix by preventing nexthop FDB status change while the nexthop is in a
+group:
+
+ # ip nexthop add id 7 via 192.0.2.2 dev dummy1
+ # ip nexthop add id 8 group 7
+ # ip nexthop replace id 7 via 192.0.2.2 fdb
+ Error: Cannot change nexthop FDB status while in a group.
+
+[1]
+BUG: kernel NULL pointer dereference, address: 00000000000003c0
+[...]
+Oops: Oops: 0000 [#1] SMP
+CPU: 6 UID: 0 PID: 367 Comm: ping Not tainted 6.17.0-rc6-virtme-gb65678cacc03 #1 PREEMPT(voluntary)
+Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-4.fc41 04/01/2014
+RIP: 0010:fib_lookup_good_nhc+0x1e/0x80
+[...]
+Call Trace:
+ <TASK>
+ fib_table_lookup+0x541/0x650
+ ip_route_output_key_hash_rcu+0x2ea/0x970
+ ip_route_output_key_hash+0x55/0x80
+ __ip4_datagram_connect+0x250/0x330
+ udp_connect+0x2b/0x60
+ __sys_connect+0x9c/0xd0
+ __x64_sys_connect+0x18/0x20
+ do_syscall_64+0xa4/0x2a0
+ entry_SYSCALL_64_after_hwframe+0x4b/0x53
+
+Fixes: 38428d68719c ("nexthop: support for fdb ecmp nexthops")
+Reported-by: syzbot+6596516dd2b635ba2350@syzkaller.appspotmail.com
+Closes: https://lore.kernel.org/netdev/68c9a4d2.050a0220.3c6139.0e63.GAE@google.com/
+Tested-by: syzbot+6596516dd2b635ba2350@syzkaller.appspotmail.com
+Signed-off-by: Ido Schimmel <idosch@nvidia.com>
+Reviewed-by: David Ahern <dsahern@kernel.org>
+Link: https://patch.msgid.link/20250921150824.149157-2-idosch@nvidia.com
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ net/ipv4/nexthop.c | 7 +++++++
+ 1 file changed, 7 insertions(+)
+
+diff --git a/net/ipv4/nexthop.c b/net/ipv4/nexthop.c
+index 8d41b03942197..fab550633ec9f 100644
+--- a/net/ipv4/nexthop.c
++++ b/net/ipv4/nexthop.c
+@@ -2136,6 +2136,13 @@ static int replace_nexthop_single(struct net *net, struct nexthop *old,
+ return -EINVAL;
+ }
+
++ if (!list_empty(&old->grp_list) &&
++ rtnl_dereference(new->nh_info)->fdb_nh !=
++ rtnl_dereference(old->nh_info)->fdb_nh) {
++ NL_SET_ERR_MSG(extack, "Cannot change nexthop FDB status while in a group");
++ return -EINVAL;
++ }
++
+ err = call_nexthop_notifiers(net, NEXTHOP_EVENT_REPLACE, new, extack);
+ if (err)
+ return err;
+--
+2.51.0
+
--- /dev/null
+From b89bc5ca4fe79f20c331c46ce71786d254ffe6ec Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 23 Sep 2025 14:19:11 +0300
+Subject: octeontx2-pf: Fix potential use after free in otx2_tc_add_flow()
+
+From: Dan Carpenter <dan.carpenter@linaro.org>
+
+[ Upstream commit d9c70e93ec5988ab07ad2a92d9f9d12867f02c56 ]
+
+This code calls kfree_rcu(new_node, rcu) and then dereferences "new_node"
+and then dereferences it on the next line. Two lines later, we take
+a mutex so I don't think this is an RCU safe region. Re-order it to do
+the dereferences before queuing up the free.
+
+Fixes: 68fbff68dbea ("octeontx2-pf: Add police action for TC flower")
+Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
+Reviewed-by: Vadim Fedorenko <vadim.fedorenko@linux.dev>
+Link: https://patch.msgid.link/aNKCL1jKwK8GRJHh@stanley.mountain
+Signed-off-by: Paolo Abeni <pabeni@redhat.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/ethernet/marvell/octeontx2/nic/otx2_tc.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/drivers/net/ethernet/marvell/octeontx2/nic/otx2_tc.c b/drivers/net/ethernet/marvell/octeontx2/nic/otx2_tc.c
+index 46bdbee9d38ad..635cfb9a3e2c5 100644
+--- a/drivers/net/ethernet/marvell/octeontx2/nic/otx2_tc.c
++++ b/drivers/net/ethernet/marvell/octeontx2/nic/otx2_tc.c
+@@ -1116,7 +1116,6 @@ static int otx2_tc_add_flow(struct otx2_nic *nic,
+
+ free_leaf:
+ otx2_tc_del_from_flow_list(flow_cfg, new_node);
+- kfree_rcu(new_node, rcu);
+ if (new_node->is_act_police) {
+ mutex_lock(&nic->mbox.lock);
+
+@@ -1136,6 +1135,7 @@ static int otx2_tc_add_flow(struct otx2_nic *nic,
+
+ mutex_unlock(&nic->mbox.lock);
+ }
++ kfree_rcu(new_node, rcu);
+
+ return rc;
+ }
+--
+2.51.0
+
--- /dev/null
+From 908e8e73446d11a8cf2d008790ff384e34d8377f Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Sun, 21 Sep 2025 18:08:23 +0300
+Subject: selftests: fib_nexthops: Fix creation of non-FDB nexthops
+
+From: Ido Schimmel <idosch@nvidia.com>
+
+[ Upstream commit c29913109c70383cdf90b6fc792353e1009f24f5 ]
+
+The test creates non-FDB nexthops without a nexthop device which leads
+to the expected failure, but for the wrong reason:
+
+ # ./fib_nexthops.sh -t "ipv6_fdb_grp_fcnal ipv4_fdb_grp_fcnal" -v
+
+ IPv6 fdb groups functional
+ --------------------------
+ [...]
+ COMMAND: ip -netns me-nRsN3E nexthop add id 63 via 2001:db8:91::4
+ Error: Device attribute required for non-blackhole and non-fdb nexthops.
+ COMMAND: ip -netns me-nRsN3E nexthop add id 64 via 2001:db8:91::5
+ Error: Device attribute required for non-blackhole and non-fdb nexthops.
+ COMMAND: ip -netns me-nRsN3E nexthop add id 103 group 63/64 fdb
+ Error: Invalid nexthop id.
+ TEST: Fdb Nexthop group with non-fdb nexthops [ OK ]
+ [...]
+
+ IPv4 fdb groups functional
+ --------------------------
+ [...]
+ COMMAND: ip -netns me-nRsN3E nexthop add id 14 via 172.16.1.2
+ Error: Device attribute required for non-blackhole and non-fdb nexthops.
+ COMMAND: ip -netns me-nRsN3E nexthop add id 15 via 172.16.1.3
+ Error: Device attribute required for non-blackhole and non-fdb nexthops.
+ COMMAND: ip -netns me-nRsN3E nexthop add id 103 group 14/15 fdb
+ Error: Invalid nexthop id.
+ TEST: Fdb Nexthop group with non-fdb nexthops [ OK ]
+
+ COMMAND: ip -netns me-nRsN3E nexthop add id 16 via 172.16.1.2 fdb
+ COMMAND: ip -netns me-nRsN3E nexthop add id 17 via 172.16.1.3 fdb
+ COMMAND: ip -netns me-nRsN3E nexthop add id 104 group 14/15
+ Error: Invalid nexthop id.
+ TEST: Non-Fdb Nexthop group with fdb nexthops [ OK ]
+ [...]
+ COMMAND: ip -netns me-0dlhyd ro add 172.16.0.0/22 nhid 15
+ Error: Nexthop id does not exist.
+ TEST: Route add with fdb nexthop [ OK ]
+
+In addition, as can be seen in the above output, a couple of IPv4 test
+cases used the non-FDB nexthops (14 and 15) when they intended to use
+the FDB nexthops (16 and 17). These test cases only passed because
+failure was expected, but they failed for the wrong reason.
+
+Fix the test to create the non-FDB nexthops with a nexthop device and
+adjust the IPv4 test cases to use the FDB nexthops instead of the
+non-FDB nexthops.
+
+Output after the fix:
+
+ # ./fib_nexthops.sh -t "ipv6_fdb_grp_fcnal ipv4_fdb_grp_fcnal" -v
+
+ IPv6 fdb groups functional
+ --------------------------
+ [...]
+ COMMAND: ip -netns me-lNzfHP nexthop add id 63 via 2001:db8:91::4 dev veth1
+ COMMAND: ip -netns me-lNzfHP nexthop add id 64 via 2001:db8:91::5 dev veth1
+ COMMAND: ip -netns me-lNzfHP nexthop add id 103 group 63/64 fdb
+ Error: FDB nexthop group can only have fdb nexthops.
+ TEST: Fdb Nexthop group with non-fdb nexthops [ OK ]
+ [...]
+
+ IPv4 fdb groups functional
+ --------------------------
+ [...]
+ COMMAND: ip -netns me-lNzfHP nexthop add id 14 via 172.16.1.2 dev veth1
+ COMMAND: ip -netns me-lNzfHP nexthop add id 15 via 172.16.1.3 dev veth1
+ COMMAND: ip -netns me-lNzfHP nexthop add id 103 group 14/15 fdb
+ Error: FDB nexthop group can only have fdb nexthops.
+ TEST: Fdb Nexthop group with non-fdb nexthops [ OK ]
+
+ COMMAND: ip -netns me-lNzfHP nexthop add id 16 via 172.16.1.2 fdb
+ COMMAND: ip -netns me-lNzfHP nexthop add id 17 via 172.16.1.3 fdb
+ COMMAND: ip -netns me-lNzfHP nexthop add id 104 group 16/17
+ Error: Non FDB nexthop group cannot have fdb nexthops.
+ TEST: Non-Fdb Nexthop group with fdb nexthops [ OK ]
+ [...]
+ COMMAND: ip -netns me-lNzfHP ro add 172.16.0.0/22 nhid 16
+ Error: Route cannot point to a fdb nexthop.
+ TEST: Route add with fdb nexthop [ OK ]
+ [...]
+ Tests passed: 30
+ Tests failed: 0
+ Tests skipped: 0
+
+Fixes: 0534c5489c11 ("selftests: net: add fdb nexthop tests")
+Signed-off-by: Ido Schimmel <idosch@nvidia.com>
+Reviewed-by: David Ahern <dsahern@kernel.org>
+Link: https://patch.msgid.link/20250921150824.149157-3-idosch@nvidia.com
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ tools/testing/selftests/net/fib_nexthops.sh | 12 ++++++------
+ 1 file changed, 6 insertions(+), 6 deletions(-)
+
+diff --git a/tools/testing/selftests/net/fib_nexthops.sh b/tools/testing/selftests/net/fib_nexthops.sh
+index a6f2c0b9555d1..e2e4fffd87e39 100755
+--- a/tools/testing/selftests/net/fib_nexthops.sh
++++ b/tools/testing/selftests/net/fib_nexthops.sh
+@@ -464,8 +464,8 @@ ipv6_fdb_grp_fcnal()
+ log_test $? 0 "Get Fdb nexthop group by id"
+
+ # fdb nexthop group can only contain fdb nexthops
+- run_cmd "$IP nexthop add id 63 via 2001:db8:91::4"
+- run_cmd "$IP nexthop add id 64 via 2001:db8:91::5"
++ run_cmd "$IP nexthop add id 63 via 2001:db8:91::4 dev veth1"
++ run_cmd "$IP nexthop add id 64 via 2001:db8:91::5 dev veth1"
+ run_cmd "$IP nexthop add id 103 group 63/64 fdb"
+ log_test $? 2 "Fdb Nexthop group with non-fdb nexthops"
+
+@@ -544,15 +544,15 @@ ipv4_fdb_grp_fcnal()
+ log_test $? 0 "Get Fdb nexthop group by id"
+
+ # fdb nexthop group can only contain fdb nexthops
+- run_cmd "$IP nexthop add id 14 via 172.16.1.2"
+- run_cmd "$IP nexthop add id 15 via 172.16.1.3"
++ run_cmd "$IP nexthop add id 14 via 172.16.1.2 dev veth1"
++ run_cmd "$IP nexthop add id 15 via 172.16.1.3 dev veth1"
+ run_cmd "$IP nexthop add id 103 group 14/15 fdb"
+ log_test $? 2 "Fdb Nexthop group with non-fdb nexthops"
+
+ # Non fdb nexthop group can not contain fdb nexthops
+ run_cmd "$IP nexthop add id 16 via 172.16.1.2 fdb"
+ run_cmd "$IP nexthop add id 17 via 172.16.1.3 fdb"
+- run_cmd "$IP nexthop add id 104 group 14/15"
++ run_cmd "$IP nexthop add id 104 group 16/17"
+ log_test $? 2 "Non-Fdb Nexthop group with fdb nexthops"
+
+ # fdb nexthop cannot have blackhole
+@@ -579,7 +579,7 @@ ipv4_fdb_grp_fcnal()
+ run_cmd "$BRIDGE fdb add 02:02:00:00:00:14 dev vx10 nhid 12 self"
+ log_test $? 255 "Fdb mac add with nexthop"
+
+- run_cmd "$IP ro add 172.16.0.0/22 nhid 15"
++ run_cmd "$IP ro add 172.16.0.0/22 nhid 16"
+ log_test $? 2 "Route add with fdb nexthop"
+
+ run_cmd "$IP ro add 172.16.0.0/22 nhid 103"
+--
+2.51.0
+
wifi-virt_wifi-fix-page-fault-on-connect.patch
can-rcar_can-rcar_can_resume-fix-s2ram-with-psci.patch
bpf-reject-bpf_timer-for-preempt_rt.patch
+xfrm-xfrm_alloc_spi-shouldn-t-use-0-as-spi.patch
+can-etas_es58x-populate-ndo_change_mtu-to-prevent-bu.patch
+can-hi311x-populate-ndo_change_mtu-to-prevent-buffer.patch
+can-sun4i_can-populate-ndo_change_mtu-to-prevent-buf.patch
+can-mcba_usb-populate-ndo_change_mtu-to-prevent-buff.patch
+can-peak_usb-fix-shift-out-of-bounds-issue.patch
+ethernet-rvu-af-remove-slash-from-the-driver-name.patch
+bluetooth-hci_sync-fix-hci_resume_advertising_sync.patch
+bluetooth-hci_event-fix-uaf-in-hci_acl_create_conn_s.patch
+vhost-take-a-reference-on-the-task-in-struct-vhost_t.patch
+bnxt_en-correct-offset-handling-for-ipv6-destination.patch
+net-allow-alloc_skb_with_frags-to-use-max_skb_frags.patch
+nexthop-forbid-fdb-status-change-while-nexthop-is-in.patch
+selftests-fib_nexthops-fix-creation-of-non-fdb-nexth.patch
+net-dsa-lantiq_gswip-do-also-enable-or-disable-cpu-p.patch
+net-dsa-lantiq_gswip-move-gswip_add_single_port_br-c.patch
+net-dsa-lantiq_gswip-suppress-einval-errors-for-brid.patch
+octeontx2-pf-fix-potential-use-after-free-in-otx2_tc.patch
--- /dev/null
+From 8d2b6ad8602038140c8d5ee160f21d43bc8c9984 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 18 Sep 2025 20:11:44 +0200
+Subject: vhost: Take a reference on the task in struct vhost_task.
+
+From: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
+
+[ Upstream commit afe16653e05db07d658b55245c7a2e0603f136c0 ]
+
+vhost_task_create() creates a task and keeps a reference to its
+task_struct. That task may exit early via a signal and its task_struct
+will be released.
+A pending vhost_task_wake() will then attempt to wake the task and
+access a task_struct which is no longer there.
+
+Acquire a reference on the task_struct while creating the thread and
+release the reference while the struct vhost_task itself is removed.
+If the task exits early due to a signal, then the vhost_task_wake() will
+still access a valid task_struct. The wake is safe and will be skipped
+in this case.
+
+Fixes: f9010dbdce911 ("fork, vhost: Use CLONE_THREAD to fix freezer/ps regression")
+Reported-by: Sean Christopherson <seanjc@google.com>
+Closes: https://lore.kernel.org/all/aKkLEtoDXKxAAWju@google.com/
+Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
+Message-Id: <20250918181144.Ygo8BZ-R@linutronix.de>
+Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
+Tested-by: Sean Christopherson <seanjc@google.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ kernel/vhost_task.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+diff --git a/kernel/vhost_task.c b/kernel/vhost_task.c
+index 8800f5acc0071..5a2116356428f 100644
+--- a/kernel/vhost_task.c
++++ b/kernel/vhost_task.c
+@@ -100,6 +100,7 @@ void vhost_task_stop(struct vhost_task *vtsk)
+ * freeing it below.
+ */
+ wait_for_completion(&vtsk->exited);
++ put_task_struct(vtsk->task);
+ kfree(vtsk);
+ }
+ EXPORT_SYMBOL_GPL(vhost_task_stop);
+@@ -148,7 +149,7 @@ struct vhost_task *vhost_task_create(bool (*fn)(void *),
+ return NULL;
+ }
+
+- vtsk->task = tsk;
++ vtsk->task = get_task_struct(tsk);
+ return vtsk;
+ }
+ EXPORT_SYMBOL_GPL(vhost_task_create);
+--
+2.51.0
+
--- /dev/null
+From a57b3ee4dd1c05a25257dfc5b4560f3abec4ddc7 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 29 Aug 2025 10:54:15 +0200
+Subject: xfrm: xfrm_alloc_spi shouldn't use 0 as SPI
+
+From: Sabrina Dubroca <sd@queasysnail.net>
+
+[ Upstream commit cd8ae32e4e4652db55bce6b9c79267d8946765a9 ]
+
+x->id.spi == 0 means "no SPI assigned", but since commit
+94f39804d891 ("xfrm: Duplicate SPI Handling"), we now create states
+and add them to the byspi list with this value.
+
+__xfrm_state_delete doesn't remove those states from the byspi list,
+since they shouldn't be there, and this shows up as a UAF the next
+time we go through the byspi list.
+
+Reported-by: syzbot+a25ee9d20d31e483ba7b@syzkaller.appspotmail.com
+Closes: https://syzkaller.appspot.com/bug?extid=a25ee9d20d31e483ba7b
+Fixes: 94f39804d891 ("xfrm: Duplicate SPI Handling")
+Signed-off-by: Sabrina Dubroca <sd@queasysnail.net>
+Reviewed-by: Simon Horman <horms@kernel.org>
+Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ net/xfrm/xfrm_state.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+diff --git a/net/xfrm/xfrm_state.c b/net/xfrm/xfrm_state.c
+index acfbe1f013d1b..ded559f557675 100644
+--- a/net/xfrm/xfrm_state.c
++++ b/net/xfrm/xfrm_state.c
+@@ -2296,6 +2296,8 @@ int xfrm_alloc_spi(struct xfrm_state *x, u32 low, u32 high,
+
+ for (h = 0; h < range; h++) {
+ u32 spi = (low == high) ? low : get_random_u32_inclusive(low, high);
++ if (spi == 0)
++ goto next;
+ newspi = htonl(spi);
+
+ spin_lock_bh(&net->xfrm.xfrm_state_lock);
+@@ -2311,6 +2313,7 @@ int xfrm_alloc_spi(struct xfrm_state *x, u32 low, u32 high,
+ xfrm_state_put(x0);
+ spin_unlock_bh(&net->xfrm.xfrm_state_lock);
+
++next:
+ if (signal_pending(current)) {
+ err = -ERESTARTSYS;
+ goto unlock;
+--
+2.51.0
+
projects / thirdparty / kernel / stable-queue.git / commitdiff
