CVE-2026-68144 in Linux
Summary
by MITRE • 08/10/2026
In the Linux kernel, the following vulnerability has been resolved:
phonet: pep: fix use-after-free in pep_get_sb()
pep_get_sb() doesn't consider that pskb_may_pull() might have relocated the skb data, and continue to access the older pointer, causing UAF.
Reproduced under KASAN:
BUG: KASAN: slab-use-after-free in pep_get_sb+0x234/0x3b0 Read of size 1 at addr ff11000105510f50 by task repro/157 pep_get_sb+0x234/0x3b0 pipe_handler_do_rcv+0x5f7/0xa10 pep_do_rcv+0x203/0x410 __sk_receive_skb+0x471/0x4a0 phonet_rcv+0x5b3/0x6c0 __netif_receive_skb+0xcc/0x1d0
Refetch the header with skb_header_pointer() after pskb_may_pull(), so the possibly stale pointer is no longer dereferenced. There are better ways to solve this, but, this is the less instrusive one.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 08/10/2026
The vulnerability identified in the Linux kernel represents a use-after-free condition within the phonet protocol implementation, specifically affecting the pep_get_sb() function. This issue occurs in the context of the phonet networking subsystem which provides support for the phonet protocol used in certain mobile and embedded systems. The vulnerability arises from improper handling of socket buffer memory management during packet processing operations.
The technical flaw manifests when pskb_may_pull() function is called to ensure sufficient data is available in the socket buffer, but subsequent code continues to reference an older pointer that may have become invalid due to memory reallocation. This occurs because pskb_may_pull() can relocate the socket buffer data in memory, while the original pointer reference persists and is subsequently dereferenced, leading to a use-after-free condition. The vulnerability is particularly dangerous as it allows for potential memory corruption and arbitrary code execution.
The operational impact of this vulnerability is significant within kernel space environments where the phonet protocol is actively utilized. When exploited, the use-after-free condition can result in system instability, crashes, or potentially allow privilege escalation attacks. The vulnerability was successfully reproduced under KASAN (Kernel Address Sanitizer) which confirmed the slab-use-after-free error at the specific memory address ff11000105510f50. The call stack shows the execution path leading to the vulnerability through pipe_handler_do_rcv, pep_do_rcv, and ultimately __sk_receive_skb functions, demonstrating how the issue propagates through the network stack processing.
The fix implemented addresses this by refetching the header information using skb_header_pointer() after pskb_may_pull() has potentially relocated the socket buffer data. This approach ensures that all subsequent pointer references are valid and point to the current memory location of the data. While there are other potential solutions for addressing such memory management issues, this particular fix was chosen as the least intrusive method that maintains backward compatibility while resolving the core problem. The solution aligns with CWE-416 which describes use-after-free vulnerabilities in software systems.
This vulnerability classification places it within the broader context of kernel security flaws that can be exploited through network-based attacks, potentially enabling adversaries to gain elevated privileges or cause denial of service conditions. The ATT&CK framework would categorize this under privilege escalation techniques where attackers leverage kernel vulnerabilities to execute malicious code with system-level privileges. The phonet subsystem's use in mobile and embedded environments increases the attack surface, particularly in scenarios involving wireless communications or device-to-device networking protocols.
The mitigation strategy represents a defensive programming approach that ensures memory safety in kernel space operations. By implementing proper pointer validation after memory management functions, this fix prevents the exploitation of similar patterns in other kernel components. The solution demonstrates the importance of careful memory management practices in kernel code development and aligns with security best practices recommended by organizations such as the Linux Kernel Security Team. This vulnerability serves as a reminder of the critical need for thorough testing of memory management operations in kernel space, particularly when dealing with network protocol implementations that handle dynamic packet data structures.