Look up another CVE · open CVE-2026-64069 in the interactive tracker
CVE-2026-64069
netfs: Fix cancellation of a DIO and single read subrequests
Published 2026-07-19 (3 months ago) by the Linux kernel CNA. Subsystem fs/netfs. Debian urgency: unimportant.
What to do, per Debian release
Debian's own status for CVE-2026-64069 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 | not affected | 6.1.190-1 | Nothing to do. bookworm never shipped the vulnerable code. |
| Debian 13trixie | not affected | 6.12.113-1 | Nothing to do. trixie never shipped the vulnerable code. |
| Debian 14forky | fixed | 7.0.12-1 | Update the kernel and reboot. Fixed in 7.0.12-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 7.0.12-1 | Update the kernel and reboot. Fixed in 7.0.12-1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
When the preparation of a new subrequest for a read fails, if the subrequest has already been added to the stream->subrequests list, it can't simply be put and abandoned as the collector may see it. Also, if it hasn't been queued yet, it has two outstanding refs that both need to be put. Both DIO read and single-read dispatch fail at this; further, both differ in the order they do things to the way buffered read works. Fix cancellation of both DIO-read and single-read subrequests that failed preparation by the following steps: (1) Harmonise all three reads (buffered, dio, single) to queue the subreq before prepping it. (2) Make all three call netfs_queue_read() to do the queuing. (3) Set NETFS_RREQ_ALL_QUEUED independently of the queuing as we don't know the length of the subreq at this point. (4) In all cases, set the error and NETFS_SREQ_FAILED flag on the subreq and then call netfs_read_subreq_terminated() to deal with it. This will pass responsibility off to the collector for dealing with it.
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/netfs/buffered_read.c
fs/netfs/direct_read.c
fs/netfs/internal.h
fs/netfs/read_collect.c
fs/netfs/read_single.c
- What this is
- FILESYSTEMS [NETFS LIBRARY]MAINTAINERS section matched on fs/netfs/ · netfs@lists.linux.dev · Supported
- Kernel module
- netfs
Check it on the machine
grep -w CONFIG_NETFS_SUPPORT /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 netfsPrints 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_NETFS_SUPPORT
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-07-19 (3 months ago)source
- CVSS
- 9.8 critical
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:Hsource recompute it - Attack vector
- network (AV:N)source
- EPSS
- 0.65%, higher than 50.1% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- unimportantsource
- Subsystem
- fs/netfs
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 6.14 | 6.18.34 | 5366199be46f |
| 6.14 | 7.0.11 | f73372a4c690 |
| 6.14 | 7.1 | 6f0f7ac1915a |
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 in the netfs client read path used by CIFS/SMB, 9p, AFS, and Ceph when serving network-backed I/O; a malicious remote filesystem server can induce prepare_read failure during multi-chunk O_DIRECT reads, exercising the faulty cancellation without local shell access on the victim.
- AC:LAttack complexity, low
- An attacker controlling the remote server and read parameters (O_DIRECT, read size spanning multiple subrequests) can reliably trigger prepare_read failure after partial submission, creating the stuck subrequest state; no rare memory layout or victim timing is required.
- PR:NPrivileges required, none
- Exploitation requires only that some client process perform a read on a mounted network filesystem share, which needs no elevated Linux privileges; SMB authentication to the attacker-controlled server does not constitute privilege on the victim host.
- UI:NUser interaction, none
- In common enterprise deployments the CIFS/AFS/9p mount is already established, so a remote attacker can trigger the bug through normal file access over the mount without additional victim actions beyond routine use of the share.
- S:UScope, unchanged
- Impact is confined to the kernel host processing the network filesystem read; it does not cross a VM/hypervisor or IOMMU security boundary.
- C:HConfidentiality impact, high
- Improper subrequest cancellation leaves queued objects visible to the collector with incorrect refcounting, creating a use-after-free class lifecycle bug where freed or inconsistent subrequest memory may be accessed during collection.
- I:HIntegrity impact, high
- The refcount/collector desynchronization can corrupt kernel heap metadata and, in the DIO path, prematurely calls inode_dio_end() while subrequests remain active, enabling memory corruption primitives beyond a simple error return.
- A:HAvailability impact, high
- A failed mid-read cancellation leaves subrequests stuck with NETFS_SREQ_IN_PROGRESS set, causing netfs_wait_for_read() to sleep in TASK_UNINTERRUPTIBLE indefinitely and producing a severe kernel-level denial of service.