nfsd: clean up potential nfsd_file refcount leaks in COPY codepath
- Published
- Last modified
- Where the record stands: published, rejected by its publisher, or superseded by another id.What do these mean? →
- published
- Whether CISA lists it in its Known Exploited Vulnerabilities catalog: proof that attackers are using it.What do these mean? →
- Not listed in CISA KEV
- Fix
- Fixed in 5.10.220, 5.15.154, 6.1.16, 6.2.3
- Whether working attack code is public (Exploit-DB, Metasploit, Nuclei or GitHub). Public code makes attacks easier.What do these mean? →
- None on Exploit-DB, Metasploit or GitHub
- Exploitation: none
- Automatable: yes
- Technical impact: partial
Summary
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.
Timeline
- CVE published
- CISA SSVC assessment
Exploitation: none · Automatable: yes · Technical impact: partial
- Record last updated
Affected versions
- Linux Linux
From e0639dc5805a9d4faaa2c07ad98fa853b9529dd3 · fixed in fd63299db8090307eae66f2aef17c8f00aafa0a9; From e0639dc5805a9d4faaa2c07ad98fa853b9529dd3 · fixed in b3169b6ffe036b549c296a9e71591d29a1fb3209; From e0639dc5805a9d4faaa2c07ad98fa853b9529dd3 · fixed in 75b8c681c563ef7e85da6862354efc18d2a08b1b; From e0639dc5805a9d4faaa2c07ad98fa853b9529dd3 · fixed in 8f565846fbe8182961498d4cbe618b15076a683b; From e0639dc5805a9d4faaa2c07ad98fa853b9529dd3 · fixed in 6ba434cb1a8d403ea9aad1b667c3ea3ad8b3191f
- Linux Linux
4.20
- KernelLinux
From 4.20.0 · fixed in 5.10.220; From 5.11.0 · fixed in 5.15.154; From 5.16.0 · fixed in 6.1.16; From 6.2.0 · fixed in 6.2.3