Skip to main content
VulnerabilityPublished Updated

CVE-2026-52946: Linux kernel · fs/fcntl: fix SOFTIRQ-unsafe lock order in fasync signaling

Affects Linux kernelSource GCVE Database

0
Authoritative record:CVE-2026-52946· High 7.5

Not known to be exploited · CVSS 7.5 High.

Data as of 26 Oct 2026, 17:16 UTC

CVSS 3.1 base score
7.5High
How severe the flaw is on the 0–10 CVSS scale.
EPSS
0.4% chance of exploitation in 30 days – higher than 40% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

Exploitation evidence

  1. Disclosed: evidence found.

    CVE published 24 Jun 2026

  2. Detectable: no evidence on record.

    No public nuclei template indexed

  3. Weaponised: no evidence on record.

    No public exploit code indexed in Metasploit or Exploit-DB

  4. Exploited in the wild: no evidence on record.

    Not in CISA KEV and no source reports exploitation

  5. Observed by OffSeq Mirage: no evidence on record.

    No attack traffic recorded by OffSeq Mirage sensors

A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 26 Oct 2026.

What to do

Affected software

ProductAffectedFixed in
Ubuntu 26.04 LTSlinux-azure-fdepkg:deb/ubuntu/linux-azure-fde@7.0.0-1008.8?arch=source&distro=resoluteOther threatsAffected
  • 7.0.0-1003.3 – 7.0.0-1008.8
4 affected builds
Fixed in–
Ubuntu 25.10linuxpkg:deb/ubuntu/linux?arch=source&distro=questingOther threatsAffected
  • 6.14.0-15.15 – 6.17.0-40.40
20 affected builds
Fixed in–
Ubuntu 25.10linux-awspkg:deb/ubuntu/linux-aws?arch=source&distro=questingOther threatsAffected
  • 6.14.0-1005.5 – 6.17.0-1019.19
17 affected builds
Fixed in–
Ubuntu 25.10linux-azurepkg:deb/ubuntu/linux-azure?arch=source&distro=questingOther threatsAffected
  • 6.14.0-1004.4 – 6.17.0-1020.20
16 affected builds
Fixed in–
Ubuntu 25.10linux-azure-fdepkg:deb/ubuntu/linux-azure-fde?arch=source&distro=questingOther threatsAffected
  • 6.17.0-1003.3 – 6.17.0-1017.17
10 affected builds
Fixed in–
Ubuntu 25.10linux-gcppkg:deb/ubuntu/linux-gcp?arch=source&distro=questingOther threatsAffected
  • 6.14.0-1006.6 – 6.17.0-1020.22
17 affected builds
Fixed in–

Check your own hosts for these packages with threat-finder (opens in a new tab), our free open-source scanner.

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 ***

References

Community reviews

Loading reviews…