Cloudanix VulnDB

CVE-2025-40305

None

CVSS

—

EPSS

0.2%

Published

Dec 8, 2025

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A bug in the Linux kernel can cause file operations over certain network filesystems to stop responding, requiring a software update to restore normal behavior.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
Moderate
Impact
Denial Of Service
Component
OS kernel
Class
Race Condition
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

Race condition in 9p/trans_fd where p9_fd_request fails to invoke p9_poll_mux on EPOLLIN when the pipe is full after the pipe_read optimization, preventing p9_read_work scheduling and rx thread progress.

Why it matters to the business

9p filesystem mounts may stall or hang under load, disrupting file I/O for affected Linux systems and increasing operational downtime risk until patched.

How an attack unfolds

An attacker with local or network access to a 9p mount triggers repeated pipe-full conditions during request processing; the missing wakeup leaves the rx work item unscheduled, causing indefinite stalls without authentication or code execution.

How to fix it

Update the Linux kernel to the fixed commit 242531004d7de8c159f9bfadebe33fe8060b1046 or later stable releases containing the p9_fd_request change; rebuild and reboot affected systems.

How to confirm the fix worked

Confirm the patch is present by checking the commit in the kernel source tree or running a kernel version that includes 242531004d7de8c159f9bfadebe33fe8060b1046; test 9p mounts under pipe-full conditions to verify rx thread scheduling resumes.

Typical attack path

  1. Establish 9p connection over a transport that uses pipes
  2. Fill the pipe buffer while submitting requests
  3. Trigger EPOLLIN events without the prior unnecessary wakeup path
  4. Observe stalled p9_read_work and blocked I/O operations

How to detect it

Review kernel logs for 9p-related stalls or hung tasks involving p9_read_work or p9_poll; correlate with high pipe buffer usage on 9p transports; no public exploitation artifacts are known.

What your security team should do

  • Prioritize kernel updates on systems using 9p filesystems
  • Monitor for upstream stable releases containing the fix
  • Test 9p workloads in staging before production rollout
  • Review EPSS and KEV status weekly for any change in exploit likelihood

The record

In the Linux kernel, the following vulnerability has been resolved: 9p/trans_fd: p9_fd_request: kick rx thread if EPOLLIN p9_read_work() doesn't set Rworksched and doesn't do schedule_work(m->rq) if list_empty(&m->req_list). However, if the pipe is full, we need to read more data and this used to work prior to commit aaec5a95d59615 ("pipe_read: don't wake up the writer if the pipe is still full"). p9_read_work() does p9_fd_read() -> ... -> anon_pipe_read() which (before the commit above) triggered the unnecessary wakeup. This wakeup calls p9_pollwake() which kicks p9_poll_workfn() -> p9_poll_mux(), p9_poll_mux() will notice EPOLLIN and schedule_work(&m->rq). This no longer happens after the optimization above, change p9_fd_request() to use p9_poll_mux() instead of only checking for EPOLLOUT.

Affected packages

Ecosystem Package Introduced Fixed
Linux Kernel 0 6.12.58
Linux Kernel 6.14.0 6.17.8

Related vulnerabilities