Look up another CVE · open CVE-2025-21961 in the interactive tracker
CVE-2025-21961
eth: bnxt: fix truesize for mb-xdp-pass case
Published 2025-04-01 (19 months ago) by the Linux kernel CNA. Subsystem drivers/net. Debian urgency: not yet assigned.
What to do, per Debian release
Debian's own status for CVE-2025-21961 in every release this site tracks, and what each one means in practice. Every status below is the one the Debian Security Team publishes for this CVE. source
| Release | Status | Version | What this means |
|---|---|---|---|
| Debian 12bookworm | vulnerable | 6.1.190-1 | No fix published anywhere yet, neither in Debian nor upstream for the series bookworm tracks. Watch the Debian tracker page for this CVE. Advisories for bookworm have historically landed a median of 23 days after publication. |
| Debian 13trixie | fixed | 6.12.20-1 | Update the kernel and reboot. Fixed in 6.12.20-1. A running kernel keeps the old code until the machine restarts. |
| Debian 14forky | fixed | 6.12.20-1 | Update the kernel and reboot. Fixed in 6.12.20-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 6.12.20-1 | Update the kernel and reboot. Fixed in 6.12.20-1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
When mb-xdp is set and return is XDP_PASS, packet is converted from xdp_buff to sk_buff with xdp_update_skb_shared_info() in bnxt_xdp_build_skb(). bnxt_xdp_build_skb() passes incorrect truesize argument to xdp_update_skb_shared_info(). The truesize is calculated as BNXT_RX_PAGE_SIZE * sinfo->nr_frags but the skb_shared_info was wiped by napi_build_skb() before. So it stores sinfo->nr_frags before bnxt_xdp_build_skb() and use it instead of getting skb_shared_info from xdp_get_shared_info_from_buff(). Splat looks like: ------------[ cut here ]------------ WARNING: CPU: 2 PID: 0 at net/core/skbuff.c:6072 skb_try_coalesce+0x504/0x590 Modules linked in: xt_nat xt_tcpudp veth af_packet xt_conntrack nft_chain_nat xt_MASQUERADE nf_conntrack_netlink xfrm_user xt_addrtype nft_coms CPU: 2 UID: 0 PID: 0 Comm: swapper/2 Not tainted 6.14.0-rc2+ #3 RIP: 0010:skb_try_coalesce+0x504/0x590 Code: 4b fd ff ff 49 8b 34 24 40 80 e6 40 0f 84 3d fd ff ff 49 8b 74 24 48 40 f6 c6 01 0f 84 2e fd ff ff 48 8d 4e ff e9 25 fd ff ff <0f> 0b e99 RSP: 0018:ffffb62c4120caa8 EFLAGS: 00010287 RAX: 0000000000000003 RBX: ffffb62c4120cb14 RCX: 0000000000000ec0 RDX: 0000000000001000 RSI: ffffa06e5d7dc000 RDI: 0000000000000003 RBP: ffffa06e5d7ddec0 R08: ffffa06e6120a800 R09: ffffa06e7a119900 R10: 0000000000002310 R11: ffffa06e5d7dcec0 R12: ffffe4360575f740 R13: ffffe43600000000 R14: 0000000000000002 R15: 0000000000000002 FS: 0000000000000000(0000) GS:ffffa0755f700000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f147b76b0f8 CR3: 00000001615d4000 CR4: 00000000007506f0 PKRU: 55555554 Call Trace: <IRQ> ? __warn+0x84/0x130 ? skb_try_coalesce+0x504/0x590 ? report_bug+0x18a/0x1a0 ? handle_bug+0x53/0x90 ? exc_invalid_op+0x14/0x70 ? asm_exc_invalid_op+0x16/0x20 ? skb_try_coalesce+0x504/0x590 inet_frag_reasm_finish+0x11f/0x2e0 ip_defrag+0x37a/0x900 ip_local_deliver+0x51/0x120 ip_sublist_rcv_finish+0x64/0x70 ip_sublist_rcv+0x179/0x210 ip_list_rcv+0xf9/0x130 How to reproduce: <Node A> ip link set $interface1 xdp obj xdp_pass.o ip link set $interface1 mtu 9000 up ip a a 10.0.0.1/24 dev $interface1 <Node B> ip link set $interfac2 mtu 9000 up ip a a 10.0.0.2/24 dev $interface2 ping 10.0.0.1 -s 65000 Following ping.py patch adds xdp-mb-pass case. so ping.py is going to be able to reproduce this issue.
Where it lives
The fix touches these files. If the subsystem is one you do not use, the practical exposure is lower, though the package is still the vulnerable one.
drivers/net/ethernet/broadcom/bnxt/bnxt.c
drivers/net/ethernet/broadcom/bnxt/bnxt_xdp.c
- What this is
- BROADCOM BNXT_EN 50 GIGABIT ETHERNET DRIVERMAINTAINERS section matched on drivers/net/ethernet/broadcom/bnxt/ · netdev@vger.kernel.org · Maintained
- Kernel module
- bnxt_en
Check it on the machine
grep -wE 'CONFIG_BNXT|CONFIG_ETHERNET|CONFIG_NET_VENDOR_BROADCOM' /boot/config-$(uname -r)Reads the booted kernel's own configuration, on the machine and nowhere else. =y is built in, =m is a module, and an is not set line means the code is not there.
lsmod | grep -w bnxt_enPrints a line if that module is loaded right now, and nothing if it is not. One that is not loaded can still be loaded later by anything that needs it.
Show whether Debian builds this, per release
Debian builds this, but not on every flavour. At least one release below builds the code on some of its kernel flavours and not on others, so the answer depends on the architecture and flavour installed.
- bookwormMnot built on amd64/cloud-amd64, arm64/cloud-arm64
- trixieMnot built on amd64/cloud-amd64, arm64/cloud-arm64, armel/rpi
- forky, sidMnot built on amd64/cloud-amd64, arm64/cloud-arm64
- M
- a module where it is built at all; some flavours do not build it
- Build switches
- CONFIG_BNXT, CONFIG_ETHERNET, CONFIG_NET_VENDOR_BROADCOM
- Reads as
- all on means the file is compiled; any one off means it is not.
From the configuration Debian publishes for every kernel flavour it builds. It covers only the architectures Debian ships a linux-config package for, and nothing about a kernel you built yourself. Debian's own status above stays authoritative about the source package.MAINTAINERS kbuild Makefiles Debian linux-config packages
Signals
- Published
- 2025-04-01 (19 months ago)source
- CVSS
- 7.5 high
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:Hsource recompute it - Attack vector
- network (AV:N)source
- EPSS
- 0.47%, higher than 39.2% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- not yet assignedsource
- Subsystem
- drivers/net
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 5.19 | 6.12.20 | 19107e71be33 |
| 5.19 | 6.13.8 | b4679807c608 |
| 5.19 | 6.14 | 9f7b2aa5034e |
Why the CNA scored it this way
Quoted from the kernel CNA's own scoring file, word for word. A highlighted metric carries the most severe value CVSS v3.1 defines for it, which is what pushes the score up. source
- AV:NAttack vector, network
- The bug is triggered entirely by an inbound Ethernet frame processed in the bnxt_en NAPI receive path (bnxt_rx_pkt → bnxt_xdp_build_skb), with the splat landing in ip_defrag()/skb_try_coalesce(); no local access to the target is required. Jumbo/multi-buffer frames are routable end-to-end inside jumbo-enabled datacenter and cloud VPC fabrics, so the sender need not share the victim's L2 segment.
- AC:LAttack complexity, low
- On an affected host (Broadcom NetXtreme NIC, jumbo MTU, multi-buffer XDP program returning XDP_PASS) every oversized packet deterministically produces the wrong truesize — the upstream reproducer is a single `ping -s 65000`. There is no race to win and no memory-layout condition outside the attacker's control.
- PR:NPrivileges required, none
- The vulnerable code executes in softirq/NAPI context on raw received frames, long before any socket lookup, authentication, or capability check. An unauthenticated attacker with no account on the target simply emits packets.
- UI:NUser interaction, none
- No victim action is needed at attack time; the XDP program and jumbo MTU are pre-existing deployment configuration, not interaction solicited from a user. Packet arrival alone drives the entire path.
- S:UScope, unchanged
- The miscounted truesize corrupts skb and socket memory accounting within the same kernel security authority that owns the RX path. No VM, container, or IOMMU boundary is crossed.
- C:NConfidentiality impact, none
- Only the truesize accounting field is wrong; skb->frags[] and xdp_frags_size retain their correct values, so no out-of-bounds or uninitialized memory is read or exposed to userspace. Nothing is disclosed to the attacker.
- I:NIntegrity impact, none
- There is no out-of-bounds write, type confusion, or control-flow corruption — the erroneous value only skews internal memory-accounting counters, whose consequence is availability rather than data modification.
- A:HAvailability impact, high
- The under-counted truesize trips WARN_ON_ONCE(delta < len) in skb_try_coalesce() during IP reassembly, which is an immediate kernel panic on the panic_on_warn configurations common in cloud and hardened fleets. Even without panic_on_warn, sk_rmem_alloc/sk_forward_alloc and the IP-defrag memory limit are under-charged by roughly the frag count, letting a remote flood pin several times the configured buffer memory and drive the system to OOM.