CVE-2026-52946
Received Received - Intake
BaseFortify

Publication date: 2026-06-24

Last updated on: 2026-06-24

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-06-24
Generated
2026-06-25
AI Q&A
2026-06-25
EPSS Evaluated
N/A
NVD
CVE-2026-52946
EUVD
EUVD-2026-38814
Affected Vendors & Products
Showing 1 associated CPE
Vendor Product Version / Range
linux linux_kernel *
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-UNKNOWN
Attack-Flow Graph
AI Quick Actions
Instant insights powered by AI
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.

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.

Chat Assistant
Ask questions about this CVE
Hi! I’m here to help you understand CVE-2026-52946. Ask me anything about the vulnerability, its impact, or mitigation strategies.
0/70
EPSS Chart