CVE-2026-64560

Резюме

В ядре Linux устранена следующая уязвимость: posix-cpu-timers: предотвращение UAF, вызванного гонкой exec() не-лидера Wongi и Jungwoo декодировали и сообщили о гонке, связанной с exec() не-лидера, которая может привести к UAF: sys_timer_delete() exec() posix_cpu_timer_del() // Наблюдает старого лидера p = pid_task(pid, pid_type); de_thread() switch_leader(); release_task(old_leader) __exit_signal(old_leader) sighand = lock(old_leader, sighand); posix_cpu_timers*_exit(); sighand = lock_task_sighand(p) unhash_task(old_leader); sh = lock(p, sighand) old_leader->sighand = NULL; unlock(sighand); (p->sighand == NULL) unlock(sh) return NULL; // Возвращает без действия if(!sighand) return 0; free_posix_timer(); Это «безвредно», если только удалённый таймер не был взведён и поставлен в очередь в p->signal, поскольку при exec() таймер, нацеленный на TGID, наследуется. Так как sys_timer_delete() освободил базовый объект posix-таймера, run_posix_cpu_timers() или любые операции добавления/удаления в timerqueue для других таймеров будут обращаться к узлу timerqueue освобождённого объекта, что приводит к UAF. Существует аналогичная проблема с posix_cpu_timer_set(). Для обычных posix-таймеров это лишь временно возвращает -ESRCH в пользовательское пространство, но для случая использования в do_cpu_nanosleep() это тот же UAF, только k_itimer выделен на стеке. Также posix_cpu_timer_rearm() не перевзводит таймер, что означает, что он перестаёт истекать. Обсуждая решения, Frederic указал на ещё одну проблему: posix_cpu_timer_del(tmr) __exit_signal(p) posix_cpu_timers*_exit(p); unhash_task(p); p->sighand = NULL; sh = lock_task_sighand(p) sighand = p->sighand; if (!sighand) return NULL; lock(sighand); if (!sh) WARN_ON_ONCE(timer_queued(tmr)); На слабо упорядоченных архитектурах не гарантируется, что posix_cpu_timer_del() увидит записи в posix_cpu_timers*_exit(), когда p->sighand наблюдается как NULL, что означает, что WARN() может быть ложным срабатыванием. Решите эти проблемы следующим образом: 1) Измените запись в __exit_signal() на smp_store_release(). 2) Добавьте smp_acquire__after_ctrl_dep() в путь !sighand функции lock_task_sighand(). 3) Создайте вспомогательную функцию для поиска задачи и блокировки sighand, которая не возвращается, когда sighand == NULL. Вместо этого она повторяет поиск задачи, и только если он не удаётся, сдаётся. 4) Используйте эту вспомогательную функцию в трёх затронутых функциях. #1/#2 гарантирует, что сторона чтения, которая наблюдает sighand == NULL, также наблюдает все предшествующие записи, т.е. записи в posix_cpu_timers*_exit() и записи в unhash_task(). #3 гарантирует, что описанная выше ситуация с exec() не-лидера обрабатывается корректно. Когда поиск задачи возвращает старого лидера, но sighand == NULL, выполняется повторная попытка. В случае exec() не-лидера последующий поиск задачи увидит нового лидера благодаря #1/#2. В обычных сценариях exit() последующий поиск не удаётся. Когда поиск задачи не удаётся, функция также проверяет, всё ли ещё таймер находится в очереди, и выдаёт предупреждение, если это так. К сожалению, с этим ничего нельзя поделать, но поскольку задача уже больше не видна, к таймеру не следует обращаться. Эта проверка также требует упорядочивания памяти, которое не обеспечивается, когда первый поиск не удаётся. Для этого проверке предшествует smp_rmb(), который сочетается с smp_wmb() в write_seqlock() в __exit_signal(). Это гарантирует, что записи в posix_cpu_timers*_exit() видны. История проблемы с exec() не-лидера уходит корнями в ранние дни posix CPU-таймеров, которые хранили указатель на задачу лидера группы в таймере. Это, очевидно, не работает, когда exec() не-лидера переключает лидера. commit e0a70217107e ("posix-cpu-timers: workaround to suppress the problems with mt exec") добавил временный обходной путь для этого в 2010 году, который пережил ---обрезано---