Look up another CVE · open CVE-2024-53090 in the interactive tracker
CVE-2024-53090
afs: Fix lock recursion
Published 2024-11-21 (23 months ago) by the Linux kernel CNA. Subsystem fs/afs. Debian urgency: not yet assigned.
What to do, per Debian release
Debian's own status for CVE-2024-53090 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.11.9-1 | Update the kernel and reboot. Fixed in 6.11.9-1. A running kernel keeps the old code until the machine restarts. |
| Debian 14forky | fixed | 6.11.9-1 | Update the kernel and reboot. Fixed in 6.11.9-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 6.11.9-1 | Update the kernel and reboot. Fixed in 6.11.9-1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
afs_wake_up_async_call() can incur lock recursion. The problem is that it is called from AF_RXRPC whilst holding the ->notify_lock, but it tries to take a ref on the afs_call struct in order to pass it to a work queue - but if the afs_call is already queued, we then have an extraneous ref that must be put... calling afs_put_call() may call back down into AF_RXRPC through rxrpc_kernel_shutdown_call(), however, which might try taking the ->notify_lock again. This case isn't very common, however, so defer it to a workqueue. The oops looks something like: BUG: spinlock recursion on CPU#0, krxrpcio/7001/1646 lock: 0xffff888141399b30, .magic: dead4ead, .owner: krxrpcio/7001/1646, .owner_cpu: 0 CPU: 0 UID: 0 PID: 1646 Comm: krxrpcio/7001 Not tainted 6.12.0-rc2-build3+ #4351 Hardware name: ASUS All Series/H97-PLUS, BIOS 2306 10/09/2014 Call Trace: <TASK> dump_stack_lvl+0x47/0x70 do_raw_spin_lock+0x3c/0x90 rxrpc_kernel_shutdown_call+0x83/0xb0 afs_put_call+0xd7/0x180 rxrpc_notify_socket+0xa0/0x190 rxrpc_input_split_jumbo+0x198/0x1d0 rxrpc_input_data+0x14b/0x1e0 ? rxrpc_input_call_packet+0xc2/0x1f0 rxrpc_input_call_event+0xad/0x6b0 rxrpc_input_packet_on_conn+0x1e1/0x210 rxrpc_input_packet+0x3f2/0x4d0 rxrpc_io_thread+0x243/0x410 ? __pfx_rxrpc_io_thread+0x10/0x10 kthread+0xcf/0xe0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x24/0x40 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/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.
fs/afs/internal.h
fs/afs/rxrpc.c
- What this is
- AFS FILESYSTEMMAINTAINERS section matched on fs/afs/ · linux-afs@lists.infradead.org · Supported
- Kernel module
- kafs
Check it on the machine
grep -w CONFIG_AFS_FS /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 kafsPrints 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.
- bookworm, trixie, forky, sidMnot built on amd64/cloud-amd64, arm64/cloud-arm64
- M
- a module where it is built at all; some flavours do not build it
- Build switch
- CONFIG_AFS_FS
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
- 2024-11-21 (23 months ago)source
- CVSS
- 7.5 high
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:Hsource recompute it - Attack vector
- network (AV:N)source
- EPSS
- 0.46%, higher than 38.5% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- not yet assignedsource
- Subsystem
- fs/afs
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 4.15 | 6.11.9 | d7cbf81df996 |
| 4.15 | 6.12 | 610a79ffea02 |
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:NAttack vector, network
- The bug is reached from the rxrpc I/O thread processing received network data packets (rxrpc_input_packet → rxrpc_input_split_jumbo → rxrpc_notify_socket) on AFS calls carried over RxRPC/UDP, which is routable across networks; a remote AFS server or packet-injecting attacker triggers it.
- AC:LAttack complexity, low
- Triggering needs the async_work already queued and the dropped ref to be the last one, but an attacker can flood jumbo data packets to pile up notifications and repeatedly drive this window; per the choose-higher rule this is Low.
- PR:NPrivileges required, none
- The trigger is remote network packets processed in the kernel's packet-receive path; the attacker needs no account or privileges on the target host.
- UI:NUser interaction, none
- The vulnerable async paths (server GetCapabilities probes and server-initiated CM/callback calls) fire automatically as part of normal AFS operation, so no victim action is required at exploit time.
- S:UScope, unchanged
- The deadlock/crash is confined to the kernel that owns the affected code; no security boundary (VM/IOMMU/sandbox) is crossed.
- C:NConfidentiality impact, none
- This is a spinlock self-recursion with no out-of-bounds access or freed-object reuse, so no memory contents are exposed.
- I:NIntegrity impact, none
- The bug provides no write primitive and corrupts no data; it only deadlocks a lock, so integrity is unaffected.
- A:HAvailability impact, high
- The recursion deadlocks (or BUG-splats) the krxrpcio I/O thread while holding the notify spinlock, hanging all rxrpc/AFS packet processing and crashing/wedging the kernel.