7.8 CVE-2025-38236
Enriched by CISA Patch
In the Linux kernel, the following vulnerability has been resolved:
af_unix: Don't leave consecutive consumed OOB skbs.
Jann Horn reported a use-after-free in unix_stream_read_generic().
The following sequences reproduce the issue:
$ python3
from socket import *
s1, s2 = socketpair(AF_UNIX, SOCK_STREAM)
s1.send(b'x', MSG_OOB)
s2.recv(1, MSG_OOB) # leave a consumed OOB skb
s1.send(b'y', MSG_OOB)
s2.recv(1, MSG_OOB) # leave a consumed OOB skb
s1.send(b'z', MSG_OOB)
s2.recv(1) # recv 'z' illegally
s2.recv(1, MSG_OOB) # access 'z' skb (use-after-free)
Even though a user reads OOB data, the skb holding the data stays on
the recv queue to mark the OOB boundary and break the next recv().
After the last send() in the scenario above, the sk2's recv queue has
2 leading consumed OOB skbs and 1 real OOB skb.
Then, the following happens during the next recv() without MSG_OOB
1. unix_stream_read_generic() peeks the first consumed OOB skb
2. manage_oob() returns the next consumed OOB skb
3. unix_stream_read_generic() fetches the next not-yet-consumed OOB skb
4. unix_stream_read_generic() reads and frees the OOB skb
, and the last recv(MSG_OOB) triggers KASAN splat.
The 3. above occurs because of the SO_PEEK_OFF code, which does not
expect unix_skb_len(skb) to be 0, but this is true for such consumed
OOB skbs.
while (skip >= unix_skb_len(skb)) {
skip -= unix_skb_len(skb);
skb = skb_peek_next(skb, &sk->sk_receive_queue);
...
}
In addition to this use-after-free, there is another issue that
ioctl(SIOCATMARK) does not function properly with consecutive consumed
OOB skbs.
So, nothing good comes out of such a situation.
Instead of complicating manage_oob(), ioctl() handling, and the next
ECONNRESET fix by introducing a loop for consecutive consumed OOB skbs,
let's not leave such consecutive OOB unnecessarily.
Now, while receiving an OOB skb in unix_stream_recv_urg(), if its
previous skb is a consumed OOB skb, it is freed.
[0]:
BUG: KASAN: slab-use-after-free in unix_stream_read_actor (net/unix/af_unix.c:3027)
Read of size 4 at addr ffff888106ef2904 by task python3/315
CPU: 2 UID: 0 PID: 315 Comm: python3 Not tainted 6.16.0-rc1-00407-gec315832f6f9 #8 PREEMPT(voluntary)
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-4.fc42 04/01/2014
Call Trace:
<TASK>
dump_stack_lvl (lib/dump_stack.c:122)
print_report (mm/kasan/report.c:409 mm/kasan/report.c:521)
kasan_report (mm/kasan/report.c:636)
unix_stream_read_actor (net/unix/af_unix.c:3027)
unix_stream_read_generic (net/unix/af_unix.c:2708 net/unix/af_unix.c:2847)
unix_stream_recvmsg (net/unix/af_unix.c:3048)
sock_recvmsg (net/socket.c:1063 (discriminator 20) net/socket.c:1085 (discriminator 20))
__sys_recvfrom (net/socket.c:2278)
__x64_sys_recvfrom (net/socket.c:2291 (discriminator 1) net/socket.c:2287 (discriminator 1) net/socket.c:2287 (discriminator 1))
do_syscall_64 (arch/x86/entry/syscall_64.c:63 (discriminator 1) arch/x86/entry/syscall_64.c:94 (discriminator 1))
entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)
RIP: 0033:0x7f8911fcea06
Code: 5d e8 41 8b 93 08 03 00 00 59 5e 48 83 f8 fc 75 19 83 e2 39 83 fa 08 75 11 e8 26 ff ff ff 66 0f 1f 44 00 00 48 8b 45 10 0f 05 <48> 8b 5d f8 c9 c3 0f 1f 40 00 f3 0f 1e fa 55 48 89 e5 48 83 ec 08
RSP: 002b:00007fffdb0dccb0 EFLAGS: 00000202 ORIG_RAX: 000000000000002d
RAX: ffffffffffffffda RBX: 00007fffdb0dcdc8 RCX: 00007f8911fcea06
RDX: 0000000000000001 RSI: 00007f8911a5e060 RDI: 0000000000000006
RBP: 00007fffdb0dccd0 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000001 R11: 0000000000000202 R12: 00007f89119a7d20
R13: ffffffffc4653600 R14: 0000000000000000 R15: 0000000000000000
</TASK>
Allocated by task 315:
kasan_save_stack (mm/kasan/common.c:48)
kasan_save_track (mm/kasan/common.c:60 (discriminator 1) mm/kasan/common.c:69 (discriminator 1))
__kasan_slab_alloc (mm/kasan/common.c:348)
kmem_cache_alloc_
---truncated---
https://nvd.nist.gov/vuln/detail/CVE-2025-38236
Categories
CWE-416 : Use After Free
The product reuses or references memory after it has been freed. At some point afterward, the memory may be allocated again and saved in another pointer, while the original pointer references a location somewhere within the new allocation. Any operations using the original pointer are no longer valid because the memory "belongs" to the code that operates on the new pointer. If the product accesses a previously-freed pointer, then it means that a separate weakness or error already occurred previously, such as a race condition, an unexpected or poorly handled error condition, confusion over which part of the program is responsible for freeing the memory, performing the free too soon, etc. a pointer that no longer points to valid memory, often after it has been freed commonly used acronym for Use After Free Fuzz testing (fuzzing) is a powerful technique for generating large numbers of diverse inputs - either randomly or algorithmically - and dynamically invoking the code with those inputs. Even with random inputs, it is often capable of generating unexpected results such as crashes, memory corruption, or resource consumption. Fuzzing effectively produces repeatable test cases that clearly indicate bugs, which helps developers to diagnose the issues. Automated static analysis, commonly referred to as Static Application Security Testing (SAST), can find some instances of this weakness by analyzing source code (or binary/compiled code) without having to execute it. Typically, this is done by building a model of data flow and control flow, then searching for potentially-vulnerable patterns that connect "sources" (origins of input) with "sinks" (destinations where the data interacts with external components, a lower layer such as the OS, etc.) Use tools that are integrated duringcompilation to insert runtime error-checking mechanismsrelated to memory safety errors, such as AddressSanitizer(ASan) for C/C++ [REF-1518]. Choose a language that provides automatic memory management. When freeing pointers, be sure to set them to NULL once they are freed. However, the utilization of multiple or complex data structures may lower the usefulness of this strategy. Chain: an operating system kernel has insufficent resource locking (CWE-413) leading to a use after free (CWE-416). Chain: two threads in a web browser use the same resource (CWE-366), but one of those threads can destroy the resource before the other has completed (CWE-416). Chain: mobile platform race condition (CWE-362) leading to use-after-free (CWE-416), as exploited in the wild per CISA KEV. Chain: race condition (CWE-362) leads to use-after-free (CWE-416), as exploited in the wild per CISA KEV. Use-after-free triggered by closing a connection while data is still being transmitted. Improper allocation for invalid data leads to use-after-free. certificate with a large number of Subject Alternate Names not properly handled in realloc, leading to use-after-free Timers are not disabled when a related object is deleted Access to a "dead" object that is being cleaned up object is deleted even with a non-zero reference count, and later accessed use-after-free involving request containing an invalid version number unload of an object that is currently being accessed by other functionality incorrectly tracking a reference count leads to use-after-free use-after-free related to use of uninitialized memory HTML document with incorrectly-nested tags Use after free in ActiveX object by providing a malformed argument to a method use-after-free by disconnecting during data transfer, or a message containing incorrect data types disconnect during a large data transfer causes incorrect reference count, leading to use-after-free use-after-free found by fuzzing Chain: race condition (CWE-362) from improper handling of a page transition in web client while an applet is loading (CWE-368) leads to use after free (CWE-416) realloc generates new buffer and pointer, but previous pointer is still retained, leading to use after free Use-after-free in web browser, probably resultant from not initializing memory. use-after-free when one thread accessed memory that was freed by another thread assignment of malformed values to certain properties triggers use after free mail server does not properly handle a long header. chain: integer overflow leads to use-after-free freed pointer dereference Chain: A multi-threaded race condition (CWE-367) allows attackers to cause two threads to process the same RPC request, which causes a use-after-free (CWE-416) in one thread
References
416baaa9-dc9f-4396-8d5f-8c081fb06d67 Patch
af854a3a-2127-422b-91ae-364da2661108 Patch
| https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html Mailing List Third Party Advisory |
AFFECTED (from MITRE)
| Vendor | Product | Versions |
|---|---|---|
| Linux | Linux |
|
| Linux | Linux |
|
| © 2022 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. | ||
CPE
| cpe | start | end |
|---|---|---|
| Configuration 1 | ||
| cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* | >= 5.15 | < 5.15.194 |
| cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* | >= 5.16 | < 6.1.143 |
| cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* | >= 6.2 | < 6.6.96 |
| cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* | >= 6.7 | < 6.12.36 |
| cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* | >= 6.13 | < 6.15.5 |
| cpe:2.3:o:linux:linux_kernel:6.16:rc1:*:*:*:*:*:* | ||
| cpe:2.3:o:linux:linux_kernel:6.16:rc2:*:*:*:*:*:* | ||
| cpe:2.3:o:linux:linux_kernel:6.16:rc3:*:*:*:*:*:* | ||
| Configuration 2 | ||
| cpe:2.3:o:debian:debian_linux:11.0:*:*:*:*:*:*:* | ||
REMEDIATION
Patch
EXPLOITS
Exploit-db.com
| id | description | date | |
|---|---|---|---|
| No known exploits | |||
POC Github
| Url |
|---|
| No known exploits |
Other Nist (github, ...)
| Url |
|---|
| No known exploits |
CAPEC
Common Attack Pattern Enumerations and Classifications
| id | description | severity |
|---|---|---|
| No entry | ||
Cybersecurity needs ?
Strengthen software security from the outset with our DevSecOps expertise
Integrate security right from the start of the software development cycle for more robust applications and greater customer confidence.
Our team of DevSecOps experts can help you secure your APIs, data pipelines, CI/CD chains, Docker containers and Kubernetes deployments.
