CVE-2023-53606

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nfsd: clean up potential nfsd_file refcount leaks in COPY codepath<br /> <br /> There are two different flavors of the nfsd4_copy struct. One is<br /> embedded in the compound and is used directly in synchronous copies. The<br /> other is dynamically allocated, refcounted and tracked in the client<br /> struture. For the embedded one, the cleanup just involves releasing any<br /> nfsd_files held on its behalf. For the async one, the cleanup is a bit<br /> more involved, and we need to dequeue it from lists, unhash it, etc.<br /> <br /> There is at least one potential refcount leak in this code now. If the<br /> kthread_create call fails, then both the src and dst nfsd_files in the<br /> original nfsd4_copy object are leaked.<br /> <br /> The cleanup in this codepath is also sort of weird. In the async copy<br /> case, we&amp;#39;ll have up to four nfsd_file references (src and dst for both<br /> flavors of copy structure). They are both put at the end of<br /> nfsd4_do_async_copy, even though the ones held on behalf of the embedded<br /> one outlive that structure.<br /> <br /> Change it so that we always clean up the nfsd_file refs held by the<br /> embedded copy structure before nfsd4_copy returns. Rework<br /> cleanup_async_copy to handle both inter and intra copies. Eliminate<br /> nfsd4_cleanup_intra_ssc since it now becomes a no-op.