CVE-2026-52946: Linux Kernel Deadlock DoS Vulnerability

CVE-2026-52946 Overview

CVE-2026-52946 is a Linux kernel vulnerability in the fs/fcntl subsystem affecting the fasync signaling path. The flaw is a SOFTIRQ-safe to SOFTIRQ-unsafe lock order deadlock occurring in send_sigio() and send_sigurg() when a process group receives a signal. Attackers can potentially trigger the condition remotely by sending TCP URG packets, creating a denial of service vector against systems that have configured FASYNC for a process group. The Linux kernel maintainers resolved the issue by replacing read_lock(&tasklist_lock) with rcu_read_lock() in the process group signaling path.

Critical Impact
A remote attacker can trigger a kernel deadlock via TCP URG packets when fasync signaling is configured for a process group, resulting in denial of service on affected Linux systems.

Affected Products

Linux kernel (multiple stable branches receiving backported fixes)
Distributions packaging affected kernel versions of fs/fcntl
Systems using FASYNC signaling with PIDTYPE_PGID process groups

Discovery Timeline

2026-06-24 - CVE-2026-52946 published to NVD
2026-06-24 - Last updated in NVD database

Technical Details for CVE-2026-52946

Vulnerability Analysis

The vulnerability is a race-condition-style deadlock [CWE category: Deadlock] in the Linux kernel's fasync signal delivery path. When FASYNC is configured for a process group identified by PIDTYPE_PGID, both send_sigio() and send_sigurg() acquire read_lock(&tasklist_lock) to traverse the task list. These functions are invoked from softirq context through paths such as input_inject_event calling kill_fasync, and tcp_check_urg calling sk_send_sigurg during NET_RX_SOFTIRQ processing. The combination of softirq invocation and a non-IRQ-safe reader lock creates an unsafe lock ordering.

Root Cause

The defect stems from the rwlock writer fairness mechanism. A process-context thread on CPU 0 holds read_lock(&tasklist_lock) in do_wait(). A second process-context thread on CPU 1 attempts write_lock(&tasklist_lock) during fork() or exit() and spins, which blocks all new readers. When a softirq fires on CPU 0 and calls send_sigurg(), the new reader attempt deadlocks because the pending writer on CPU 1 prevents reader acquisition. Lockdep reports the chain &dev->event_lock --> &f_owner->lock --> tasklist_lock as a SOFTIRQ-safe to SOFTIRQ-unsafe order violation.

Attack Vector

A remote attacker can reach the vulnerable code path by sending crafted TCP segments with the URG flag set to a socket where the receiving process has registered FASYNC for a process group. Reception is handled in softirq context, which triggers send_sigurg() and the deadlocking lock acquisition. No authentication or local access is required when the target service exposes a TCP listener configured for fasync delivery.

The upstream fix replaces read_lock(&tasklist_lock) with rcu_read_lock() since PID hashing and do_each_pid_task() traversals are already RCU-protected. This aligns the process group signaling path with the single-PID path and removes the unsafe softirq interaction. See Kernel Git Commit 1bee417 for the canonical patch.

Detection Methods for CVE-2026-52946

Indicators of Compromise

Kernel hangs or soft-lockup messages referencing send_sigio or send_sigurg in dmesg and /var/log/kern.log
Lockdep splat with the chain &dev->event_lock --> &f_owner->lock --> tasklist_lock
Unexplained system-wide stalls coincident with bursts of TCP traffic containing URG flags
Processes stuck in uninterruptible sleep (D state) on tasklist_lock

Detection Strategies

Enable CONFIG_PROVE_LOCKING and CONFIG_LOCKDEP on test kernels to surface unsafe lock order chains
Monitor packet captures for anomalous volumes of TCP URG segments toward services using fasync
Correlate kernel watchdog NMI events with network traffic patterns to identify softirq-driven stalls

Monitoring Recommendations

Track running kernel versions across the fleet and compare against the patched stable releases listed in the kernel.org commits
Alert on repeated RCU stall or soft lockup warnings in kernel logs
Inspect inbound TCP flows for sustained URG flag usage, which is rare in legitimate traffic

How to Mitigate CVE-2026-52946

Immediate Actions Required

Identify Linux hosts running unpatched kernels and prioritize those exposing TCP services with fasync-configured process groups
Apply the stable kernel update containing the RCU-based fix and reboot affected systems
For internet-facing systems, restrict TCP URG-bearing traffic at upstream filtering devices until patches are deployed

Patch Information

The fix has been merged across multiple stable kernel branches. Apply the update corresponding to your kernel series. Relevant commits include Kernel Git Commit 1bee417, Kernel Git Commit 20a93e3, Kernel Git Commit 32dbd5c, Kernel Git Commit 36c1b57, Kernel Git Commit 5462633, Kernel Git Commit 897d6a7, Kernel Git Commit b5fa9e3, and Kernel Git Commit bfcc8e8.

Workarounds

Where patching is delayed, avoid configuring fasync delivery to process groups (PIDTYPE_PGID) and use single-PID delivery instead, which already uses RCU
Filter or rate-limit unsolicited TCP URG-flag traffic at perimeter firewalls and load balancers
Disable network-driven fasync notification for non-essential services on exposed hosts

bash

# Verify current kernel version and compare against fixed stable releases
uname -r

# Drop or rate-limit inbound TCP segments with the URG flag set (example, adjust to environment)
iptables -A INPUT -p tcp --tcp-flags URG URG -m limit --limit 5/sec -j ACCEPT
iptables -A INPUT -p tcp --tcp-flags URG URG -j DROP