CVE-2023-53593

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

cifs: Release folio lock on fscache read hit.

Under the current code, when cifs_readpage_worker 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
[] folio_wait_bit_common+0x124/0x350
[] filemap_read_folio+0xad/0xf0
[] filemap_fault+0x8b1/0xab0
[] __do_fault+0x39/0x150
[] do_fault+0x25c/0x3e0
[] __handle_mm_fault+0x6ca/0xc70
[] handle_mm_fault+0xe9/0x350
[] do_user_addr_fault+0x225/0x6c0
[] exc_page_fault+0x84/0x1b0
[] asm_exc_page_fault+0x27/0x30

This requires a reboot to resolve; it is a deadlock.

Note however that the call to cifs_readpage_from_fscache does mark the
page clean, but does not free the folio lock. This happens in
__cifs_readpage_from_fscache on success. Releasing the lock at that
point however is not appropriate as cifs_readahead also calls
cifs_readpage_from_fscache and *does* unconditionally release the lock
after its return. This change therefore effectively makes
cifs_readpage_worker work like cifs_readahead.