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

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 sendsigio() and sendsigurg() when a process group receives a signal.

When FASYNC is configured for a process group (PIDTYPEPGID), both functions use readlock(&tasklistlock) to traverse the task list. However, they are frequently called from softirq context: - sendsigio() via inputinjectevent -> killfasync - sendsigurg() via tcpcheckurg -> sksendsigurg (NETRXSOFTIRQ)

The deadlock is caused by the rwlock writer fairness mechanism: 1. CPU 0 (process context) holds readlock(&tasklistlock) in dowait(). 2. CPU 1 (process context) attempts writelock(&tasklistlock) 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 sendsigurg() and attempts to acquire readlock(&tasklistlock), deadlocking because CPU 1 is waiting.

Since PID hashing and doeachpidtask() traversals are already RCU-protected, the readlock on tasklistlock is no longer strictly required for safe traversal. Fix this by replacing tasklistlock with rcureadlock(), 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->eventlock --> &fowner->lock --> tasklistlock

Possible interrupt unsafe locking scenario: CPU0 CPU1 ---- ---- lock(tasklistlock); localirqdisable(); lock(&dev->eventlock); lock(&fowner->lock); <Interrupt> lock(&dev->eventlock);

DEADLOCK