PT-2026-106589 · Linux · Linux

CVE-2026-98260

·

Published

2026-10-06

·

Updated

2026-10-06

None

No severity ratings or metrics are available. When they are, we'll update the corresponding info on the page.
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() ]
Found an issue in the description? Have something to add? Feel free to write us 👾

Related Identifiers

CVE-2026-98260

Affected Products

Linux