Look up another CVE · open CVE-2026-63795 in the interactive tracker
CVE-2026-63795
9p: avoid putting oldfid in p9_client_walk() error path
Published 2026-07-19 (3 months ago) by the Linux kernel CNA. Subsystem net/9p. Debian urgency: not yet assigned.
What to do, per Debian release
Debian's own status for CVE-2026-63795 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.177-1 | Update the kernel and reboot. Fixed in 6.1.177-1. A running kernel keeps the old code until the machine restarts. |
| Debian 13trixie | fixed | 6.12.95-1 | Update the kernel and reboot. Fixed in 6.12.95-1. A running kernel keeps the old code until the machine restarts. |
| Debian 14forky | fixed | 7.1.3-1 | Update the kernel and reboot. Fixed in 7.1.3-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 7.1.3-1 | Update the kernel and reboot. Fixed in 7.1.3-1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
When p9_client_walk() is called with clone set to false, fid aliases oldfid. If the walk subsequently fails after the request has been sent, the error path jumps to clunk_fid, which currently calls p9_fid_put(fid) unconditionally. This drops a reference to oldfid even though ownership of oldfid remains with the caller. If this is the last reference, oldfid can be clunked and destroyed while the caller still expects it to be valid. A later use or put of oldfid can then trigger a use-after-free or refcount underflow. Fix this by only putting fid in the clunk_fid error path when it does not alias oldfid, matching the existing guard in the error path below. This can be triggered when a multi-component walk is split into multiple p9_client_walk() calls and a later non-cloning walk fails. A reproducer and refcount warning logs are available on request.
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.
net/9p/client.c
- What this is
- 9P FILE SYSTEMMAINTAINERS section matched on net/9p/ · v9fs@lists.linux.dev · Maintained
- Kernel module
- 9pnet
Check it on the machine
grep -w CONFIG_NET_9P /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 9pnetPrints 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_NET_9P
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
- 10.0 critical
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:Hsource recompute it - Attack vector
- network (AV:N)source
- EPSS
- 0.50%, higher than 41.7% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- not yet assignedsource
- Subsystem
- net/9p
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 6.0 | 6.1.177 | 99c379ca1e22 |
| 6.0 | 6.6.144 | b84f46179c80 |
| 6.0 | 6.12.95 | a61bdcba4f64 |
| 6.0 | 6.18.38 | 6dbe9443d9f5 |
| 6.0 | 7.1.3 | a7656d368265 |
| 6.0 | 7.2 | 1a3860d46e3e |
Debian advisories
| Advisory | Date | Shipped to | Debian |
|---|---|---|---|
| DLA-4700-1 | 2026-07-26 | bullseye 6.1.177-1~deb11u1 | 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:NAttack vector, network
- The kernel 9p client processes TWALK responses from a remote 9p server over TCP/RDMA transports, and a malicious or compromised server can return a partial RWALK (nwqids < nwname) or malformed reply to hit the clunk_fid error path during a multi-segment walk.
- AC:LAttack complexity, low
- An attacker who controls the 9p server can reliably craft deep directory layouts and RWALK failure responses; the reproducer path (split multi-component walk with a failing non-cloning segment) does not depend on race timing or memory layout.
- PR:NPrivileges required, none
- Exploitation only requires access to an already-mounted 9p filesystem and normal file operations (lookup/stat/open) that trigger v9fs_fid_lookup(); no elevated kernel capabilities or real-root privileges are needed beyond filesystem access permissions.
- UI:NUser interaction, none
- No interactive victim action is required beyond routine file access on a pre-mounted 9p filesystem (common with virtio-9p in QEMU/KVM/Firecracker VMs where the mount is established at boot).
- S:CScope, changed
- A malicious remote 9p server operates outside the kernel client's security boundary, and successful exploitation corrupts kernel heap memory (struct p9_fid use-after-free), impacting the kernel beyond the 9p client's own scope.
- C:HConfidentiality impact, high
- Premature p9_fid_put() can destroy oldfid while callers still hold dangling references, producing a heap use-after-free on struct p9_fid that is exploitable for arbitrary kernel memory disclosure.
- I:HIntegrity impact, high
- The use-after-free and refcount underflow on struct p9_fid provide heap corruption primitives that can be leveraged for arbitrary kernel writes and local privilege escalation.
- A:HAvailability impact, high
- The bug can cause immediate kernel oops/panic from use-after-free or refcount underflow when the prematurely freed fid is subsequently accessed or put again.