From 51cefa873b917a3b7624c1a4397ffb2bf7077647 Mon Sep 17 00:00:00 2001 From: Sasha Levin Date: Fri, 26 Sep 2025 20:04:38 -0400 Subject: [PATCH] Fixes for all trees Signed-off-by: Sasha Levin --- ...offset-handling-for-ipv6-destination.patch | 43 + ...ate-ndo_change_mtu-to-prevent-buffer.patch | 85 ++ ...ulate-ndo_change_mtu-to-prevent-buff.patch | 83 ++ ...ak_usb-fix-shift-out-of-bounds-issue.patch | 44 + ...pulate-ndo_change_mtu-to-prevent-buf.patch | 85 ++ ...notification-when-a-nexthop-is-added.patch | 69 ++ ...otification-when-a-single-nexthop-is.patch | 55 ++ ...db-status-change-while-nexthop-is-in.patch | 100 +++ ...thop-pass-extack-to-nexthop-notifier.patch | 47 ++ .../rtnetlink-add-rtnh_f_trap-flag.patch | 68 ++ ...xthops-fix-creation-of-non-fdb-nexth.patch | 149 ++++ queue-5.10/series | 11 + ...offset-handling-for-ipv6-destination.patch | 43 + ...low-tdc-v-o-to-be-zero-and-add-can_t.patch | 263 ++++++ ...place-can-units-with-the-generic-one.patch | 136 +++ ...-generic-function-can_eth_ioctl_hwts.patch | 87 ++ ...ric-function-can_ethtool_op_get_ts_i.patch | 92 +++ ...dvertise-timestamping-capabilities-a.patch | 75 ++ ...opulate-ndo_change_mtu-to-prevent-bu.patch | 98 +++ ...ort-the-includes-by-alphabetic-order.patch | 115 +++ ...ate-ndo_change_mtu-to-prevent-buffer.patch | 85 ++ ...ulate-ndo_change_mtu-to-prevent-buff.patch | 83 ++ ...ak_usb-fix-shift-out-of-bounds-issue.patch | 44 + ...pulate-ndo_change_mtu-to-prevent-buf.patch | 85 ++ ...af-remove-slash-from-the-driver-name.patch | 41 + ...swip-do-also-enable-or-disable-cpu-p.patch | 84 ++ ...swip-move-gswip_add_single_port_br-c.patch | 97 +++ ...swip-suppress-einval-errors-for-brid.patch | 69 ++ ...db-status-change-while-nexthop-is-in.patch | 100 +++ ...xthops-fix-creation-of-non-fdb-nexth.patch | 149 ++++ queue-5.15/series | 18 + ...ate-ndo_change_mtu-to-prevent-buffer.patch | 85 ++ ...ulate-ndo_change_mtu-to-prevent-buff.patch | 83 ++ ...ak_usb-fix-shift-out-of-bounds-issue.patch | 44 + ...pulate-ndo_change_mtu-to-prevent-buf.patch | 85 ++ queue-5.4/series | 4 + ...ent-fix-uaf-in-hci_acl_create_conn_s.patch | 199 +++++ ...sync-fix-hci_resume_advertising_sync.patch | 42 + ...offset-handling-for-ipv6-destination.patch | 43 + ...opulate-ndo_change_mtu-to-prevent-bu.patch | 98 +++ ...ort-the-includes-by-alphabetic-order.patch | 115 +++ ...ate-ndo_change_mtu-to-prevent-buffer.patch | 85 ++ ...ulate-ndo_change_mtu-to-prevent-buff.patch | 83 ++ ...ak_usb-fix-shift-out-of-bounds-issue.patch | 44 + ...pulate-ndo_change_mtu-to-prevent-buf.patch | 85 ++ ...af-remove-slash-from-the-driver-name.patch | 41 + ...swip-do-also-enable-or-disable-cpu-p.patch | 84 ++ ...swip-move-gswip_add_single_port_br-c.patch | 97 +++ ...swip-suppress-einval-errors-for-brid.patch | 69 ++ ...db-status-change-while-nexthop-is-in.patch | 100 +++ ...-potential-use-after-free-in-otx2_tc.patch | 47 ++ ...xthops-fix-creation-of-non-fdb-nexth.patch | 149 ++++ queue-6.1/series | 16 + ...ent-fix-uaf-in-hci_acl_create_conn_s.patch | 199 +++++ ...sync-fix-hci_resume_advertising_sync.patch | 42 + ...offset-handling-for-ipv6-destination.patch | 43 + ...opulate-ndo_change_mtu-to-prevent-bu.patch | 98 +++ ...ate-ndo_change_mtu-to-prevent-buffer.patch | 85 ++ ...ulate-ndo_change_mtu-to-prevent-buff.patch | 83 ++ ...ak_usb-fix-shift-out-of-bounds-issue.patch | 44 + ...pulate-ndo_change_mtu-to-prevent-buf.patch | 85 ++ ...af-remove-slash-from-the-driver-name.patch | 41 + ...e_lru_cached-unless-folio_test_large.patch | 150 ++++ ..._add_drain-to-avoid-lru_add_drain_al.patch | 89 ++ ...-clear-the-lru-flag-of-a-page-before.patch | 203 +++++ ..._skb_with_frags-to-use-max_skb_frags.patch | 47 ++ ...swip-move-gswip_add_single_port_br-c.patch | 97 +++ ...swip-suppress-einval-errors-for-brid.patch | 69 ++ ...ing-in-smc_rx_splice-when-calling-ge.patch | 107 +++ ...un-update-napi-skb-after-xdp-process.patch | 113 +++ ...db-status-change-while-nexthop-is-in.patch | 100 +++ ...-potential-use-after-free-in-otx2_tc.patch | 47 ++ ...xthops-fix-creation-of-non-fdb-nexth.patch | 149 ++++ queue-6.12/series | 22 + ...erence-on-the-task-in-struct-vhost_t.patch | 57 ++ ...frm_alloc_spi-shouldn-t-use-0-as-spi.patch | 52 ++ ...ent-fix-uaf-in-hci_acl_create_conn_s.patch | 199 +++++ ...event-fix-uaf-in-hci_conn_tx_dequeue.patch | 118 +++ ...sync-fix-hci_resume_advertising_sync.patch | 42 + .../bluetooth-mgmt-fix-possible-uafs.patch | 775 ++++++++++++++++++ ...offset-handling-for-ipv6-destination.patch | 43 + ...support-for-ptp_extts_request2-ioctl.patch | 65 ++ ...ix-support-for-ptp_perout_duty_cycle.patch | 60 ++ ...opulate-ndo_change_mtu-to-prevent-bu.patch | 98 +++ ...ate-ndo_change_mtu-to-prevent-buffer.patch | 85 ++ ...ulate-ndo_change_mtu-to-prevent-buff.patch | 83 ++ ...ak_usb-fix-shift-out-of-bounds-issue.patch | 44 + ...pulate-ndo_change_mtu-to-prevent-buf.patch | 85 ++ ...af-remove-slash-from-the-driver-name.patch | 41 + ..._skb_with_frags-to-use-max_skb_frags.patch | 47 ++ ...swip-move-gswip_add_single_port_br-c.patch | 97 +++ ...swip-suppress-einval-errors-for-brid.patch | 69 ++ ...5-fs-fix-uaf-in-flow-counter-release.patch | 171 ++++ ...nore-flow-level-for-multi-dest-table.patch | 119 +++ ...ove-unused-create_dest_array-paramet.patch | 116 +++ ...ssing-fec-rs-stats-for-rs_544_514_in.patch | 40 + ...ing-in-smc_rx_splice-when-calling-ge.patch | 107 +++ ...un-update-napi-skb-after-xdp-process.patch | 113 +++ ...db-status-change-while-nexthop-is-in.patch | 100 +++ ...-potential-use-after-free-in-otx2_tc.patch | 47 ++ ...xthops-fix-creation-of-non-fdb-nexth.patch | 149 ++++ queue-6.16/series | 28 + ...erence-on-the-task-in-struct-vhost_t.patch | 57 ++ ...x-offloading-of-cross-family-tunnels.patch | 71 ++ ...frm_alloc_spi-shouldn-t-use-0-as-spi.patch | 52 ++ ...ent-fix-uaf-in-hci_acl_create_conn_s.patch | 199 +++++ ...sync-fix-hci_resume_advertising_sync.patch | 42 + ...offset-handling-for-ipv6-destination.patch | 43 + ...opulate-ndo_change_mtu-to-prevent-bu.patch | 98 +++ ...ate-ndo_change_mtu-to-prevent-buffer.patch | 85 ++ ...ulate-ndo_change_mtu-to-prevent-buff.patch | 83 ++ ...ak_usb-fix-shift-out-of-bounds-issue.patch | 44 + ...pulate-ndo_change_mtu-to-prevent-buf.patch | 85 ++ ...af-remove-slash-from-the-driver-name.patch | 41 + ..._skb_with_frags-to-use-max_skb_frags.patch | 47 ++ ...swip-do-also-enable-or-disable-cpu-p.patch | 84 ++ ...swip-move-gswip_add_single_port_br-c.patch | 97 +++ ...swip-suppress-einval-errors-for-brid.patch | 69 ++ ...db-status-change-while-nexthop-is-in.patch | 100 +++ ...-potential-use-after-free-in-otx2_tc.patch | 47 ++ ...xthops-fix-creation-of-non-fdb-nexth.patch | 149 ++++ queue-6.6/series | 18 + ...erence-on-the-task-in-struct-vhost_t.patch | 57 ++ ...frm_alloc_spi-shouldn-t-use-0-as-spi.patch | 52 ++ 124 files changed, 10884 insertions(+) create mode 100644 queue-5.10/bnxt_en-correct-offset-handling-for-ipv6-destination.patch create mode 100644 queue-5.10/can-hi311x-populate-ndo_change_mtu-to-prevent-buffer.patch create mode 100644 queue-5.10/can-mcba_usb-populate-ndo_change_mtu-to-prevent-buff.patch create mode 100644 queue-5.10/can-peak_usb-fix-shift-out-of-bounds-issue.patch create mode 100644 queue-5.10/can-sun4i_can-populate-ndo_change_mtu-to-prevent-buf.patch create mode 100644 queue-5.10/nexthop-emit-a-notification-when-a-nexthop-is-added.patch create mode 100644 queue-5.10/nexthop-emit-a-notification-when-a-single-nexthop-is.patch create mode 100644 queue-5.10/nexthop-forbid-fdb-status-change-while-nexthop-is-in.patch create mode 100644 queue-5.10/nexthop-pass-extack-to-nexthop-notifier.patch create mode 100644 queue-5.10/rtnetlink-add-rtnh_f_trap-flag.patch create mode 100644 queue-5.10/selftests-fib_nexthops-fix-creation-of-non-fdb-nexth.patch create mode 100644 queue-5.15/bnxt_en-correct-offset-handling-for-ipv6-destination.patch create mode 100644 queue-5.15/can-bittiming-allow-tdc-v-o-to-be-zero-and-add-can_t.patch create mode 100644 queue-5.15/can-bittiming-replace-can-units-with-the-generic-one.patch create mode 100644 queue-5.15/can-dev-add-generic-function-can_eth_ioctl_hwts.patch create mode 100644 queue-5.15/can-dev-add-generic-function-can_ethtool_op_get_ts_i.patch create mode 100644 queue-5.15/can-etas_es58x-advertise-timestamping-capabilities-a.patch create mode 100644 queue-5.15/can-etas_es58x-populate-ndo_change_mtu-to-prevent-bu.patch create mode 100644 queue-5.15/can-etas_es58x-sort-the-includes-by-alphabetic-order.patch create mode 100644 queue-5.15/can-hi311x-populate-ndo_change_mtu-to-prevent-buffer.patch create mode 100644 queue-5.15/can-mcba_usb-populate-ndo_change_mtu-to-prevent-buff.patch create mode 100644 queue-5.15/can-peak_usb-fix-shift-out-of-bounds-issue.patch create mode 100644 queue-5.15/can-sun4i_can-populate-ndo_change_mtu-to-prevent-buf.patch create mode 100644 queue-5.15/ethernet-rvu-af-remove-slash-from-the-driver-name.patch create mode 100644 queue-5.15/net-dsa-lantiq_gswip-do-also-enable-or-disable-cpu-p.patch create mode 100644 queue-5.15/net-dsa-lantiq_gswip-move-gswip_add_single_port_br-c.patch create mode 100644 queue-5.15/net-dsa-lantiq_gswip-suppress-einval-errors-for-brid.patch create mode 100644 queue-5.15/nexthop-forbid-fdb-status-change-while-nexthop-is-in.patch create mode 100644 queue-5.15/selftests-fib_nexthops-fix-creation-of-non-fdb-nexth.patch create mode 100644 queue-5.4/can-hi311x-populate-ndo_change_mtu-to-prevent-buffer.patch create mode 100644 queue-5.4/can-mcba_usb-populate-ndo_change_mtu-to-prevent-buff.patch create mode 100644 queue-5.4/can-peak_usb-fix-shift-out-of-bounds-issue.patch create mode 100644 queue-5.4/can-sun4i_can-populate-ndo_change_mtu-to-prevent-buf.patch create mode 100644 queue-6.1/bluetooth-hci_event-fix-uaf-in-hci_acl_create_conn_s.patch create mode 100644 queue-6.1/bluetooth-hci_sync-fix-hci_resume_advertising_sync.patch create mode 100644 queue-6.1/bnxt_en-correct-offset-handling-for-ipv6-destination.patch create mode 100644 queue-6.1/can-etas_es58x-populate-ndo_change_mtu-to-prevent-bu.patch create mode 100644 queue-6.1/can-etas_es58x-sort-the-includes-by-alphabetic-order.patch create mode 100644 queue-6.1/can-hi311x-populate-ndo_change_mtu-to-prevent-buffer.patch create mode 100644 queue-6.1/can-mcba_usb-populate-ndo_change_mtu-to-prevent-buff.patch create mode 100644 queue-6.1/can-peak_usb-fix-shift-out-of-bounds-issue.patch create mode 100644 queue-6.1/can-sun4i_can-populate-ndo_change_mtu-to-prevent-buf.patch create mode 100644 queue-6.1/ethernet-rvu-af-remove-slash-from-the-driver-name.patch create mode 100644 queue-6.1/net-dsa-lantiq_gswip-do-also-enable-or-disable-cpu-p.patch create mode 100644 queue-6.1/net-dsa-lantiq_gswip-move-gswip_add_single_port_br-c.patch create mode 100644 queue-6.1/net-dsa-lantiq_gswip-suppress-einval-errors-for-brid.patch create mode 100644 queue-6.1/nexthop-forbid-fdb-status-change-while-nexthop-is-in.patch create mode 100644 queue-6.1/octeontx2-pf-fix-potential-use-after-free-in-otx2_tc.patch create mode 100644 queue-6.1/selftests-fib_nexthops-fix-creation-of-non-fdb-nexth.patch create mode 100644 queue-6.12/bluetooth-hci_event-fix-uaf-in-hci_acl_create_conn_s.patch create mode 100644 queue-6.12/bluetooth-hci_sync-fix-hci_resume_advertising_sync.patch create mode 100644 queue-6.12/bnxt_en-correct-offset-handling-for-ipv6-destination.patch create mode 100644 queue-6.12/can-etas_es58x-populate-ndo_change_mtu-to-prevent-bu.patch create mode 100644 queue-6.12/can-hi311x-populate-ndo_change_mtu-to-prevent-buffer.patch create mode 100644 queue-6.12/can-mcba_usb-populate-ndo_change_mtu-to-prevent-buff.patch create mode 100644 queue-6.12/can-peak_usb-fix-shift-out-of-bounds-issue.patch create mode 100644 queue-6.12/can-sun4i_can-populate-ndo_change_mtu-to-prevent-buf.patch create mode 100644 queue-6.12/ethernet-rvu-af-remove-slash-from-the-driver-name.patch create mode 100644 queue-6.12/mm-folio_may_be_lru_cached-unless-folio_test_large.patch create mode 100644 queue-6.12/mm-gup-local-lru_add_drain-to-avoid-lru_add_drain_al.patch create mode 100644 queue-6.12/mm-revert-mm-gup-clear-the-lru-flag-of-a-page-before.patch create mode 100644 queue-6.12/net-allow-alloc_skb_with_frags-to-use-max_skb_frags.patch create mode 100644 queue-6.12/net-dsa-lantiq_gswip-move-gswip_add_single_port_br-c.patch create mode 100644 queue-6.12/net-dsa-lantiq_gswip-suppress-einval-errors-for-brid.patch create mode 100644 queue-6.12/net-smc-fix-warning-in-smc_rx_splice-when-calling-ge.patch create mode 100644 queue-6.12/net-tun-update-napi-skb-after-xdp-process.patch create mode 100644 queue-6.12/nexthop-forbid-fdb-status-change-while-nexthop-is-in.patch create mode 100644 queue-6.12/octeontx2-pf-fix-potential-use-after-free-in-otx2_tc.patch create mode 100644 queue-6.12/selftests-fib_nexthops-fix-creation-of-non-fdb-nexth.patch create mode 100644 queue-6.12/vhost-take-a-reference-on-the-task-in-struct-vhost_t.patch create mode 100644 queue-6.12/xfrm-xfrm_alloc_spi-shouldn-t-use-0-as-spi.patch create mode 100644 queue-6.16/bluetooth-hci_event-fix-uaf-in-hci_acl_create_conn_s.patch create mode 100644 queue-6.16/bluetooth-hci_event-fix-uaf-in-hci_conn_tx_dequeue.patch create mode 100644 queue-6.16/bluetooth-hci_sync-fix-hci_resume_advertising_sync.patch create mode 100644 queue-6.16/bluetooth-mgmt-fix-possible-uafs.patch create mode 100644 queue-6.16/bnxt_en-correct-offset-handling-for-ipv6-destination.patch create mode 100644 queue-6.16/broadcom-fix-support-for-ptp_extts_request2-ioctl.patch create mode 100644 queue-6.16/broadcom-fix-support-for-ptp_perout_duty_cycle.patch create mode 100644 queue-6.16/can-etas_es58x-populate-ndo_change_mtu-to-prevent-bu.patch create mode 100644 queue-6.16/can-hi311x-populate-ndo_change_mtu-to-prevent-buffer.patch create mode 100644 queue-6.16/can-mcba_usb-populate-ndo_change_mtu-to-prevent-buff.patch create mode 100644 queue-6.16/can-peak_usb-fix-shift-out-of-bounds-issue.patch create mode 100644 queue-6.16/can-sun4i_can-populate-ndo_change_mtu-to-prevent-buf.patch create mode 100644 queue-6.16/ethernet-rvu-af-remove-slash-from-the-driver-name.patch create mode 100644 queue-6.16/net-allow-alloc_skb_with_frags-to-use-max_skb_frags.patch create mode 100644 queue-6.16/net-dsa-lantiq_gswip-move-gswip_add_single_port_br-c.patch create mode 100644 queue-6.16/net-dsa-lantiq_gswip-suppress-einval-errors-for-brid.patch create mode 100644 queue-6.16/net-mlx5-fs-fix-uaf-in-flow-counter-release.patch create mode 100644 queue-6.16/net-mlx5-hws-ignore-flow-level-for-multi-dest-table.patch create mode 100644 queue-6.16/net-mlx5-hws-remove-unused-create_dest_array-paramet.patch create mode 100644 queue-6.16/net-mlx5e-fix-missing-fec-rs-stats-for-rs_544_514_in.patch create mode 100644 queue-6.16/net-smc-fix-warning-in-smc_rx_splice-when-calling-ge.patch create mode 100644 queue-6.16/net-tun-update-napi-skb-after-xdp-process.patch create mode 100644 queue-6.16/nexthop-forbid-fdb-status-change-while-nexthop-is-in.patch create mode 100644 queue-6.16/octeontx2-pf-fix-potential-use-after-free-in-otx2_tc.patch create mode 100644 queue-6.16/selftests-fib_nexthops-fix-creation-of-non-fdb-nexth.patch create mode 100644 queue-6.16/vhost-take-a-reference-on-the-task-in-struct-vhost_t.patch create mode 100644 queue-6.16/xfrm-fix-offloading-of-cross-family-tunnels.patch create mode 100644 queue-6.16/xfrm-xfrm_alloc_spi-shouldn-t-use-0-as-spi.patch create mode 100644 queue-6.6/bluetooth-hci_event-fix-uaf-in-hci_acl_create_conn_s.patch create mode 100644 queue-6.6/bluetooth-hci_sync-fix-hci_resume_advertising_sync.patch create mode 100644 queue-6.6/bnxt_en-correct-offset-handling-for-ipv6-destination.patch create mode 100644 queue-6.6/can-etas_es58x-populate-ndo_change_mtu-to-prevent-bu.patch create mode 100644 queue-6.6/can-hi311x-populate-ndo_change_mtu-to-prevent-buffer.patch create mode 100644 queue-6.6/can-mcba_usb-populate-ndo_change_mtu-to-prevent-buff.patch create mode 100644 queue-6.6/can-peak_usb-fix-shift-out-of-bounds-issue.patch create mode 100644 queue-6.6/can-sun4i_can-populate-ndo_change_mtu-to-prevent-buf.patch create mode 100644 queue-6.6/ethernet-rvu-af-remove-slash-from-the-driver-name.patch create mode 100644 queue-6.6/net-allow-alloc_skb_with_frags-to-use-max_skb_frags.patch create mode 100644 queue-6.6/net-dsa-lantiq_gswip-do-also-enable-or-disable-cpu-p.patch create mode 100644 queue-6.6/net-dsa-lantiq_gswip-move-gswip_add_single_port_br-c.patch create mode 100644 queue-6.6/net-dsa-lantiq_gswip-suppress-einval-errors-for-brid.patch create mode 100644 queue-6.6/nexthop-forbid-fdb-status-change-while-nexthop-is-in.patch create mode 100644 queue-6.6/octeontx2-pf-fix-potential-use-after-free-in-otx2_tc.patch create mode 100644 queue-6.6/selftests-fib_nexthops-fix-creation-of-non-fdb-nexth.patch create mode 100644 queue-6.6/vhost-take-a-reference-on-the-task-in-struct-vhost_t.patch create mode 100644 queue-6.6/xfrm-xfrm_alloc_spi-shouldn-t-use-0-as-spi.patch diff --git a/queue-5.10/bnxt_en-correct-offset-handling-for-ipv6-destination.patch b/queue-5.10/bnxt_en-correct-offset-handling-for-ipv6-destination.patch new file mode 100644 index 0000000000..66375ec13b --- /dev/null +++ b/queue-5.10/bnxt_en-correct-offset-handling-for-ipv6-destination.patch @@ -0,0 +1,43 @@ +From 107ea90348c89027249852375bed3cdb87e16ec8 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Sat, 20 Sep 2025 05:11:17 -0700 +Subject: bnxt_en: correct offset handling for IPv6 destination address + +From: Alok Tiwari + +[ 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 +Reviewed-by: Somnath Kotur +Link: https://patch.msgid.link/20250920121157.351921-1-alok.a.tiwari@oracle.com +Signed-off-by: Jakub Kicinski +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-5.10/can-hi311x-populate-ndo_change_mtu-to-prevent-buffer.patch b/queue-5.10/can-hi311x-populate-ndo_change_mtu-to-prevent-buffer.patch new file mode 100644 index 0000000000..b2bf97c32b --- /dev/null +++ b/queue-5.10/can-hi311x-populate-ndo_change_mtu-to-prevent-buffer.patch @@ -0,0 +1,85 @@ +From f31d83c30782f020f2fd481e5bd7db06fe7669a1 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 18 Sep 2025 18:00:25 +0900 +Subject: can: hi311x: populate ndo_change_mtu() to prevent buffer overflow + +From: Vincent Mailhol + +[ 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 +Link: https://patch.msgid.link/20250918-can-fix-mtu-v1-2-0d1cada9393b@kernel.org +Signed-off-by: Marc Kleine-Budde +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-5.10/can-mcba_usb-populate-ndo_change_mtu-to-prevent-buff.patch b/queue-5.10/can-mcba_usb-populate-ndo_change_mtu-to-prevent-buff.patch new file mode 100644 index 0000000000..266537cf23 --- /dev/null +++ b/queue-5.10/can-mcba_usb-populate-ndo_change_mtu-to-prevent-buff.patch @@ -0,0 +1,83 @@ +From 2d62cada090b6ebf087e7dae8d059161425534c4 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 18 Sep 2025 18:00:27 +0900 +Subject: can: mcba_usb: populate ndo_change_mtu() to prevent buffer overflow + +From: Vincent Mailhol + +[ 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 +Link: https://patch.msgid.link/20250918-can-fix-mtu-v1-4-0d1cada9393b@kernel.org +Signed-off-by: Marc Kleine-Budde +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-5.10/can-peak_usb-fix-shift-out-of-bounds-issue.patch b/queue-5.10/can-peak_usb-fix-shift-out-of-bounds-issue.patch new file mode 100644 index 0000000000..d92b71bcdf --- /dev/null +++ b/queue-5.10/can-peak_usb-fix-shift-out-of-bounds-issue.patch @@ -0,0 +1,44 @@ +From e1b9489eebec4d0199a647ffe6436396a017cdd2 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +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 + +[ 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 +Link: https://patch.msgid.link/20250918132413.30071-1-stephane.grosjean@free.fr +Reported-by: Marc Kleine-Budde +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 +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-5.10/can-sun4i_can-populate-ndo_change_mtu-to-prevent-buf.patch b/queue-5.10/can-sun4i_can-populate-ndo_change_mtu-to-prevent-buf.patch new file mode 100644 index 0000000000..9d955907a5 --- /dev/null +++ b/queue-5.10/can-sun4i_can-populate-ndo_change_mtu-to-prevent-buf.patch @@ -0,0 +1,85 @@ +From 64bba5f8706a0ee10d4ecb8b09e8059678cd3dbb Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 18 Sep 2025 18:00:26 +0900 +Subject: can: sun4i_can: populate ndo_change_mtu() to prevent buffer overflow + +From: Vincent Mailhol + +[ 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 +Link: https://patch.msgid.link/20250918-can-fix-mtu-v1-3-0d1cada9393b@kernel.org +Signed-off-by: Marc Kleine-Budde +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-5.10/nexthop-emit-a-notification-when-a-nexthop-is-added.patch b/queue-5.10/nexthop-emit-a-notification-when-a-nexthop-is-added.patch new file mode 100644 index 0000000000..ab20ffcaf5 --- /dev/null +++ b/queue-5.10/nexthop-emit-a-notification-when-a-nexthop-is-added.patch @@ -0,0 +1,69 @@ +From ca3d05f1e4f71ee8ab6ac588877dec27341abafb Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Wed, 4 Nov 2020 15:30:29 +0200 +Subject: nexthop: Emit a notification when a nexthop is added + +From: Ido Schimmel + +[ 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 +Signed-off-by: Jakub Kicinski +Stable-dep-of: 390b3a300d78 ("nexthop: Forbid FDB status change while nexthop is in a group") +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-5.10/nexthop-emit-a-notification-when-a-single-nexthop-is.patch b/queue-5.10/nexthop-emit-a-notification-when-a-single-nexthop-is.patch new file mode 100644 index 0000000000..c687c5ae93 --- /dev/null +++ b/queue-5.10/nexthop-emit-a-notification-when-a-single-nexthop-is.patch @@ -0,0 +1,55 @@ +From 82aa0ae2be4570cca2caa9cc54c25892be3626c2 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Wed, 4 Nov 2020 15:30:31 +0200 +Subject: nexthop: Emit a notification when a single nexthop is replaced + +From: Ido Schimmel + +[ 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 +Signed-off-by: Jakub Kicinski +Stable-dep-of: 390b3a300d78 ("nexthop: Forbid FDB status change while nexthop is in a group") +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-5.10/nexthop-forbid-fdb-status-change-while-nexthop-is-in.patch b/queue-5.10/nexthop-forbid-fdb-status-change-while-nexthop-is-in.patch new file mode 100644 index 0000000000..66ccfa75c5 --- /dev/null +++ b/queue-5.10/nexthop-forbid-fdb-status-change-while-nexthop-is-in.patch @@ -0,0 +1,100 @@ +From 3c0f619db603937bd9b9c12a8f81740bf837f0b3 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Sun, 21 Sep 2025 18:08:22 +0300 +Subject: nexthop: Forbid FDB status change while nexthop is in a group + +From: Ido Schimmel + +[ 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: + + 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 +Reviewed-by: David Ahern +Link: https://patch.msgid.link/20250921150824.149157-2-idosch@nvidia.com +Signed-off-by: Jakub Kicinski +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-5.10/nexthop-pass-extack-to-nexthop-notifier.patch b/queue-5.10/nexthop-pass-extack-to-nexthop-notifier.patch new file mode 100644 index 0000000000..fd450dda71 --- /dev/null +++ b/queue-5.10/nexthop-pass-extack-to-nexthop-notifier.patch @@ -0,0 +1,47 @@ +From da3fbdc18e8f91c7a6921dc9ed36f2d24b618d96 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Wed, 4 Nov 2020 15:30:24 +0200 +Subject: nexthop: Pass extack to nexthop notifier + +From: Ido Schimmel + +[ 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 +Reviewed-by: David Ahern +Signed-off-by: Jakub Kicinski +Stable-dep-of: 390b3a300d78 ("nexthop: Forbid FDB status change while nexthop is in a group") +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-5.10/rtnetlink-add-rtnh_f_trap-flag.patch b/queue-5.10/rtnetlink-add-rtnh_f_trap-flag.patch new file mode 100644 index 0000000000..3a42e19826 --- /dev/null +++ b/queue-5.10/rtnetlink-add-rtnh_f_trap-flag.patch @@ -0,0 +1,68 @@ +From 31c3545e25e708b38ba62d687a435a06adbc215f Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Wed, 4 Nov 2020 15:30:27 +0200 +Subject: rtnetlink: Add RTNH_F_TRAP flag + +From: Ido Schimmel + +[ 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 +Reviewed-by: David Ahern +Signed-off-by: Jakub Kicinski +Stable-dep-of: 390b3a300d78 ("nexthop: Forbid FDB status change while nexthop is in a group") +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-5.10/selftests-fib_nexthops-fix-creation-of-non-fdb-nexth.patch b/queue-5.10/selftests-fib_nexthops-fix-creation-of-non-fdb-nexth.patch new file mode 100644 index 0000000000..a84570bec0 --- /dev/null +++ b/queue-5.10/selftests-fib_nexthops-fix-creation-of-non-fdb-nexth.patch @@ -0,0 +1,149 @@ +From f9f2a3d5c30338e2e2101a8b11b865dddb53933e Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Sun, 21 Sep 2025 18:08:23 +0300 +Subject: selftests: fib_nexthops: Fix creation of non-FDB nexthops + +From: Ido Schimmel + +[ 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 +Reviewed-by: David Ahern +Link: https://patch.msgid.link/20250921150824.149157-3-idosch@nvidia.com +Signed-off-by: Jakub Kicinski +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-5.10/series b/queue-5.10/series index e796710456..0cff4f05be 100644 --- a/queue-5.10/series +++ b/queue-5.10/series @@ -94,3 +94,14 @@ ib-mlx5-fix-obj_type-mismatch-for-srq-event-subscrip.patch 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 diff --git a/queue-5.15/bnxt_en-correct-offset-handling-for-ipv6-destination.patch b/queue-5.15/bnxt_en-correct-offset-handling-for-ipv6-destination.patch new file mode 100644 index 0000000000..e8eb54e099 --- /dev/null +++ b/queue-5.15/bnxt_en-correct-offset-handling-for-ipv6-destination.patch @@ -0,0 +1,43 @@ +From 5001ea4e3eb3f09622af1a72caaccf53324679ac Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Sat, 20 Sep 2025 05:11:17 -0700 +Subject: bnxt_en: correct offset handling for IPv6 destination address + +From: Alok Tiwari + +[ 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 +Reviewed-by: Somnath Kotur +Link: https://patch.msgid.link/20250920121157.351921-1-alok.a.tiwari@oracle.com +Signed-off-by: Jakub Kicinski +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-5.15/can-bittiming-allow-tdc-v-o-to-be-zero-and-add-can_t.patch b/queue-5.15/can-bittiming-allow-tdc-v-o-to-be-zero-and-add-can_t.patch new file mode 100644 index 0000000000..346ba1357b --- /dev/null +++ b/queue-5.15/can-bittiming-allow-tdc-v-o-to-be-zero-and-add-can_t.patch @@ -0,0 +1,263 @@ +From d85d73b661080954d3cfd3e3797df73b28a34914 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +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 + +[ 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 +Signed-off-by: Marc Kleine-Budde +Stable-dep-of: 38c0abad45b1 ("can: etas_es58x: populate ndo_change_mtu() to prevent buffer overflow") +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-5.15/can-bittiming-replace-can-units-with-the-generic-one.patch b/queue-5.15/can-bittiming-replace-can-units-with-the-generic-one.patch new file mode 100644 index 0000000000..0bc98060b7 --- /dev/null +++ b/queue-5.15/can-bittiming-replace-can-units-with-the-generic-one.patch @@ -0,0 +1,136 @@ +From faac6dc5ddf9dd04b32c70ec983f1dcb3d89905b Mon Sep 17 00:00:00 2001 +From: Sasha Levin +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 + +[ 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 +Suggested-by: Oliver Hartkopp +Signed-off-by: Vincent Mailhol +Signed-off-by: Marc Kleine-Budde +Stable-dep-of: 38c0abad45b1 ("can: etas_es58x: populate ndo_change_mtu() to prevent buffer overflow") +Signed-off-by: Sasha Levin +--- + 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 + */ + ++#include + #include + + #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 ++#include + #include + + #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 ++#include + #include + + #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 + diff --git a/queue-5.15/can-dev-add-generic-function-can_eth_ioctl_hwts.patch b/queue-5.15/can-dev-add-generic-function-can_eth_ioctl_hwts.patch new file mode 100644 index 0000000000..e91e62e437 --- /dev/null +++ b/queue-5.15/can-dev-add-generic-function-can_eth_ioctl_hwts.patch @@ -0,0 +1,87 @@ +From 087fff186c857fba487f83de51ca611ee2b78519 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Wed, 27 Jul 2022 19:16:35 +0900 +Subject: can: dev: add generic function can_eth_ioctl_hwts() + +From: Vincent Mailhol + +[ 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 +Link: https://lore.kernel.org/all/20220727101641.198847-9-mailhol.vincent@wanadoo.fr +Signed-off-by: Marc Kleine-Budde +Stable-dep-of: 38c0abad45b1 ("can: etas_es58x: populate ndo_change_mtu() to prevent buffer overflow") +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-5.15/can-dev-add-generic-function-can_ethtool_op_get_ts_i.patch b/queue-5.15/can-dev-add-generic-function-can_ethtool_op_get_ts_i.patch new file mode 100644 index 0000000000..faf8ba72b7 --- /dev/null +++ b/queue-5.15/can-dev-add-generic-function-can_ethtool_op_get_ts_i.patch @@ -0,0 +1,92 @@ +From fb81ee434de7081d777fa44d3c8f5c08090825fc Mon Sep 17 00:00:00 2001 +From: Sasha Levin +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 + +[ 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 +Link: https://lore.kernel.org/all/20220727101641.198847-8-mailhol.vincent@wanadoo.fr +Signed-off-by: Marc Kleine-Budde +Stable-dep-of: 38c0abad45b1 ("can: etas_es58x: populate ndo_change_mtu() to prevent buffer overflow") +Signed-off-by: Sasha Levin +--- + 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 + #include + #include ++#include + #include + + /* +@@ -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 + diff --git a/queue-5.15/can-etas_es58x-advertise-timestamping-capabilities-a.patch b/queue-5.15/can-etas_es58x-advertise-timestamping-capabilities-a.patch new file mode 100644 index 0000000000..5a04c26bc4 --- /dev/null +++ b/queue-5.15/can-etas_es58x-advertise-timestamping-capabilities-a.patch @@ -0,0 +1,75 @@ +From db448bfaeee1343f1a5ff833c3796fa5a8a712e1 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Wed, 27 Jul 2022 19:16:37 +0900 +Subject: can: etas_es58x: advertise timestamping capabilities and add ioctl + support + +From: Vincent Mailhol + +[ 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 +Link: https://lore.kernel.org/all/20220727101641.198847-11-mailhol.vincent@wanadoo.fr +Signed-off-by: Marc Kleine-Budde +Stable-dep-of: 38c0abad45b1 ("can: etas_es58x: populate ndo_change_mtu() to prevent buffer overflow") +Signed-off-by: Sasha Levin +--- + 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 + */ + ++#include + #include + #include + #include +@@ -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 + diff --git a/queue-5.15/can-etas_es58x-populate-ndo_change_mtu-to-prevent-bu.patch b/queue-5.15/can-etas_es58x-populate-ndo_change_mtu-to-prevent-bu.patch new file mode 100644 index 0000000000..b2df29d467 --- /dev/null +++ b/queue-5.15/can-etas_es58x-populate-ndo_change_mtu-to-prevent-bu.patch @@ -0,0 +1,98 @@ +From 7f4fd3205bfb912bc0c9ebe5493ed38aa68857d3 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 18 Sep 2025 18:00:24 +0900 +Subject: can: etas_es58x: populate ndo_change_mtu() to prevent buffer overflow + +From: Vincent Mailhol + +[ 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 +Link: https://patch.msgid.link/20250918-can-fix-mtu-v1-1-0d1cada9393b@kernel.org +Signed-off-by: Marc Kleine-Budde +Signed-off-by: Sasha Levin +--- + 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 ++ * Copyright (c) 2020-2025 Vincent Mailhol + */ + + #include +@@ -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 + diff --git a/queue-5.15/can-etas_es58x-sort-the-includes-by-alphabetic-order.patch b/queue-5.15/can-etas_es58x-sort-the-includes-by-alphabetic-order.patch new file mode 100644 index 0000000000..02b67a16ed --- /dev/null +++ b/queue-5.15/can-etas_es58x-sort-the-includes-by-alphabetic-order.patch @@ -0,0 +1,115 @@ +From ca6f40b05e83fcaa8d4f9538c652a68874728137 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Sun, 27 Nov 2022 01:05:25 +0900 +Subject: can: etas_es58x: sort the includes by alphabetic order + +From: Vincent Mailhol + +[ 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 +Link: https://lore.kernel.org/all/20221126160525.87036-1-mailhol.vincent@wanadoo.fr +Signed-off-by: Marc Kleine-Budde +Stable-dep-of: 38c0abad45b1 ("can: etas_es58x: populate ndo_change_mtu() to prevent buffer overflow") +Signed-off-by: Sasha Levin +--- + 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 ++ * Copyright (c) 2020-2022 Vincent Mailhol + */ + ++#include + #include + #include +-#include + + #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 ++ * Copyright (c) 2020-2022 Vincent Mailhol + */ + ++#include ++#include + #include + #include + #include + #include +-#include +-#include + + #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 ++ * Copyright (c) 2020-2022 Vincent Mailhol + */ + + #ifndef __ES58X_COMMON_H__ + #define __ES58X_COMMON_H__ + +-#include +-#include +-#include + #include + #include ++#include ++#include ++#include + + #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 ++ * Copyright (c) 2020-2022 Vincent Mailhol + */ + ++#include + #include + #include +-#include + + #include "es58x_core.h" + #include "es58x_fd.h" +-- +2.51.0 + diff --git a/queue-5.15/can-hi311x-populate-ndo_change_mtu-to-prevent-buffer.patch b/queue-5.15/can-hi311x-populate-ndo_change_mtu-to-prevent-buffer.patch new file mode 100644 index 0000000000..88d6a385cb --- /dev/null +++ b/queue-5.15/can-hi311x-populate-ndo_change_mtu-to-prevent-buffer.patch @@ -0,0 +1,85 @@ +From dcd40c91e5fd1f67a86ed612b03b51ee91b58dbd Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 18 Sep 2025 18:00:25 +0900 +Subject: can: hi311x: populate ndo_change_mtu() to prevent buffer overflow + +From: Vincent Mailhol + +[ 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 +Link: https://patch.msgid.link/20250918-can-fix-mtu-v1-2-0d1cada9393b@kernel.org +Signed-off-by: Marc Kleine-Budde +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-5.15/can-mcba_usb-populate-ndo_change_mtu-to-prevent-buff.patch b/queue-5.15/can-mcba_usb-populate-ndo_change_mtu-to-prevent-buff.patch new file mode 100644 index 0000000000..100877381a --- /dev/null +++ b/queue-5.15/can-mcba_usb-populate-ndo_change_mtu-to-prevent-buff.patch @@ -0,0 +1,83 @@ +From 424c805717cc85f63de9184eeccc5f825ebda262 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 18 Sep 2025 18:00:27 +0900 +Subject: can: mcba_usb: populate ndo_change_mtu() to prevent buffer overflow + +From: Vincent Mailhol + +[ 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 +Link: https://patch.msgid.link/20250918-can-fix-mtu-v1-4-0d1cada9393b@kernel.org +Signed-off-by: Marc Kleine-Budde +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-5.15/can-peak_usb-fix-shift-out-of-bounds-issue.patch b/queue-5.15/can-peak_usb-fix-shift-out-of-bounds-issue.patch new file mode 100644 index 0000000000..4a7abfd4c6 --- /dev/null +++ b/queue-5.15/can-peak_usb-fix-shift-out-of-bounds-issue.patch @@ -0,0 +1,44 @@ +From 17b80caa7c883efe8dc8c40bd8478043b9f5aa10 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +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 + +[ 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 +Link: https://patch.msgid.link/20250918132413.30071-1-stephane.grosjean@free.fr +Reported-by: Marc Kleine-Budde +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 +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-5.15/can-sun4i_can-populate-ndo_change_mtu-to-prevent-buf.patch b/queue-5.15/can-sun4i_can-populate-ndo_change_mtu-to-prevent-buf.patch new file mode 100644 index 0000000000..6f10f89337 --- /dev/null +++ b/queue-5.15/can-sun4i_can-populate-ndo_change_mtu-to-prevent-buf.patch @@ -0,0 +1,85 @@ +From e371607d23494b8016c2fec497d57c0cde3e83f8 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 18 Sep 2025 18:00:26 +0900 +Subject: can: sun4i_can: populate ndo_change_mtu() to prevent buffer overflow + +From: Vincent Mailhol + +[ 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 +Link: https://patch.msgid.link/20250918-can-fix-mtu-v1-3-0d1cada9393b@kernel.org +Signed-off-by: Marc Kleine-Budde +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-5.15/ethernet-rvu-af-remove-slash-from-the-driver-name.patch b/queue-5.15/ethernet-rvu-af-remove-slash-from-the-driver-name.patch new file mode 100644 index 0000000000..0c9e151dbb --- /dev/null +++ b/queue-5.15/ethernet-rvu-af-remove-slash-from-the-driver-name.patch @@ -0,0 +1,41 @@ +From 4af17035846a45642e3b180f8c0a348611cd1138 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 18 Sep 2025 17:21:07 +0200 +Subject: ethernet: rvu-af: Remove slash from the driver name + +From: Petr Malat + +[ 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 +Reviewed-by: Simon Horman +Link: https://patch.msgid.link/20250918152106.1798299-1-oss@malat.biz +Signed-off-by: Jakub Kicinski +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-5.15/net-dsa-lantiq_gswip-do-also-enable-or-disable-cpu-p.patch b/queue-5.15/net-dsa-lantiq_gswip-do-also-enable-or-disable-cpu-p.patch new file mode 100644 index 0000000000..6da1073775 --- /dev/null +++ b/queue-5.15/net-dsa-lantiq_gswip-do-also-enable-or-disable-cpu-p.patch @@ -0,0 +1,84 @@ +From dd2fafb3adb419dcfb75a5da4cfd00dbc979989e Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Tue, 11 Jun 2024 15:54:28 +0200 +Subject: net: dsa: lantiq_gswip: do also enable or disable cpu port + +From: Martin Schiller + +[ 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 +Acked-by: Hauke Mehrtens +Reviewed-by: Vladimir Oltean +Link: https://lore.kernel.org/r/20240611135434.3180973-7-ms@dev.tdt.de +Signed-off-by: Jakub Kicinski +Stable-dep-of: c0054b25e2f1 ("net: dsa: lantiq_gswip: move gswip_add_single_port_br() call to port_setup()") +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-5.15/net-dsa-lantiq_gswip-move-gswip_add_single_port_br-c.patch b/queue-5.15/net-dsa-lantiq_gswip-move-gswip_add_single_port_br-c.patch new file mode 100644 index 0000000000..c540b30064 --- /dev/null +++ b/queue-5.15/net-dsa-lantiq_gswip-move-gswip_add_single_port_br-c.patch @@ -0,0 +1,97 @@ +From 0e301384564ba4d58e4cefaf7c6dc81c7dead8fc Mon Sep 17 00:00:00 2001 +From: Sasha Levin +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 + +[ 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 +Link: https://patch.msgid.link/20250918072142.894692-2-vladimir.oltean@nxp.com +Tested-by: Daniel Golle +Reviewed-by: Daniel Golle +Signed-off-by: Paolo Abeni +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-5.15/net-dsa-lantiq_gswip-suppress-einval-errors-for-brid.patch b/queue-5.15/net-dsa-lantiq_gswip-suppress-einval-errors-for-brid.patch new file mode 100644 index 0000000000..3e6528b158 --- /dev/null +++ b/queue-5.15/net-dsa-lantiq_gswip-suppress-einval-errors-for-brid.patch @@ -0,0 +1,69 @@ +From 61cea404401802b92ef2ba5366a712a2d6e8cda4 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +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 + +[ 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 +Closes: https://lore.kernel.org/netdev/aJfNMLNoi1VOsPrN@pidgin.makrotopia.org/ +Signed-off-by: Vladimir Oltean +Link: https://patch.msgid.link/20250918072142.894692-3-vladimir.oltean@nxp.com +Tested-by: Daniel Golle +Reviewed-by: Daniel Golle +Signed-off-by: Paolo Abeni +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-5.15/nexthop-forbid-fdb-status-change-while-nexthop-is-in.patch b/queue-5.15/nexthop-forbid-fdb-status-change-while-nexthop-is-in.patch new file mode 100644 index 0000000000..be776744e4 --- /dev/null +++ b/queue-5.15/nexthop-forbid-fdb-status-change-while-nexthop-is-in.patch @@ -0,0 +1,100 @@ +From f3cd7d4a16328bdf9b4964c5b2c19e4be28f423c Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Sun, 21 Sep 2025 18:08:22 +0300 +Subject: nexthop: Forbid FDB status change while nexthop is in a group + +From: Ido Schimmel + +[ 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: + + 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 +Reviewed-by: David Ahern +Link: https://patch.msgid.link/20250921150824.149157-2-idosch@nvidia.com +Signed-off-by: Jakub Kicinski +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-5.15/selftests-fib_nexthops-fix-creation-of-non-fdb-nexth.patch b/queue-5.15/selftests-fib_nexthops-fix-creation-of-non-fdb-nexth.patch new file mode 100644 index 0000000000..87be7abd89 --- /dev/null +++ b/queue-5.15/selftests-fib_nexthops-fix-creation-of-non-fdb-nexth.patch @@ -0,0 +1,149 @@ +From 7007eb87e400f5e9473683f6357662929d682eba Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Sun, 21 Sep 2025 18:08:23 +0300 +Subject: selftests: fib_nexthops: Fix creation of non-FDB nexthops + +From: Ido Schimmel + +[ 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 +Reviewed-by: David Ahern +Link: https://patch.msgid.link/20250921150824.149157-3-idosch@nvidia.com +Signed-off-by: Jakub Kicinski +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-5.15/series b/queue-5.15/series index e016c65efe..1a8e7690c1 100644 --- a/queue-5.15/series +++ b/queue-5.15/series @@ -114,3 +114,21 @@ 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 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 diff --git a/queue-5.4/can-hi311x-populate-ndo_change_mtu-to-prevent-buffer.patch b/queue-5.4/can-hi311x-populate-ndo_change_mtu-to-prevent-buffer.patch new file mode 100644 index 0000000000..4cf45eb9b6 --- /dev/null +++ b/queue-5.4/can-hi311x-populate-ndo_change_mtu-to-prevent-buffer.patch @@ -0,0 +1,85 @@ +From 22ebebbcfec33f7b6fa049632722a46b1548fe03 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 18 Sep 2025 18:00:25 +0900 +Subject: can: hi311x: populate ndo_change_mtu() to prevent buffer overflow + +From: Vincent Mailhol + +[ 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 +Link: https://patch.msgid.link/20250918-can-fix-mtu-v1-2-0d1cada9393b@kernel.org +Signed-off-by: Marc Kleine-Budde +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-5.4/can-mcba_usb-populate-ndo_change_mtu-to-prevent-buff.patch b/queue-5.4/can-mcba_usb-populate-ndo_change_mtu-to-prevent-buff.patch new file mode 100644 index 0000000000..da799bc726 --- /dev/null +++ b/queue-5.4/can-mcba_usb-populate-ndo_change_mtu-to-prevent-buff.patch @@ -0,0 +1,83 @@ +From c8607413694ee364107dab1460aef9a43aca7262 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 18 Sep 2025 18:00:27 +0900 +Subject: can: mcba_usb: populate ndo_change_mtu() to prevent buffer overflow + +From: Vincent Mailhol + +[ 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 +Link: https://patch.msgid.link/20250918-can-fix-mtu-v1-4-0d1cada9393b@kernel.org +Signed-off-by: Marc Kleine-Budde +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-5.4/can-peak_usb-fix-shift-out-of-bounds-issue.patch b/queue-5.4/can-peak_usb-fix-shift-out-of-bounds-issue.patch new file mode 100644 index 0000000000..240de96752 --- /dev/null +++ b/queue-5.4/can-peak_usb-fix-shift-out-of-bounds-issue.patch @@ -0,0 +1,44 @@ +From 9bcaf6bdfb517533b6c70454f99aa3abde808756 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +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 + +[ 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 +Link: https://patch.msgid.link/20250918132413.30071-1-stephane.grosjean@free.fr +Reported-by: Marc Kleine-Budde +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 +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-5.4/can-sun4i_can-populate-ndo_change_mtu-to-prevent-buf.patch b/queue-5.4/can-sun4i_can-populate-ndo_change_mtu-to-prevent-buf.patch new file mode 100644 index 0000000000..1eb5bba265 --- /dev/null +++ b/queue-5.4/can-sun4i_can-populate-ndo_change_mtu-to-prevent-buf.patch @@ -0,0 +1,85 @@ +From 6b90562c45df50158ab1da33878a6fff1aa2b794 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 18 Sep 2025 18:00:26 +0900 +Subject: can: sun4i_can: populate ndo_change_mtu() to prevent buffer overflow + +From: Vincent Mailhol + +[ 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 +Link: https://patch.msgid.link/20250918-can-fix-mtu-v1-3-0d1cada9393b@kernel.org +Signed-off-by: Marc Kleine-Budde +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-5.4/series b/queue-5.4/series index 5d972ce8f2..6984ee48a9 100644 --- a/queue-5.4/series +++ b/queue-5.4/series @@ -62,3 +62,7 @@ alsa-usb-audio-fix-build-with-config_input-n.patch 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 diff --git a/queue-6.1/bluetooth-hci_event-fix-uaf-in-hci_acl_create_conn_s.patch b/queue-6.1/bluetooth-hci_event-fix-uaf-in-hci_acl_create_conn_s.patch new file mode 100644 index 0000000000..188e0391ba --- /dev/null +++ b/queue-6.1/bluetooth-hci_event-fix-uaf-in-hci_acl_create_conn_s.patch @@ -0,0 +1,199 @@ +From 2fd2e764c7c8fc5b1e487203ba5bfd41922e998c Mon Sep 17 00:00:00 2001 +From: Sasha Levin +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 + +[ 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: + + 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 + + +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 +Signed-off-by: Luiz Augusto von Dentz +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-6.1/bluetooth-hci_sync-fix-hci_resume_advertising_sync.patch b/queue-6.1/bluetooth-hci_sync-fix-hci_resume_advertising_sync.patch new file mode 100644 index 0000000000..25e0a8b863 --- /dev/null +++ b/queue-6.1/bluetooth-hci_sync-fix-hci_resume_advertising_sync.patch @@ -0,0 +1,42 @@ +From bbce37af004ee9478b66fb32695533e239dedd96 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Fri, 5 Sep 2025 10:29:18 -0400 +Subject: Bluetooth: hci_sync: Fix hci_resume_advertising_sync + +From: Luiz Augusto von Dentz + +[ 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 +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-6.1/bnxt_en-correct-offset-handling-for-ipv6-destination.patch b/queue-6.1/bnxt_en-correct-offset-handling-for-ipv6-destination.patch new file mode 100644 index 0000000000..e14f08ccc4 --- /dev/null +++ b/queue-6.1/bnxt_en-correct-offset-handling-for-ipv6-destination.patch @@ -0,0 +1,43 @@ +From b8f6b9924181e51b90c01a8a4cc2925b16e7e098 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Sat, 20 Sep 2025 05:11:17 -0700 +Subject: bnxt_en: correct offset handling for IPv6 destination address + +From: Alok Tiwari + +[ 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 +Reviewed-by: Somnath Kotur +Link: https://patch.msgid.link/20250920121157.351921-1-alok.a.tiwari@oracle.com +Signed-off-by: Jakub Kicinski +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-6.1/can-etas_es58x-populate-ndo_change_mtu-to-prevent-bu.patch b/queue-6.1/can-etas_es58x-populate-ndo_change_mtu-to-prevent-bu.patch new file mode 100644 index 0000000000..73d107bab2 --- /dev/null +++ b/queue-6.1/can-etas_es58x-populate-ndo_change_mtu-to-prevent-bu.patch @@ -0,0 +1,98 @@ +From af28760a2bd3c0a0ae36947153007964faaa4c4b Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 18 Sep 2025 18:00:24 +0900 +Subject: can: etas_es58x: populate ndo_change_mtu() to prevent buffer overflow + +From: Vincent Mailhol + +[ 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 +Link: https://patch.msgid.link/20250918-can-fix-mtu-v1-1-0d1cada9393b@kernel.org +Signed-off-by: Marc Kleine-Budde +Signed-off-by: Sasha Levin +--- + 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 ++ * Copyright (c) 2020-2025 Vincent Mailhol + */ + + #include +@@ -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 + diff --git a/queue-6.1/can-etas_es58x-sort-the-includes-by-alphabetic-order.patch b/queue-6.1/can-etas_es58x-sort-the-includes-by-alphabetic-order.patch new file mode 100644 index 0000000000..4b01bd97a7 --- /dev/null +++ b/queue-6.1/can-etas_es58x-sort-the-includes-by-alphabetic-order.patch @@ -0,0 +1,115 @@ +From 467f8f397356ad7b6b4916400ef8af77cf678395 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Sun, 27 Nov 2022 01:05:25 +0900 +Subject: can: etas_es58x: sort the includes by alphabetic order + +From: Vincent Mailhol + +[ 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 +Link: https://lore.kernel.org/all/20221126160525.87036-1-mailhol.vincent@wanadoo.fr +Signed-off-by: Marc Kleine-Budde +Stable-dep-of: 38c0abad45b1 ("can: etas_es58x: populate ndo_change_mtu() to prevent buffer overflow") +Signed-off-by: Sasha Levin +--- + 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 ++ * Copyright (c) 2020-2022 Vincent Mailhol + */ + ++#include + #include + #include +-#include + + #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 ++ * Copyright (c) 2020-2022 Vincent Mailhol + */ + ++#include ++#include + #include + #include + #include + #include +-#include +-#include + + #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 ++ * Copyright (c) 2020-2022 Vincent Mailhol + */ + + #ifndef __ES58X_COMMON_H__ + #define __ES58X_COMMON_H__ + +-#include +-#include +-#include + #include + #include ++#include ++#include ++#include + + #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 ++ * Copyright (c) 2020-2022 Vincent Mailhol + */ + ++#include + #include + #include +-#include + + #include "es58x_core.h" + #include "es58x_fd.h" +-- +2.51.0 + diff --git a/queue-6.1/can-hi311x-populate-ndo_change_mtu-to-prevent-buffer.patch b/queue-6.1/can-hi311x-populate-ndo_change_mtu-to-prevent-buffer.patch new file mode 100644 index 0000000000..7fc88b2455 --- /dev/null +++ b/queue-6.1/can-hi311x-populate-ndo_change_mtu-to-prevent-buffer.patch @@ -0,0 +1,85 @@ +From 8c15656bf34d9126734798f02ea6efe6f5c72d33 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 18 Sep 2025 18:00:25 +0900 +Subject: can: hi311x: populate ndo_change_mtu() to prevent buffer overflow + +From: Vincent Mailhol + +[ 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 +Link: https://patch.msgid.link/20250918-can-fix-mtu-v1-2-0d1cada9393b@kernel.org +Signed-off-by: Marc Kleine-Budde +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-6.1/can-mcba_usb-populate-ndo_change_mtu-to-prevent-buff.patch b/queue-6.1/can-mcba_usb-populate-ndo_change_mtu-to-prevent-buff.patch new file mode 100644 index 0000000000..feac12c36d --- /dev/null +++ b/queue-6.1/can-mcba_usb-populate-ndo_change_mtu-to-prevent-buff.patch @@ -0,0 +1,83 @@ +From 60c20f5be63bbc5110046406eb1012c67b5255d5 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 18 Sep 2025 18:00:27 +0900 +Subject: can: mcba_usb: populate ndo_change_mtu() to prevent buffer overflow + +From: Vincent Mailhol + +[ 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 +Link: https://patch.msgid.link/20250918-can-fix-mtu-v1-4-0d1cada9393b@kernel.org +Signed-off-by: Marc Kleine-Budde +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-6.1/can-peak_usb-fix-shift-out-of-bounds-issue.patch b/queue-6.1/can-peak_usb-fix-shift-out-of-bounds-issue.patch new file mode 100644 index 0000000000..82aaa08b27 --- /dev/null +++ b/queue-6.1/can-peak_usb-fix-shift-out-of-bounds-issue.patch @@ -0,0 +1,44 @@ +From ad08e25df5dc9bb13ca97b9257af9d083f445afa Mon Sep 17 00:00:00 2001 +From: Sasha Levin +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 + +[ 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 +Link: https://patch.msgid.link/20250918132413.30071-1-stephane.grosjean@free.fr +Reported-by: Marc Kleine-Budde +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 +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-6.1/can-sun4i_can-populate-ndo_change_mtu-to-prevent-buf.patch b/queue-6.1/can-sun4i_can-populate-ndo_change_mtu-to-prevent-buf.patch new file mode 100644 index 0000000000..eaa7e89d30 --- /dev/null +++ b/queue-6.1/can-sun4i_can-populate-ndo_change_mtu-to-prevent-buf.patch @@ -0,0 +1,85 @@ +From 7f7d35e2de10e274da581bced68635968d6240d1 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 18 Sep 2025 18:00:26 +0900 +Subject: can: sun4i_can: populate ndo_change_mtu() to prevent buffer overflow + +From: Vincent Mailhol + +[ 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 +Link: https://patch.msgid.link/20250918-can-fix-mtu-v1-3-0d1cada9393b@kernel.org +Signed-off-by: Marc Kleine-Budde +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-6.1/ethernet-rvu-af-remove-slash-from-the-driver-name.patch b/queue-6.1/ethernet-rvu-af-remove-slash-from-the-driver-name.patch new file mode 100644 index 0000000000..65db1e7ea4 --- /dev/null +++ b/queue-6.1/ethernet-rvu-af-remove-slash-from-the-driver-name.patch @@ -0,0 +1,41 @@ +From cd194d6d842ae3a166d0b14f4758a8b8c4b7bed9 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 18 Sep 2025 17:21:07 +0200 +Subject: ethernet: rvu-af: Remove slash from the driver name + +From: Petr Malat + +[ 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 +Reviewed-by: Simon Horman +Link: https://patch.msgid.link/20250918152106.1798299-1-oss@malat.biz +Signed-off-by: Jakub Kicinski +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-6.1/net-dsa-lantiq_gswip-do-also-enable-or-disable-cpu-p.patch b/queue-6.1/net-dsa-lantiq_gswip-do-also-enable-or-disable-cpu-p.patch new file mode 100644 index 0000000000..561a8ac04d --- /dev/null +++ b/queue-6.1/net-dsa-lantiq_gswip-do-also-enable-or-disable-cpu-p.patch @@ -0,0 +1,84 @@ +From be2293ece965e1e88f545ba1da81ddd2e0ac182a Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Tue, 11 Jun 2024 15:54:28 +0200 +Subject: net: dsa: lantiq_gswip: do also enable or disable cpu port + +From: Martin Schiller + +[ 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 +Acked-by: Hauke Mehrtens +Reviewed-by: Vladimir Oltean +Link: https://lore.kernel.org/r/20240611135434.3180973-7-ms@dev.tdt.de +Signed-off-by: Jakub Kicinski +Stable-dep-of: c0054b25e2f1 ("net: dsa: lantiq_gswip: move gswip_add_single_port_br() call to port_setup()") +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-6.1/net-dsa-lantiq_gswip-move-gswip_add_single_port_br-c.patch b/queue-6.1/net-dsa-lantiq_gswip-move-gswip_add_single_port_br-c.patch new file mode 100644 index 0000000000..4e2aae1a64 --- /dev/null +++ b/queue-6.1/net-dsa-lantiq_gswip-move-gswip_add_single_port_br-c.patch @@ -0,0 +1,97 @@ +From 14441f1c039927c4cb9ef52fa29977ed1d2b34ab Mon Sep 17 00:00:00 2001 +From: Sasha Levin +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 + +[ 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 +Link: https://patch.msgid.link/20250918072142.894692-2-vladimir.oltean@nxp.com +Tested-by: Daniel Golle +Reviewed-by: Daniel Golle +Signed-off-by: Paolo Abeni +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-6.1/net-dsa-lantiq_gswip-suppress-einval-errors-for-brid.patch b/queue-6.1/net-dsa-lantiq_gswip-suppress-einval-errors-for-brid.patch new file mode 100644 index 0000000000..5e4b60ec7d --- /dev/null +++ b/queue-6.1/net-dsa-lantiq_gswip-suppress-einval-errors-for-brid.patch @@ -0,0 +1,69 @@ +From 3b77a20721f385d3acb5d189d2646087eb615f0b Mon Sep 17 00:00:00 2001 +From: Sasha Levin +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 + +[ 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 +Closes: https://lore.kernel.org/netdev/aJfNMLNoi1VOsPrN@pidgin.makrotopia.org/ +Signed-off-by: Vladimir Oltean +Link: https://patch.msgid.link/20250918072142.894692-3-vladimir.oltean@nxp.com +Tested-by: Daniel Golle +Reviewed-by: Daniel Golle +Signed-off-by: Paolo Abeni +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-6.1/nexthop-forbid-fdb-status-change-while-nexthop-is-in.patch b/queue-6.1/nexthop-forbid-fdb-status-change-while-nexthop-is-in.patch new file mode 100644 index 0000000000..40d5ba89bd --- /dev/null +++ b/queue-6.1/nexthop-forbid-fdb-status-change-while-nexthop-is-in.patch @@ -0,0 +1,100 @@ +From 6113c5ed958f34c0f65aec9dbd174de33428936e Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Sun, 21 Sep 2025 18:08:22 +0300 +Subject: nexthop: Forbid FDB status change while nexthop is in a group + +From: Ido Schimmel + +[ 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: + + 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 +Reviewed-by: David Ahern +Link: https://patch.msgid.link/20250921150824.149157-2-idosch@nvidia.com +Signed-off-by: Jakub Kicinski +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-6.1/octeontx2-pf-fix-potential-use-after-free-in-otx2_tc.patch b/queue-6.1/octeontx2-pf-fix-potential-use-after-free-in-otx2_tc.patch new file mode 100644 index 0000000000..317104563a --- /dev/null +++ b/queue-6.1/octeontx2-pf-fix-potential-use-after-free-in-otx2_tc.patch @@ -0,0 +1,47 @@ +From a865d5ca46dc08146c0a96d596d191fcd09ce490 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +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 + +[ 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 +Reviewed-by: Vadim Fedorenko +Link: https://patch.msgid.link/aNKCL1jKwK8GRJHh@stanley.mountain +Signed-off-by: Paolo Abeni +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-6.1/selftests-fib_nexthops-fix-creation-of-non-fdb-nexth.patch b/queue-6.1/selftests-fib_nexthops-fix-creation-of-non-fdb-nexth.patch new file mode 100644 index 0000000000..135b17973e --- /dev/null +++ b/queue-6.1/selftests-fib_nexthops-fix-creation-of-non-fdb-nexth.patch @@ -0,0 +1,149 @@ +From 3784c94c702ee5d791758756cec6d6bff5d47b6d Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Sun, 21 Sep 2025 18:08:23 +0300 +Subject: selftests: fib_nexthops: Fix creation of non-FDB nexthops + +From: Ido Schimmel + +[ 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 +Reviewed-by: David Ahern +Link: https://patch.msgid.link/20250921150824.149157-3-idosch@nvidia.com +Signed-off-by: Jakub Kicinski +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-6.1/series b/queue-6.1/series index cf5fd9bec0..8ed9aa9e7b 100644 --- a/queue-6.1/series +++ b/queue-6.1/series @@ -25,3 +25,19 @@ cpufreq-initialize-cpufreq-based-invariance-before-s.patch 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 diff --git a/queue-6.12/bluetooth-hci_event-fix-uaf-in-hci_acl_create_conn_s.patch b/queue-6.12/bluetooth-hci_event-fix-uaf-in-hci_acl_create_conn_s.patch new file mode 100644 index 0000000000..4c9630eaa9 --- /dev/null +++ b/queue-6.12/bluetooth-hci_event-fix-uaf-in-hci_acl_create_conn_s.patch @@ -0,0 +1,199 @@ +From 69d376ca92d6f8fe5b6e56e96ec9d66d03bbff01 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +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 + +[ 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: + + 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 + + +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 +Signed-off-by: Luiz Augusto von Dentz +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-6.12/bluetooth-hci_sync-fix-hci_resume_advertising_sync.patch b/queue-6.12/bluetooth-hci_sync-fix-hci_resume_advertising_sync.patch new file mode 100644 index 0000000000..6a8b58f538 --- /dev/null +++ b/queue-6.12/bluetooth-hci_sync-fix-hci_resume_advertising_sync.patch @@ -0,0 +1,42 @@ +From 7f0ad8c4c294f19390b56ea2bc6d3eecdcde3715 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Fri, 5 Sep 2025 10:29:18 -0400 +Subject: Bluetooth: hci_sync: Fix hci_resume_advertising_sync + +From: Luiz Augusto von Dentz + +[ 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 +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-6.12/bnxt_en-correct-offset-handling-for-ipv6-destination.patch b/queue-6.12/bnxt_en-correct-offset-handling-for-ipv6-destination.patch new file mode 100644 index 0000000000..a77af23d5d --- /dev/null +++ b/queue-6.12/bnxt_en-correct-offset-handling-for-ipv6-destination.patch @@ -0,0 +1,43 @@ +From 345d4a67afc7c44edbf59e54d13983ca493f0761 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Sat, 20 Sep 2025 05:11:17 -0700 +Subject: bnxt_en: correct offset handling for IPv6 destination address + +From: Alok Tiwari + +[ 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 +Reviewed-by: Somnath Kotur +Link: https://patch.msgid.link/20250920121157.351921-1-alok.a.tiwari@oracle.com +Signed-off-by: Jakub Kicinski +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-6.12/can-etas_es58x-populate-ndo_change_mtu-to-prevent-bu.patch b/queue-6.12/can-etas_es58x-populate-ndo_change_mtu-to-prevent-bu.patch new file mode 100644 index 0000000000..034b5ed228 --- /dev/null +++ b/queue-6.12/can-etas_es58x-populate-ndo_change_mtu-to-prevent-bu.patch @@ -0,0 +1,98 @@ +From a4b3f0773485ffc88d71da04f33de53eca1180e1 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 18 Sep 2025 18:00:24 +0900 +Subject: can: etas_es58x: populate ndo_change_mtu() to prevent buffer overflow + +From: Vincent Mailhol + +[ 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 +Link: https://patch.msgid.link/20250918-can-fix-mtu-v1-1-0d1cada9393b@kernel.org +Signed-off-by: Marc Kleine-Budde +Signed-off-by: Sasha Levin +--- + 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 ++ * Copyright (c) 2020-2025 Vincent Mailhol + */ + + #include +@@ -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 + diff --git a/queue-6.12/can-hi311x-populate-ndo_change_mtu-to-prevent-buffer.patch b/queue-6.12/can-hi311x-populate-ndo_change_mtu-to-prevent-buffer.patch new file mode 100644 index 0000000000..64dd515e5d --- /dev/null +++ b/queue-6.12/can-hi311x-populate-ndo_change_mtu-to-prevent-buffer.patch @@ -0,0 +1,85 @@ +From f3576255319dc2cc29483e2d251d7a242c29671a Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 18 Sep 2025 18:00:25 +0900 +Subject: can: hi311x: populate ndo_change_mtu() to prevent buffer overflow + +From: Vincent Mailhol + +[ 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 +Link: https://patch.msgid.link/20250918-can-fix-mtu-v1-2-0d1cada9393b@kernel.org +Signed-off-by: Marc Kleine-Budde +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-6.12/can-mcba_usb-populate-ndo_change_mtu-to-prevent-buff.patch b/queue-6.12/can-mcba_usb-populate-ndo_change_mtu-to-prevent-buff.patch new file mode 100644 index 0000000000..28fd62729f --- /dev/null +++ b/queue-6.12/can-mcba_usb-populate-ndo_change_mtu-to-prevent-buff.patch @@ -0,0 +1,83 @@ +From 21d8defca18e22b01765ffa92b9a17bad88f82f7 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 18 Sep 2025 18:00:27 +0900 +Subject: can: mcba_usb: populate ndo_change_mtu() to prevent buffer overflow + +From: Vincent Mailhol + +[ 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 +Link: https://patch.msgid.link/20250918-can-fix-mtu-v1-4-0d1cada9393b@kernel.org +Signed-off-by: Marc Kleine-Budde +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-6.12/can-peak_usb-fix-shift-out-of-bounds-issue.patch b/queue-6.12/can-peak_usb-fix-shift-out-of-bounds-issue.patch new file mode 100644 index 0000000000..72ba5b2569 --- /dev/null +++ b/queue-6.12/can-peak_usb-fix-shift-out-of-bounds-issue.patch @@ -0,0 +1,44 @@ +From f14b2e4414669bfe93f1699535857ddef1fc75ef Mon Sep 17 00:00:00 2001 +From: Sasha Levin +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 + +[ 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 +Link: https://patch.msgid.link/20250918132413.30071-1-stephane.grosjean@free.fr +Reported-by: Marc Kleine-Budde +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 +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-6.12/can-sun4i_can-populate-ndo_change_mtu-to-prevent-buf.patch b/queue-6.12/can-sun4i_can-populate-ndo_change_mtu-to-prevent-buf.patch new file mode 100644 index 0000000000..0c6506bfe2 --- /dev/null +++ b/queue-6.12/can-sun4i_can-populate-ndo_change_mtu-to-prevent-buf.patch @@ -0,0 +1,85 @@ +From db5168e12436386af699ab1139e3ea3bfe114a82 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 18 Sep 2025 18:00:26 +0900 +Subject: can: sun4i_can: populate ndo_change_mtu() to prevent buffer overflow + +From: Vincent Mailhol + +[ 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 +Link: https://patch.msgid.link/20250918-can-fix-mtu-v1-3-0d1cada9393b@kernel.org +Signed-off-by: Marc Kleine-Budde +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-6.12/ethernet-rvu-af-remove-slash-from-the-driver-name.patch b/queue-6.12/ethernet-rvu-af-remove-slash-from-the-driver-name.patch new file mode 100644 index 0000000000..71262effdc --- /dev/null +++ b/queue-6.12/ethernet-rvu-af-remove-slash-from-the-driver-name.patch @@ -0,0 +1,41 @@ +From 569cef8e5c3bcbb5a06716dce4267af12bacfdcf Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 18 Sep 2025 17:21:07 +0200 +Subject: ethernet: rvu-af: Remove slash from the driver name + +From: Petr Malat + +[ 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 +Reviewed-by: Simon Horman +Link: https://patch.msgid.link/20250918152106.1798299-1-oss@malat.biz +Signed-off-by: Jakub Kicinski +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-6.12/mm-folio_may_be_lru_cached-unless-folio_test_large.patch b/queue-6.12/mm-folio_may_be_lru_cached-unless-folio_test_large.patch new file mode 100644 index 0000000000..f75684627e --- /dev/null +++ b/queue-6.12/mm-folio_may_be_lru_cached-unless-folio_test_large.patch @@ -0,0 +1,150 @@ +From 661428c0ce427b8b1a1de386e3ff3d18967e94bb Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Mon, 8 Sep 2025 15:23:15 -0700 +Subject: mm: folio_may_be_lru_cached() unless folio_test_large() + +From: Hugh Dickins + +[ 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 +Suggested-by: David Hildenbrand +Acked-by: David Hildenbrand +Cc: "Aneesh Kumar K.V" +Cc: Axel Rasmussen +Cc: Chris Li +Cc: Christoph Hellwig +Cc: Jason Gunthorpe +Cc: Johannes Weiner +Cc: John Hubbard +Cc: Keir Fraser +Cc: Konstantin Khlebnikov +Cc: Li Zhe +Cc: Matthew Wilcox (Oracle) +Cc: Peter Xu +Cc: Rik van Riel +Cc: Shivank Garg +Cc: Vlastimil Babka +Cc: Wei Xu +Cc: Will Deacon +Cc: yangge +Cc: Yuanchu Xie +Cc: Yu Zhao +Cc: +Signed-off-by: Andrew Morton +[ Clean cherry-pick now into this tree ] +Signed-off-by: Hugh Dickins +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-6.12/mm-gup-local-lru_add_drain-to-avoid-lru_add_drain_al.patch b/queue-6.12/mm-gup-local-lru_add_drain-to-avoid-lru_add_drain_al.patch new file mode 100644 index 0000000000..7fe47d9a42 --- /dev/null +++ b/queue-6.12/mm-gup-local-lru_add_drain-to-avoid-lru_add_drain_al.patch @@ -0,0 +1,89 @@ +From ece92a6bbb4712c913d932af786546450f485247 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +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 + +[ 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 +Acked-by: David Hildenbrand +Cc: "Aneesh Kumar K.V" +Cc: Axel Rasmussen +Cc: Chris Li +Cc: Christoph Hellwig +Cc: Jason Gunthorpe +Cc: Johannes Weiner +Cc: John Hubbard +Cc: Keir Fraser +Cc: Konstantin Khlebnikov +Cc: Li Zhe +Cc: Matthew Wilcox (Oracle) +Cc: Peter Xu +Cc: Rik van Riel +Cc: Shivank Garg +Cc: Vlastimil Babka +Cc: Wei Xu +Cc: Will Deacon +Cc: yangge +Cc: Yuanchu Xie +Cc: Yu Zhao +Cc: +Signed-off-by: Andrew Morton +[ Clean cherry-pick now into this tree ] +Signed-off-by: Hugh Dickins +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-6.12/mm-revert-mm-gup-clear-the-lru-flag-of-a-page-before.patch b/queue-6.12/mm-revert-mm-gup-clear-the-lru-flag-of-a-page-before.patch new file mode 100644 index 0000000000..49a27b7211 --- /dev/null +++ b/queue-6.12/mm-revert-mm-gup-clear-the-lru-flag-of-a-page-before.patch @@ -0,0 +1,203 @@ +From b78af0a74f449bbfcd16afbdfb9766fed548f23d Mon Sep 17 00:00:00 2001 +From: Sasha Levin +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 + +[ 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 +Acked-by: David Hildenbrand +Cc: "Aneesh Kumar K.V" +Cc: Axel Rasmussen +Cc: Chris Li +Cc: Christoph Hellwig +Cc: Jason Gunthorpe +Cc: Johannes Weiner +Cc: John Hubbard +Cc: Keir Fraser +Cc: Konstantin Khlebnikov +Cc: Li Zhe +Cc: Matthew Wilcox (Oracle) +Cc: Peter Xu +Cc: Rik van Riel +Cc: Shivank Garg +Cc: Vlastimil Babka +Cc: Wei Xu +Cc: Will Deacon +Cc: yangge +Cc: Yuanchu Xie +Cc: Yu Zhao +Cc: +Signed-off-by: Andrew Morton +[ Resolved conflicts in applying the revert to this tree ] +Signed-off-by: Hugh Dickins +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-6.12/net-allow-alloc_skb_with_frags-to-use-max_skb_frags.patch b/queue-6.12/net-allow-alloc_skb_with_frags-to-use-max_skb_frags.patch new file mode 100644 index 0000000000..959060ee9b --- /dev/null +++ b/queue-6.12/net-allow-alloc_skb_with_frags-to-use-max_skb_frags.patch @@ -0,0 +1,47 @@ +From 84e91666c16616f8b5cf0eb55483936ec225da07 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Mon, 22 Sep 2025 15:19:57 -0400 +Subject: net: allow alloc_skb_with_frags() to use MAX_SKB_FRAGS + +From: Jason Baron + +[ 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 +Reviewed-by: Eric Dumazet +Link: https://patch.msgid.link/20250922191957.2855612-1-jbaron@akamai.com +Signed-off-by: Jakub Kicinski +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-6.12/net-dsa-lantiq_gswip-move-gswip_add_single_port_br-c.patch b/queue-6.12/net-dsa-lantiq_gswip-move-gswip_add_single_port_br-c.patch new file mode 100644 index 0000000000..af1e86f9f7 --- /dev/null +++ b/queue-6.12/net-dsa-lantiq_gswip-move-gswip_add_single_port_br-c.patch @@ -0,0 +1,97 @@ +From 1a3ef6f203a2e4ed289c86b6f2fb7ce85868e01e Mon Sep 17 00:00:00 2001 +From: Sasha Levin +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 + +[ 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 +Link: https://patch.msgid.link/20250918072142.894692-2-vladimir.oltean@nxp.com +Tested-by: Daniel Golle +Reviewed-by: Daniel Golle +Signed-off-by: Paolo Abeni +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-6.12/net-dsa-lantiq_gswip-suppress-einval-errors-for-brid.patch b/queue-6.12/net-dsa-lantiq_gswip-suppress-einval-errors-for-brid.patch new file mode 100644 index 0000000000..3afb9ba19e --- /dev/null +++ b/queue-6.12/net-dsa-lantiq_gswip-suppress-einval-errors-for-brid.patch @@ -0,0 +1,69 @@ +From 42c738b785be79cde81909bdd4338f2c72179f13 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +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 + +[ 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 +Closes: https://lore.kernel.org/netdev/aJfNMLNoi1VOsPrN@pidgin.makrotopia.org/ +Signed-off-by: Vladimir Oltean +Link: https://patch.msgid.link/20250918072142.894692-3-vladimir.oltean@nxp.com +Tested-by: Daniel Golle +Reviewed-by: Daniel Golle +Signed-off-by: Paolo Abeni +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-6.12/net-smc-fix-warning-in-smc_rx_splice-when-calling-ge.patch b/queue-6.12/net-smc-fix-warning-in-smc_rx_splice-when-calling-ge.patch new file mode 100644 index 0000000000..85ccd439f8 --- /dev/null +++ b/queue-6.12/net-smc-fix-warning-in-smc_rx_splice-when-calling-ge.patch @@ -0,0 +1,107 @@ +From 10a00703e836cb9b62db85ebdb834a4a93ccab65 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +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 + +[ 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 +Signed-off-by: Sidraya Jayagond +Link: https://patch.msgid.link/20250917184220.801066-1-sidraya@linux.ibm.com +Signed-off-by: Jakub Kicinski +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-6.12/net-tun-update-napi-skb-after-xdp-process.patch b/queue-6.12/net-tun-update-napi-skb-after-xdp-process.patch new file mode 100644 index 0000000000..e9620d9a5a --- /dev/null +++ b/queue-6.12/net-tun-update-napi-skb-after-xdp-process.patch @@ -0,0 +1,113 @@ +From fcd92562db4890d3507c441524034cfebae713fb Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Wed, 17 Sep 2025 19:39:19 +0800 +Subject: net: tun: Update napi->skb after XDP process + +From: Wang Liang + +[ 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: + + 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 + + + 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 +Reviewed-by: Willem de Bruijn +Link: https://patch.msgid.link/20250917113919.3991267-1-wangliang74@huawei.com +Signed-off-by: Jakub Kicinski +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-6.12/nexthop-forbid-fdb-status-change-while-nexthop-is-in.patch b/queue-6.12/nexthop-forbid-fdb-status-change-while-nexthop-is-in.patch new file mode 100644 index 0000000000..c056dab289 --- /dev/null +++ b/queue-6.12/nexthop-forbid-fdb-status-change-while-nexthop-is-in.patch @@ -0,0 +1,100 @@ +From dc8a0270bd68654b34d73a485ad803a2f367c1b4 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Sun, 21 Sep 2025 18:08:22 +0300 +Subject: nexthop: Forbid FDB status change while nexthop is in a group + +From: Ido Schimmel + +[ 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: + + 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 +Reviewed-by: David Ahern +Link: https://patch.msgid.link/20250921150824.149157-2-idosch@nvidia.com +Signed-off-by: Jakub Kicinski +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-6.12/octeontx2-pf-fix-potential-use-after-free-in-otx2_tc.patch b/queue-6.12/octeontx2-pf-fix-potential-use-after-free-in-otx2_tc.patch new file mode 100644 index 0000000000..35dc8a793b --- /dev/null +++ b/queue-6.12/octeontx2-pf-fix-potential-use-after-free-in-otx2_tc.patch @@ -0,0 +1,47 @@ +From c6c67f9d5cf852fdd464dc1b974e66a8056cc2d3 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +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 + +[ 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 +Reviewed-by: Vadim Fedorenko +Link: https://patch.msgid.link/aNKCL1jKwK8GRJHh@stanley.mountain +Signed-off-by: Paolo Abeni +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-6.12/selftests-fib_nexthops-fix-creation-of-non-fdb-nexth.patch b/queue-6.12/selftests-fib_nexthops-fix-creation-of-non-fdb-nexth.patch new file mode 100644 index 0000000000..40b16f0bcc --- /dev/null +++ b/queue-6.12/selftests-fib_nexthops-fix-creation-of-non-fdb-nexth.patch @@ -0,0 +1,149 @@ +From 6a82371a116c64cb2ff68030b4aa3dd93d8049b7 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Sun, 21 Sep 2025 18:08:23 +0300 +Subject: selftests: fib_nexthops: Fix creation of non-FDB nexthops + +From: Ido Schimmel + +[ 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 +Reviewed-by: David Ahern +Link: https://patch.msgid.link/20250921150824.149157-3-idosch@nvidia.com +Signed-off-by: Jakub Kicinski +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-6.12/series b/queue-6.12/series index a00ff30610..02db66d5e9 100644 --- a/queue-6.12/series +++ b/queue-6.12/series @@ -36,3 +36,25 @@ btrfs-don-t-allow-adding-block-device-of-less-than-1.patch 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 diff --git a/queue-6.12/vhost-take-a-reference-on-the-task-in-struct-vhost_t.patch b/queue-6.12/vhost-take-a-reference-on-the-task-in-struct-vhost_t.patch new file mode 100644 index 0000000000..a261420bcb --- /dev/null +++ b/queue-6.12/vhost-take-a-reference-on-the-task-in-struct-vhost_t.patch @@ -0,0 +1,57 @@ +From 328e23e36c2a38619af38d11ef2c764daff74018 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +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 + +[ 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 +Closes: https://lore.kernel.org/all/aKkLEtoDXKxAAWju@google.com/ +Signed-off-by: Sebastian Andrzej Siewior +Message-Id: <20250918181144.Ygo8BZ-R@linutronix.de> +Signed-off-by: Michael S. Tsirkin +Tested-by: Sean Christopherson +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-6.12/xfrm-xfrm_alloc_spi-shouldn-t-use-0-as-spi.patch b/queue-6.12/xfrm-xfrm_alloc_spi-shouldn-t-use-0-as-spi.patch new file mode 100644 index 0000000000..9e29e4b351 --- /dev/null +++ b/queue-6.12/xfrm-xfrm_alloc_spi-shouldn-t-use-0-as-spi.patch @@ -0,0 +1,52 @@ +From 5cb58e600b044801b11c92e37c76ca7879894501 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Fri, 29 Aug 2025 10:54:15 +0200 +Subject: xfrm: xfrm_alloc_spi shouldn't use 0 as SPI + +From: Sabrina Dubroca + +[ 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 +Reviewed-by: Simon Horman +Signed-off-by: Steffen Klassert +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-6.16/bluetooth-hci_event-fix-uaf-in-hci_acl_create_conn_s.patch b/queue-6.16/bluetooth-hci_event-fix-uaf-in-hci_acl_create_conn_s.patch new file mode 100644 index 0000000000..57b2f94794 --- /dev/null +++ b/queue-6.16/bluetooth-hci_event-fix-uaf-in-hci_acl_create_conn_s.patch @@ -0,0 +1,199 @@ +From 850f143e559c5372be6480dcb379eeaab0339e07 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +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 + +[ 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: + + 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 + + +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 +Signed-off-by: Luiz Augusto von Dentz +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-6.16/bluetooth-hci_event-fix-uaf-in-hci_conn_tx_dequeue.patch b/queue-6.16/bluetooth-hci_event-fix-uaf-in-hci_conn_tx_dequeue.patch new file mode 100644 index 0000000000..6e6b8cdb61 --- /dev/null +++ b/queue-6.16/bluetooth-hci_event-fix-uaf-in-hci_conn_tx_dequeue.patch @@ -0,0 +1,118 @@ +From 1e86283a5a47fc5f952038b743d7f331625815a5 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +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 + +[ 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: + + 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 + + +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 +Signed-off-by: Luiz Augusto von Dentz +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-6.16/bluetooth-hci_sync-fix-hci_resume_advertising_sync.patch b/queue-6.16/bluetooth-hci_sync-fix-hci_resume_advertising_sync.patch new file mode 100644 index 0000000000..fc0012de56 --- /dev/null +++ b/queue-6.16/bluetooth-hci_sync-fix-hci_resume_advertising_sync.patch @@ -0,0 +1,42 @@ +From 6c4fd30021a152fee4429a5be02936b620ebbe9b Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Fri, 5 Sep 2025 10:29:18 -0400 +Subject: Bluetooth: hci_sync: Fix hci_resume_advertising_sync + +From: Luiz Augusto von Dentz + +[ 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 +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-6.16/bluetooth-mgmt-fix-possible-uafs.patch b/queue-6.16/bluetooth-mgmt-fix-possible-uafs.patch new file mode 100644 index 0000000000..af42fd23d9 --- /dev/null +++ b/queue-6.16/bluetooth-mgmt-fix-possible-uafs.patch @@ -0,0 +1,775 @@ +From a9e0b5d32726bef20a40eebfdef20f44ffb57d7f Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Mon, 25 Aug 2025 10:03:07 -0400 +Subject: Bluetooth: MGMT: Fix possible UAFs + +From: Luiz Augusto von Dentz + +[ 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: + + 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 + + +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 +Signed-off-by: Luiz Augusto von Dentz +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-6.16/bnxt_en-correct-offset-handling-for-ipv6-destination.patch b/queue-6.16/bnxt_en-correct-offset-handling-for-ipv6-destination.patch new file mode 100644 index 0000000000..cc91a4a59d --- /dev/null +++ b/queue-6.16/bnxt_en-correct-offset-handling-for-ipv6-destination.patch @@ -0,0 +1,43 @@ +From 1a24d35cca6849cd87a14e21bc89175d1033b610 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Sat, 20 Sep 2025 05:11:17 -0700 +Subject: bnxt_en: correct offset handling for IPv6 destination address + +From: Alok Tiwari + +[ 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 +Reviewed-by: Somnath Kotur +Link: https://patch.msgid.link/20250920121157.351921-1-alok.a.tiwari@oracle.com +Signed-off-by: Jakub Kicinski +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-6.16/broadcom-fix-support-for-ptp_extts_request2-ioctl.patch b/queue-6.16/broadcom-fix-support-for-ptp_extts_request2-ioctl.patch new file mode 100644 index 0000000000..6d817348b0 --- /dev/null +++ b/queue-6.16/broadcom-fix-support-for-ptp_extts_request2-ioctl.patch @@ -0,0 +1,65 @@ +From 0a2e4690626c5005e0623e1a1f5e5dbd3b27f73d Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 18 Sep 2025 17:33:17 -0700 +Subject: broadcom: fix support for PTP_EXTTS_REQUEST2 ioctl + +From: Jacob Keller + +[ 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 +Fixes: 7c571ac57d9d ("net: ptp: introduce .supported_extts_flags to ptp_clock_info") +Signed-off-by: Jacob Keller +Reviewed-by: Vadim Fedorenko +Acked-by: Richard Cochran +Reviewed-by: Kory Maincent +Tested-by: James Clark +Link: https://patch.msgid.link/20250918-jk-fix-bcm-phy-supported-flags-v1-2-747b60407c9c@intel.com +Signed-off-by: Jakub Kicinski +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-6.16/broadcom-fix-support-for-ptp_perout_duty_cycle.patch b/queue-6.16/broadcom-fix-support-for-ptp_perout_duty_cycle.patch new file mode 100644 index 0000000000..6afe90c4e2 --- /dev/null +++ b/queue-6.16/broadcom-fix-support-for-ptp_perout_duty_cycle.patch @@ -0,0 +1,60 @@ +From a1c60257dd3f0c355e7ae7e02f597810932a6e1f Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 18 Sep 2025 17:33:16 -0700 +Subject: broadcom: fix support for PTP_PEROUT_DUTY_CYCLE + +From: Jacob Keller + +[ 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 +Fixes: d9f3e9ecc456 ("net: ptp: introduce .supported_perout_flags to ptp_clock_info") +Signed-off-by: Jacob Keller +Reviewed-by: Vadim Fedorenko +Acked-by: Richard Cochran +Reviewed-by: Kory Maincent +Tested-by: James Clark +Link: https://patch.msgid.link/20250918-jk-fix-bcm-phy-supported-flags-v1-1-747b60407c9c@intel.com +Signed-off-by: Jakub Kicinski +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-6.16/can-etas_es58x-populate-ndo_change_mtu-to-prevent-bu.patch b/queue-6.16/can-etas_es58x-populate-ndo_change_mtu-to-prevent-bu.patch new file mode 100644 index 0000000000..fc863ee1f8 --- /dev/null +++ b/queue-6.16/can-etas_es58x-populate-ndo_change_mtu-to-prevent-bu.patch @@ -0,0 +1,98 @@ +From cd821d3410bdd7de2399ff7a9b0aa7c008fb56bf Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 18 Sep 2025 18:00:24 +0900 +Subject: can: etas_es58x: populate ndo_change_mtu() to prevent buffer overflow + +From: Vincent Mailhol + +[ 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 +Link: https://patch.msgid.link/20250918-can-fix-mtu-v1-1-0d1cada9393b@kernel.org +Signed-off-by: Marc Kleine-Budde +Signed-off-by: Sasha Levin +--- + 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 ++ * Copyright (c) 2020-2025 Vincent Mailhol + */ + + #include +@@ -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 + diff --git a/queue-6.16/can-hi311x-populate-ndo_change_mtu-to-prevent-buffer.patch b/queue-6.16/can-hi311x-populate-ndo_change_mtu-to-prevent-buffer.patch new file mode 100644 index 0000000000..e2ca42e2e5 --- /dev/null +++ b/queue-6.16/can-hi311x-populate-ndo_change_mtu-to-prevent-buffer.patch @@ -0,0 +1,85 @@ +From 70e45cf7b2da9d02e2e1ffc989e091d66bcef6ba Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 18 Sep 2025 18:00:25 +0900 +Subject: can: hi311x: populate ndo_change_mtu() to prevent buffer overflow + +From: Vincent Mailhol + +[ 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 +Link: https://patch.msgid.link/20250918-can-fix-mtu-v1-2-0d1cada9393b@kernel.org +Signed-off-by: Marc Kleine-Budde +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-6.16/can-mcba_usb-populate-ndo_change_mtu-to-prevent-buff.patch b/queue-6.16/can-mcba_usb-populate-ndo_change_mtu-to-prevent-buff.patch new file mode 100644 index 0000000000..1ccbb69f8e --- /dev/null +++ b/queue-6.16/can-mcba_usb-populate-ndo_change_mtu-to-prevent-buff.patch @@ -0,0 +1,83 @@ +From 04fb35b72d572a437a1d5b0560c65d52c0fb9974 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 18 Sep 2025 18:00:27 +0900 +Subject: can: mcba_usb: populate ndo_change_mtu() to prevent buffer overflow + +From: Vincent Mailhol + +[ 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 +Link: https://patch.msgid.link/20250918-can-fix-mtu-v1-4-0d1cada9393b@kernel.org +Signed-off-by: Marc Kleine-Budde +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-6.16/can-peak_usb-fix-shift-out-of-bounds-issue.patch b/queue-6.16/can-peak_usb-fix-shift-out-of-bounds-issue.patch new file mode 100644 index 0000000000..b6a2580204 --- /dev/null +++ b/queue-6.16/can-peak_usb-fix-shift-out-of-bounds-issue.patch @@ -0,0 +1,44 @@ +From 5c8a3d1cb36b88492adf6cc2b7c7fc62f64ce28d Mon Sep 17 00:00:00 2001 +From: Sasha Levin +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 + +[ 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 +Link: https://patch.msgid.link/20250918132413.30071-1-stephane.grosjean@free.fr +Reported-by: Marc Kleine-Budde +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 +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-6.16/can-sun4i_can-populate-ndo_change_mtu-to-prevent-buf.patch b/queue-6.16/can-sun4i_can-populate-ndo_change_mtu-to-prevent-buf.patch new file mode 100644 index 0000000000..f09ae71ec7 --- /dev/null +++ b/queue-6.16/can-sun4i_can-populate-ndo_change_mtu-to-prevent-buf.patch @@ -0,0 +1,85 @@ +From 34f0fdf7bcb9e34fc5672cc8f13e3e18f309c41c Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 18 Sep 2025 18:00:26 +0900 +Subject: can: sun4i_can: populate ndo_change_mtu() to prevent buffer overflow + +From: Vincent Mailhol + +[ 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 +Link: https://patch.msgid.link/20250918-can-fix-mtu-v1-3-0d1cada9393b@kernel.org +Signed-off-by: Marc Kleine-Budde +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-6.16/ethernet-rvu-af-remove-slash-from-the-driver-name.patch b/queue-6.16/ethernet-rvu-af-remove-slash-from-the-driver-name.patch new file mode 100644 index 0000000000..ca50ec6ed1 --- /dev/null +++ b/queue-6.16/ethernet-rvu-af-remove-slash-from-the-driver-name.patch @@ -0,0 +1,41 @@ +From 9f390b0f717af67aaff259e8ace7847e0ad3af13 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 18 Sep 2025 17:21:07 +0200 +Subject: ethernet: rvu-af: Remove slash from the driver name + +From: Petr Malat + +[ 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 +Reviewed-by: Simon Horman +Link: https://patch.msgid.link/20250918152106.1798299-1-oss@malat.biz +Signed-off-by: Jakub Kicinski +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-6.16/net-allow-alloc_skb_with_frags-to-use-max_skb_frags.patch b/queue-6.16/net-allow-alloc_skb_with_frags-to-use-max_skb_frags.patch new file mode 100644 index 0000000000..12aa7714c6 --- /dev/null +++ b/queue-6.16/net-allow-alloc_skb_with_frags-to-use-max_skb_frags.patch @@ -0,0 +1,47 @@ +From 8879e9b4a2079b0b02e7eafd3fd14b4fba276fd0 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Mon, 22 Sep 2025 15:19:57 -0400 +Subject: net: allow alloc_skb_with_frags() to use MAX_SKB_FRAGS + +From: Jason Baron + +[ 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 +Reviewed-by: Eric Dumazet +Link: https://patch.msgid.link/20250922191957.2855612-1-jbaron@akamai.com +Signed-off-by: Jakub Kicinski +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-6.16/net-dsa-lantiq_gswip-move-gswip_add_single_port_br-c.patch b/queue-6.16/net-dsa-lantiq_gswip-move-gswip_add_single_port_br-c.patch new file mode 100644 index 0000000000..dd9cb08793 --- /dev/null +++ b/queue-6.16/net-dsa-lantiq_gswip-move-gswip_add_single_port_br-c.patch @@ -0,0 +1,97 @@ +From b5fe9d9862922c64e25b82237888dedd9e9658b4 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +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 + +[ 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 +Link: https://patch.msgid.link/20250918072142.894692-2-vladimir.oltean@nxp.com +Tested-by: Daniel Golle +Reviewed-by: Daniel Golle +Signed-off-by: Paolo Abeni +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-6.16/net-dsa-lantiq_gswip-suppress-einval-errors-for-brid.patch b/queue-6.16/net-dsa-lantiq_gswip-suppress-einval-errors-for-brid.patch new file mode 100644 index 0000000000..188e1a7404 --- /dev/null +++ b/queue-6.16/net-dsa-lantiq_gswip-suppress-einval-errors-for-brid.patch @@ -0,0 +1,69 @@ +From dbed9fba3f6daf036bdc645b8a6d9782acec16f6 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +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 + +[ 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 +Closes: https://lore.kernel.org/netdev/aJfNMLNoi1VOsPrN@pidgin.makrotopia.org/ +Signed-off-by: Vladimir Oltean +Link: https://patch.msgid.link/20250918072142.894692-3-vladimir.oltean@nxp.com +Tested-by: Daniel Golle +Reviewed-by: Daniel Golle +Signed-off-by: Paolo Abeni +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-6.16/net-mlx5-fs-fix-uaf-in-flow-counter-release.patch b/queue-6.16/net-mlx5-fs-fix-uaf-in-flow-counter-release.patch new file mode 100644 index 0000000000..2ef61d0f40 --- /dev/null +++ b/queue-6.16/net-mlx5-fs-fix-uaf-in-flow-counter-release.patch @@ -0,0 +1,171 @@ +From f34b6120dbb964ba7554418fb669118143b7f576 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Mon, 22 Sep 2025 10:11:32 +0300 +Subject: net/mlx5: fs, fix UAF in flow counter release + +From: Moshe Shemesh + +[ 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: + + 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 +Reviewed-by: Yevgeny Kliteynik +Reviewed-by: Mark Bloch +Signed-off-by: Tariq Toukan +Link: https://patch.msgid.link/1758525094-816583-2-git-send-email-tariqt@nvidia.com +Signed-off-by: Jakub Kicinski +Signed-off-by: Sasha Levin +--- + .../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 + diff --git a/queue-6.16/net-mlx5-hws-ignore-flow-level-for-multi-dest-table.patch b/queue-6.16/net-mlx5-hws-ignore-flow-level-for-multi-dest-table.patch new file mode 100644 index 0000000000..2b8f61b26c --- /dev/null +++ b/queue-6.16/net-mlx5-hws-ignore-flow-level-for-multi-dest-table.patch @@ -0,0 +1,119 @@ +From 38842c949d2d11fc84748c1933dc1c2be1ad8d6f Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Mon, 22 Sep 2025 10:11:33 +0300 +Subject: net/mlx5: HWS, ignore flow level for multi-dest table + +From: Yevgeny Kliteynik + +[ 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 +Reviewed-by: Moshe Shemesh +Reviewed-by: Mark Bloch +Signed-off-by: Tariq Toukan +Link: https://patch.msgid.link/1758525094-816583-3-git-send-email-tariqt@nvidia.com +Signed-off-by: Jakub Kicinski +Signed-off-by: Sasha Levin +--- + .../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 + diff --git a/queue-6.16/net-mlx5-hws-remove-unused-create_dest_array-paramet.patch b/queue-6.16/net-mlx5-hws-remove-unused-create_dest_array-paramet.patch new file mode 100644 index 0000000000..3555dd0417 --- /dev/null +++ b/queue-6.16/net-mlx5-hws-remove-unused-create_dest_array-paramet.patch @@ -0,0 +1,116 @@ +From 4518a726465cae2d4ab0846f48109f9ef25079f2 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 3 Jul 2025 21:54:22 +0300 +Subject: net/mlx5: HWS, remove unused create_dest_array parameter + +From: Vlad Dogaru + +[ Upstream commit 60afb51c89414b3d0061226415651f29a7eaf932 ] + +`flow_source` is not used anywhere in mlx5hws_action_create_dest_array. + +Signed-off-by: Vlad Dogaru +Signed-off-by: Yevgeny Kliteynik +Reviewed-by: Simon Horman +Signed-off-by: Mark Bloch +Link: https://patch.msgid.link/20250703185431.445571-2-mbloch@nvidia.com +Signed-off-by: Jakub Kicinski +Stable-dep-of: efb877cf27e3 ("net/mlx5: HWS, ignore flow level for multi-dest table") +Signed-off-by: Sasha Levin +--- + .../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 + diff --git a/queue-6.16/net-mlx5e-fix-missing-fec-rs-stats-for-rs_544_514_in.patch b/queue-6.16/net-mlx5e-fix-missing-fec-rs-stats-for-rs_544_514_in.patch new file mode 100644 index 0000000000..6b1334c0b5 --- /dev/null +++ b/queue-6.16/net-mlx5e-fix-missing-fec-rs-stats-for-rs_544_514_in.patch @@ -0,0 +1,40 @@ +From 23f2d6f657aaec66e45180beee97f65e1a6cca13 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +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 + +[ 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 +Reviewed-by: Dragos Tatulea +Reviewed-by: Yael Chemla +Signed-off-by: Tariq Toukan +Link: https://patch.msgid.link/1758525094-816583-4-git-send-email-tariqt@nvidia.com +Signed-off-by: Jakub Kicinski +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-6.16/net-smc-fix-warning-in-smc_rx_splice-when-calling-ge.patch b/queue-6.16/net-smc-fix-warning-in-smc_rx_splice-when-calling-ge.patch new file mode 100644 index 0000000000..f828ff9cdf --- /dev/null +++ b/queue-6.16/net-smc-fix-warning-in-smc_rx_splice-when-calling-ge.patch @@ -0,0 +1,107 @@ +From 8542c28d8a19b38cf4073187c98f7c5288d0460a Mon Sep 17 00:00:00 2001 +From: Sasha Levin +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 + +[ 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 +Signed-off-by: Sidraya Jayagond +Link: https://patch.msgid.link/20250917184220.801066-1-sidraya@linux.ibm.com +Signed-off-by: Jakub Kicinski +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-6.16/net-tun-update-napi-skb-after-xdp-process.patch b/queue-6.16/net-tun-update-napi-skb-after-xdp-process.patch new file mode 100644 index 0000000000..6b0073aa26 --- /dev/null +++ b/queue-6.16/net-tun-update-napi-skb-after-xdp-process.patch @@ -0,0 +1,113 @@ +From 4c7837cdbd6477c762f9ab99b9c59d82580439d9 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Wed, 17 Sep 2025 19:39:19 +0800 +Subject: net: tun: Update napi->skb after XDP process + +From: Wang Liang + +[ 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: + + 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 + + + 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 +Reviewed-by: Willem de Bruijn +Link: https://patch.msgid.link/20250917113919.3991267-1-wangliang74@huawei.com +Signed-off-by: Jakub Kicinski +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-6.16/nexthop-forbid-fdb-status-change-while-nexthop-is-in.patch b/queue-6.16/nexthop-forbid-fdb-status-change-while-nexthop-is-in.patch new file mode 100644 index 0000000000..44015e9d42 --- /dev/null +++ b/queue-6.16/nexthop-forbid-fdb-status-change-while-nexthop-is-in.patch @@ -0,0 +1,100 @@ +From 0e0227167649de45dbd03a07a01449b728dfae28 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Sun, 21 Sep 2025 18:08:22 +0300 +Subject: nexthop: Forbid FDB status change while nexthop is in a group + +From: Ido Schimmel + +[ 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: + + 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 +Reviewed-by: David Ahern +Link: https://patch.msgid.link/20250921150824.149157-2-idosch@nvidia.com +Signed-off-by: Jakub Kicinski +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-6.16/octeontx2-pf-fix-potential-use-after-free-in-otx2_tc.patch b/queue-6.16/octeontx2-pf-fix-potential-use-after-free-in-otx2_tc.patch new file mode 100644 index 0000000000..385d4b3eef --- /dev/null +++ b/queue-6.16/octeontx2-pf-fix-potential-use-after-free-in-otx2_tc.patch @@ -0,0 +1,47 @@ +From 1287c1287bf192e8492eb2add2f7b6cae3a95096 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +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 + +[ 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 +Reviewed-by: Vadim Fedorenko +Link: https://patch.msgid.link/aNKCL1jKwK8GRJHh@stanley.mountain +Signed-off-by: Paolo Abeni +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-6.16/selftests-fib_nexthops-fix-creation-of-non-fdb-nexth.patch b/queue-6.16/selftests-fib_nexthops-fix-creation-of-non-fdb-nexth.patch new file mode 100644 index 0000000000..9f2f28e6c0 --- /dev/null +++ b/queue-6.16/selftests-fib_nexthops-fix-creation-of-non-fdb-nexth.patch @@ -0,0 +1,149 @@ +From 04230642e7d9788e4638e9470dde553e7bd5cff0 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Sun, 21 Sep 2025 18:08:23 +0300 +Subject: selftests: fib_nexthops: Fix creation of non-FDB nexthops + +From: Ido Schimmel + +[ 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 +Reviewed-by: David Ahern +Link: https://patch.msgid.link/20250921150824.149157-3-idosch@nvidia.com +Signed-off-by: Jakub Kicinski +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-6.16/series b/queue-6.16/series index a41d69177e..10be2596a9 100644 --- a/queue-6.16/series +++ b/queue-6.16/series @@ -55,3 +55,31 @@ 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 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 diff --git a/queue-6.16/vhost-take-a-reference-on-the-task-in-struct-vhost_t.patch b/queue-6.16/vhost-take-a-reference-on-the-task-in-struct-vhost_t.patch new file mode 100644 index 0000000000..89c871aa38 --- /dev/null +++ b/queue-6.16/vhost-take-a-reference-on-the-task-in-struct-vhost_t.patch @@ -0,0 +1,57 @@ +From 8c0180fc25fadbc83b653833f7b84245d4e0ff35 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +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 + +[ 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 +Closes: https://lore.kernel.org/all/aKkLEtoDXKxAAWju@google.com/ +Signed-off-by: Sebastian Andrzej Siewior +Message-Id: <20250918181144.Ygo8BZ-R@linutronix.de> +Signed-off-by: Michael S. Tsirkin +Tested-by: Sean Christopherson +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-6.16/xfrm-fix-offloading-of-cross-family-tunnels.patch b/queue-6.16/xfrm-fix-offloading-of-cross-family-tunnels.patch new file mode 100644 index 0000000000..e52e8cc326 --- /dev/null +++ b/queue-6.16/xfrm-fix-offloading-of-cross-family-tunnels.patch @@ -0,0 +1,71 @@ +From 49f3b601e230ce6d16e86e81ea20577e0a630f1f Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Wed, 10 Sep 2025 17:22:13 +0200 +Subject: xfrm: fix offloading of cross-family tunnels + +From: Sabrina Dubroca + +[ 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 +Signed-off-by: Sabrina Dubroca +Reviewed-by: Leon Romanovsky +Reviewed-by: Zhu Yanjun +Signed-off-by: Steffen Klassert +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-6.16/xfrm-xfrm_alloc_spi-shouldn-t-use-0-as-spi.patch b/queue-6.16/xfrm-xfrm_alloc_spi-shouldn-t-use-0-as-spi.patch new file mode 100644 index 0000000000..22c68e2ca9 --- /dev/null +++ b/queue-6.16/xfrm-xfrm_alloc_spi-shouldn-t-use-0-as-spi.patch @@ -0,0 +1,52 @@ +From 86eef6dae59927a077a0fddbae5d4a15586e553b Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Fri, 29 Aug 2025 10:54:15 +0200 +Subject: xfrm: xfrm_alloc_spi shouldn't use 0 as SPI + +From: Sabrina Dubroca + +[ 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 +Reviewed-by: Simon Horman +Signed-off-by: Steffen Klassert +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-6.6/bluetooth-hci_event-fix-uaf-in-hci_acl_create_conn_s.patch b/queue-6.6/bluetooth-hci_event-fix-uaf-in-hci_acl_create_conn_s.patch new file mode 100644 index 0000000000..5d9d3faa40 --- /dev/null +++ b/queue-6.6/bluetooth-hci_event-fix-uaf-in-hci_acl_create_conn_s.patch @@ -0,0 +1,199 @@ +From 6763b962418f9068aafa88205268063fb93f47ea Mon Sep 17 00:00:00 2001 +From: Sasha Levin +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 + +[ 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: + + 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 + + +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 +Signed-off-by: Luiz Augusto von Dentz +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-6.6/bluetooth-hci_sync-fix-hci_resume_advertising_sync.patch b/queue-6.6/bluetooth-hci_sync-fix-hci_resume_advertising_sync.patch new file mode 100644 index 0000000000..b97371245a --- /dev/null +++ b/queue-6.6/bluetooth-hci_sync-fix-hci_resume_advertising_sync.patch @@ -0,0 +1,42 @@ +From 3d372877572520d9c420c4536304ab8e65679cf2 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Fri, 5 Sep 2025 10:29:18 -0400 +Subject: Bluetooth: hci_sync: Fix hci_resume_advertising_sync + +From: Luiz Augusto von Dentz + +[ 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 +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-6.6/bnxt_en-correct-offset-handling-for-ipv6-destination.patch b/queue-6.6/bnxt_en-correct-offset-handling-for-ipv6-destination.patch new file mode 100644 index 0000000000..b8245564d9 --- /dev/null +++ b/queue-6.6/bnxt_en-correct-offset-handling-for-ipv6-destination.patch @@ -0,0 +1,43 @@ +From c5d6600b032bedb41764a3c9043345a0e7d8741f Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Sat, 20 Sep 2025 05:11:17 -0700 +Subject: bnxt_en: correct offset handling for IPv6 destination address + +From: Alok Tiwari + +[ 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 +Reviewed-by: Somnath Kotur +Link: https://patch.msgid.link/20250920121157.351921-1-alok.a.tiwari@oracle.com +Signed-off-by: Jakub Kicinski +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-6.6/can-etas_es58x-populate-ndo_change_mtu-to-prevent-bu.patch b/queue-6.6/can-etas_es58x-populate-ndo_change_mtu-to-prevent-bu.patch new file mode 100644 index 0000000000..dd522a6220 --- /dev/null +++ b/queue-6.6/can-etas_es58x-populate-ndo_change_mtu-to-prevent-bu.patch @@ -0,0 +1,98 @@ +From 2cc4d4163c0c166f10552081a448f623afc797d6 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 18 Sep 2025 18:00:24 +0900 +Subject: can: etas_es58x: populate ndo_change_mtu() to prevent buffer overflow + +From: Vincent Mailhol + +[ 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 +Link: https://patch.msgid.link/20250918-can-fix-mtu-v1-1-0d1cada9393b@kernel.org +Signed-off-by: Marc Kleine-Budde +Signed-off-by: Sasha Levin +--- + 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 ++ * Copyright (c) 2020-2025 Vincent Mailhol + */ + + #include +@@ -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 + diff --git a/queue-6.6/can-hi311x-populate-ndo_change_mtu-to-prevent-buffer.patch b/queue-6.6/can-hi311x-populate-ndo_change_mtu-to-prevent-buffer.patch new file mode 100644 index 0000000000..269b7f4c94 --- /dev/null +++ b/queue-6.6/can-hi311x-populate-ndo_change_mtu-to-prevent-buffer.patch @@ -0,0 +1,85 @@ +From 2b9361019166335ceee9a8d0d2b5d14fd08abb84 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 18 Sep 2025 18:00:25 +0900 +Subject: can: hi311x: populate ndo_change_mtu() to prevent buffer overflow + +From: Vincent Mailhol + +[ 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 +Link: https://patch.msgid.link/20250918-can-fix-mtu-v1-2-0d1cada9393b@kernel.org +Signed-off-by: Marc Kleine-Budde +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-6.6/can-mcba_usb-populate-ndo_change_mtu-to-prevent-buff.patch b/queue-6.6/can-mcba_usb-populate-ndo_change_mtu-to-prevent-buff.patch new file mode 100644 index 0000000000..d5ee35cafc --- /dev/null +++ b/queue-6.6/can-mcba_usb-populate-ndo_change_mtu-to-prevent-buff.patch @@ -0,0 +1,83 @@ +From e02ce26e497b5359bf7cb41f224f3afdb3a6a366 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 18 Sep 2025 18:00:27 +0900 +Subject: can: mcba_usb: populate ndo_change_mtu() to prevent buffer overflow + +From: Vincent Mailhol + +[ 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 +Link: https://patch.msgid.link/20250918-can-fix-mtu-v1-4-0d1cada9393b@kernel.org +Signed-off-by: Marc Kleine-Budde +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-6.6/can-peak_usb-fix-shift-out-of-bounds-issue.patch b/queue-6.6/can-peak_usb-fix-shift-out-of-bounds-issue.patch new file mode 100644 index 0000000000..0be619c6c5 --- /dev/null +++ b/queue-6.6/can-peak_usb-fix-shift-out-of-bounds-issue.patch @@ -0,0 +1,44 @@ +From 120468436b822eeca1211d3e639ee2a7f0b16416 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +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 + +[ 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 +Link: https://patch.msgid.link/20250918132413.30071-1-stephane.grosjean@free.fr +Reported-by: Marc Kleine-Budde +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 +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-6.6/can-sun4i_can-populate-ndo_change_mtu-to-prevent-buf.patch b/queue-6.6/can-sun4i_can-populate-ndo_change_mtu-to-prevent-buf.patch new file mode 100644 index 0000000000..b093766bb7 --- /dev/null +++ b/queue-6.6/can-sun4i_can-populate-ndo_change_mtu-to-prevent-buf.patch @@ -0,0 +1,85 @@ +From b893f1c6d46c60dd463e7f7690f65984d26995fe Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 18 Sep 2025 18:00:26 +0900 +Subject: can: sun4i_can: populate ndo_change_mtu() to prevent buffer overflow + +From: Vincent Mailhol + +[ 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 +Link: https://patch.msgid.link/20250918-can-fix-mtu-v1-3-0d1cada9393b@kernel.org +Signed-off-by: Marc Kleine-Budde +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-6.6/ethernet-rvu-af-remove-slash-from-the-driver-name.patch b/queue-6.6/ethernet-rvu-af-remove-slash-from-the-driver-name.patch new file mode 100644 index 0000000000..69be4ec30b --- /dev/null +++ b/queue-6.6/ethernet-rvu-af-remove-slash-from-the-driver-name.patch @@ -0,0 +1,41 @@ +From 7bd320b0a1307272adf423702b41c94d2f55d51b Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 18 Sep 2025 17:21:07 +0200 +Subject: ethernet: rvu-af: Remove slash from the driver name + +From: Petr Malat + +[ 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 +Reviewed-by: Simon Horman +Link: https://patch.msgid.link/20250918152106.1798299-1-oss@malat.biz +Signed-off-by: Jakub Kicinski +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-6.6/net-allow-alloc_skb_with_frags-to-use-max_skb_frags.patch b/queue-6.6/net-allow-alloc_skb_with_frags-to-use-max_skb_frags.patch new file mode 100644 index 0000000000..897ef73537 --- /dev/null +++ b/queue-6.6/net-allow-alloc_skb_with_frags-to-use-max_skb_frags.patch @@ -0,0 +1,47 @@ +From 47729e275d5f3470588c9345b1c2920039ca5c38 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Mon, 22 Sep 2025 15:19:57 -0400 +Subject: net: allow alloc_skb_with_frags() to use MAX_SKB_FRAGS + +From: Jason Baron + +[ 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 +Reviewed-by: Eric Dumazet +Link: https://patch.msgid.link/20250922191957.2855612-1-jbaron@akamai.com +Signed-off-by: Jakub Kicinski +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-6.6/net-dsa-lantiq_gswip-do-also-enable-or-disable-cpu-p.patch b/queue-6.6/net-dsa-lantiq_gswip-do-also-enable-or-disable-cpu-p.patch new file mode 100644 index 0000000000..e7e9976807 --- /dev/null +++ b/queue-6.6/net-dsa-lantiq_gswip-do-also-enable-or-disable-cpu-p.patch @@ -0,0 +1,84 @@ +From 8df00aceb3ee397e658ab05902b32ba55bbbbc9a Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Tue, 11 Jun 2024 15:54:28 +0200 +Subject: net: dsa: lantiq_gswip: do also enable or disable cpu port + +From: Martin Schiller + +[ 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 +Acked-by: Hauke Mehrtens +Reviewed-by: Vladimir Oltean +Link: https://lore.kernel.org/r/20240611135434.3180973-7-ms@dev.tdt.de +Signed-off-by: Jakub Kicinski +Stable-dep-of: c0054b25e2f1 ("net: dsa: lantiq_gswip: move gswip_add_single_port_br() call to port_setup()") +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-6.6/net-dsa-lantiq_gswip-move-gswip_add_single_port_br-c.patch b/queue-6.6/net-dsa-lantiq_gswip-move-gswip_add_single_port_br-c.patch new file mode 100644 index 0000000000..5d1cad444d --- /dev/null +++ b/queue-6.6/net-dsa-lantiq_gswip-move-gswip_add_single_port_br-c.patch @@ -0,0 +1,97 @@ +From 1ce2accf518c84f5c8c781dbbc4ef872f3f0a48e Mon Sep 17 00:00:00 2001 +From: Sasha Levin +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 + +[ 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 +Link: https://patch.msgid.link/20250918072142.894692-2-vladimir.oltean@nxp.com +Tested-by: Daniel Golle +Reviewed-by: Daniel Golle +Signed-off-by: Paolo Abeni +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-6.6/net-dsa-lantiq_gswip-suppress-einval-errors-for-brid.patch b/queue-6.6/net-dsa-lantiq_gswip-suppress-einval-errors-for-brid.patch new file mode 100644 index 0000000000..c2e44af940 --- /dev/null +++ b/queue-6.6/net-dsa-lantiq_gswip-suppress-einval-errors-for-brid.patch @@ -0,0 +1,69 @@ +From 039cbaa910a396ad366de633398c083f88b41ca8 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +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 + +[ 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 +Closes: https://lore.kernel.org/netdev/aJfNMLNoi1VOsPrN@pidgin.makrotopia.org/ +Signed-off-by: Vladimir Oltean +Link: https://patch.msgid.link/20250918072142.894692-3-vladimir.oltean@nxp.com +Tested-by: Daniel Golle +Reviewed-by: Daniel Golle +Signed-off-by: Paolo Abeni +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-6.6/nexthop-forbid-fdb-status-change-while-nexthop-is-in.patch b/queue-6.6/nexthop-forbid-fdb-status-change-while-nexthop-is-in.patch new file mode 100644 index 0000000000..06df6c1773 --- /dev/null +++ b/queue-6.6/nexthop-forbid-fdb-status-change-while-nexthop-is-in.patch @@ -0,0 +1,100 @@ +From 85ee291f485d3ea514069e7a3ebc1c58d7cad5c3 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Sun, 21 Sep 2025 18:08:22 +0300 +Subject: nexthop: Forbid FDB status change while nexthop is in a group + +From: Ido Schimmel + +[ 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: + + 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 +Reviewed-by: David Ahern +Link: https://patch.msgid.link/20250921150824.149157-2-idosch@nvidia.com +Signed-off-by: Jakub Kicinski +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-6.6/octeontx2-pf-fix-potential-use-after-free-in-otx2_tc.patch b/queue-6.6/octeontx2-pf-fix-potential-use-after-free-in-otx2_tc.patch new file mode 100644 index 0000000000..a8d285c7a8 --- /dev/null +++ b/queue-6.6/octeontx2-pf-fix-potential-use-after-free-in-otx2_tc.patch @@ -0,0 +1,47 @@ +From b89bc5ca4fe79f20c331c46ce71786d254ffe6ec Mon Sep 17 00:00:00 2001 +From: Sasha Levin +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 + +[ 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 +Reviewed-by: Vadim Fedorenko +Link: https://patch.msgid.link/aNKCL1jKwK8GRJHh@stanley.mountain +Signed-off-by: Paolo Abeni +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-6.6/selftests-fib_nexthops-fix-creation-of-non-fdb-nexth.patch b/queue-6.6/selftests-fib_nexthops-fix-creation-of-non-fdb-nexth.patch new file mode 100644 index 0000000000..329f88246c --- /dev/null +++ b/queue-6.6/selftests-fib_nexthops-fix-creation-of-non-fdb-nexth.patch @@ -0,0 +1,149 @@ +From 908e8e73446d11a8cf2d008790ff384e34d8377f Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Sun, 21 Sep 2025 18:08:23 +0300 +Subject: selftests: fib_nexthops: Fix creation of non-FDB nexthops + +From: Ido Schimmel + +[ 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 +Reviewed-by: David Ahern +Link: https://patch.msgid.link/20250921150824.149157-3-idosch@nvidia.com +Signed-off-by: Jakub Kicinski +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-6.6/series b/queue-6.6/series index d22d5539ff..3c5bd4d613 100644 --- a/queue-6.6/series +++ b/queue-6.6/series @@ -31,3 +31,21 @@ smb-server-don-t-use-delayed_work-for-post_recv_cred.patch 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 diff --git a/queue-6.6/vhost-take-a-reference-on-the-task-in-struct-vhost_t.patch b/queue-6.6/vhost-take-a-reference-on-the-task-in-struct-vhost_t.patch new file mode 100644 index 0000000000..0809577301 --- /dev/null +++ b/queue-6.6/vhost-take-a-reference-on-the-task-in-struct-vhost_t.patch @@ -0,0 +1,57 @@ +From 8d2b6ad8602038140c8d5ee160f21d43bc8c9984 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +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 + +[ 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 +Closes: https://lore.kernel.org/all/aKkLEtoDXKxAAWju@google.com/ +Signed-off-by: Sebastian Andrzej Siewior +Message-Id: <20250918181144.Ygo8BZ-R@linutronix.de> +Signed-off-by: Michael S. Tsirkin +Tested-by: Sean Christopherson +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-6.6/xfrm-xfrm_alloc_spi-shouldn-t-use-0-as-spi.patch b/queue-6.6/xfrm-xfrm_alloc_spi-shouldn-t-use-0-as-spi.patch new file mode 100644 index 0000000000..3712feb0dd --- /dev/null +++ b/queue-6.6/xfrm-xfrm_alloc_spi-shouldn-t-use-0-as-spi.patch @@ -0,0 +1,52 @@ +From a57b3ee4dd1c05a25257dfc5b4560f3abec4ddc7 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Fri, 29 Aug 2025 10:54:15 +0200 +Subject: xfrm: xfrm_alloc_spi shouldn't use 0 as SPI + +From: Sabrina Dubroca + +[ 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 +Reviewed-by: Simon Horman +Signed-off-by: Steffen Klassert +Signed-off-by: Sasha Levin +--- + 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 + -- 2.47.3