CVE-2026-52946

Analyzed Analyzed - Analysis Complete

Deadlock in Linux Kernel Fasync Signaling Path

Publication date: 2026-06-24

Last updated on: 2026-07-14

Assigner: kernel.org

Description

In the Linux kernel, the following vulnerability has been resolved: fs/fcntl: fix SOFTIRQ-unsafe lock order in fasync signaling A SOFTIRQ-safe to SOFTIRQ-unsafe lock order deadlock can occur in send_sigio() and send_sigurg() when a process group receives a signal. When FASYNC is configured for a process group (PIDTYPE_PGID), both functions use read_lock(&tasklist_lock) to traverse the task list. However, they are frequently called from softirq context: - send_sigio() via input_inject_event -> kill_fasync - send_sigurg() via tcp_check_urg -> sk_send_sigurg (NET_RX_SOFTIRQ) The deadlock is caused by the rwlock writer fairness mechanism: 1. CPU 0 (process context) holds read_lock(&tasklist_lock) in do_wait(). 2. CPU 1 (process context) attempts write_lock(&tasklist_lock) in fork() or exit() and spins, which blocks all new readers. 3. CPU 0 is interrupted by a softirq (e.g., TCP URG packet reception). 4. The softirq calls send_sigurg() and attempts to acquire read_lock(&tasklist_lock), deadlocking because CPU 1 is waiting. Since PID hashing and do_each_pid_task() traversals are already RCU-protected, the read_lock on tasklist_lock is no longer strictly required for safe traversal. Fix this by replacing tasklist_lock with rcu_read_lock(), aligning the process group signaling path with the single-PID path. This also mitigates a potential remote denial of service vector via TCP URG packets. Lockdep splat: ===================================================== WARNING: SOFTIRQ-safe -> SOFTIRQ-unsafe lock order detected [...] Chain exists of: &dev->event_lock --> &f_owner->lock --> tasklist_lock Possible interrupt unsafe locking scenario: CPU0 CPU1 ---- ---- lock(tasklist_lock); local_irq_disable(); lock(&dev->event_lock); lock(&f_owner->lock); <Interrupt> lock(&dev->event_lock); *** DEADLOCK ***

CVSS Scores

EPSS Scores

Probability:
Percentile:

Meta Information

Published

2026-06-24

Last Modified

2026-07-14

Generated

2026-07-15

AI Q&A

2026-06-24

EPSS Evaluated

2026-07-13

NVD

CVE-2026-52946

EUVD

EUVD-2026-38814

Affected Vendors & Products

Vendor	Product	Version / Range
linux	linux_kernel	2.6.12
linux	linux_kernel	2.6.12
linux	linux_kernel	2.6.12
linux	linux_kernel	2.6.12
linux	linux_kernel	2.6.12
linux	linux_kernel	From 5.16 (inc) to 6.1.176 (exc)
linux	linux_kernel	From 6.2 (inc) to 6.6.143 (exc)
linux	linux_kernel	From 5.11 (inc) to 5.15.210 (exc)
linux	linux_kernel	From 6.13 (inc) to 6.18.36 (exc)
linux	linux_kernel	From 6.7 (inc) to 6.12.94 (exc)
linux	linux_kernel	From 6.19 (inc) to 7.0.13 (exc)
linux	linux_kernel	From 2.6.12.1 (inc) to 5.10.259 (exc)
linux	linux_kernel	From 7.1 (inc) to 7.1.1 (exc)

Helpful Resources

Exploitability

CWE

KEV

CWE ID	Description
CWE-667	The product does not properly acquire or release a lock on a resource, leading to unexpected resource state changes and behaviors.

Attack-Flow Graph

Compliance Impact

The provided information about CVE-2026-52946 does not include any details on how this vulnerability impacts compliance with common standards and regulations such as GDPR or HIPAA.

Detection Guidance

This vulnerability involves a SOFTIRQ-unsafe lock order deadlock in the Linux kernel related to fasync signaling and tasklist_lock usage. Detection would typically involve monitoring for symptoms of deadlock or lock contention in the kernel, especially related to tasklist_lock and fasync signaling.

Since the vulnerability manifests as a deadlock involving specific kernel locks, one approach is to check kernel logs for lockdep warnings or deadlock reports similar to the provided lockdep splat.

Commands that might help detect this issue include:

Check kernel logs for lockdep warnings: `dmesg | grep -i lockdep`
Monitor for softirq related deadlocks or stalls: `cat /proc/softirqs` and look for abnormal counts or stalls
Use kernel debugging tools like `lockstat` or `perf` to trace lock contention on `tasklist_lock`
Check for processes stuck in uninterruptible sleep (D state) which might indicate deadlock: `ps aux | grep D`

Note that no specific detection commands or tools are provided in the CVE description or resources.

Executive Summary

This vulnerability is a deadlock issue in the Linux kernel related to the order of locking mechanisms used during asynchronous signal handling for process groups.

Specifically, functions send_sigio() and send_sigurg() use a read lock on tasklist_lock while operating in softirq context, which can conflict with write locks held by other CPUs during process operations like fork() or exit().

This conflicting lock order between softirq-safe and softirq-unsafe contexts can cause a deadlock, where processes wait indefinitely for locks held by each other.

The fix replaces the use of tasklist_lock with rcu_read_lock(), which is safer and aligns with existing protections, preventing the deadlock and mitigating a potential remote denial of service attack vector via TCP URG packets.

Impact Analysis

This vulnerability can cause a deadlock in the Linux kernel, leading to system hangs or freezes when certain signals are sent to process groups.

An attacker could potentially exploit this by sending TCP URG packets to trigger the deadlock, resulting in a denial of service (DoS) condition where affected processes or the entire system become unresponsive.

Mitigation Strategies

The vulnerability is fixed by replacing the use of read_lock(&tasklist_lock) with rcu_read_lock() in the process group signaling path in the Linux kernel. This change aligns the signaling path with the single-PID path and mitigates the deadlock issue.

Therefore, the immediate mitigation step is to update your Linux kernel to a version that includes this fix.

Hi! I’m here to help you understand CVE-2026-52946. Ask me anything about the vulnerability, its impact, or mitigation strategies.

0/70