Description
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---
Published: 2026-10-06
Score: 7.8 High
EPSS: < 1% Very Low
KEV: No
Impact: Kernel Use‑After‑Free via Signal Race
Action: Immediate Patch
AI Analysis

Impact

Based on the description, this is a race condition in the Linux kernel’s signal module that allows a local attacker to trigger a use‑after‑free of timer structures when a non‑leader process performs exec(). The flaw occurs during the flush of queued POSIX timer signals and can corrupt kernel memory, potentially giving the attacker control of the kernel and full system compromise.

Affected Systems

The CVE does not provide explicit vendor or product version details, but based on the description it applies to all Linux kernel builds that have not incorporated the race‑condition fix. Therefore, any system running a kernel older than the fixed commit is vulnerable.

Risk and Exploitability

The CVSS score of 7.8 categorizes the vulnerability as high severity. The EPSS score is under 1 % and the vulnerability is not listed in CISA KEV, implying no public exploits yet. Based on the description and the nature of the kernel use‑after‑free, a local attacker who can create POSIX timers or trigger non‑leader execs could potentially execute arbitrary code with kernel privileges.

Generated by OpenCVE AI on October 11, 2026 at 04:44 UTC.

Remediation

No solution or workaround provided in the CVE record.

OpenCVE Recommended Actions

  • Apply the latest Linux kernel release or patch that implements the race‑condition fix, including the commit that removes delayed task::pending flushing and secures signal queuing.
  • If an immediate patch cannot be deployed, limit POSIX timer usage by disabling the timer_create syscall for untrusted processes using seccomp‑BPF filters or adjusting capabilities to prevent timer creation.
  • Ensure the system is kept up to date with security patches and monitor kernel logs for unexpected segmentation faults or memory corruption indicators that could reveal exploitation attempts.

Generated by OpenCVE AI on October 11, 2026 at 04:44 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

History

Sun, 11 Oct 2026 00:30:00 +0000

Type Values Removed Values Added
Weaknesses CWE-825
References
Metrics threat_severity

None

 threat_severity

Moderate

Wed, 07 Oct 2026 09:30:00 +0000

Type Values Removed Values Added
Weaknesses CWE-362
CWE-416

Wed, 07 Oct 2026 07:00:00 +0000

Type Values Removed Values Added
Metrics cvssV3_1

{'score': 7.8, 'vector': 'CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H'}

Wed, 07 Oct 2026 06:30:00 +0000

Type Values Removed Values Added
Weaknesses CWE-362
CWE-416

Wed, 07 Oct 2026 04:30:00 +0000

Type Values Removed Values Added
Weaknesses CWE-416

Tue, 06 Oct 2026 14:45:00 +0000

Type Values Removed Values Added
Weaknesses CWE-416

Tue, 06 Oct 2026 09:00:00 +0000

Type Values Removed Values Added
Description 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---
Title signal: Prevent exec() race
First Time appeared Linux
Linux linux Kernel
CPEs cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
Vendors & Products Linux
Linux linux Kernel
References

Subscriptions

Linux Linux Kernel
cve-icon MITRE

Status: PUBLISHED

Assigner: Linux

Published:

Updated: 2026-10-19T09:16:27.502Z

Reserved: 2026-09-25T10:25:14.331Z

Link: CVE-2026-98256

cve-icon Vulnrichment

No data.

cve-icon NVD

Status : Received

Published: 2026-10-06T09:18:14.373

Modified: 2026-10-19T10:18:26.607

Link: CVE-2026-98256

cve-icon Redhat

Severity : Moderate

Publid Date: 2026-10-06T00:00:00Z

Links: CVE-2026-98256 - Bugzilla

cve-icon OpenCVE Enrichment

Updated: 2026-10-11T04:45:17Z

Weaknesses
  • CWE-825

    Expired Pointer Dereference