CVE-2025-21718: Linux Kernel Use-After-Free Vulnerability

CVE-2025-21718 Overview

CVE-2025-21718 is a race condition vulnerability in the Linux kernel's ROSE (Radio Over Serial Line Encapsulation) network protocol implementation. The vulnerability exists in the timer handling code where Rose timers only acquire the socket spinlock without verifying if the socket is currently owned by a user thread. This improper synchronization leads to a use-after-free condition that can be exploited for privilege escalation or denial of service.

Critical Impact

Local attackers with low privileges can exploit this race condition to potentially execute arbitrary code in kernel context or cause system crashes through use-after-free memory corruption.

Affected Products

• Linux Kernel (multiple versions with ROSE protocol support)
• Debian Linux distributions (as noted in LTS announcements)
• Systems with net/rose module enabled

Discovery Timeline

• February 27, 2025 - CVE-2025-21718 published to NVD
• November 03, 2025 - Last updated in NVD database

Technical Details for CVE-2025-21718

Vulnerability Analysis

This vulnerability is classified as CWE-362 (Race Condition). The flaw occurs in the rose_timer_expiry function located at net/rose/rose_timer.c. When a timer fires and attempts to process socket data, it only acquires the socket spinlock but fails to check whether a user thread currently owns the socket. This creates a window where both the timer interrupt handler and a user thread can simultaneously access and modify socket structures.

The kernel KASAN (Kernel Address Sanitizer) detected this as a slab-use-after-free error, indicating that the timer callback accessed memory that had already been freed by a concurrent user thread operation. The vulnerability requires local access and specific timing conditions to exploit, but successful exploitation could lead to information disclosure, privilege escalation, or system instability.

Root Cause

The root cause lies in insufficient synchronization between the Rose protocol timer callbacks and user-space socket operations. The timer implementation acquires only the socket spinlock without performing an ownership check via sock_owned_by_user(). This means that when a user thread is actively manipulating the socket (holding the socket lock in user context), the timer can still proceed to access socket data structures that may be in an inconsistent state or have been deallocated.

The fix adds a check to verify socket ownership before proceeding with timer operations. If the socket is owned by a user thread, the timer is rearmed to fire again later rather than operating on potentially invalid data.

Attack Vector

The attack requires local access to the system with the ability to create and manipulate ROSE protocol sockets. An attacker would need to:

1. Create a ROSE socket and establish timer-based operations
2. Trigger a race condition between socket cleanup in user context and timer expiry in interrupt context
3. Win the race to cause the timer to access freed memory

The vulnerability was identified through automated testing (syzkaller fuzzer) running on kernel version 6.13.0-rc5-syzkaller-00172. The KASAN report shows the crash occurring in the timer softirq context (swapper/0 process with PID 0), indicating this is triggered from interrupt context accessing user-allocated memory.

The call trace demonstrates the execution path through rose_timer_expiry → call_timer_fn → expire_timers → __run_timers → run_timer_softirq, confirming the timer interrupt context. The vulnerability manifests when this timer path races against user thread socket operations that can free the underlying socket structure.

Detection Methods for CVE-2025-21718

Indicators of Compromise

• Kernel panic or crash logs referencing rose_timer_expiry in the call stack
• KASAN reports showing slab-use-after-free at address patterns in net/rose/rose_timer.c
• System instability when ROSE protocol sockets are in active use
• Unexpected system reboots on systems with ROSE networking enabled

Detection Strategies

• Enable KASAN in kernel builds to detect use-after-free conditions during testing
• Monitor kernel logs for warnings or errors related to the ROSE network subsystem (net/rose)
• Deploy intrusion detection rules to alert on unusual ROSE socket activity
• Audit loaded kernel modules for rose.ko presence on systems where it's not required

Monitoring Recommendations

• Configure kernel auditing to log ROSE socket syscall activity
• Implement system monitoring for kernel oops or panic events
• Review /var/log/kern.log and dmesg output for ROSE-related errors
• Use SentinelOne's kernel-level monitoring to detect exploitation attempts targeting race conditions

How to Mitigate CVE-2025-21718

Immediate Actions Required

• Apply the kernel patches from the official Linux kernel stable branches immediately
• If patching is not immediately possible, disable the ROSE protocol module if not required (modprobe -r rose)
• Restrict local user access to systems running vulnerable kernels
• Monitor affected systems for signs of exploitation until patches are applied

Patch Information

The Linux kernel maintainers have released patches to address this vulnerability across multiple stable kernel branches. The fix adds proper socket ownership checking before timer operations proceed, rearming the timer if the socket is currently owned by a user thread.

Official patch commits are available:

• Kernel Git Commit #1992fb2
• Kernel Git Commit #51c128b
• Kernel Git Commit #58051a2
• Kernel Git Commit #5de7665
• Kernel Git Commit #f55c88e

Debian has issued security updates via their LTS channels - see the Debian LTS Announcement March 2025 and Debian LTS Announcement May 2025.

Workarounds

• Disable the ROSE kernel module if not actively used: echo "blacklist rose" >> /etc/modprobe.d/blacklist.conf
• Remove the module from running systems: modprobe -r rose
• Restrict unprivileged user access to socket creation syscalls using seccomp or SELinux policies
• Limit local user access on affected systems until patches can be applied

# Configuration example
# Blacklist the ROSE module to prevent loading
echo "blacklist rose" >> /etc/modprobe.d/blacklist-rose.conf

# Remove the module if currently loaded
rmmod rose 2>/dev/null || true

# Verify the module is not loaded
lsmod | grep rose

# Update initramfs to persist changes
update-initramfs -u