eth: bnxt: always recalculate features after XDP clearing, fix null-deref
- Published
- Last modified
- Where the record stands: published, rejected by its publisher, or superseded by another id.What do these mean? →
- published
- Whether CISA lists it in its Known Exploited Vulnerabilities catalog: proof that attackers are using it.What do these mean? →
- Not listed in CISA KEV
- Fix
- Fixed in 6.1.167, 6.6.130, 6.12.11
- Whether working attack code is public (Exploit-DB, Metasploit, Nuclei or GitHub). Public code makes attacks easier.What do these mean? →
- None on Exploit-DB, Metasploit or GitHub
- Exploitation: none
- Automatable: no
- Technical impact: partial
Summary
In the Linux kernel, the following vulnerability has been resolved: eth: bnxt: always recalculate features after XDP clearing, fix null-deref Recalculate features when XDP is detached. Before: ip li set dev eth0 xdp obj xdp_dummy.bpf.o sec xdp ip li set dev eth0 xdp off ethtool -k eth0 | grep gro rx-gro-hw: off [requested on] After: ip li set dev eth0 xdp obj xdp_dummy.bpf.o sec xdp ip li set dev eth0 xdp off ethtool -k eth0 | grep gro rx-gro-hw: on The fact that HW-GRO doesn't get re-enabled automatically is just a minor annoyance. The real issue is that the features will randomly come back during another reconfiguration which just happens to invoke netdev_update_features(). The driver doesn't handle reconfiguring two things at a time very robustly. Starting with commit 98ba1d931f61 ("bnxt_en: Fix RSS logic in __bnxt_reserve_rings()") we only reconfigure the RSS hash table if the "effective" number of Rx rings has changed. If HW-GRO is enabled "effective" number of rings is 2x what user sees. So if we are in the bad state, with HW-GRO re-enablement "pending" after XDP off, and we lower the rings by / 2 - the HW-GRO rings doing 2x and the ethtool -L doing / 2 may cancel each other out, and the: if (old_rx_rings != bp->hw_resc.resv_rx_rings && condition in __bnxt_reserve_rings() will be false. The RSS map won't get updated, and we'll crash with: BUG: kernel NULL pointer dereference, address: 0000000000000168 RIP: 0010:__bnxt_hwrm_vnic_set_rss+0x13a/0x1a0 bnxt_hwrm_vnic_rss_cfg_p5+0x47/0x180 __bnxt_setup_vnic_p5+0x58/0x110 bnxt_init_nic+0xb72/0xf50 __bnxt_open_nic+0x40d/0xab0 bnxt_open_nic+0x2b/0x60 ethtool_set_channels+0x18c/0x1d0 As we try to access a freed ring. The issue is present since XDP support was added, really, but prior to commit 98ba1d931f61 ("bnxt_en: Fix RSS logic in __bnxt_reserve_rings()") it wasn't causing major issues.
Timeline
- CVE published
- CISA SSVC assessment
Exploitation: none · Automatable: no · Technical impact: partial
- Record last updated
Affected versions
- Linux Linux
From 1054aee82321483dceabbb9b9e5d6512e8fe684b · fixed in 076a694a42ae3f0466bc6e4126050eeb7b7d299a; From 1054aee82321483dceabbb9b9e5d6512e8fe684b · fixed in 90336fc3d6f5e716ac39a9ddbbde453e23a5aa65; From 1054aee82321483dceabbb9b9e5d6512e8fe684b · fixed in 08831a894d18abfaabb5bbde7c2069a7fb41dd93; From 1054aee82321483dceabbb9b9e5d6512e8fe684b · fixed in f0aa6a37a3dbb40b272df5fc6db93c114688adcd
- Linux Linux
4.16
- KernelLinux
From 4.16.0 · fixed in 6.1.167; From 6.2.0 · fixed in 6.6.130; From 6.7.0 · fixed in 6.12.11