CVE-2023-53606
published 2025-10-04CVE-2023-53606: In the Linux kernel, the following vulnerability has been resolved: nfsd: clean up potential nfsd_file refcount leaks in COPY codepath There are two different…
PriorityP420medium5.5CVSS 3.1
AVLACLPRLUINSUCNINAH
EPSS
0.26%
17.7th percentile
In the Linux kernel, the following vulnerability has been resolved:
nfsd: clean up potential nfsd_file refcount leaks in COPY codepath
There are two different flavors of the nfsd4_copy struct. One is
embedded in the compound and is used directly in synchronous copies. The
other is dynamically allocated, refcounted and tracked in the client
struture. For the embedded one, the cleanup just involves releasing any
nfsd_files held on its behalf. For the async one, the cleanup is a bit
more involved, and we need to dequeue it from lists, unhash it, etc.
There is at least one potential refcount leak in this code now. If the
kthread_create call fails, then both the src and dst nfsd_files in the
original nfsd4_copy object are leaked.
The cleanup in this codepath is also sort of weird. In the async copy
case, we'll have up to four nfsd_file references (src and dst for both
flavors of copy structure). They are both put at the end of
nfsd4_do_async_copy, even though the ones held on behalf of the embedded
one outlive that structure.
Change it so that we always clean up the nfsd_file refs held by the
embedded copy structure before nfsd4_copy returns. Rework
cleanup_async_copy to handle both inter and intra copies. Eliminate
nfsd4_cleanup_intra_ssc since it now becomes a no-op.
Affected
15 ranges
| Vendor | Product | Version range | Fixed in |
|---|---|---|---|
| debian | linux | < linux 6.1.20-1 (bookworm) | linux 6.1.20-1 (bookworm) |
| linux | linux | — | — |
| linux | linux | >= e0639dc5805a9d4faaa2c07ad98fa853b9529dd3 < fd63299db8090307eae66f2aef17c8f00aafa0a9 | fd63299db8090307eae66f2aef17c8f00aafa0a9 |
| linux | linux | >= e0639dc5805a9d4faaa2c07ad98fa853b9529dd3 < b3169b6ffe036b549c296a9e71591d29a1fb3209 | b3169b6ffe036b549c296a9e71591d29a1fb3209 |
| linux | linux | >= e0639dc5805a9d4faaa2c07ad98fa853b9529dd3 < 75b8c681c563ef7e85da6862354efc18d2a08b1b | 75b8c681c563ef7e85da6862354efc18d2a08b1b |
| linux | linux | >= e0639dc5805a9d4faaa2c07ad98fa853b9529dd3 < 8f565846fbe8182961498d4cbe618b15076a683b | 8f565846fbe8182961498d4cbe618b15076a683b |
| linux | linux | >= e0639dc5805a9d4faaa2c07ad98fa853b9529dd3 < 6ba434cb1a8d403ea9aad1b667c3ea3ad8b3191f | 6ba434cb1a8d403ea9aad1b667c3ea3ad8b3191f |
| linux | linux_kernel | >= 0 < 5.10.221-1 | 5.10.221-1 |
| linux | linux_kernel | >= 0 < 6.1.20-1 | 6.1.20-1 |
| linux | linux_kernel | >= 0 < 6.1.20-1 | 6.1.20-1 |
| linux | linux_kernel | >= 0 < 6.1.20-1 | 6.1.20-1 |
| linux | linux_kernel | >= 4.20 < 5.10.220 | 5.10.220 |
| linux | linux_kernel | >= 5.11 < 5.15.154 | 5.15.154 |
| linux | linux_kernel | >= 5.16 < 6.1.16 | 6.1.16 |
| linux | linux_kernel | >= 6.2 < 6.2.3 | 6.2.3 |
CVSS provenance
nvdv3.15.5MEDIUMCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
osv5.5MEDIUM
vendor_debian5.5MEDIUM
vendor_redhat5.5MEDIUM
Stop checking back — get the weekly exploitation signal.
Every Monday: what got weaponized or added to CISA KEV in the last seven days — each CVE cross-linked to its PoC, Nuclei template, and detection rule. Free, one email a week, unsubscribe in one click.
VulDB
Linux Kernel up to 5.10.219/5.15.153/6.1.15/6.2.2 nfsd_file reference count (EUVD-2023-60002 / WID-SEC-2025-2194)
vuldb·2026-04-28·CVSS 5.5
CVE-2023-53606 [MEDIUM] Linux Kernel up to 5.10.219/5.15.153/6.1.15/6.2.2 nfsd_file reference count (EUVD-2023-60002 / WID-SEC-2025-2194)
A vulnerability was found in Linux Kernel up to 5.10.219/5.15.153/6.1.15/6.2.2. It has been classified as critical. The affected element is the function nfsd_file. This manipulation causes improper update of reference count.
This vulnerability is tracked as CVE-2023-53606. The attack is only possible within the local network. No exploit exists.
Upgrading the affected component is recommended.
GHSA
GHSA-vqjq-cm24-xjp3: In the Linux kernel, the following vulnerability has been resolved:
nfsd: clean up potential nfsd_file refcount leaks in COPY codepath
There are two
ghsa_unreviewed·2025-10-04
CVE-2023-53606 [MEDIUM] GHSA-vqjq-cm24-xjp3: In the Linux kernel, the following vulnerability has been resolved:
nfsd: clean up potential nfsd_file refcount leaks in COPY codepath
There are two
In the Linux kernel, the following vulnerability has been resolved:
nfsd: clean up potential nfsd_file refcount leaks in COPY codepath
There are two different flavors of the nfsd4_copy struct. One is
embedded in the compound and is used directly in synchronous copies. The
other is dynamically allocated, refcounted and tracked in the client
struture. For the embedded one, the cleanup just involves releasing any
nfsd_files held on its behalf. For the async one, the cleanup is a bit
more involved, and we need to dequeue it from lists, unhash it, etc.
There is at least one potential refcount leak in this code now. If the
kthread_create call fails, then both the src and dst nfsd_files in the
original nfsd4_copy object are leaked.
The cleanup in this codepath is also sort of weird. In the as
OSV
CVE-2023-53606: In the Linux kernel, the following vulnerability has been resolved: nfsd: clean up potential nfsd_file refcount leaks in COPY codepath There are two d
osv·2025-10-04·CVSS 5.5
CVE-2023-53606 [MEDIUM] CVE-2023-53606: In the Linux kernel, the following vulnerability has been resolved: nfsd: clean up potential nfsd_file refcount leaks in COPY codepath There are two d
In the Linux kernel, the following vulnerability has been resolved: nfsd: clean up potential nfsd_file refcount leaks in COPY codepath There are two different flavors of the nfsd4_copy struct. One is embedded in the compound and is used directly in synchronous copies. The other is dynamically allocated, refcounted and tracked in the client struture. For the embedded one, the cleanup just involves releasing any nfsd_files held on its behalf. For the async one, the cleanup is a bit more involved, and we need to dequeue it from lists, unhash it, etc. There is at least one potential refcount leak in this code now. If the kthread_create call fails, then both the src and dst nfsd_files in the original nfsd4_copy object are leaked. The cleanup in this codepath is also sort of weird. In the async
Red Hat
kernel: nfsd: clean up potential nfsd_file refcount leaks in COPY codepath
vendor_redhat·2025-10-04·CVSS 5.5
CVE-2023-53606 [MEDIUM] CWE-911 kernel: nfsd: clean up potential nfsd_file refcount leaks in COPY codepath
kernel: nfsd: clean up potential nfsd_file refcount leaks in COPY codepath
In the Linux kernel, the following vulnerability has been resolved:
nfsd: clean up potential nfsd_file refcount leaks in COPY codepath
There are two different flavors of the nfsd4_copy struct. One is
embedded in the compound and is used directly in synchronous copies. The
other is dynamically allocated, refcounted and tracked in the client
struture. For the embedded one, the cleanup just involves releasing any
nfsd_files held on its behalf. For the async one, the cleanup is a bit
more involved, and we need to dequeue it from lists, unhash it, etc.
There is at least one potential refcount leak in this code now. If the
kthread_create call fails, then both the src and dst nfsd_files in the
original nfsd4_copy object a
Debian
CVE-2023-53606: linux - In the Linux kernel, the following vulnerability has been resolved: nfsd: clean...
vendor_debian·2023·CVSS 5.5
CVE-2023-53606 [MEDIUM] CVE-2023-53606: linux - In the Linux kernel, the following vulnerability has been resolved: nfsd: clean...
In the Linux kernel, the following vulnerability has been resolved: nfsd: clean up potential nfsd_file refcount leaks in COPY codepath There are two different flavors of the nfsd4_copy struct. One is embedded in the compound and is used directly in synchronous copies. The other is dynamically allocated, refcounted and tracked in the client struture. For the embedded one, the cleanup just involves releasing any nfsd_files held on its behalf. For the async one, the cleanup is a bit more involved, and we need to dequeue it from lists, unhash it, etc. There is at least one potential refcount leak in this code now. If the kthread_create call fails, then both the src and dst nfsd_files in the original nfsd4_copy object are leaked. The cleanup in this codepath is also sort of weird. In the async
No detection rules found.
No public exploits indexed.
https://git.kernel.org/stable/c/6ba434cb1a8d403ea9aad1b667c3ea3ad8b3191fhttps://git.kernel.org/stable/c/75b8c681c563ef7e85da6862354efc18d2a08b1bhttps://git.kernel.org/stable/c/8f565846fbe8182961498d4cbe618b15076a683bhttps://git.kernel.org/stable/c/b3169b6ffe036b549c296a9e71591d29a1fb3209https://git.kernel.org/stable/c/fd63299db8090307eae66f2aef17c8f00aafa0a9
2025-10-04
Published