In the Linux kernel, the following vulnerability has been resolved:

9p: skip nlink update in cacheless mode to fix WARNON

v9fsdeccount() unconditionally calls dropnlink() on regular files, even when the inode's nlink is already zero. In cacheless mode the client refetches inode metadata from the server (the source of truth) on every operation, so by the time v9fsremove() returns, the locally cached nlink may already reflect the post-unlink value:

1. Client initiates unlink, server processes it and sets nlink to 0 2. Client refetches inode metadata (nlink=0) before unlink returns 3. Client's v9fsremove() completes successfully 4. Client calls v9fsdeccount() which calls dropnlink() on nlink=0

This race is easily triggered under heavy unlink workloads, such as stress-ng's unlink stressor, producing the following warning:

WARNING: fs/inode.c:417 at dropnlink+0x4c/0xc8 Call trace: dropnlink+0x4c/0xc8 v9fsremove+0x1e0/0x250 [9p] v9fsvfsunlink+0x20/0x38 [9p] vfsunlink+0x13c/0x258 ...

In cacheless mode the server is authoritative and the inode is on its way out, so locally adjusting nlink buys nothing. Skip v9fsdeccount() entirely when neither CACHEMETA nor CACHELOOSE is set, which both avoids the warning and removes a class of nlink races (two concurrent unlinkers observing nlink > 0 and both calling dropnlink()) that an nlink == 0 guard alone would only narrow rather than close.