In the Linux kernel, the following vulnerability has been resolved:
cifs: Release folio lock on fscache read hit.
Under the current code, when cifsreadpageworker is called, the call contract is that the callee should unlock the page. This is documented in the read_folio section of Documentation/filesystems/vfs.rst as:
The filesystem should unlock the folio once the read has completed, whether it was successful or not.
Without this change, when fscache is in use and cache hit occurs during a read, the page lock is leaked, producing the following stack on subsequent reads (via mmap) to the page:
$ cat /proc/3890/task/12864/stack [<0>] foliowaitbitcommon+0x124/0x350 [<0>] filemapreadfolio+0xad/0xf0 [<0>] filemapfault+0x8b1/0xab0 [<0>] _dofault+0x39/0x150 [<0>] dofault+0x25c/0x3e0 [<0>] _handlemmfault+0x6ca/0xc70 [<0>] handlemmfault+0xe9/0x350 [<0>] douseraddrfault+0x225/0x6c0 [<0>] excpagefault+0x84/0x1b0 [<0>] asmexcpagefault+0x27/0x30
This requires a reboot to resolve; it is a deadlock.
Note however that the call to cifsreadpagefromfscache does mark the page clean, but does not free the folio lock. This happens in _cifsreadpagefromfscache on success. Releasing the lock at that point however is not appropriate as cifsreadahead also calls cifsreadpagefromfscache and *does* unconditionally release the lock after its return. This change therefore effectively makes cifsreadpageworker work like cifsreadahead.