The 9p client in the Linux kernel contains a race condition in its reference‑count handling. When the client operates in cacheless mode, a file that has just been unlinked may have its inode metadata refetched from the server with a zero link count before the local unlink operation finishes. The kernel then calls drop_nlink on an inode that already has a zero link count, which triggers a warning. According to the description, repeated unlink operations under heavy load can produce the warning, and the race might lead to confusing inode state. This flaw does not provide code execution; it may destabilise the file system and cause inconsistent inode information.

All Linux kernel releases that contain the 9p virtual filesystem and have not incorporated the commit that removes the unconditional drop_nlink call are affected. This includes the standard kernels provided by major distributions such as Ubuntu, Red Hat, Debian, and others that ship the in‑kernel 9p implementation.

The CVSS score of 7.8 indicates a moderate severity, while the EPSS score of <1% signals a very low exploitation probability. The flaw is not listed in the CISA KEV catalog. According to the description, the race can be triggered by local users performing many unlink operations on a 9p mount configured in cacheless mode; it does not appear to provide a remote code‑execution vector. The risk therefore lies primarily with stability rather than confidentiality or integrity, and the likely attack vector is local workload manipulation.