CVE-2026-98383 in Linux
Summary
by MITRE • 10/09/2026
In the Linux kernel, the following vulnerability has been resolved:
bpf: Disallow bpf_skb_pull_data() for LWT_SEG6LOCAL
An LWT_SEG6LOCAL program can invalidate its cached SRH with bpf_lwt_seg6_adjust_srh() and then call bpf_skb_pull_data(). The latter may reallocate skb->head, leaving the per-CPU SRH pointer dangling. Post-program SRH validation then writes through that pointer.
Disallow bpf_skb_pull_data() for LWT_SEG6LOCAL programs so the verifier rejects this unsafe helper combination. Other LWT program types continue to expose the helper through lwt_out_func_proto().
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/09/2026
The Linux kernel's eBPF subsystem provides a powerful mechanism for extending network functionality, allowing developers to write safe and efficient code that runs in kernel space. However, the complexity of managing memory pointers across different contexts introduces subtle risks when helpers interact with specific data structures. In this instance, a critical vulnerability was identified within the handling of Light Weight Tunneling (LWT) programs, specifically those utilizing the SEG6LOCAL type. The core issue stems from an unsafe interaction between two eBPF helper functions: bpf_lwt_seg6_adjust_srh() and bpf_skb_pull_data(). While each function serves a legitimate purpose in network packet manipulation, their combined use within this specific program context creates a dangerous race condition leading to memory corruption.
The technical flaw arises from the way Segment Routing Header (SRH) data is cached for LWT_SEG6LOCAL programs. When an eBPF program calls bpf_lwt_seg6_adjust_srh(), it modifies the SRH and updates a per-CPU cache pointer that tracks this header's location in memory to optimize subsequent operations. Subsequently, if the same program invokes bpf_skb_pull_data() to adjust the packet data pointers or reallocate the socket buffer head due to insufficient space, the underlying kernel may move the skb->head to a new memory address. This reallocation invalidates the previously cached per-CPU SRH pointer because it still references the old, now freed or unmapped, memory location. Consequently, any post-program validation logic that attempts to write through this stale pointer results in writing to an arbitrary or corrupted memory address, effectively creating a dangling pointer vulnerability.
From a security perspective, this flaw represents a classic use-after-free scenario where kernel memory is accessed after it has been made available for reuse by other parts of the system. This can lead to severe operational impacts including kernel panics due to invalid memory access, privilege escalation if an attacker can control the data written through the dangling pointer, or denial of service by corrupting critical kernel structures. The vulnerability highlights the difficulty in maintaining consistency between cached metadata and actual packet buffer locations during dynamic reallocation events. It underscores the necessity for strict validation within eBPF programs to ensure that helper functions do not invalidate previously established pointers without proper synchronization or cache invalidation mechanisms.
To mitigate this risk, the Linux kernel developers have implemented a fix by explicitly disallowing the use of bpf_skb_pull_data() within LWT_SEG6LOCAL program contexts. The BPF verifier now rejects any attempt to invoke this helper function when running under an LWT_SEG6LOCAL program type, thereby preventing the unsafe combination at compile time rather than relying on runtime checks alone. This restriction ensures that programs cannot trigger the memory reallocation sequence while holding a stale SRH pointer. Other LWT program types remain unaffected and continue to expose the bpf_skb_pull_data() helper through their respective function prototypes, as they do not suffer from this specific caching inconsistency.
This vulnerability aligns with CWE-416, Use After Free, where memory is accessed after it has been freed or invalidated, leading to undefined behavior. In terms of the MITRE ATT&CK framework for enterprise security, such kernel-level vulnerabilities are often associated with techniques that facilitate persistence or privilege escalation by exploiting low-level system components. The fix demonstrates a proactive approach to secure coding within the eBPF ecosystem by tightening verifier rules to prevent known dangerous helper combinations. Administrators and developers should ensure their systems are updated with patches containing this verification logic update to maintain the integrity of network processing pipelines and prevent potential exploitation through crafted eBPF programs targeting Segment Routing functionalities.