Look up another CVE · open CVE-2025-21972 in the interactive tracker
CVE-2025-21972
net: mctp: unshare packets when reassembling
Published 2025-04-01 (19 months ago) by the Linux kernel CNA. Subsystem net/mctp. Debian urgency: not yet assigned.
Debian does not build this code. The per-release build detail is under "Where it lives" below.
What to do, per Debian release
Debian's own status for CVE-2025-21972 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
Ensure that the frag_list used for reassembly isn't shared with other packets. This avoids incorrect reassembly when packets are cloned, and prevents a memory leak due to circular references between fragments and their skb_shared_info. The upcoming MCTP-over-USB driver uses skb_clone which can trigger the problem - other MCTP drivers don't share SKBs. A kunit test is added to reproduce the 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.
net/mctp/route.c
net/mctp/test/route-test.c
- What this is
- MANAGEMENT COMPONENT TRANSPORT PROTOCOL (MCTP)MAINTAINERS section matched on net/mctp/ · netdev@vger.kernel.org · Maintained
- Kernel module
- none to look for. The file would have gone into mctp, and Debian does not compile it into that module, so finding mctp in lsmod would say nothing about this CVE.
Check it on the machine
grep -w CONFIG_MCTP /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.
Show whether Debian builds this, per release
Debian does not build this code. In 4 releases below, every kernel flavour Debian publishes has the switch off, so the vulnerable file is compiled into no kernel binary Debian ships.
- bookworm, trixie, forky, sidn
- n
- not enabled on any flavour - this release does not build the code
- Build switch
- CONFIG_MCTP
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
- 8.8 high
CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:Hsource recompute it - Attack vector
- adjacent network (AV:A)source
- EPSS
- 0.23%, higher than 12.7% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- not yet assignedsource
- Subsystem
- net/mctp
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 5.15 | 6.12.20 | 5c47d5bfa7b0 |
| 5.15 | 6.13.8 | f44fff3d3c6c |
| 5.15 | 6.14 | f5d83cf0eeb9 |
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:AAttack vector, adjacent network
- The vulnerable code is a network-stack packet handler (`ETH_P_MCTP` packet_type → `mctp_route_input`), but MCTP has no internet-routable transport in the kernel — packets arrive from a device on the local management bus (SMBus/I2C, I3C, USB, serial), a limited administrative domain directly analogous to the Bluetooth/WiFi case.
- AC:LAttack complexity, low
- The attacker fully controls both preconditions: sending a multi-packet (SOM/EOM) fragmented message, and causing the skbs to be clones by packing several MCTP packets into a single transfer (`mctp-usb.c:219`). No race, memory-layout dependency, or victim state is involved, and the kunit reproducer added by the fix triggers it deterministically.
- PR:NPrivileges required, none
- There is no authentication or authorization anywhere on the path from `mctp_pkttype_receive()` to `mctp_frag_queue()` — MCTP packets are parsed and reassembled purely on header contents, so a device on the bus needs no credentials or local account.
- UI:NUser interaction, none
- Reassembly happens in softirq context on packet receive; no user action is needed on the victim system beyond having MCTP configured, which is the normal state for the affected BMC/host management deployments.
- S:UScope, unchanged
- The corruption and its consequences are confined to kernel skb structures within the same security authority; no VM, IOMMU, or sandbox boundary is crossed.
- C:HConfidentiality impact, high
- Writing the reassembly `frag_list` into a shared `skb_shared_info` cross-links skbs belonging to different reassembly contexts and to other subsystems (e.g. AF_PACKET clones), so a socket can be delivered a fragment chain from an unrelated message with mismatched length accounting — memory-state corruption leveragable for disclosure of data from another context.
- I:HIntegrity impact, high
- The bug both delivers incorrectly reassembled message content to MCTP sockets (corrupting PLDM/NVMe-MI/NC-SI management traffic) and plants an attacker-influenced skb pointer into a `skb_shared_info` owned by other subsystems, which is later dereferenced and freed by an owner that never expected a fragment list.
- A:HAvailability impact, high
- Every cloned fragmented message permanently leaks its skbs and backing data buffer through the circular `frag_list`/`dataref` reference, and the attacker can repeat this without limit — driving memory exhaustion and OOM/kernel failure on the memory-constrained BMC and embedded systems where MCTP is deployed.