Answer in brief
CVE-2026-98260 records a Unknown severity vulnerability in exec: Cleanup POSIX timers right after de_thread(). The current sources do not mark it as known exploited. The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
A CVSS score is not reported in the current record. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| Linux/Linuxgeneric | >=55e8c8eb2c7b6bf30e99423ccfe7ca032f498f59 <6f1977cea3e85cd8ab55fb337d3e1725fe61d1ce || >=55e8c8eb2c7b6bf30e99423ccfe7ca032f498f59 <d9ae467e617ca29b825493a362bf0d75ad5f4ac3 || >=55e8c8eb2c7b6bf30e99423ccfe7ca032f498f59 <75aa08b93c65766040f9ca99f41ac85ad22596b6 || >=55e8c8eb2c7b6bf30e99423ccfe7ca032f498f59 <d602877baf36c43c788a5f472c977e0be414029f || >=55e8c8eb2c7b6bf30e99423ccfe7ca032f498f59 <acb03d3881818581052924a9bbbe92b8741ed448 | 6f1977cea3e85cd8ab55fb337d3e1725fe61d1ce, d9ae467e617ca29b825493a362bf0d75ad5f4ac3, 75aa08b93c65766040f9ca99f41ac85ad22596b6, d602877baf36c43c788a5f472c977e0be414029f, acb03d3881818581052924a9bbbe92b8741ed448 |
| Linux/Linuxgeneric | 5.7 | Not reported |
Published upstream
Oct 6, 2026
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Oct 6, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Oct 6, 2026
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() ]
Quoted source text, attributed separately from HOL analysis.