CVE-2025-40220
Full vulnerability record from the local CVENow database.
Description
In the Linux kernel, the following vulnerability has been resolved: fuse: fix livelock in synchronous file put from fuseblk workers I observed a hang when running generic/323 against a fuseblk server. This test opens a file, initiates a lot of AIO writes to that file descriptor, and closes the file descriptor before the writes complete. Unsurprisingly, the AIO exerciser threads are mostly stuck waiting for responses from the fuseblk server: # cat /proc/372265/task/372313/stack [<0>] request_wait_answer+0x1fe/0x2a0 [fuse] [<0>] __fuse_simple_request+0xd3/0x2b0 [fuse] [<0>] fuse_do_getattr+0xfc/0x1f0 [fuse] [<0>] fuse_file_read_iter+0xbe/0x1c0 [fuse] [<0>] aio_read+0x130/0x1e0 [<0>] io_submit_one+0x542/0x860 [<0>] __x64_sys_io_submit+0x98/0x1a0 [<0>] do_syscall_64+0x37/0xf0 [<0>] entry_SYSCALL_64_after_hwframe+0x4b/0x53 But the /weird/ part is that the fuseblk server threads are waiting for responses from itself: # cat /proc/372210/task/372232/stack [<0>] request_wait_answer+0x1fe/0x2a0 [fuse] [<0>] __fuse_simple_request+0xd3/0x2b0 [fuse] [<0>] fuse_file_put+0x9a/0xd0 [fuse] [<0>] fuse_release+0x36/0x50 [fuse] [<0>] __fput+0xec/0x2b0 [<0>] task_work_run+0x55/0x90 [<0>] syscall_exit_to_user_mode+0xe9/0x100 [<0>] do_syscall_64+0x43/0xf0 [<0>] entry_SYSCALL_64_after_hwframe+0x4b/0x53 The fuseblk server is fuse2fs so there's nothing all that exciting in the server itself. So why is the fuse server calling fuse_file_put? The commit message for the fstest sheds some light on that: "By closing the file descriptor before calling io_destroy, you pretty much guarantee that the last put on the ioctx will be done in interrupt context (during I/O completion). Aha. AIO fgets a new struct file from the fd when it queues the ioctx. The completion of the FUSE_WRITE command from userspace causes the fuse server to call the AIO completion function. The completion puts the struct file, queuing a delayed fput to the fuse server task. When the fuse server task returns to userspace, it has to run the delayed fput, which in the case of a fuseblk server, it does synchronously. Sending the FUSE_RELEASE command sychronously from fuse server threads is a bad idea because a client program can initiate enough simultaneous AIOs such that all the fuse server threads end up in delayed_fput, and now there aren't any threads left to handle the queued fuse commands. Fix this by only using asynchronous fputs when closing files, and leave a comment explaining why.
Severity
Not scored
CVSS score
Not available
Vulnerability status
Deferred
Source identifier
416baaa9-dc9f-4396-8d5f-8c081fb06d67
Published
2025-12-04 15:15:58.033000
Last modified
2026-10-19 21:10:00.160000
View original CVE JSON
{
"id": "CVE-2025-40220",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"published": "2025-12-04T15:15:58.033",
"lastModified": "2026-10-19T21:10:00.160",
"vulnStatus": "Deferred",
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nfuse: fix livelock in synchronous file put from fuseblk workers\n\nI observed a hang when running generic/323 against a fuseblk server.\nThis test opens a file, initiates a lot of AIO writes to that file\ndescriptor, and closes the file descriptor before the writes complete.\nUnsurprisingly, the AIO exerciser threads are mostly stuck waiting for\nresponses from the fuseblk server:\n\n# cat /proc/372265/task/372313/stack\n[<0>] request_wait_answer+0x1fe/0x2a0 [fuse]\n[<0>] __fuse_simple_request+0xd3/0x2b0 [fuse]\n[<0>] fuse_do_getattr+0xfc/0x1f0 [fuse]\n[<0>] fuse_file_read_iter+0xbe/0x1c0 [fuse]\n[<0>] aio_read+0x130/0x1e0\n[<0>] io_submit_one+0x542/0x860\n[<0>] __x64_sys_io_submit+0x98/0x1a0\n[<0>] do_syscall_64+0x37/0xf0\n[<0>] entry_SYSCALL_64_after_hwframe+0x4b/0x53\n\nBut the /weird/ part is that the fuseblk server threads are waiting for\nresponses from itself:\n\n# cat /proc/372210/task/372232/stack\n[<0>] request_wait_answer+0x1fe/0x2a0 [fuse]\n[<0>] __fuse_simple_request+0xd3/0x2b0 [fuse]\n[<0>] fuse_file_put+0x9a/0xd0 [fuse]\n[<0>] fuse_release+0x36/0x50 [fuse]\n[<0>] __fput+0xec/0x2b0\n[<0>] task_work_run+0x55/0x90\n[<0>] syscall_exit_to_user_mode+0xe9/0x100\n[<0>] do_syscall_64+0x43/0xf0\n[<0>] entry_SYSCALL_64_after_hwframe+0x4b/0x53\n\nThe fuseblk server is fuse2fs so there's nothing all that exciting in\nthe server itself. So why is the fuse server calling fuse_file_put?\nThe commit message for the fstest sheds some light on that:\n\n\"By closing the file descriptor before calling io_destroy, you pretty\nmuch guarantee that the last put on the ioctx will be done in interrupt\ncontext (during I/O completion).\n\nAha. AIO fgets a new struct file from the fd when it queues the ioctx.\nThe completion of the FUSE_WRITE command from userspace causes the fuse\nserver to call the AIO completion function. The completion puts the\nstruct file, queuing a delayed fput to the fuse server task. When the\nfuse server task returns to userspace, it has to run the delayed fput,\nwhich in the case of a fuseblk server, it does synchronously.\n\nSending the FUSE_RELEASE command sychronously from fuse server threads\nis a bad idea because a client program can initiate enough simultaneous\nAIOs such that all the fuse server threads end up in delayed_fput, and\nnow there aren't any threads left to handle the queued fuse commands.\n\nFix this by only using asynchronous fputs when closing files, and leave\na comment explaining why."
},
{
"lang": "es",
"value": "En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:\n\nfuse: corrige el livelock en la operación síncrona de “file put” de los workers de fuseblk\n\nObservé un cuelgue al ejecutar generic/323 contra un servidor fuseblk.\nEsta prueba abre un archivo, inicia muchas escrituras AIO a ese descriptor de archivo y cierra el descriptor de archivo antes de que las escrituras se completen.\nComo era de esperar, los hilos ejercitadores de AIO están mayormente atascados esperando respuestas del servidor fuseblk:\n\n# cat /proc/372265/task/372313/stack\n[<0>] request_wait_answer+0x1fe/0x2a0 [fuse]\n[<0>] __fuse_simple_request+0xd3/0x2b0 [fuse]\n[<0>] fuse_do_getattr+0xfc/0x1f0 [fuse]\n[<0>] fuse_file_read_iter+0xbe/0x1c0 [fuse]\n[<0>] aio_read+0x130/0x1e0\n[<0>] io_submit_one+0x542/0x860\n[<0>] __x64_sys_io_submit+0x98/0x1a0\n[<0>] do_syscall_64+0x37/0xf0\n[<0>] entry_SYSCALL_64_after_hwframe+0x4b/0x53\n\nPero la parte /extraña/ es que los hilos del servidor fuseblk están esperando respuestas de sí mismo:\n\n# cat /proc/372210/task/372232/stack\n[<0>] request_wait_answer+0x1fe/0x2a0 [fuse]\n[<0>] __fuse_simple_request+0xd3/0x2b0 [fuse]\n[<0>] fuse_file_put+0x9a/0xd0 [fuse]\n[<0>] fuse_release+0x36/0x50 [fuse]\n[<0>] __fput+0xec/0x2b0\n[<0>] task_work_run+0x55/0x90\n[<0>] syscall_exit_to_user_mode+0xe9/0x100\n[<0>] do_syscall_64+0x43/0xf0\n[<0>] entry_SYSCALL_64_after_hwframe+0x4b/0x53\n\nEl servidor fuseblk es fuse2fs, así que no hay nada tan emocionante en el propio servidor. Entonces, ¿por qué el servidor fuse está llamando a fuse_file_put? El mensaje de commit para fstest arroja algo de luz sobre eso:\n\n“Al cerrar el descriptor de archivo antes de llamar a io_destroy, prácticamente garantizas que el último ”put“ en el ioctx se realizará en contexto de interrupción (durante la finalización de E/S).\n\nAjá. AIO obtiene un nuevo ”struct file“ del fd cuando encola el ioctx. La finalización del comando FUSE_WRITE desde el espacio de usuario hace que el servidor fuse llame a la función de finalización de AIO. La finalización ”pone“ el ”struct file”, encolando un fput retrasado a la tarea del servidor fuse. Cuando la tarea del servidor fuse regresa al espacio de usuario, tiene que ejecutar el fput retrasado, lo cual, en el caso de un servidor fuseblk, lo hace de forma síncrona.\n\nEnviar el comando FUSE_RELEASE de forma síncrona desde los hilos del servidor fuse es una mala idea porque un programa cliente puede iniciar suficientes AIOs simultáneos de modo que todos los hilos del servidor fuse terminen en delayed_fput, y ahora no quedan hilos para manejar los comandos fuse encolados.\n\nSoluciona esto usando solo fputs asíncronos al cerrar archivos, y deja un comentario explicando por qué."
}
],
"affected": [
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"affectedData": [
{
"vendor": "Linux",
"product": "Linux",
"defaultStatus": "unaffected",
"programFiles": [
"fs/fuse/file.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"versions": [
{
"version": "5a18ec176c934ca1bc9dc61580a5e0e90a9b5733",
"lessThan": "548e1f2bac1d4df91a6138f26bb4ab00323fd948",
"versionType": "git",
"status": "affected"
},
{
"version": "5a18ec176c934ca1bc9dc61580a5e0e90a9b5733",
"lessThan": "cfd1aa3e2b71f3327cb373c45a897c9028c62b35",
"versionType": "git",
"status": "affected"
},
{
"version": "5a18ec176c934ca1bc9dc61580a5e0e90a9b5733",
"lessThan": "83b375c6efef69b1066ad2d79601221e7892745a",
"versionType": "git",
"status": "affected"
},
{
"version": "5a18ec176c934ca1bc9dc61580a5e0e90a9b5733",
"lessThan": "bfd17b6138df0122a95989457d8e18ce0b86165e",
"versionType": "git",
"status": "affected"
},
{
"version": "5a18ec176c934ca1bc9dc61580a5e0e90a9b5733",
"lessThan": "b26923512dbe57ae4917bafd31396d22a9d1691a",
"versionType": "git",
"status": "affected"
},
{
"version": "5a18ec176c934ca1bc9dc61580a5e0e90a9b5733",
"lessThan": "f19a1390af448d9e193c08e28ea5f727bf3c3049",
"versionType": "git",
"status": "affected"
},
{
"version": "5a18ec176c934ca1bc9dc61580a5e0e90a9b5733",
"lessThan": "26e5c67deb2e1f42a951f022fdf5b9f7eb747b01",
"versionType": "git",
"status": "affected"
},
{
"version": "9efe56738fecd591b5bf366a325440f9b457ebd6",
"versionType": "git",
"status": "affected"
},
{
"version": "5c46eb076e0a1b2c1769287cd6942e4594ade1b1",
"versionType": "git",
"status": "affected"
},
{
"version": "83e6726210d6c815ce044437106c738eda5ff6f6",
"versionType": "git",
"status": "affected"
},
{
"version": "23d154c71721fd0fa6199851078f32e6bd765664",
"versionType": "git",
"status": "affected"
},
{
"version": "ca3edc920f5fd7d8ac040caaf109f925c24620a0",
"versionType": "git",
"status": "affected"
},
{
"version": "2.6.32.32",
"lessThan": "2.6.33",
"versionType": "semver",
"status": "affected"
},
{
"version": "2.6.33.8",
"lessThan": "2.6.34",
"versionType": "semver",
"status": "affected"
},
{
"version": "2.6.34.10",
"lessThan": "2.6.35",
"versionType": "semver",
"status": "affected"
},
{
"version": "2.6.35.12",
"lessThan": "2.6.36",
"versionType": "semver",
"status": "affected"
},
{
"version": "2.6.37.3",
"lessThan": "2.6.38",
"versionType": "semver",
"status": "affected"
}
]
},
{
"vendor": "Linux",
"product": "Linux",
"defaultStatus": "affected",
"programFiles": [
"fs/fuse/file.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"versions": [
{
"version": "2.6.38",
"status": "affected"
},
{
"version": "0",
"lessThan": "2.6.38",
"versionType": "semver",
"status": "unaffected"
},
{
"version": "5.10.246",
"lessThanOrEqual": "5.10.*",
"versionType": "semver",
"status": "unaffected"
},
{
"version": "5.15.196",
"lessThanOrEqual": "5.15.*",
"versionType": "semver",
"status": "unaffected"
},
{
"version": "6.1.158",
"lessThanOrEqual": "6.1.*",
"versionType": "semver",
"status": "unaffected"
},
{
"version": "6.6.115",
"lessThanOrEqual": "6.6.*",
"versionType": "semver",
"status": "unaffected"
},
{
"version": "6.12.54",
"lessThanOrEqual": "6.12.*",
"versionType": "semver",
"status": "unaffected"
},
{
"version": "6.17.4",
"lessThanOrEqual": "6.17.*",
"versionType": "semver",
"status": "unaffected"
},
{
"version": "6.18",
"lessThanOrEqual": "*",
"versionType": "original_commit_for_fix",
"status": "unaffected"
}
]
}
]
}
],
"metrics": {},
"references": [
{
"url": "https://git.kernel.org/stable/c/26e5c67deb2e1f42a951f022fdf5b9f7eb747b01",
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
},
{
"url": "https://git.kernel.org/stable/c/548e1f2bac1d4df91a6138f26bb4ab00323fd948",
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
},
{
"url": "https://git.kernel.org/stable/c/83b375c6efef69b1066ad2d79601221e7892745a",
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
},
{
"url": "https://git.kernel.org/stable/c/b26923512dbe57ae4917bafd31396d22a9d1691a",
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
},
{
"url": "https://git.kernel.org/stable/c/bfd17b6138df0122a95989457d8e18ce0b86165e",
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
},
{
"url": "https://git.kernel.org/stable/c/cfd1aa3e2b71f3327cb373c45a897c9028c62b35",
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
},
{
"url": "https://git.kernel.org/stable/c/f19a1390af448d9e193c08e28ea5f727bf3c3049",
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
}
]
}