Look up another CVE · open CVE-2025-21714 in the interactive tracker
CVE-2025-21714
RDMA/mlx5: Fix implicit ODP use after free
Published 2025-02-27 (20 months ago) by the Linux kernel CNA. Subsystem drivers/infiniband. Debian urgency: not yet assigned.
What to do, per Debian release
Debian's own status for CVE-2025-21714 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.13-1 | Update the kernel and reboot. Fixed in 6.12.13-1. A running kernel keeps the old code until the machine restarts. |
| Debian 14forky | fixed | 6.12.13-1 | Update the kernel and reboot. Fixed in 6.12.13-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 6.12.13-1 | Update the kernel and reboot. Fixed in 6.12.13-1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
Prevent double queueing of implicit ODP mr destroy work by using __xa_cmpxchg() to make sure this is the only time we are destroying this specific mr. Without this change, we could try to invalidate this mr twice, which in turn could result in queuing a MR work destroy twice, and eventually the second work could execute after the MR was freed due to the first work, causing a user after free and trace below. refcount_t: underflow; use-after-free. WARNING: CPU: 2 PID: 12178 at lib/refcount.c:28 refcount_warn_saturate+0x12b/0x130 Modules linked in: bonding ib_ipoib vfio_pci ip_gre geneve nf_tables ip6_gre gre ip6_tunnel tunnel6 ipip tunnel4 ib_umad rdma_ucm mlx5_vfio_pci vfio_pci_core vfio_iommu_type1 mlx5_ib vfio ib_uverbs mlx5_core iptable_raw openvswitch nsh rpcrdma ib_iser libiscsi scsi_transport_iscsi rdma_cm iw_cm ib_cm ib_core xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink xt_addrtype iptable_nat nf_nat br_netfilter rpcsec_gss_krb5 auth_rpcgss oid_registry overlay zram zsmalloc fuse [last unloaded: ib_uverbs] CPU: 2 PID: 12178 Comm: kworker/u20:5 Not tainted 6.5.0-rc1_net_next_mlx5_58c644e #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 Workqueue: events_unbound free_implicit_child_mr_work [mlx5_ib] RIP: 0010:refcount_warn_saturate+0x12b/0x130 Code: 48 c7 c7 38 95 2a 82 c6 05 bc c6 fe 00 01 e8 0c 66 aa ff 0f 0b 5b c3 48 c7 c7 e0 94 2a 82 c6 05 a7 c6 fe 00 01 e8 f5 65 aa ff <0f> 0b 5b c3 90 8b 07 3d 00 00 00 c0 74 12 83 f8 01 74 13 8d 50 ff RSP: 0018:ffff8881008e3e40 EFLAGS: 00010286 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000027 RDX: ffff88852c91b5c8 RSI: 0000000000000001 RDI: ffff88852c91b5c0 RBP: ffff8881dacd4e00 R08: 00000000ffffffff R09: 0000000000000019 R10: 000000000000072e R11: 0000000063666572 R12: ffff88812bfd9e00 R13: ffff8881c792d200 R14: ffff88810011c005 R15: ffff8881002099c0 FS: 0000000000000000(0000) GS:ffff88852c900000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f5694b5e000 CR3: 00000001153f6003 CR4: 0000000000370ea0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> ? refcount_warn_saturate+0x12b/0x130 free_implicit_child_mr_work+0x180/0x1b0 [mlx5_ib] process_one_work+0x1cc/0x3c0 worker_thread+0x218/0x3c0 kthread+0xc6/0xf0 ret_from_fork+0x1f/0x30 </TASK>
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/infiniband/hw/mlx5/odp.c
- What this is
- MELLANOX MLX5 IB driverMAINTAINERS section matched on drivers/infiniband/hw/mlx5/ · linux-rdma@vger.kernel.org · Supported
- Kernel module
- mlx5_ib
Check it on the machine
grep -wE 'CONFIG_INFINIBAND|CONFIG_INFINIBAND_ON_DEMAND_PAGING|CONFIG_MLX5_INFINIBAND' /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 mlx5_ibPrints 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.
- bookwormm
- trixieMnot built on armel/rpi
- forky, sidm
- m
- a loadable module on every flavour - check lsmod, can be blacklisted
- M
- a module where it is built at all; some flavours do not build it
- Build switches
- CONFIG_INFINIBAND, CONFIG_INFINIBAND_ON_DEMAND_PAGING, CONFIG_MLX5_INFINIBAND
- 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-02-27 (20 months ago)source
- CVSS
- 7.8 high
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:Hsource recompute it - Attack vector
- local (AV:L)source
- EPSS
- 0.20%, higher than 9.1% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- not yet assignedsource
- Subsystem
- drivers/infiniband
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 5.5 | 6.12.13 | 7cc8f681f6d4 |
| 5.5 | 6.13.2 | edfb65dbb9ff |
| 5.5 | 6.14 | d3d930411ce3 |
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:LAttack vector, local
- The attack requires local access to the RDMA verbs uAPI (/dev/infiniband/uverbs*) to register an implicit ODP MR, and the invalidation half of the race requires local mm operations (munmap/madvise) that a remote peer cannot induce. Remote RDMA traffic can drive the page-fault half but not the whole race, so the vector is Local.
- AC:LAttack complexity, low
- The attacker controls both sides of the race from its own process — repeated ibv_advise_mr prefetch faults on the implicit MR in one thread and munmap/MADV_DONTNEED invalidations of the same range in another — and can retry the loop indefinitely on many child MRs in parallel. No condition depends on state outside the attacker's influence.
- PR:LPrivileges required, low
- An unprivileged local account with access to the InfiniBand verbs character device suffices; there is no capability check anywhere on the reg_mr/ODP/prefetch path (only CAP_NET_RAW for raw QPs and CAP_IPC_LOCK for pinning, neither of which applies to ODP). Unprivileged verbs access is the intended design of RDMA and is routine in HPC, RoCE cloud, and containerized deployments.
- UI:NUser interaction, none
- The attacking process registers its own implicit ODP MR and triggers both the page faults and the invalidations itself. No victim action or cooperation is needed.
- S:UScope, unchanged
- The corruption is confined to kernel memory managed by the same kernel security authority; there is no VM, IOMMU, or sandbox boundary crossed. Standard kernel-local privilege escalation scope.
- C:HConfidentiality impact, high
- The second execution of free_implicit_child_mr_work() operates on a freed, kzalloc'd mlx5_ib_mr from a generic kmalloc slab, so an attacker who reclaims the object controls mr->parent, mr->umem, and mr->mmkey and can turn the dereferences into arbitrary kernel reads. Destroying an mkey number that has been reassigned can additionally expose another RDMA consumer's registered memory.
- I:HIntegrity impact, high
- The double queue_work yields a use-after-free plus a double mlx5_ib_dereg_mr() free, and INIT_WORK() on an already-pending work item corrupts workqueue linked lists — both classic paths to a controlled write primitive and control-flow hijack via heap spraying.
- A:HAvailability impact, high
- Even unweaponized, the bug produces the refcount_t underflow WARNING and subsequent oops shown in the commit trace, and the underflowed usecount can leave mlx5r_deref_wait_odp_mkey() waiting forever, hanging an unbound workqueue worker. Any of these is a full availability loss.