CVE-2026-23460: Linux Kernel ROSE Protocol DoS Vulnerability

CVE-2026-23460 Overview

CVE-2026-23460 is a NULL pointer dereference vulnerability in the Linux kernel's ROSE (Radio Amateur Packet Switching) networking subsystem. The flaw resides in the rose_connect() function within net/rose, which fails to validate the TCP_SYN_SENT socket state before processing a second connect call. A local attacker can trigger the bug by issuing a second connect() while an initial ROSE connection attempt is still in progress, leaving rose->neighbour as NULL. Subsequent socket release invokes rose_transmit_link(skb, NULL), dereferencing the NULL pointer and crashing the kernel. The bug was reported by syzkaller automated fuzzing.

Critical Impact
Local users can cause a kernel NULL pointer dereference, leading to denial of service through a kernel panic on systems with the ROSE protocol module loaded.

Affected Products

Linux kernel versions containing the ROSE protocol implementation in net/rose
Distributions shipping the AX.25/ROSE amateur radio networking stack
Systems where the rose kernel module can be loaded by local users

Discovery Timeline

2026-04-03 - CVE-2026-23460 published to NVD
2026-04-18 - Last updated in NVD database

Technical Details for CVE-2026-23460

Vulnerability Analysis

The vulnerability is a NULL pointer dereference [CWE-476] in the Linux kernel ROSE socket layer. ROSE sockets use four sk->sk_state values: TCP_CLOSE, TCP_LISTEN, TCP_SYN_SENT, and TCP_ESTABLISHED. The rose_connect() function already rejects calls in the TCP_ESTABLISHED state with -EISCONN and TCP_CLOSE with SS_CONNECTING returning -ECONNREFUSED. However, the function lacks an equivalent guard for TCP_SYN_SENT.

When rose_connect() is called a second time while an earlier attempt is still pending, it overwrites the rose->neighbour pointer through rose_get_neigh(). If rose_get_neigh() returns NULL on the second call, the socket retains rose->state == ROSE_STATE_1 but holds a NULL neighbour reference. The inconsistent state persists until socket teardown.

Root Cause

The root cause is incomplete state validation in rose_connect(). Per connect(2) semantics, a second connect() issued during an in-progress connection must return -EALREADY. The missing TCP_SYN_SENT check allowed the function to re-enter the connection setup path, corrupting socket state by replacing a valid neighbour reference with NULL while leaving the connection state machine advanced.

Attack Vector

A local unprivileged user with permission to create ROSE sockets can trigger the bug. The attacker opens a ROSE socket, issues a connect() that places the socket into TCP_SYN_SENT, then issues a second connect() that triggers the inconsistent state. When close() is later called, rose_release() observes ROSE_STATE_1 and invokes rose_write_internal(), which calls rose_transmit_link(skb, NULL). The dereference of the NULL neighbour pointer panics the kernel. The syzkaller reproducer is referenced in the upstream bug report.

No verified public exploit code is available beyond the syzkaller reproducer linked in the kernel commit message.

Detection Methods for CVE-2026-23460

Indicators of Compromise

Kernel oops or panic logs referencing rose_transmit_link, rose_write_internal, or rose_release in the call trace
dmesg entries showing NULL pointer dereference faults originating from the rose kernel module
Unexpected loading of the rose module on systems that do not use amateur radio networking

Detection Strategies

Audit lsmod output across the fleet for the presence of the rose and ax25 kernel modules
Monitor for processes invoking socket(AF_ROSE, ...) via auditd or eBPF tracing on __sys_socket
Correlate kernel crash dumps with ROSE-related symbols using kdump or pstore collection

Monitoring Recommendations

Forward dmesg, journald, and kern.log events into a centralized log platform and alert on kernel oops signatures containing rose_
Track module load events through kernel.modprobe auditd rules to detect attempts to bring the ROSE stack online
Review systems exposing user namespaces where unprivileged module loading or socket creation may be possible

How to Mitigate CVE-2026-23460

Immediate Actions Required

Apply the upstream stable kernel patches that add the missing TCP_SYN_SENT check to rose_connect()
Blacklist the rose kernel module on systems that do not require amateur radio packet networking
Restrict the CAP_NET_RAW capability and limit which users can create raw and uncommon protocol sockets

Patch Information

The fix adds a state check that returns -EALREADY when rose_connect() is invoked on a socket already in TCP_SYN_SENT. The change is distributed across multiple stable branches in the following commits: Kernel Git Commit 0c3e8bf, Kernel Git Commit 0c9fb70, Kernel Git Commit 508f49c, Kernel Git Commit a122540, Kernel Git Commit a753844, Kernel Git Commit c2ab74c, Kernel Git Commit c85fe65, and Kernel Git Commit e1f0a18.

Workarounds

Add install rose /bin/true to /etc/modprobe.d/ to prevent the module from loading on production hosts
Remove or unload the rose module with modprobe -r rose where it is not required
Disable autoloading of rare protocol families by setting kernel.modules_disabled=1 after boot on hardened systems

bash

# Configuration example: prevent ROSE module from loading
echo 'install rose /bin/true' | sudo tee /etc/modprobe.d/blacklist-rose.conf
sudo modprobe -r rose 2>/dev/null || true
lsmod | grep -E '^rose'