CVE-2026-23326 Overview
A memory leak vulnerability exists in the Linux kernel's XSK (AF_XDP socket) subsystem due to improper fragment node deletion in the buffer management code. The vulnerability was introduced after commit b692bf9a7543 which reused the list_node field for both the xskb pool list and the buffer free list. When buffers are removed from the xskb pool list using list_del(), the node pointers are not reinitialized, causing list_empty() checks to incorrectly return false. This results in xp_free() skipping the addition of buffers to the free list, leading to a gradual memory leak that can impact system stability over time.
Critical Impact
Sustained exploitation of this memory leak can lead to kernel memory exhaustion, potentially causing system instability or denial of service on systems utilizing AF_XDP sockets for high-performance network packet processing.
Affected Products
- Linux Kernel (versions with commit b692bf9a7543 applied)
- Systems utilizing AF_XDP sockets for network packet processing
- Network appliances and servers with XDP-enabled network configurations
Discovery Timeline
- 2026-03-25 - CVE CVE-2026-23326 published to NVD
- 2026-03-25 - Last updated in NVD database
Technical Details for CVE-2026-23326
Vulnerability Analysis
The vulnerability stems from a code change in the XSK subsystem that consolidated the use of the list_node field within the xdp_buff_xsk structure. Prior to commit b692bf9a7543, separate list nodes were maintained for the xskb pool list and the buffer free list. After the consolidation, a single list_node field serves dual purposes, creating a conflict in how list membership is tracked.
The core issue lies in the xp_free() function's use of list_empty(&xskb->list_node) to determine whether a buffer should be added to the free list. When list_del() is called to remove a node from the xskb pool list, it sets the node's next and prev pointers to LIST_POISON1 and LIST_POISON2 respectively, rather than reinitializing them to point to the node itself. Consequently, list_empty() returns false (indicating the node is still part of a list), causing xp_free() to skip the buffer, resulting in a memory leak.
Root Cause
The root cause is the improper use of list_del() instead of list_del_init() in fragment handling paths within the XSK subsystem. The list_del() function removes a node from a linked list but leaves the node's pointers in an undefined state (poisoned values for debugging). In contrast, list_del_init() removes the node and reinitializes its pointers to create an empty list state, which is the expected behavior for subsequent list_empty() checks to function correctly.
Attack Vector
This vulnerability manifests during normal XSK socket operations involving fragmented packets. When XDP programs process multi-fragment packets and subsequently free buffers, the improper list management causes buffers to be orphaned rather than returned to the free pool. An attacker with local access who can generate sustained XDP socket traffic with fragmented packets could potentially accelerate memory exhaustion, leading to degraded system performance or denial of service conditions.
The vulnerability requires local access to create and manipulate AF_XDP sockets, which typically requires elevated privileges or specific capability grants (CAP_NET_RAW or CAP_NET_ADMIN).
Detection Methods for CVE-2026-23326
Indicators of Compromise
- Gradual increase in kernel memory usage over time on systems running AF_XDP applications
- xsk or xdp related memory allocation failures in kernel logs
- Unexplained system slowdowns or OOM (Out of Memory) killer activations on network-intensive workloads
- Growing slab cache utilization in /proc/slabinfo for XSK-related objects
Detection Strategies
- Monitor /proc/meminfo for abnormal kernel memory growth patterns on systems using AF_XDP
- Implement alerting on MemFree and Slab metrics trending toward critical thresholds
- Use bpftrace or ftrace to trace xp_free() function calls and detect skipped buffer additions
- Deploy kernel memory leak detection tools such as kmemleak during testing phases
Monitoring Recommendations
- Enable kernel memory debugging options during development and testing phases
- Implement continuous monitoring of kernel slab allocations on production systems using XDP
- Set up automated alerts for memory pressure events that may indicate gradual leaks
- Regularly review dmesg output for XSK-related warning or error messages
How to Mitigate CVE-2026-23326
Immediate Actions Required
- Apply the latest kernel patches that replace list_del() with list_del_init() in XSK fragment handling paths
- Prioritize patching on systems that actively utilize AF_XDP sockets for network processing
- Schedule kernel updates for all affected systems, prioritizing network appliances and high-performance computing nodes
- Implement regular system reboots as a temporary measure to reclaim leaked memory if patching is delayed
Patch Information
The Linux kernel maintainers have released patches that fix this vulnerability by changing all fragment handling paths to use list_del_init() instead of list_del(). This ensures the list node is properly reinitialized after removal, allowing list_empty() checks to function correctly and preventing buffer leaks.
Multiple patch commits are available for different kernel stable branches:
- Linux Kernel Commit 2a9ea98
- Linux Kernel Commit 5172adf9
- Linux Kernel Commit 60abb0ac
- Linux Kernel Commit 645c6d83
- Linux Kernel Commit b38cbd4a
Workarounds
- If immediate patching is not feasible, consider temporarily disabling XDP-accelerated applications and reverting to traditional socket interfaces
- Implement memory monitoring scripts that trigger proactive system restarts when kernel memory reaches critical thresholds
- Reduce the volume of fragmented packet processing through XDP sockets where possible
- Limit AF_XDP socket creation to essential services and trusted applications using capability restrictions
# Configuration example: Monitor kernel memory and alert on potential leaks
#!/bin/bash
# Memory monitoring script for systems vulnerable to CVE-2026-23326
THRESHOLD_KB=1048576 # 1GB threshold for kernel slab growth
INTERVAL=300 # Check every 5 minutes
while true; do
SLAB_USAGE=$(grep "^Slab:" /proc/meminfo | awk '{print $2}')
if [ "$SLAB_USAGE" -gt "$THRESHOLD_KB" ]; then
logger -p kern.warning "CVE-2026-23326: High slab usage detected: ${SLAB_USAGE}KB"
fi
sleep $INTERVAL
done
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.


