Look up another CVE · open CVE-2024-57795 in the interactive tracker
CVE-2024-57795
RDMA/rxe: Remove the direct link to net_device
Published 2025-01-15 (21 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-2024-57795 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.9-1 | Update the kernel and reboot. Fixed in 6.12.9-1. A running kernel keeps the old code until the machine restarts. |
| Debian 14forky | fixed | 6.12.9-1 | Update the kernel and reboot. Fixed in 6.12.9-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 6.12.9-1 | Update the kernel and reboot. Fixed in 6.12.9-1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
The similar patch in siw is in the link: https://git.kernel.org/rdma/rdma/c/16b87037b48889 This problem also occurred in RXE. The following analyze this problem. In the following Call Traces: " BUG: KASAN: slab-use-after-free in dev_get_flags+0x188/0x1d0 net/core/dev.c:8782 Read of size 4 at addr ffff8880554640b0 by task kworker/1:4/5295 CPU: 1 UID: 0 PID: 5295 Comm: kworker/1:4 Not tainted 6.12.0-rc3-syzkaller-00399-g9197b73fd7bb #0 Hardware name: Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 Workqueue: infiniband ib_cache_event_task Call Trace: <TASK> __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:377 [inline] print_report+0x169/0x550 mm/kasan/report.c:488 kasan_report+0x143/0x180 mm/kasan/report.c:601 dev_get_flags+0x188/0x1d0 net/core/dev.c:8782 rxe_query_port+0x12d/0x260 drivers/infiniband/sw/rxe/rxe_verbs.c:60 __ib_query_port drivers/infiniband/core/device.c:2111 [inline] ib_query_port+0x168/0x7d0 drivers/infiniband/core/device.c:2143 ib_cache_update+0x1a9/0xb80 drivers/infiniband/core/cache.c:1494 ib_cache_event_task+0xf3/0x1e0 drivers/infiniband/core/cache.c:1568 process_one_work kernel/workqueue.c:3229 [inline] process_scheduled_works+0xa65/0x1850 kernel/workqueue.c:3310 worker_thread+0x870/0xd30 kernel/workqueue.c:3391 kthread+0x2f2/0x390 kernel/kthread.c:389 ret_from_fork+0x4d/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 </TASK> " 1). In the link [1], " infiniband syz2: set down " This means that on 839.350575, the event ib_cache_event_task was sent andi queued in ib_wq. 2). In the link [1], " team0 (unregistering): Port device team_slave_0 removed " It indicates that before 843.251853, the net device should be freed. 3). In the link [1], " BUG: KASAN: slab-use-after-free in dev_get_flags+0x188/0x1d0 " This means that on 850.559070, this slab-use-after-free problem occurred. In all, on 839.350575, the event ib_cache_event_task was sent and queued in ib_wq, before 843.251853, the net device veth was freed. on 850.559070, this event was executed, and the mentioned freed net device was called. Thus, the above call trace occurred. [1] https://syzkaller.appspot.com/x/log.txt?x=12e7025f980000
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.c
drivers/infiniband/sw/rxe/rxe.h
drivers/infiniband/sw/rxe/rxe_mcast.c
drivers/infiniband/sw/rxe/rxe_net.c
drivers/infiniband/sw/rxe/rxe_verbs.c
drivers/infiniband/sw/rxe/rxe_verbs.h
- 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
- 2025-01-15 (21 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.22%, higher than 11.9% 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 |
|---|---|---|
| 4.8 | 6.6.120 | 32ca3557d968 |
| 4.8 | 6.12.9 | 9f6f54e6a686 |
| 4.8 | 6.13 | 2ac5415022d1 |
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 dangling `rxe->ndev` is dereferenced from local paths — RDMA netlink link add/del, netdev up/down/unregister events, and uverbs QUERY_PORT/ATTACH_MCAST on /dev/infiniband/uverbsN. Incoming RoCEv2 packets use `skb->dev` rather than the cached pointer, so there is no remote trigger.
- AC:LAttack complexity, low
- The attacker drives both halves deterministically: bring the netdev down to queue `ib_cache_event_task`, then delete the netdev so `free_netdevs()` drops the last reference before `flush_workqueue(ib_wq)` runs the pending work. syzbot reproduced it, and the sequence can be looped until it lands.
- PR:LPrivileges required, low
- On a system with Soft-RoCE already configured, the UAF dereference sites (`rxe_query_port`, `rxe_mcast_add`/`rxe_mcast_del`) are reachable by any local unprivileged user through the world-accessible uverbs character device and sysfs port attributes. This matches the scoring of the same class of RDMA lifetime UAFs (CVE-2025-22085, CVE-2025-38022, CVE-2025-38024).
- UI:NUser interaction, none
- The entire sequence is performed by the attacker via netlink and verbs calls; no victim action or cooperation is needed.
- S:UScope, unchanged
- The freed `struct net_device` and the corrupting code both live in the kernel's own security authority; no VM, IOMMU, or sandbox boundary is crossed.
- C:HConfidentiality impact, high
- This is a slab use-after-free on `struct net_device`; the attacker can spray the freed slab and have `dev_get_flags()`/`netif_running()`/`netdev_name()` read back reclaimed content, and the leaked port state and device-name data flow back to userspace via query_port and dev_info.
- I:HIntegrity impact, high
- `dev_mc_add()`/`dev_mc_del()` on the freed netdev perform list manipulation into reclaimed slab memory and then indirect-call `dev->netdev_ops->ndo_set_rx_mode` through a freed function-pointer table, giving a write and control-flow-hijack primitive.
- A:HAvailability impact, high
- The confirmed KASAN slab-use-after-free read in `dev_get_flags()` panics the kernel with `panic_on_warn`/KASAN and readily oopses otherwise, and the multicast paths corrupt freed heap state leading to further crashes.