CVE-2026-23004: Linux Kernel Use-After-Free Vulnerability

CVE-2026-23004 Overview

CVE-2026-23004 is a race condition vulnerability in the Linux kernel affecting the destination cache (dst) subsystem. The vulnerability exists in the rt6_uncached_list_del() and rt_del_uncached_list() functions, where improper synchronization during list operations can lead to a use-after-free condition. This flaw was discovered through syzbot fuzzing, which triggered a kernel crash in rt6_uncached_list_flush_dev().

The race condition occurs when one CPU performs list_del_init() or INIT_LIST_HEAD() operations while another CPU has already freed the underlying memory. Specifically, the issue manifests when writing to list->prev after list->next has been successfully modified, but the memory has been freed in the interim by a concurrent operation that bypassed the spinlock due to a premature list_empty() check returning true.

Critical Impact
This use-after-free vulnerability can cause kernel crashes (denial of service) and may potentially be exploitable for privilege escalation in multi-threaded network environments where network namespace cleanup occurs concurrently with route cache operations.

Affected Products

Linux kernel (IPv6 routing subsystem - net/ipv6/route.c)
Linux kernel (IPv4 routing subsystem - net/ipv4/route.c)
Systems using network namespaces with frequent interface bring-up/teardown operations

Discovery Timeline

January 25, 2026 - CVE-2026-23004 published to NVD
January 26, 2026 - Last updated in NVD database

Technical Details for CVE-2026-23004

Vulnerability Analysis

The vulnerability is a classic Time-of-Check Time-of-Use (TOCTOU) race condition in the kernel's route cache management. The root issue lies in the rt6_uncached_list_del() function, which checks whether a route entry's uncached list is empty before acquiring the spinlock. Due to the non-atomic nature of doubly-linked list operations, a concurrent INIT_LIST_HEAD() operation can set list->next to point to itself, causing list_empty() to return true on another CPU even before list->prev has been updated.

The crash occurs in the rt6_disable_ip() path during network device unregistration via addrconf_ifdown(). When processing the uncached route list flush, if the spinlock is not properly acquired due to the false positive from list_empty(), the code proceeds to access memory that has already been freed, resulting in a slab-use-after-free condition as reported by KASAN.

Root Cause

The root cause is insufficient locking discipline in rt6_uncached_list_del(). The function used list_empty(&rt->dst.rt_uncached) as a fast-path check to avoid acquiring the spinlock ul->lock. However, this check is not safe against concurrent list_del_init() operations because the WRITE_ONCE(list->next, list) in INIT_LIST_HEAD() can complete before WRITE_ONCE(list->prev, list), creating a window where list_empty() returns true while the list entry is still being modified.

The fix requires either using list_del_init_careful() paired with list_empty_careful() (which provides proper memory barriers), or unconditionally acquiring the spinlock whenever rt->dst.rt_uncached_list has been set, regardless of the apparent list emptiness.

Attack Vector

This vulnerability can be triggered through normal kernel operations involving network namespace cleanup, particularly when:

Multiple workqueues are processing network events concurrently
Network interfaces are being rapidly brought up and down
MLD (Multicast Listener Discovery) operations are occurring simultaneously with device unregistration
The cleanup_net workqueue processes namespace teardown while mld_ifc_work handles ICMP6 destination allocations

The vulnerability is triggered internally by kernel operations rather than direct user input, but an unprivileged user with network namespace capabilities (CAP_NET_ADMIN in a user namespace) could potentially craft conditions to trigger this race by manipulating network interface states.

Detection Methods for CVE-2026-23004

Indicators of Compromise

KASAN (Kernel Address Sanitizer) reports showing slab-use-after-free in rt6_uncached_list_flush_dev or related functions
Kernel crash dumps with stack traces involving list_del_init, INIT_LIST_HEAD, rt6_disable_ip, or addrconf_ifdown
Unexpected kernel panics during network namespace cleanup or interface teardown operations
System log entries indicating BUG: KASAN with writes to freed memory at offsets consistent with struct list_head

Detection Strategies

Enable KASAN (Kernel Address Sanitizer) in debug kernel builds to detect use-after-free conditions
Monitor for kernel oops or panic events with stack traces containing rt6_uncached_list or rt_del_uncached_list functions
Deploy eBPF probes to monitor spinlock acquisition patterns in rt6_uncached_list_del() and rt_del_uncached_list()
Use kernel tracing (ftrace) to detect anomalous list operations in the IPv4/IPv6 routing subsystems

Monitoring Recommendations

Enable continuous kernel log monitoring for KASAN reports and use-after-free warnings
Implement alerts for unexpected worker thread crashes in netns cleanup_net workqueue
Monitor system stability metrics during periods of high network namespace churn
Track kernel crash patterns that correlate with network interface bring-up/teardown events

How to Mitigate CVE-2026-23004

Immediate Actions Required

Apply the official kernel patches referenced in Kernel Patch 722de9452161 and Kernel Patch 9a6f0c4d5796
Update to the latest stable kernel version that includes these fixes
Reduce the frequency of network namespace creation and destruction if patching is not immediately possible
Monitor systems for unexpected kernel panics and collect crash dumps for analysis

Patch Information

The fix has been committed to the stable kernel tree. Two patches are available:

Kernel Patch 722de9452161 - Primary fix for the race condition
Kernel Patch 9a6f0c4d5796 - Related fix for IPv4/IPv6 uncached list handling

These patches ensure that rt6_uncached_list_del() always acquires the spinlock when rt->dst.rt_uncached_list has been set, eliminating the TOCTOU race condition. Organizations should upgrade to kernel versions containing these commits through their Linux distribution's package manager.

Workarounds

Limit network namespace operations to reduce the likelihood of triggering the race condition
Avoid rapid interface bring-up/teardown cycles in production environments
Consider using kernel livepatching solutions (kpatch, livepatch) if immediate reboot is not feasible
Isolate workloads that heavily use network namespaces until patching is complete

bash

# Check current kernel version
uname -r

# Verify if patches are applied (check git log of your kernel source)
# Example for distributions using git-based kernel sources:
git log --oneline net/ipv6/route.c | grep -i "uncached"

# Update kernel on Debian/Ubuntu
sudo apt update && sudo apt upgrade linux-image-$(uname -r)

# Update kernel on RHEL/CentOS/Fedora
sudo dnf update kernel