UBUNTU-CVE-2024-26831
In the Linux kernel, the following vulnerability has been resolved: net/handshake: Fix handshake_req_destroy_test1 Recently, handshake_req_destroy_test1 started failing: Expected handshake_req_destroy_test == req, but handshake_req_destroy_test == 0000000000000000 req == 0000000060f99b40 not ok 11 req_destroy works This is because "sock_release(sock)" was replaced with "fput(filp)" to address a memory leak. Note that sock_release() is synchronous but fput() usually delays the final close and clean-up. The delay is not consequential in the other cases that were changed but handshake_req_destroy_test1 is testing that handshake_req_cancel() followed by closing the file actually does call the ->hp_destroy method. Thus the PTR_EQ test at the end has to be sure that the final close is complete before it checks the pointer. We cannot use a completion here because if ->hp_destroy is never called (ie, there is an API bug) then the test will hang. Reported by: Guenter Roeck <[email protected]>
02 / AFFECTED SOFTWARE
Affected packages
12 explicit affected versions
29 explicit affected versions
10 explicit affected versions
1 explicit affected versions
11 explicit affected versions
7 explicit affected versions
26 explicit affected versions
37 explicit affected versions
10 explicit affected versions
10 explicit affected versions
13 explicit affected versions
13 explicit affected versions
9 explicit affected versions
12 explicit affected versions
37 explicit affected versions
8 explicit affected versions
4 explicit affected versions
8 explicit affected versions
18 explicit affected versions
2 explicit affected versions
23 explicit affected versions
7 explicit affected versions
10 explicit affected versions
11 explicit affected versions
33 explicit affected versions
16 explicit affected versions
12 explicit affected versions
11 explicit affected versions
38 explicit affected versions
51 explicit affected versions
13 explicit affected versions
10 explicit affected versions
10 explicit affected versions
13 explicit affected versions
1 explicit affected versions
10 explicit affected versions
8 explicit affected versions
21 explicit affected versions
6 explicit affected versions
13 explicit affected versions
12 explicit affected versions
7 explicit affected versions
12 explicit affected versions
26 explicit affected versions
23 explicit affected versions
5 explicit affected versions
3 explicit affected versions
26 explicit affected versions
12 explicit affected versions
44 explicit affected versions
4 explicit affected versions
4 explicit affected versions
16 explicit affected versions
9 explicit affected versions
12 explicit affected versions
13 explicit affected versions
7 explicit affected versions
7 explicit affected versions
10 explicit affected versions
11 explicit affected versions
14 explicit affected versions
18 explicit affected versions
3 explicit affected versions
16 explicit affected versions
43 explicit affected versions
11 explicit affected versions
35 explicit affected versions
12 explicit affected versions
6 explicit affected versions
12 explicit affected versions
50 explicit affected versions
12 explicit affected versions
9 explicit affected versions
27 explicit affected versions
12 explicit affected versions
7 explicit affected versions
03 / CONNECTIONS
Connected vulnerabilities
04 / EVIDENCE
Source records
In the Linux kernel, the following vulnerability has been resolved: net/handshake: Fix handshake_req_destroy_test1 Recently, handshake_req_destroy_test1 started failing: Expected handshake_req_destroy_test == req, but handshake_req_destroy_test == 0000000000000000 req == 0000000060f99b40 not ok 11 req_destroy works This is because "sock_release(sock)" was replaced with "fput(filp)" to address a memory leak. Note that sock_release() is synchronous but fput() usually delays the final close and clean-up. The delay is not consequential in the other cases that were changed but handshake_req_destroy_test1 is testing that handshake_req_cancel() followed by closing the file actually does call the ->hp_destroy method. Thus the PTR_EQ test at the end has to be sure that the final close is complete before it checks the pointer. We cannot use a completion here because if ->hp_destroy is never called (ie, there is an API bug) then the test will hang. Reported by: Guenter Roeck <[email protected]>
05 / REFERENCES
Further evidence
- https://git.kernel.org/linus/4e1d71cabb19ec2586827adfc60d68689c68c194
- https://git.kernel.org/stable/c/4e1d71cabb19ec2586827adfc60d68689c68c194
- https://git.kernel.org/stable/c/7f97805b8df6e33850e225e6bd3ebd9e246920af
- https://git.kernel.org/stable/c/d74226e03df1bf19848f18344401f254345af912
- https://ubuntu.com/security/CVE-2024-26831
- https://ubuntu.com/security/notices/USN-6895-1
- https://ubuntu.com/security/notices/USN-6895-2
- https://ubuntu.com/security/notices/USN-6895-3
- https://ubuntu.com/security/notices/USN-6895-4
- https://ubuntu.com/security/notices/USN-6900-1
- https://www.cve.org/CVERecord?id=CVE-2024-26831