net/handshake: Take a long-lived file reference at submit
- 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 6.6.160, 6.12.93, 6.18.44, 7.0.12
- 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: total
Summary
In the Linux kernel, the following vulnerability has been resolved: net/handshake: Take a long-lived file reference at submit handshake_nl_accept_doit() needs the file pointer backing req->hr_sk->sk_socket to survive the window between handshake_req_next() and the subsequent FD_PREPARE() and get_file(). The submit-side sock_hold() does not provide that. sk_refcnt keeps struct sock alive, but struct socket is owned by sock->file: when the consumer fputs the last file reference, sock_release() tears the socket down regardless of any sock_hold. Add an hr_file pointer to struct handshake_req and acquire an explicit reference on sock->file during handshake_req_submit(). handshake_complete() and handshake_req_cancel() release the reference on the completion-bit-winning path. The submit error path must also release the file reference, but after rhashtable insertion a concurrent handshake_req_cancel() can discover the request and race the error path. Gate the error-path cleanup -- sk_destruct restoration, fput, and request destruction -- with test_and_set_bit(HANDSHAKE_F_REQ_COMPLETED), the same serialization handshake_complete() and handshake_req_cancel() already use. When cancel has already claimed ownership, the submit error path returns without touching the request; socket teardown handles final destruction. The accept-side dereferences are not yet retargeted; that change comes in the next patch.
Timeline
- CVE published
- CISA SSVC assessment
Exploitation: none · Automatable: yes · Technical impact: total
- Record last updated
Affected versions
- Linux Linux
From 3b3009ea8abb713b022d94fba95ec270cf6e7eae · fixed in 22e371a93563c30ebebc576db049785e0d7fc617; From 3b3009ea8abb713b022d94fba95ec270cf6e7eae · fixed in 685b10dd0e32c7782cead16c8cf055c609678583; From 3b3009ea8abb713b022d94fba95ec270cf6e7eae · fixed in b913801ad9b9a51437d84d030ec6843e08976bd6; From 3b3009ea8abb713b022d94fba95ec270cf6e7eae · fixed in 16eaba5aa89c04eea125905bb8f988c1897f4f29; From 3b3009ea8abb713b022d94fba95ec270cf6e7eae · fixed in 09dba37eee70d0596e26645015f1aa95a9848e9d
- Linux Linux
6.4
- KernelLinux
From 6.4.0 · fixed in 6.6.160; From 6.7.0 · fixed in 6.12.93; From 6.13.0 · fixed in 6.18.44; From 6.19.0 · fixed in 7.0.12