Vulnerability · CVE-2026-98260
exec: Cleanup POSIX timers right after de_thread()
Published Oct 6, 2026 · catalog updated Oct 21, 2026 · exec: Cleanup POSIX timers
Open the advisory
Exploitation likelihood is not on this record for CVE-2026-98260. A missing EPSS score is not a low risk. Compare exec: Cleanup POSIX timers with the linked advisory before you change production.
Gaps on this record
- The stored product name is a package slug. The name on this page is taken from the title (exec: Cleanup POSIX timers).
- No vendor fix or required action is stored. Compare the linked advisory before you change production.
- EPSS is missing. A missing score is not a low risk.
- Severity
- High7.8
- Known exploitation
- Not in CISA/VulnCheck KEV
- EPSS
- Awaiting synchronization with FIRST
- Remediation
- Advisory link
- Affected products
- Linux Kernel
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() ]
Are you affected?
Enter the version you run. The result uses only the ranges stored on this record.
The check returns affected, not affected, or incomplete. It does not guess a version that is missing from the record.
- Linux Kernel5.7.0 → 6.6.158; 6.7.0 → 6.12.112; 6.13.0 → 6.18.54
How to fix CVE-2026-98260
Recommended remediation
A patch or advisory reference is linked. Open the original publisher for availability by product version.
Official advisories
What to do
Three questions, each answered from this record only. Confirm the vendor advisory before you patch.
Should you patch?
Exploitation likelihood is not on this record for CVE-2026-98260. A missing EPSS score is not a low risk. Compare exec: Cleanup POSIX timers with the linked advisory before you change production.
Which versions are affected?
Compare what you have installed with Kernel 5.7.0 → 6.6.158; 6.7.0 → 6.12.112; 6.13.0 → 6.18.54. Compare the installed version with the linked vendor advisory before you change production.
What should an analyst verify?
No weakness class is stored. EPSS is not on this record yet. There is no CISA KEV listing. No Exploit-DB or Metasploit reference is linked. Use the source links for the original advisory.
Code
The project this record applies to. Exploit listings stay in References.
Timeline
Detection, updates, and resolution for this record.
Oct 6, 2026 · OpenSSF OSV / OSV Scanner
Detected
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_t
Oct 21, 2026 · OpenSSF OSV / OSV Scanner
Fix available
Kernel fixed in 6.6.158; Kernel fixed in 6.12.112; Kernel fixed in 6.18.54; Kernel fixed in 7.2.8
Oct 21, 2026 · OpenSSF OSV / OSV Scanner
Fix available
Kernel fixed in 6.6.158; 6.7.0
Oct 21, 2026 · OpenSSF OSV / OSV Scanner
Updated
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_t
Sources
- CVE.orgVulnerability recordCVE-2026-98260
Official CVE identifier
cve.org - OpenSSF OSV / OSV ScannerPackage advisoryCVE-2026-98260
exec: Cleanup POSIX timers right after de_thread()
osv.dev
References
Freshness
Last verified in this catalog Oct 21, 2026. Significant claims (KEV, EPSS, CVSS, affected ranges) come from the source rows above — open the original publisher for the authoritative advisory.