data built 2026-10-19T13:16:53Z

Look up another CVE · open CVE-2025-21972 in the interactive tracker

CVE-2025-21972

net: mctp: unshare packets when reassembling

8.8 EPSS 0.2% AV:A

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

ReleaseStatus VersionWhat this means
Debian 12bookwormvulnerable6.1.190-1No 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 13trixiefixed6.12.20-1Update the kernel and reboot. Fixed in 6.12.20-1. A running kernel keeps the old code until the machine restarts.
Debian 14forkyfixed6.12.20-1Update the kernel and reboot. Fixed in 6.12.20-1. A running kernel keeps the old code until the machine restarts.
Debian unstablesidfixed6.12.20-1Update 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

IntroducedFixed inCommit
5.156.12.205c47d5bfa7b0
5.156.13.8f44fff3d3c6c
5.156.14f5d83cf0eeb9

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.