CVE-2026-52946

published 2026-06-24

CVE-2026-52946: In the Linux kernel, the following vulnerability has been resolved: fs/fcntl: fix SOFTIRQ-unsafe lock order in fasync signaling A SOFTIRQ-safe to…

Priority P3 43 high 7.5 CVSS 3.1

AV N AC L PR N UI N S U C N I N A H

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);

lock(&dev->event_lock);

*** DEADLOCK ***

Affected

11 ranges

Vendor	Product	Version range	Fixed in
linux	linux	—	—
linux	linux	>= 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 < 54626335ea4174ab2d9a183b511d825f6765e47b	54626335ea4174ab2d9a183b511d825f6765e47b
linux	linux	>= 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 < 897d6a7247739fb1528f98c575df4f2e5de7f994	897d6a7247739fb1528f98c575df4f2e5de7f994
linux	linux	>= 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 < 32dbd5ce4be3a3ed7e00f8af18795cc84fc50a33	32dbd5ce4be3a3ed7e00f8af18795cc84fc50a33
linux	linux	>= 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 < b5fa9e32fb6718f70c986ee14dd5d01b4846f331	b5fa9e32fb6718f70c986ee14dd5d01b4846f331
linux	linux	>= 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 < 1bee417678f1135e35b25a37734db46aa94258d2	1bee417678f1135e35b25a37734db46aa94258d2
linux	linux	>= 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 < 20a93e397abe850c49b6fa0e8cc827b5f634a8f5	20a93e397abe850c49b6fa0e8cc827b5f634a8f5
linux	linux	>= 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 < bfcc8e8d8a495bb34cae9e620adfb75fb13a3954	bfcc8e8d8a495bb34cae9e620adfb75fb13a3954
linux	linux	>= 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 < 36c1b57b2ecf3c61ac93f5f07bd29b6f21e226ed	36c1b57b2ecf3c61ac93f5f07bd29b6f21e226ed
linux	linux	>= 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 < 00633c4683828acd5256fa8d5163f440d74bbe71	00633c4683828acd5256fa8d5163f440d74bbe71
linux	linux_kernel	—	—

CVSS provenance

nvd v3.1 7.5 HIGH CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

vendor_redhat 5.5 MEDIUM

Stop checking back — get the weekly exploitation signal.

Every Monday: what got weaponized or added to CISA KEV in the last seven days — each CVE cross-linked to its PoC, Nuclei template, and detection rule. Free, one email a week, unsubscribe in one click.

CWE-833