Skip to main content
← All vulnerabilities
CVE-2026-98260

exec: Cleanup POSIX timers right after de_thread()

Linux kernel branches from 5.7 up to their fixed releases (6.6.158, 6.12.112, 6.18.54, 7.2.8) are affected when a non-leader thread calls exec with a per-thread CPU timer armed. Fixed in those releases.

Published
Last modified
published
Not listed in CISA KEV
Specific setups only
Fix
Fixed in 6.6.158, 6.12.112, 6.18.54, 7.2.8
27 proofs of concept on GitHub

Summary

In the Linux kernel, the following vulnerability has been resolved: exec: Cleanup POSIX timers right after de_thread() A per-thread CPU timer holds a reference to the PID of the thread it is attached to and, while it is armed, its node is queued in that thread's posix_cputimers. The task is looked up by that PID. When a non-leader thread exec()s, de_thread() changes which task owns that PID. pid_task(timer->it.cpu.pid, PIDTYPE_PID) then returns NULL, but the node is still queued on tsk, which is alive. timer_lock_sighand() takes a failed lookup to mean that the node is already dequeued, so it has nothing to undo. begin_new_exec() calls posix_cpu_timers_exit(me) right after exec_task_namespaces() and that removes the leftover node, so the state normally stays invisible. But bprm->point_of_no_return is set before de_thread(), so if unshare_files(), set_mm_exe_file(), exec_mmap() or exec_task_namespaces() fails, the task dies before it gets there. exit_itimers() then frees the k_itimer while its node is still queued, and reaping tsk later erases that freed node from the rbtree. In short: the non-leader thread B the parent timer_create(CLOCK_THREAD_CPUTIME_ID) timer_settime() arm_timer() // the node is queued on B execve() de_thread(B) exchange_tids(B, leader) // B's PID now belongs to the leader release_task(leader) __exit_signal(leader) posix_cpu_timers_exit(leader) // cleans leader's queue, not B's __unhash_process(leader) // that PID has no task anymore exec_mmap() mmap_read_lock_killable(old_mm) kill(B, SIGKILL) // -EINTR get_signal() do_exit() exit_itimers() posix_timer_delete() posix_cpu_timer_del() posix_timer_unhash_and_free() // freed while still queued wait4() release_task(B) posix_cpu_timers_exit(B) cleanup_timerqueue() timerqueue_del() // use-after-free Move the POSIX timer cleanup right after de_thread() before any of the later failure conditions brings the task into do_exit(). [ tglx: Move the cleanup right after de_thread() ]

Timeline

  1. CVE published
  2. Record last updated

Affected versions

  • Linux Linux

    Version range not reported

  • Linux Linux

    5.7

  • KernelLinux

    From 5.7.0 · fixed in 6.6.158; From 6.7.0 · fixed in 6.12.112; From 6.13.0 · fixed in 6.18.54; From 6.19.0 · fixed in 7.2.8

References 32

git.kernel.org

GitHub · 4627488/cve-2026-98260-nezha

GitHub · Again1996-bit/CVE-2026-98260-GhostKey

GitHub · AzirX1337/CVE-2026-98260-OnePlus16-PYB110-Jailbreak

GitHub · AzirX1337/CVE-2026-98260-PMX110-Root618-Jailbreak

GitHub · ChaYeWuu/prague-CVE-2026-98260-OS4.0

GitHub · ChaYeWuu/violin-CVE-2026-98260-OS4.0

GitHub · Feiman55/CVE-2026-98260-GhostKey

GitHub · Lw5959/xring-cve-2026-98260

GitHub · NanoTurtle1145/cve-2026-98260-uaf

GitHub · YuKongA/CVE-2026-98260

GitHub · addxemmm/CVE-2026-98260-pudding-android

GitHub · b1gmang0/CVE-2026-98260-pandora-lpe

GitHub · colorgarden/CVE-2026-98260-y700-TB321FU-lpe

GitHub · jadedFella/lpe-study-notes

GitHub · janewas/cve-2026-98260-vivo-gki-research

GitHub · kpgc10kai/TimerRoot

GitHub · molanp/CVE-2026-98260-vivo-s60-poc

GitHub · quyicheng03-boop/CVE-2026-98260-dada-android

GitHub · quyicheng03-boop/CVE-2026-98260-nezha-android

GitHub · quyicheng03-boop/CVE-2026-98260-popsicle-android

GitHub · sganggs/CVE-2026-98260-BRM-AN00

GitHub · simayang01/CVE-2026-98260-vivo-x-fold6-poc

GitHub · villager1314/CVE-2026-98260-Analysis

GitHub · woshigenm/CVE-2026-98260

GitHub · ylh440104/InfinityCore-Android-CVE-2026-98260

GitHub · zjns/CVE-2026-98260

GitHub · zsw125/o3root

FAQ

Questions about CVE-2026-98260

What does this mean?

A POSIX timer structure can be freed while it is still linked to a thread, so later use of that freed memory is a use-after-free. This happens when a non-leader thread runs exec and a later failure makes the task die before the timer cleanup runs.Source: git.kernel.org

Am I affected, and how do I check?

Affected kernel ranges are 5.7.0 up to 6.6.158, 6.7.0 up to 6.12.112, 6.13.0 up to 6.18.54, and 6.19.0 up to 7.2.8. The bug needs a per-thread CPU timer armed on a non-leader thread that calls exec. To check, compare the running kernel version (shown by uname -r) against these ranges.Source: git.kernel.org

What should I do about it?

Upgrade to the fixed release in the matching branch: 6.6.158, 6.12.112, 6.18.54, or 7.2.8.Source: git.kernel.org

Is it being exploited?

It is not in CISA's Known Exploited Vulnerabilities catalog, and CISA's SSVC assessment does not mark exploitation as active. That does not mean it has not been attacked: vendors and researchers can report attacks before CISA lists them. Public exploit code exists (a proof of concept on GitHub).Source: cve.now feed data