CVE-2023-53593

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cifs: Release folio lock on fscache read hit.<br /> <br /> Under the current code, when cifs_readpage_worker is called, the call<br /> contract is that the callee should unlock the page. This is documented<br /> in the read_folio section of Documentation/filesystems/vfs.rst as:<br /> <br /> &gt; The filesystem should unlock the folio once the read has completed,<br /> &gt; whether it was successful or not.<br /> <br /> Without this change, when fscache is in use and cache hit occurs during<br /> a read, the page lock is leaked, producing the following stack on<br /> subsequent reads (via mmap) to the page:<br /> <br /> $ cat /proc/3890/task/12864/stack<br /> [] folio_wait_bit_common+0x124/0x350<br /> [] filemap_read_folio+0xad/0xf0<br /> [] filemap_fault+0x8b1/0xab0<br /> [] __do_fault+0x39/0x150<br /> [] do_fault+0x25c/0x3e0<br /> [] __handle_mm_fault+0x6ca/0xc70<br /> [] handle_mm_fault+0xe9/0x350<br /> [] do_user_addr_fault+0x225/0x6c0<br /> [] exc_page_fault+0x84/0x1b0<br /> [] asm_exc_page_fault+0x27/0x30<br /> <br /> This requires a reboot to resolve; it is a deadlock.<br /> <br /> Note however that the call to cifs_readpage_from_fscache does mark the<br /> page clean, but does not free the folio lock. This happens in<br /> __cifs_readpage_from_fscache on success. Releasing the lock at that<br /> point however is not appropriate as cifs_readahead also calls<br /> cifs_readpage_from_fscache and *does* unconditionally release the lock<br /> after its return. This change therefore effectively makes<br /> cifs_readpage_worker work like cifs_readahead.