CVE-2026-98256
High · 7.8CVSS
7.8
EPSS
0.1%
Published
Oct 6, 2026
CISA due date
—
Cloudanix analysis
A timing flaw in the operating system's handling of program startup and signals could let a logged-in attacker take over the entire machine.
- Exploitation
- Local Privilege
- Attacker needs
- Low Privilege
- Complexity
- Moderate
- Impact
- Privilege Gain
- Component
- OS kernel
- Class
- Race Condition
- Remediation
- Patch
- Effort
- Medium
- Patch risk
- Low
What it actually does
Race condition in Linux kernel signal delivery during non-leader exec() allows use-after-free of a sigqueue structure when POSIX timers with SIGEV_THREAD_ID target a thread that is exiting; PF_EXITING check and early flush in exit_signals() were missing, enabling list corruption and write to freed memory via __send_signal_locked.
Why it matters to the business
Local attackers on affected Red Hat Enterprise Linux systems can achieve kernel code execution or privilege escalation, potentially leading to full host compromise; the flaw affects widely deployed kernels but has low observed exploitability so far.
How an attack unfolds
An attacker on the system creates a POSIX timer targeting a thread ID, triggers a non-leader exec() that swaps TIDs, then races signal delivery against release_task() flush; the non-atomic list operations allow the timer sigqueue to be re-queued after RCU free, resulting in a write into freed slab memory when a later tgkill occurs.
How to fix it
Upgrade kernel (redhat el10) to 6.12.0-211.67.1.el10_2 or later via RHSA-2026:85321; enable kernel address space layout randomization and restrict unprivileged user namespaces as temporary hardening.
How to confirm the fix worked
Confirm kernel version matches or exceeds the fixed release; run reproducer from the commit message under KASAN; verify absence of the described UAF splat and check that exit_signals() now flushes pending signals under sighand lock.
Typical attack path
- Obtain local shell on affected kernel
- Create SIGEV_THREAD_ID timer against thread leader
- Trigger execve() from non-leader thread while timer is armed
- Block and unblock the signal to leave sigqueue on pending list
- Force concurrent tgkill or timer expiry to trigger UAF write
How to detect it
Search kernel logs for KASAN splats referencing __send_signal_locked and slab-use-after-free during exec or timer paths; inspect audit logs for unusual timer_create and tgkill sequences from untrusted users around process exit events.
What your security team should do
- Patch all Red Hat Enterprise Linux 10 systems to the fixed kernel within the next maintenance window
- Monitor EPSS and threat intelligence feeds for any rise in exploitation activity
- Restrict local user access on high-value systems until patches are deployed
The record
In the Linux kernel, the following vulnerability has been resolved: signal: Prevent exec() race Hyunwoo debugged the following KASAN UAF splat: BUG: KASAN: slab-use-after-free in __send_signal_locked+0xb27/0xba0 Write of size 8 at addr ffff888007ed80c8 by task poc/79 ... Call Trace: __send_signal_locked+0xb27/0xba0 do_send_sig_info+0xa7/0x160 do_send_specific+0x76/0xa0 __x64_sys_tgkill+0x193/0x270 ... Allocated by task 80: do_timer_create+0x1a4/0x1030 __x64_sys_timer_create+0x145/0x190 ... Freed by task 12: kmem_cache_free_bulk+0x1f8/0x4a0 kvfree_rcu_bulk+0x14f/0x1c0 kfree_rcu_work+0x128/0x1a0 ... Last potentially related work creation: kvfree_call_rcu+0x39/0x390 __flush_itimer_signals+0x211/0x320 flush_itimer_signals+0x47/0x90 begin_new_exec+0xa6b/0x28c0 It turned out that this happens with a non-leader exec() as Hyunwoo explained: de_thread() calls exchange_tids() before release_task(leader), so the struct pid held by a SIGEV_THREAD_ID timer created against the leader's tid now points to the thread which called execve(). pid_task() returns that thread and lock_task_sighand() on it succeeds. If the timer signal is blocked, its sigqueue stays queued on the leader's task::pending. The next expiry of that timer can then run while release_task() flushes the queue. posixtimer_send_sigqueue() checks whether the sigqueue is already queued with a plain list_empty(), which only reads list_head::next. list_del_init() is not atomic and INIT_LIST_HEAD() stores list_head::next before list_head::prev, so the check can pass in between. list_add_tail() queues the entry on the task::pending of the live thread, and the list_head::prev store from the flush then overwrites the list_head::prev link that list_add_tail() has just set. __flush_itimer_signals() does not undo that either. With list_head::prev pointing at the entry itself, its list_del_init() only stores the same values again, so the entry is not removed from the list. It is still there after the last reference is dropped and the timer is freed by RCU, and the list_add_tail() of a later tgkill() follows that list_head::prev into the freed timer. This problem surfaced with the recent commit which moved the sigqueue flush out of the sighand lock held region. Hyonwoo proposed to fix this by using list_del_init_careful(), but that just papers over the problem. After some disucssions and various attempts to solve it, Eric pointed out that there is no reason to flush task::pending late in release_task() and it should be done in exit_signals() already. As nothing can collect and deliver signals which are queued in a dying task's pending queue, there is no reason to delay it further. But it has to be ensured that no signals can be queued into it after that point. exit_signals() sets PF_EXITING in task::flags, which can be used as an indicator for this. Cure it by: - Preventing signal queueing for task private signals (PIDTYPE_PID) when the task has PF_EXITING set in __send_signal_locked() and in posixtimer_send_sigqueue(). - Protecting the unlocked setting of PF_EXITING in exit_signals() for the task group empty and the group exit case with sighand lock - Flushing task::pending signals right there. Optimize that by moving the whole pending list to an on-stack list head under sighand lock and free the signals without the lock held. There has been quite some discussion about the lockless flush and the non-leader exec case on weakly ordered systems. The problem is that a third party which tries to send a posix timer signal relies on the PID lookup to find the target task and that lookup might result in the new leader when the signal was originaly directed to the old leader. In case that the signal was queued on the old leader then the lockless flush raised a concern over the following situation: old_leader new_leader third party A: flush_list() // list_del_in ---truncated---
Affected packages
| Ecosystem | Package | Introduced | Fixed |
|---|