Look up another CVE · open CVE-2026-74321 in the interactive tracker
CVE-2026-74321
btrfs: fix invalid pointer dereference in __btrfs_run_delayed_refs()
Published 2026-08-15 (2 months ago) by the Linux kernel CNA. Subsystem fs/btrfs. Debian urgency: not yet assigned.
What to do, per Debian release
Debian's own status for CVE-2026-74321 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 | fixed | 6.1.180-1 | Update the kernel and reboot. Fixed in 6.1.180-1. A running kernel keeps the old code until the machine restarts. |
| Debian 13trixie | fixed | 6.12.100-1 | Update the kernel and reboot. Fixed in 6.12.100-1. A running kernel keeps the old code until the machine restarts. |
| Debian 14forky | fixed | 7.1.5-1 | Update the kernel and reboot. Fixed in 7.1.5-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 7.1.5-1 | Update the kernel and reboot. Fixed in 7.1.5-1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
In the beginning of the loop, we try to obtain a locked delayed ref head, if 'locked_ref' is currently NULL, by calling btrfs_select_ref_head(), which can return an error pointer. If the error pointer is -EAGAIN we do a continue and go back to the beginning of the loop, which will not try again to call btrfs_select_ref_head() since 'locked_ref' is no longer NULL but it's ERR_PTR(-EAGAIN), and then we do: spin_lock(&locked_ref->lock); against a ERR_PTR(-EAGAIN) value, generating an invalid pointer dereference. Fix this by ensuring that 'locked_ref' is set to NULL when btrfs_select_ref_head() returns ERR_PTR(-EAGAIN) and incrementing 'count' as well, to prevent infinite looping. We do this by doing a goto to the bottom of the loop that already sets 'locked_ref' to NULL and does a cond_resched(), with an increment to 'count' right before the goto. These measures were in place before the refactoring in commit 0110a4c43451 ("btrfs: refactor __btrfs_run_delayed_refs loop") but were unintentionally lost afterwards.
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/btrfs/extent-tree.c
- What this is
- BTRFS FILE SYSTEMMAINTAINERS section matched on fs/btrfs/ · linux-btrfs@vger.kernel.org · Maintained
- Kernel module
- btrfs
Check it on the machine
grep -w CONFIG_BTRFS_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 btrfsPrints 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 as a loadable module. Every release below compiles it as a module on every flavour, so whether the code is in the running kernel depends on whether that module is loaded.
- bookworm, trixie, forky, sidm
- m
- a loadable module on every flavour - check lsmod, can be blacklisted
- Build switch
- CONFIG_BTRFS_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
- 2026-08-15 (2 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.72%, higher than 52.9% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- not yet assignedsource
- Subsystem
- fs/btrfs
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 4.20 | 5.10.261 | c372ca227e16 |
| 4.20 | 5.15.212 | a71143590ce9 |
| 4.20 | 6.1.178 | 65770111a2d4 |
| 4.20 | 6.6.145 | 015dc4a1e0c2 |
| 4.20 | 6.12.97 | ba9fa2ff5981 |
| 4.20 | 6.18.40 | 3b15d02be05e |
| 4.20 | 7.1.5 | 9faa6b69ad73 |
| 4.20 | 7.2 | 486f8298b618 |
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
- On storage servers exporting btrfs via nfsd or ksmbd, remote client write/fsync/unlink I/O reaches btrfs_run_delayed_refs() and __btrfs_run_delayed_refs() in the server kernel without any local syscall; this is the highest-impact but reasonable deployment for btrfs metadata processing.
- AC:LAttack complexity, low
- -EAGAIN is returned when a concurrent task deletes the delayed-ref head during btrfs_delayed_ref_lock(); an attacker controls both sides by driving parallel writes/unlinks/fsync or multiple NFS/SMB clients, reliably hitting the documented race without uncontrollable layout or victim state.
- PR:NPrivileges required, none
- Exploitation needs only network write access to an NFS or SMB export of the btrfs filesystem; no local account, Linux capability, or init-namespace privilege is required when the export permits client writes (including anonymous/guest exports common on NAS appliances).
- UI:NUser interaction, none
- The fault is triggered entirely by the attacker's own concurrent filesystem I/O against an already-exported btrfs volume; no separate victim must mount a filesystem, open a file, or perform any interactive action beyond the attacker's own operations.
- S:UScope, unchanged
- The invalid pointer dereference and resulting kernel oops occur within the host kernel's btrfs delayed-ref processing; no VM escape, IOMMU bypass, or cross-sandbox boundary is crossed.
- C:NConfidentiality impact, none
- The bug dereferences ERR_PTR(-EAGAIN), a small negative sentinel address, not freed or attacker-controlled memory; spin_lock faults immediately without returning kernel data, so there is no information-disclosure or read primitive.
- I:NIntegrity impact, none
- This is a logic error causing an invalid pointer dereference, not a use-after-free, out-of-bounds write, or type confusion; no kernel memory is modified before the faulting access aborts execution.
- A:HAvailability impact, high
- Dereferencing ERR_PTR(-EAGAIN) in spin_lock(&locked_ref->lock) causes a kernel oops/panic during delayed-ref processing, which can hang or crash the host and deny all service on the affected btrfs filesystem; the condition is repeatable with concurrent I/O.