{ "schema_version": "1.6.1", "id": "RPI-CVE-2025-21682", "modified": "2026-10-09T11:39:44Z", "upstream": [ "CVE-2025-21682" ], "published": "2025-01-31T11:31:15Z", "summary": "eth: bnxt: always recalculate features after XDP clearing, fix null-deref", "details": "In the Linux kernel, the following vulnerability has been resolved:\n\neth: bnxt: always recalculate features after XDP clearing, fix null-deref\n\nRecalculate features when XDP is detached.\n\nBefore:\n # ip li set dev eth0 xdp obj xdp_dummy.bpf.o sec xdp\n # ip li set dev eth0 xdp off\n # ethtool -k eth0 | grep gro\n rx-gro-hw: off [requested on]\n\nAfter:\n # ip li set dev eth0 xdp obj xdp_dummy.bpf.o sec xdp\n # ip li set dev eth0 xdp off\n # ethtool -k eth0 | grep gro\n rx-gro-hw: on\n\nThe fact that HW-GRO doesn't get re-enabled automatically is just\na minor annoyance. The real issue is that the features will randomly\ncome back during another reconfiguration which just happens to invoke\nnetdev_update_features(). The driver doesn't handle reconfiguring\ntwo things at a time very robustly.\n\nStarting with commit 98ba1d931f61 (\"bnxt_en: Fix RSS logic in\n__bnxt_reserve_rings()\") we only reconfigure the RSS hash table\nif the \"effective\" number of Rx rings has changed. If HW-GRO is\nenabled \"effective\" number of rings is 2x what user sees.\nSo if we are in the bad state, with HW-GRO re-enablement \"pending\"\nafter XDP off, and we lower the rings by / 2 - the HW-GRO rings\ndoing 2x and the ethtool -L doing / 2 may cancel each other out,\nand the:\n\n if (old_rx_rings != bp->hw_resc.resv_rx_rings &&\n\ncondition in __bnxt_reserve_rings() will be false.\nThe RSS map won't get updated, and we'll crash with:\n\n BUG: kernel NULL pointer dereference, address: 0000000000000168\n RIP: 0010:__bnxt_hwrm_vnic_set_rss+0x13a/0x1a0\n bnxt_hwrm_vnic_rss_cfg_p5+0x47/0x180\n __bnxt_setup_vnic_p5+0x58/0x110\n bnxt_init_nic+0xb72/0xf50\n __bnxt_open_nic+0x40d/0xab0\n bnxt_open_nic+0x2b/0x60\n ethtool_set_channels+0x18c/0x1d0\n\nAs we try to access a freed ring.\n\nThe issue is present since XDP support was added, really, but\nprior to commit 98ba1d931f61 (\"bnxt_en: Fix RSS logic in\n__bnxt_reserve_rings()\") it wasn't causing major issues.", "severity": [ { "type": "CVSS_V3", "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:H" } ], "affected": [ { "package": { "ecosystem": "Raspberry Pi OS:12", "name": "linux" }, "versions": [ "1:6.1.47-1+rpt4" ], "ecosystem_specific": { "binaries": [ { "binary_name": "linux-image-6.1.0-rpi3-rpi-2712", "binary_version": "1:6.1.47-1+rpt4" }, { "binary_name": "linux-image-6.1.0-rpi3-rpi-v6", "binary_version": "1:6.1.47-1+rpt4" }, { "binary_name": "linux-image-6.1.0-rpi3-rpi-v7", "binary_version": "1:6.1.47-1+rpt4" }, { "binary_name": "linux-image-6.1.0-rpi3-rpi-v7l", "binary_version": "1:6.1.47-1+rpt4" }, { "binary_name": "linux-image-6.1.0-rpi3-rpi-v8", "binary_version": "1:6.1.47-1+rpt4" } ] }, "database_specific": { "per_version": { "1:6.1.47-1+rpt4": { "linux_commit": "655fc658a15ae7a6f37103754adb39ba52a9a14e", "upstream_version": "6.1.47", "assessment": "commit ancestry (strak rule)", "upstream_fixed": "6.1.167", "compiled_filter": false } } } } ], "references": [ { "type": "ADVISORY", "url": "https://www.cve.org/CVERecord?id=CVE-2025-21682" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/076a694a42ae3f0466bc6e4126050eeb7b7d299a" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/90336fc3d6f5e716ac39a9ddbbde453e23a5aa65" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/08831a894d18abfaabb5bbde7c2069a7fb41dd93" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/f0aa6a37a3dbb40b272df5fc6db93c114688adcd" } ], "database_specific": { "source": "https://git.kernel.org/pub/scm/linux/security/vulns.git", "upstream_modified": "2026-08-05T12:19:11Z", "severity": { "source": "kernel CNA", "cvss_v3_score": 7.3, "cvss_v3_severity": "High", "scenario": "AV:L - The bug is reached only through local device-configuration interfaces \u2014 RTM_SETLINK for XDP attach/detach and the ethtool set_channels ioctl/netlink call on a bnxt netdev. No remote peer input reaches this code.\nAC:L - The commit gives a deterministic recipe: attach XDP, detach XDP, then halve the ring count so the pending HW-GRO 2x cancels the /2 and the RSS map refresh is skipped. Every input is attacker-chosen, there is no race and no memory-layout condition outside the attacker's influence.\nPR:L - Both entry points check ns_capable(net->user_ns, CAP_NET_ADMIN), which is namespace-scoped rather than requiring real root in the init namespace, so a container or namespace-confined user holding a delegated bnxt netdev (such as an SR-IOV VF) can drive the full sequence.\nUI:N - The attacker performs the XDP attach, XDP detach and channel-count change entirely on its own; no other user or administrator action is needed at any point.\nS:U - The out-of-bounds access and resulting crash are confined to the kernel's own memory and the driver's hardware configuration, within the same security authority; no VM, IOMMU or sandbox boundary is crossed.\nC:H - bnxt_fill_hw_rss_tbl_p5() indexes bp->rx_ring with stale RSS indices past the end of the newly kcalloc'd array, reading adjacent heap objects and then dereferencing an rx_cpr pointer taken from that out-of-bounds memory, which with heap grooming becomes an attacker-influenced arbitrary-address read.\nI:L - There is no out-of-bounds write, but garbage ring IDs harvested from the out-of-bounds read are programmed into the NIC's RSS indirection table, corrupting hardware receive steering \u2014 a bounded but real modification of state.\nA:H - The dereference of the NULL/wild rx_cpr pointer oopses inside __bnxt_open_nic() while holding rtnl_lock, taking down the network device and typically panicking or wedging the machine." } } }