CVE-2025-40027: net/9p: fix double req put in p9_fd_cancelled
In the Linux kernel, the following vulnerability has been resolved:
net/9p: fix double req put in p9_fd_cancelled
Syzkaller reports a KASAN issue as below:
general protection fault, probably for non-canonical address 0xfbd59c0000000021: 0000 [#1] PREEMPT SMP KASAN NOPTI
KASAN: maybe wild-memory-access in range [0xdead000000000108-0xdead00000000010f]
CPU: 0 PID: 5083 Comm: syz-executor.2 Not tainted 6.1.134-syzkaller-00037-g855bd1d7d838 #0
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014
RIP: 0010:__list_del include/linux/list.h:114 [inline]
RIP: 0010:__list_del_entry include/linux/list.h:137 [inline]
RIP: 0010:list_del include/linux/list.h:148 [inline]
RIP: 0010:p9_fd_cancelled+0xe9/0x200 net/9p/trans_fd.c:734
Call Trace:
<TASK>
p9_client_flush+0x351/0x440 net/9p/client.c:614
p9_client_rpc+0xb6b/0xc70 net/9p/client.c:734
p9_client_version net/9p/client.c:920 [inline]
p9_client_create+0xb51/0x1240 net/9p/client.c:1027
v9fs_session_init+0x1f0/0x18f0 fs/9p/v9fs.c:408
v9fs_mount+0xba/0xcb0 fs/9p/vfs_super.c:126
legacy_get_tree+0x108/0x220 fs/fs_context.c:632
vfs_get_tree+0x8e/0x300 fs/super.c:1573
do_new_mount fs/namespace.c:3056 [inline]
path_mount+0x6a6/0x1e90 fs/namespace.c:3386
do_mount fs/namespace.c:3399 [inline]
__do_sys_mount fs/namespace.c:3607 [inline]
__se_sys_mount fs/namespace.c:3584 [inline]
__x64_sys_mount+0x283/0x300 fs/namespace.c:3584
do_syscall_x64 arch/x86/entry/common.c:51 [inline]
do_syscall_64+0x35/0x80 arch/x86/entry/common.c:81
entry_SYSCALL_64_after_hwframe+0x6e/0xd8
This happens because of a race condition between:
- The 9p client sending an invalid flush request and later cleaning it up;
- The 9p client in p9_read_work() canceled all pending requests.
Thread 1 Thread 2
...
p9_client_create()
...
p9_fd_create()
...
p9_conn_create()
...
// start Thread 2
INIT_WORK(&m->rq, p9_read_work);
p9_read_work()
...
p9_client_rpc()
...
...
p9_conn_cancel()
...
spin_lock(&m->req_lock);
...
p9_fd_cancelled()
...
...
spin_unlock(&m->req_lock);
// status rewrite
p9_client_cb(m->client, req, REQ_STATUS_ERROR)
// first remove
list_del(&req->req_list);
...
spin_lock(&m->req_lock)
...
// second remove
list_del(&req->req_list);
spin_unlock(&m->req_lock)
...
Commit 74d6a5d56629 ("9p/trans_fd: Fix concurrency del of req_list in
p9_fd_cancelled/p9_read_work") fixes a concurrency issue in the 9p filesystem
client where the req_list could be deleted simultaneously by both
p9_read_work and p9_fd_cancelled functions, but for the case where req->status
equals REQ_STATUS_RCVD.
Update the check for req->status in p9_fd_cancelled to skip processing not
just received requests, but anything that is not SENT, as whatever
changed the state from SENT also removed the request from its list.
Found by Linux Verification Center (linuxtesting.org) with Syzkaller.
[updated the check from status == RECV || status == ERROR to status != SENT]
Security readout for executives and security teams
Plain-English summary
A race in the Linux 9p filesystem client can clean up the same request twice, corrupting kernel memory. A locally authenticated, low-privileged attacker may be able to trigger the flaw without user interaction. Successful exploitation could affect confidentiality, integrity, or availability, although the supplied sources do not demonstrate a working exploit.
Executive priority
Treat as high priority on multi-user or otherwise untrusted Linux systems using 9p. Patch promptly after vendor validation. Systems without reachable 9p functionality have lower practical urgency, but the ambiguous version data warrants an inventory check rather than assuming they are unaffected.
Technical view
CVE-2025-40027 affects p9_fd_cancelled in the Linux 9p file-descriptor transport. Concurrent request cancellation by p9_read_work can remove a request from req_list before p9_fd_cancelled removes it again, causing invalid list manipulation and wild kernel-memory access. The fix limits cancellation processing to requests still in REQ_STATUS_SENT.
Likely exposure
Exposure requires an affected Linux kernel and a reachable 9p client path using the relevant transport. Risk is greatest where low-privileged local users can exercise that functionality. The bundle’s affected-version data is ambiguous, so administrators should confirm applicability against their distribution’s kernel advisory and backport status.
Exploitation context
The CVSS 3.1 vector is 7.8: local access, low privileges, low complexity, and no user interaction. The supplied record is not in KEV and provides no evidence of active exploitation or a public working exploit. The issue was found using Syzkaller and demonstrated as a KASAN-detected kernel fault.
Researcher notes
The reported failure is a request-state race between p9_fd_cancelled and p9_read_work. Earlier concurrency handling covered received requests incompletely; the correction skips every state other than SENT because a state transition also removes the request. The source establishes memory corruption but does not establish reliable privilege escalation.
Mitigation direction
Install the distribution kernel update containing the applicable upstream stable fix.
Confirm the running kernel, not merely the installed package, was updated after reboot.
Where operationally acceptable, limit untrusted local access until the corrected kernel is active.
Review Linux distribution guidance for branch-specific backports and any supported temporary mitigation.
Validation and detection
Record the running kernel release and distribution package revision on potentially exposed systems.
Check vendor advisories or package changelogs for a CVE-2025-40027 backport.
Determine whether the affected 9p client and file-descriptor transport are present or used.
After updating and rebooting, verify every host runs the corrected kernel package.
Monitor kernel logs for 9p-related faults, protection faults, or KASAN-style memory errors.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cve · low confidence lookup
CVE-2025-40027 mapping review
Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
1CVSS vectors
3Timeline events
0ADP providers
10Source links
CVSS vector scores
1 official score
We collect every scored CVSS vector available in the official CNA and ADP containers. When more than one version is present, the table keeps the source vectors side by side instead of collapsing them into the highest score.