Look up another CVE · open CVE-2026-98360 in the interactive tracker
CVE-2026-98360
RDMA/rxe: insert mcg into mcg_tree only after rxe_mcast_add() succeeds
Published 2026-10-06 (13 days 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-2026-98360 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 | fixedDLA-4841-1 · 2026-10-17 · text | 6.1.190-1 | Update the kernel and reboot. DLA-4841-1 shipped the fix on 2026-10-17, in 6.1.190-1. A running kernel keeps the old code until the machine restarts. |
| Debian 13trixie | fixedDSA-6568-1 · 2026-10-16 · text | 6.12.113-1 | Update the kernel and reboot. DSA-6568-1 shipped the fix on 2026-10-16, in 6.12.113-1. A running kernel keeps the old code until the machine restarts. |
| Debian 14forky | fixed | 7.2.8-1 | Update the kernel and reboot. Fixed in 7.2.8-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 7.2.8-1 | Update the kernel and reboot. Fixed in 7.2.8-1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
rxe_get_mcg() publishes a newly allocated multicast group in rxe->mcg_tree before programming the backing Ethernet multicast address with rxe_mcast_add(), which runs outside mcg_lock. A local userspace RDMA client reaches this path with ATTACH_MCAST on a UD QP; if rxe_mcast_add() then returns an error (for example -ENODEV when the backing netdev has been removed, or a propagated dev_mc_add() error), the unwind frees the published group without removing it from the tree. A later lookup of the same MGID dereferences the freed struct rxe_mcg from __rxe_lookup_mcg(). Fix this by keeping the new mcg private until rxe_mcast_add() succeeds. Split the tree publication into __rxe_publish_mcg(), call rxe_mcast_add() before taking the tree reference, and free the still-private mcg on failure. Because the group is never visible in mcg_tree until the multicast address is programmed, no concurrent caller can look it up or attach a QP to a group that is about to be torn down, so the error path needs no conditional unwind. If another caller publishes the same MGID while the address is being programmed, the post-add re-check under mcg_lock finds the winner; this caller then drops its private object and balances its own rxe_mcast_add() with rxe_mcast_del() before returning the winner. Reproduced by forcing the rxe_mcast_add() error return under KASAN: without the change the next attach to the same MGID reports a slab-use-after-free in __rxe_lookup_mcg(); with it the forced failure returns cleanly. A no-injection attach/detach regression, including a two-QP shared join/leave and re-attach, stays KASAN- and leak-clean.
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/sw/rxe/rxe_mcast.c
- What this is
- SOFT-ROCE DRIVER (rxe)MAINTAINERS section matched on drivers/infiniband/sw/rxe/ · linux-rdma@vger.kernel.org · Supported
- Kernel module
- rdma_rxe
Check it on the machine
grep -wE 'CONFIG_INFINIBAND|CONFIG_RDMA_RXE' /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 rdma_rxePrints 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, armhf/armmp, armhf/armmp-lpae, armhf/rt/armmp, i386/686, i386/686-pae, i386/rt/686-pae
- trixieMnot built on amd64/cloud-amd64, arm64/cloud-arm64, armel/rpi, armhf/armmp, armhf/armmp-lpae, armhf/rt/armmp
- forky, sidMnot built on amd64/cloud-amd64, arm64/cloud-arm64, armhf/armmp, armhf/armmp-lpae
- M
- a module where it is built at all; some flavours do not build it
- Build switches
- CONFIG_INFINIBAND, CONFIG_RDMA_RXE
- 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
- 2026-10-06 (13 days ago)source
- CVSS
- 7.0 high
CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:Hsource recompute it - Attack vector
- local (AV:L)source
- EPSS
- 0.13%, higher than 2.4% 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.18 | 6.1.189 | ddb43ac0926d |
| 5.18 | 6.6.158 | c79a789aa151 |
| 5.18 | 6.12.112 | faae1fb4ccf8 |
| 5.18 | 6.18.54 | 02c0a2fa69c1 |
| 5.18 | 7.2.8 | d4fc4e37f8a1 |
| 5.18 | 7.3 | 1caceeb2d74b |
Debian advisories
| Advisory | Date | Shipped to | Debian |
|---|---|---|---|
| DLA-4841-1 | 2026-10-17 | bookworm 6.1.190-1 | tracker |
| DSA-6568-1 | 2026-10-16 | trixie 6.12.113-1 | tracker |
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 faulty publish-then-free sequence is in rxe_get_mcg(), reached from the uverbs ATTACH_MCAST command (ib_uverbs_attach_mcast -> ib_attach_mcast -> rxe_attach_mcast) on a local UD QP. A remote RoCEv2 multicast packet (rxe_rcv_mcast_pkt -> rxe_lookup_mcg) can only hit the stale node after a local caller has already caused the failure.
- AC:HAttack complexity, high
- The dangling mcg is only left behind when rxe_mcast_add() fails after the group is published. That needs ib_device_get_netdev() to return NULL while the rxe netdev is being unregistered (an admin or hardware event), or a GFP_ATOMIC failure in __hw_addr_create(). An unprivileged user cannot produce either on demand.
- PR:LPrivileges required, low
- ib_uverbs_attach_mcast() and rxe_attach_mcast() have no capability check, so any user who can open the rxe uverbs device and create a UD QP can drive rxe_get_mcg(). Creating the rxe link itself (RDMA_NL_ADMIN_PERM, checked with netlink_capable against the init namespace) is admin setup the attacker does not perform.
- UI:NUser interaction, none
- The attacker issues ATTACH_MCAST for the failing MGID and then the follow-up attach/detach/lookup themselves; no other user has to act.
- S:UScope, unchanged
- The freed rxe_mcg is kernel heap memory in the same kernel security authority; there is no VM, IOMMU or sandbox boundary crossed.
- C:HConfidentiality impact, high
- The freed struct rxe_mcg stays linked in rxe->mcg_tree. __rxe_lookup_mcg() walks its rb_node and mgid, and later code follows its qp_list, so reallocating that slab slot with attacker-chosen data gives a heap read primitive.
- I:HIntegrity impact, high
- After the free, __rxe_lookup_mcg() does kref_get() on the stale object, and rxe_attach_mcg() list_add()s an mca into its qp_list and updates qp_num. These are writes into reallocated memory, and the rb-tree insert/erase relinks through the freed node.
- A:HAvailability impact, high
- The next ATTACH_MCAST, detach, or received multicast lookup for that MGID dereferences the freed rxe_mcg (KASAN slab-use-after-free in __rxe_lookup_mcg()), corrupting the rb-tree and crashing the kernel.