{"resultsPerPage":1,"startIndex":0,"totalResults":1,"format":"NVD_CVE","version":"2.0","timestamp":"2026-05-12T13:48:09.652","vulnerabilities":[{"cve":{"id":"CVE-2025-68821","sourceIdentifier":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","published":"2026-01-13T16:16:04.440","lastModified":"2026-04-15T00:35:42.020","vulnStatus":"Deferred","cveTags":[],"descriptions":[{"lang":"en","value":"In the Linux kernel, the following vulnerability has been resolved:\n\nfuse: fix readahead reclaim deadlock\n\nCommit e26ee4efbc79 (\"fuse: allocate ff->release_args only if release is\nneeded\") skips allocating ff->release_args if the server does not\nimplement open. However in doing so, fuse_prepare_release() now skips\ngrabbing the reference on the inode, which makes it possible for an\ninode to be evicted from the dcache while there are inflight readahead\nrequests. This causes a deadlock if the server triggers reclaim while\nservicing the readahead request and reclaim attempts to evict the inode\nof the file being read ahead. Since the folio is locked during\nreadahead, when reclaim evicts the fuse inode and fuse_evict_inode()\nattempts to remove all folios associated with the inode from the page\ncache (truncate_inode_pages_range()), reclaim will block forever waiting\nfor the lock since readahead cannot relinquish the lock because it is\nitself blocked in reclaim:\n\n>>> stack_trace(1504735)\n folio_wait_bit_common (mm/filemap.c:1308:4)\n folio_lock (./include/linux/pagemap.h:1052:3)\n truncate_inode_pages_range (mm/truncate.c:336:10)\n fuse_evict_inode (fs/fuse/inode.c:161:2)\n evict (fs/inode.c:704:3)\n dentry_unlink_inode (fs/dcache.c:412:3)\n __dentry_kill (fs/dcache.c:615:3)\n shrink_kill (fs/dcache.c:1060:12)\n shrink_dentry_list (fs/dcache.c:1087:3)\n prune_dcache_sb (fs/dcache.c:1168:2)\n super_cache_scan (fs/super.c:221:10)\n do_shrink_slab (mm/shrinker.c:435:9)\n shrink_slab (mm/shrinker.c:626:10)\n shrink_node (mm/vmscan.c:5951:2)\n shrink_zones (mm/vmscan.c:6195:3)\n do_try_to_free_pages (mm/vmscan.c:6257:3)\n do_swap_page (mm/memory.c:4136:11)\n handle_pte_fault (mm/memory.c:5562:10)\n handle_mm_fault (mm/memory.c:5870:9)\n do_user_addr_fault (arch/x86/mm/fault.c:1338:10)\n handle_page_fault (arch/x86/mm/fault.c:1481:3)\n exc_page_fault (arch/x86/mm/fault.c:1539:2)\n asm_exc_page_fault+0x22/0x27\n\nFix this deadlock by allocating ff->release_args and grabbing the\nreference on the inode when preparing the file for release even if the\nserver does not implement open. The inode reference will be dropped when\nthe last reference on the fuse file is dropped (see fuse_file_put() ->\nfuse_release_end())."},{"lang":"es","value":"En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:\n\nfuse: corregir interbloqueo de recuperación de lectura anticipada\n\nEl commit e26ee4efbc79 ('fuse: asignar ff->release_args solo si se necesita la liberación') omite la asignación de ff->release_args si el servidor no implementa open. Sin embargo, al hacerlo, fuse_prepare_release() ahora omite tomar la referencia en el inodo, lo que hace posible que un inodo sea desalojado del dcache mientras hay solicitudes de lectura anticipada en curso. Esto causa un interbloqueo si el servidor activa la recuperación mientras atiende la solicitud de lectura anticipada y la recuperación intenta desalojar el inodo del archivo que se está leyendo anticipadamente. Dado que el folio está bloqueado durante la lectura anticipada, cuando la recuperación desaloja el inodo fuse y fuse_evict_inode() intenta eliminar todos los folios asociados con el inodo de la caché de páginas (truncate_inode_pages_range()), la recuperación se bloqueará para siempre esperando el bloqueo ya que la lectura anticipada no puede liberar el bloqueo porque está a su vez bloqueada en la recuperación:\n\n>>> traza_de_pila(1504735)\n folio_wait_bit_common (mm/filemap.c:1308:4)\n folio_lock (./include/linux/pagemap.h:1052:3)\n truncate_inode_pages_range (mm/truncate.c:336:10)\n fuse_evict_inode (fs/fuse/inode.c:161:2)\n evict (fs/inode.c:704:3)\n dentry_unlink_inode (fs/dcache.c:412:3)\n __dentry_kill (fs/dcache.c:615:3)\n shrink_kill (fs/dcache.c:1060:12)\n shrink_dentry_list (fs/dcache.c:1087:3)\n prune_dcache_sb (fs/dcache.c:1168:2)\n super_cache_scan (fs/super.c:221:10)\n do_shrink_slab (mm/shrinker.c:435:9)\n shrink_slab (mm/shrinker.c:626:10)\n shrink_node (mm/vmscan.c:5951:2)\n shrink_zones (mm/vmscan.c:6195:3)\n do_try_to_free_pages (mm/vmscan.c:6257:3)\n do_swap_page (mm/memory.c:4136:11)\n handle_pte_fault (mm/memory.c:5562:10)\n handle_mm_fault (mm/memory.c:5870:9)\n do_user_addr_fault (arch/x86/mm/fault.c:1338:10)\n handle_page_fault (arch/x86/mm/fault.c:1481:3)\n exc_page_fault (arch/x86/mm/fault.c:1539:2)\n asm_exc_page_fault+0x22/0x27\n\nSolucione este interbloqueo asignando ff->release_args y tomando la referencia en el inodo al preparar el archivo para su liberación, incluso si el servidor no implementa open. La referencia del inodo se eliminará cuando se elimine la última referencia en el archivo fuse (ver fuse_file_put() -> fuse_release_end())."}],"metrics":{},"references":[{"url":"https://git.kernel.org/stable/c/4703bc0e8cd3409acb1476a70cb5b7ff943cf39a","source":"416baaa9-dc9f-4396-8d5f-8c081fb06d67"},{"url":"https://git.kernel.org/stable/c/bd5603eaae0aabf527bfb3ce1bb07e979ce5bd50","source":"416baaa9-dc9f-4396-8d5f-8c081fb06d67"},{"url":"https://git.kernel.org/stable/c/cbbf3f1bb9f834bb2acbb61ddca74363456e19cd","source":"416baaa9-dc9f-4396-8d5f-8c081fb06d67"},{"url":"https://git.kernel.org/stable/c/cf74785c00b8b1c0c4a9dd74bfa9c22d62e2d99f","source":"416baaa9-dc9f-4396-8d5f-8c081fb06d67"},{"url":"https://git.kernel.org/stable/c/e0d6de83a4cc22bbac72713f3a58121af36cc411","source":"416baaa9-dc9f-4396-8d5f-8c081fb06d67"},{"url":"https://git.kernel.org/stable/c/fbba8b00bbe4e4f958a2b0654cc1219a7e6597f6","source":"416baaa9-dc9f-4396-8d5f-8c081fb06d67"}]}}]}