Wind River Support Network

Description

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