Please consider fb3bbcfe344e ("exit: change the release_task() paths to call flush_sigqueue() lockless") for 5.10.y, 5.15.y, 6.1.y, 6.6.y, and 6.12.y

[Michael Bommarito]

Please consider the following already-mainlined fix for the stable
series listed below.

Upstream commit: fb3bbcfe344e64a46574a638b051ffd78762c12d
Subject: exit: change the release_task() paths to call flush_sigqueue() lockless

This is a stable option-2 request for an already-mainlined fix. The
patch fixes a security-relevant bug pattern that remains present in the
listed stable branches in my current review.

Why this belongs in stable:
__exit_signal() calls flush_sigqueue(&tsk->pending) (and shared_pending)
under siglock with irqs disabled. A local unprivileged task can block an
RT signal, queue signal instances to itself up to its inherited hard
RLIMIT_SIGPENDING, and then exit, making the kernel drain the queue with
interrupts disabled. Raising the hard limit requires CAP_SYS_RESOURCE,
so the highest-impact case depends on a high inherited/system-managed
limit rather than arbitrary unprivileged limit raising.

Requested stable series:
- 5.10.y
- 5.15.y
- 6.1.y
- 6.6.y
- 6.12.y

Fresh stable check (2026-07-08):
- 5.10.y: 738ac465e4e9
  fix shape: absent; upstream diff: applies-cleanly
- 5.15.y: c86c4726e7f0
  fix shape: absent; upstream diff: applies-cleanly
- 6.1.y: 090666d3cc90
  fix shape: absent; upstream diff: applies-cleanly
- 6.6.y: da47cbc25466
  fix shape: absent; upstream diff: applies-cleanly
- 6.12.y: 296aabce4594
  fix shape: absent; upstream diff: applies-cleanly
- 6.15.y and newer checked branches already have the fixed shape

Backport note:
The mechanical check above reports whether the upstream diff applies to
each listed branch as-is. In this refresh, the upstream diff applies
cleanly to the file snapshots for all requested series.

Impact context:
- current CVSS estimate: 4.7
- vector: CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H
- direct-tracking exposure: Debian 11/12/13 and Android 13/14/15/16 GKI
- primary touched file: kernel/exit.c

Impact: local availability only. My saved v6.1.173 test at this host's
normal pending-signal hard limit (450505) produced a 1.035s clocksource
long-readout gap. With a high inherited hard limit, a v6.1.173/QEMU run
that queued 6M RT signals hit a softlockup watchdog panic in
release_task() at _raw_write_unlock_irq(); the same 6M target on
v6.1.173 plus fb3bbcfe completed with no lockup signal. The fatal case
therefore remains AC:H because it depends on a high inherited or
system-managed hard limit rather than arbitrary unprivileged limit
raising. I do not have evidence for privilege escalation, code
execution, confidentiality impact, integrity impact, NMI-hardlockup
proof, or a default-limit fatal panic.

No reproducer is included in this public stable request. I can provide
additional details privately if needed.