CVE-2026-52946

What it actually does

This Linux kernel flaw is a deadlock condition in the fasync signal delivery path for process-group-owned file descriptors. When asynchronous I/O notifications are configured for a process group, send_sigio() and send_sigurg() can be invoked from softirq context and attempt to take tasklist_lock as a reader. If another CPU is waiting for tasklist_lock as a writer during fork, exit, or related process-management activity, writer fairness can block new readers and cause a lock-order deadlock. The result is a kernel hang or severe system stall. The issue is particularly relevant to TCP urgent data handling because send_sigurg() can be reached from NET_RX_SOFTIRQ, making a remote denial-of-service scenario possible under the right workload and socket ownership conditions.

Why it matters to the business

Successful exploitation can make affected Linux systems unresponsive, interrupting applications, network services, containers, virtual machines, and infrastructure workloads that rely on the host kernel. Although this is not a data theft or privilege-escalation issue, it can cause service outages and may require manual intervention or reboot to recover. The vulnerability is not currently listed in CISA KEV, has low EPSS, and has no reported mature public exploit in the supplied data, but kernel-level denial-of-service issues should still be prioritized for internet-facing or high-availability systems.

How an attack unfolds

An attacker needs to trigger the vulnerable fasync signaling path while the target system is in a susceptible locking state. In a plausible remote scenario, a service or application has configured asynchronous notification ownership for a process group on a socket or file descriptor. The attacker sends network traffic that causes TCP urgent data processing, reaching tcp_check_urg(), sk_send_sigurg(), and then send_sigurg() from softirq context. At the same time, normal local process activity such as fork(), exit(), or wait() causes tasklist_lock contention. If the timing aligns, the softirq attempts to acquire tasklist_lock as a reader while a writer is pending, creating a SOFTIRQ-safe to SOFTIRQ-unsafe lock-order deadlock. The host can then hang or become sufficiently unresponsive to cause a denial of service. Exploitation is timing- and configuration-dependent and is more likely to be feasible against systems with relevant socket ownership behavior and high process/network activity.

How to fix it

Apply vendor-provided Linux kernel updates that include the fasync signaling fix replacing the unnecessary tasklist_lock usage with RCU read-side protection in the affected process-group signaling path. Because no exact affected product list or fixed package versions were supplied, use distribution advisories from vendors such as Red Hat, Ubuntu, Debian, SUSE, Oracle, Amazon Linux, and upstream stable kernel release notes to identify the corrected kernel build for each platform. Prioritize patching internet-facing systems, high-availability hosts, virtualization/container nodes, and systems running network services that may use asynchronous socket notification. If immediate patching is not possible, reduce exposure by limiting untrusted network access to affected services, disabling or avoiding application features that rely on TCP urgent data or SIGURG/SIGIO where feasible, and ensuring watchdogs, clustering, or automated host recovery are in place. Mitigations should be treated as temporary because the underlying issue is in kernel locking behavior.

How to confirm the fix worked

Confirm the running kernel has been updated to a vendor release that contains the fasync/tasklist_lock deadlock fix for this issue. Validate both installed and running kernel versions, since Linux systems often require a reboot to activate a patched kernel. Review vendor changelogs or kernel source/package metadata for references to the fasync signaling fix, send_sigio(), send_sigurg(), tasklist_lock replacement, or RCU protection in fs/fcntl. After reboot, verify uname -r matches the fixed kernel package and that no older vulnerable kernel remains active. For exposure assessment, identify systems running affected kernel branches and applications that use FASYNC, SIGIO, SIGURG, process-group file descriptor ownership, or TCP urgent data handling. In test environments only, regression testing may include exercising asynchronous I/O and TCP urgent data paths under process churn while monitoring for lockdep warnings or soft lockups.

Typical attack path

1. Identify a remotely reachable Linux service or workload that may use asynchronous I/O notification, F_SETOWN, FASYNC, SIGIO, SIGURG, or process-group socket ownership.
2. Send crafted or repeated TCP traffic containing urgent data or otherwise trigger code paths that invoke TCP urgent signaling.
3. Rely on concurrent process activity on the target, such as fork, exit, wait, or process-group signaling, to create contention on tasklist_lock.
4. Trigger send_sigurg() or send_sigio() from softirq context while tasklist_lock writer fairness blocks new readers.
5. Cause a kernel deadlock or severe stall, resulting in service unavailability until the system recovers or is rebooted.

How to detect it

Detection should focus on evidence of kernel deadlock or stall around fasync, SIGIO/SIGURG, tasklist_lock, TCP urgent processing, and softirq context. Review kernel logs from journald, syslog, dmesg, serial console logs, crash dumps, hypervisor console captures, and centralized log pipelines for lockdep warnings, soft lockups, hard lockups, hung tasks, RCU stalls, or call traces involving send_sigurg(), send_sigio(), kill_fasync(), sk_send_sigurg(), tcp_check_urg(), input_inject_event(), tasklist_lock, f_owner->lock, or dev->event_lock. Network telemetry may show unusual TCP urgent-flag traffic to exposed services shortly before a stall, but absence of such traffic does not rule out local or non-network triggering. Because exploitation may leave limited artifacts if the system hangs, correlate system unresponsiveness, reboot events, watchdog resets, kernel panic/crash dumps, and preceding network flows. If crash dumps are available, inspect stack traces for softirq context blocked on tasklist_lock or fasync signaling paths. There are no supplied named threat actors or ransomware campaigns associated with this issue.

• SOFTIRQ-safe -> SOFTIRQ-unsafe lock order detected
• WARNING: SOFTIRQ-safe -> SOFTIRQ-unsafe lock order detected
• tasklist_lock
• send_sigurg
• send_sigio
• kill_fasync
• sk_send_sigurg
• tcp_check_urg
• input_inject_event
• NET_RX_SOFTIRQ
• &dev->event_lock
• &f_owner->lock
• *** DEADLOCK ***
• Possible interrupt unsafe locking scenario
• soft lockup
• hard lockup
• rcu_sched detected stalls
• INFO: task
• blocked for more than
• kernel: watchdog: BUG: soft lockup
• kernel: NMI watchdog: Watchdog detected hard LOCKUP

What your security team should do

• Inventory Linux hosts and map running kernel versions against vendor advisories for this issue.
• Prioritize kernel updates on internet-facing servers, load balancers, container hosts, hypervisors, network appliances, and high-availability application nodes.
• Reboot systems after installing fixed kernel packages and verify the patched kernel is actually running.
• Search logs for lockdep, soft lockup, hard lockup, RCU stall, and tasklist_lock warnings that match the affected code path.
• Review externally exposed services for use of asynchronous I/O notification, SIGIO, SIGURG, TCP urgent data, or process-group socket ownership.
• Restrict untrusted access to services suspected of reaching the vulnerable TCP urgent-data path until patching is complete.
• Ensure watchdog, failover, and automated recovery controls are working for critical systems in case a host becomes unresponsive.
• Monitor vendor advisories for exact fixed package versions and backported patches, especially where distribution kernels do not match upstream version numbers.