CVE-2025-40007
Full vulnerability record from the local CVENow database.
Description
In the Linux kernel, the following vulnerability has been resolved: netfs: fix reference leak Commit 20d72b00ca81 ("netfs: Fix the request's work item to not require a ref") modified netfs_alloc_request() to initialize the reference counter to 2 instead of 1. The rationale was that the requet's "work" would release the second reference after completion (via netfs_{read,write}_collection_worker()). That works most of the time if all goes well. However, it leaks this additional reference if the request is released before the I/O operation has been submitted: the error code path only decrements the reference counter once and the work item will never be queued because there will never be a completion. This has caused outages of our whole server cluster today because tasks were blocked in netfs_wait_for_outstanding_io(), leading to deadlocks in Ceph (another bug that I will address soon in another patch). This was caused by a netfs_pgpriv2_begin_copy_to_cache() call which failed in fscache_begin_write_operation(). The leaked netfs_io_request was never completed, leaving `netfs_inode.io_count` with a positive value forever. All of this is super-fragile code. Finding out which code paths will lead to an eventual completion and which do not is hard to see: - Some functions like netfs_create_write_req() allocate a request, but will never submit any I/O. - netfs_unbuffered_read_iter_locked() calls netfs_unbuffered_read() and then netfs_put_request(); however, netfs_unbuffered_read() can also fail early before submitting the I/O request, therefore another netfs_put_request() call must be added there. A rule of thumb is that functions that return a `netfs_io_request` do not submit I/O, and all of their callers must be checked. For my taste, the whole netfs code needs an overhaul to make reference counting easier to understand and less fragile & obscure. But to fix this bug here and now and produce a patch that is adequate for a stable backport, I tried a minimal approach that quickly frees the request object upon early failure. I decided against adding a second netfs_put_request() each time because that would cause code duplication which obscures the code further. Instead, I added the function netfs_put_failed_request() which frees such a failed request synchronously under the assumption that the reference count is exactly 2 (as initially set by netfs_alloc_request() and never touched), verified by a WARN_ON_ONCE(). It then deinitializes the request object (without going through the "cleanup_work" indirection) and frees the allocation (with RCU protection to protect against concurrent access by netfs_requests_seq_start()). All code paths that fail early have been changed to call netfs_put_failed_request() instead of netfs_put_request(). Additionally, I have added a netfs_put_request() call to netfs_unbuffered_read() as explained above because the netfs_put_failed_request() approach does not work there.
View original CVE JSON
{
"id": "CVE-2025-40007",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"published": "2025-10-20T16:15:37.357",
"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\nnetfs: fix reference leak\n\nCommit 20d72b00ca81 (\"netfs: Fix the request's work item to not\nrequire a ref\") modified netfs_alloc_request() to initialize the\nreference counter to 2 instead of 1. The rationale was that the\nrequet's \"work\" would release the second reference after completion\n(via netfs_{read,write}_collection_worker()). That works most of the\ntime if all goes well.\n\nHowever, it leaks this additional reference if the request is released\nbefore the I/O operation has been submitted: the error code path only\ndecrements the reference counter once and the work item will never be\nqueued because there will never be a completion.\n\nThis has caused outages of our whole server cluster today because\ntasks were blocked in netfs_wait_for_outstanding_io(), leading to\ndeadlocks in Ceph (another bug that I will address soon in another\npatch). This was caused by a netfs_pgpriv2_begin_copy_to_cache() call\nwhich failed in fscache_begin_write_operation(). The leaked\nnetfs_io_request was never completed, leaving `netfs_inode.io_count`\nwith a positive value forever.\n\nAll of this is super-fragile code. Finding out which code paths will\nlead to an eventual completion and which do not is hard to see:\n\n- Some functions like netfs_create_write_req() allocate a request, but\n will never submit any I/O.\n\n- netfs_unbuffered_read_iter_locked() calls netfs_unbuffered_read()\n and then netfs_put_request(); however, netfs_unbuffered_read() can\n also fail early before submitting the I/O request, therefore another\n netfs_put_request() call must be added there.\n\nA rule of thumb is that functions that return a `netfs_io_request` do\nnot submit I/O, and all of their callers must be checked.\n\nFor my taste, the whole netfs code needs an overhaul to make reference\ncounting easier to understand and less fragile & obscure. But to fix\nthis bug here and now and produce a patch that is adequate for a\nstable backport, I tried a minimal approach that quickly frees the\nrequest object upon early failure.\n\nI decided against adding a second netfs_put_request() each time\nbecause that would cause code duplication which obscures the code\nfurther. Instead, I added the function netfs_put_failed_request()\nwhich frees such a failed request synchronously under the assumption\nthat the reference count is exactly 2 (as initially set by\nnetfs_alloc_request() and never touched), verified by a\nWARN_ON_ONCE(). It then deinitializes the request object (without\ngoing through the \"cleanup_work\" indirection) and frees the allocation\n(with RCU protection to protect against concurrent access by\nnetfs_requests_seq_start()).\n\nAll code paths that fail early have been changed to call\nnetfs_put_failed_request() instead of netfs_put_request().\nAdditionally, I have added a netfs_put_request() call to\nnetfs_unbuffered_read() as explained above because the\nnetfs_put_failed_request() approach does not work there."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad:\n\nnetfs: corregir fuga de referencia\n\nEl commit 20d72b00ca81 ('netfs: Corregir el elemento de trabajo de la solicitud para que no requiera una referencia') modificó netfs_alloc_request() para inicializar el contador de referencias a 2 en lugar de 1. La justificación era que el 'trabajo' de la solicitud liberaría la segunda referencia después de la finalización (a través de netfs_{read,write}_collection_worker()). Eso funciona la mayor parte del tiempo si todo va bien.\n\nSin embargo, fuga esta referencia adicional si la solicitud se libera antes de que se haya enviado la operación de E/S: la ruta del código de error solo decrementa el contador de referencias una vez y el elemento de trabajo nunca se pondrá en cola porque nunca habrá una finalización.\n\nEsto ha causado interrupciones en todo nuestro clúster de servidores hoy porque las tareas estaban bloqueadas en netfs_wait_for_outstanding_io(), lo que llevó a interbloqueos en Ceph (otro error que abordaré pronto en otro parche). Esto fue causado por una llamada a netfs_pgpriv2_begin_copy_to_cache() que falló en fscache_begin_write_operation(). La netfs_io_request fugada nunca se completó, dejando 'netfs_inode.io_count' con un valor positivo para siempre.\n\nTodo esto es código súper frágil. Descubrir qué rutas de código conducirán a una eventual finalización y cuáles no es difícil de ver:\n\n- Algunas funciones como netfs_create_write_req() asignan una solicitud, pero nunca enviarán ninguna E/S.\n\n- netfs_unbuffered_read_iter_locked() llama a netfs_unbuffered_read() y luego a netfs_put_request(); sin embargo, netfs_unbuffered_read() también puede fallar tempranamente antes de enviar la solicitud de E/S, por lo tanto, se debe agregar otra llamada a netfs_put_request() allí.\n\nUna regla general es que las funciones que devuelven una 'netfs_io_request' no envían E/S, y todos sus llamadores deben ser revisados.\n\nPara mi gusto, todo el código netfs necesita una revisión para que el conteo de referencias sea más fácil de entender y menos frágil y oscuro. Pero para corregir este error aquí y ahora y producir un parche que sea adecuado para un backport estable, probé un enfoque mínimo que libera rápidamente el objeto de solicitud ante un fallo temprano.\n\nDecidí no agregar una segunda netfs_put_request() cada vez porque eso causaría duplicación de código que oscurece aún más el código. En su lugar, agregué la función netfs_put_failed_request() que libera dicha solicitud fallida sincrónicamente bajo la suposición de que el conteo de referencias es exactamente 2 (como se estableció inicialmente por netfs_alloc_request() y nunca se tocó), verificado por un WARN_ON_ONCE(). Luego desinicializa el objeto de solicitud (sin pasar por la indirección 'cleanup_work') y libera la asignación (con protección RCU para proteger contra el acceso concurrente por netfs_requests_seq_start()).\n\nTodas las rutas de código que fallan tempranamente se han cambiado para llamar a netfs_put_failed_request() en lugar de netfs_put_request(). Además, he agregado una llamada a netfs_put_request() a netfs_unbuffered_read() como se explicó anteriormente porque el enfoque de netfs_put_failed_request() no funciona allí."
}
],
"affected": [
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"affectedData": [
{
"vendor": "Linux",
"product": "Linux",
"defaultStatus": "unaffected",
"programFiles": [
"fs/netfs/buffered_read.c",
"fs/netfs/direct_read.c",
"fs/netfs/direct_write.c",
"fs/netfs/internal.h",
"fs/netfs/objects.c",
"fs/netfs/read_pgpriv2.c",
"fs/netfs/read_single.c",
"fs/netfs/write_issue.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"versions": [
{
"version": "20d72b00ca814d748f5663484e5c53bb2bf37a3a",
"lessThan": "8df142e93098b4531fadb5dfcf93087649f570b3",
"versionType": "git",
"status": "affected"
},
{
"version": "20d72b00ca814d748f5663484e5c53bb2bf37a3a",
"lessThan": "4d428dca252c858bfac691c31fa95d26cd008706",
"versionType": "git",
"status": "affected"
},
{
"version": "1a8360c2eed3b292ed654c2ac61b09de4a80e298",
"versionType": "git",
"status": "affected"
},
{
"version": "6.15.3",
"lessThan": "6.16",
"versionType": "semver",
"status": "affected"
}
]
},
{
"vendor": "Linux",
"product": "Linux",
"defaultStatus": "affected",
"programFiles": [
"fs/netfs/buffered_read.c",
"fs/netfs/direct_read.c",
"fs/netfs/direct_write.c",
"fs/netfs/internal.h",
"fs/netfs/objects.c",
"fs/netfs/read_pgpriv2.c",
"fs/netfs/read_single.c",
"fs/netfs/write_issue.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"versions": [
{
"version": "6.16",
"status": "affected"
},
{
"version": "0",
"lessThan": "6.16",
"versionType": "semver",
"status": "unaffected"
},
{
"version": "6.16.10",
"lessThanOrEqual": "6.16.*",
"versionType": "semver",
"status": "unaffected"
},
{
"version": "6.17",
"lessThanOrEqual": "*",
"versionType": "original_commit_for_fix",
"status": "unaffected"
}
]
}
]
}
],
"metrics": {},
"references": [
{
"url": "https://git.kernel.org/stable/c/4d428dca252c858bfac691c31fa95d26cd008706",
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
},
{
"url": "https://git.kernel.org/stable/c/8df142e93098b4531fadb5dfcf93087649f570b3",
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
}
]
}