Odebrany

CVE-2026-98256

opublikowano: 06.10.2026, 11:18

modyfikacja: 06.10.2026, 11:18

Ocena CVSS

n/a

Brak oceny

Oficjalne źródła

>_ Opis

Tłumaczenie automatyczne – może zawierać nieścisłości.

W jądrze Linuksa usunięto następującą lukę:

sygnał: Zapobiegaj wyścigowi exec().

Hyunwoo zdebugował następującą ikonę KASAN UAF:

BŁĄD: KASAN: użycie płyty po zwolnieniu w __send_signal_locked+0xb27/0xba0
Zapisz rozmiar 8 pod adresem ffff888007ed80c8 w zadaniu poc/79
...
Zadzwoń do śledzenia:
__send_signal_locked+0xb27/0xba0
do_send_sig_info+0xa7/0x160
do_send_specific+0x76/0xa0
__x64_sys_tgkill+0x193/0x270
...
Przydzielone przez zadanie 80:
do_timer_create+0x1a4/0x1030
__x64_sys_timer_create+0x145/0x190
...
Uwolniony przez zadanie 12:
kmem_cache_free_bulk+0x1f8/0x4a0
kvfree_rcu_bulk+0x14f/0x1c0
kfree_rcu_work+0x128/0x1a0
...
Ostatni potencjalnie powiązany utwór:
kvfree_call_rcu+0x39/0x390
__flush_timer_signals+0x211/0x320
Flush_timer_signals+0x47/0x90
Begin_new_exec+0xa6b/0x28c0

Okazało się, że dzieje się tak w przypadku exec() niebędącego liderem, jakim jest Hyunwoo
wyjaśnione:

de_thread() wywołuje funkcję Exchange_tids() przed release_task(lider), więc
Identyfikator struktury przechowywany przez licznik czasu SIGEV_THREAD_ID utworzony na podstawie tid lidera
teraz wskazuje na wątek, który wywołał execve(). pid_task() zwraca to
thread i lock_task_sighand() na nim powiedzie się.

Jeśli sygnał timera zostanie zablokowany, jego kolejka pozostaje w kolejce lidera
zadanie::oczekujące. Następny wygaśnięcie tego licznika czasu może następnie nastąpić
release_task() opróżnia kolejkę.

posixtimer_send_sigqueue() sprawdza, czy kolejka nie znajduje się już w kolejce
za pomocą zwykłej funkcji list_empty(), która czyta tylko list_head::next.
list_del_init() nie jest atomowa i INIT_LIST_HEAD() przechowuje list_head::next
przed list_head::prev, więc sprawdzenie może przejść pomiędzy. lista_add_tail()
kolejkuje wpis w task::pending aktywnego wątku i
list_head::prev przechowuje z koloru, a następnie zastępuje list_head::prev
link, który właśnie ustawił list_add_tail().

__flush_timer_signals() również tego nie cofa. Z list_head::prev
wskazując na sam wpis, jego list_del_init() przechowuje tylko to samo
wartości ponownie, dzięki czemu wpis nie zostanie usunięty z listy. To nadal tam jest
po odrzuceniu ostatniej wartości zadanej i zwolnieniu timera przez RCU, oraz
list_add_tail() późniejszej tgkill() następuje po funkcji list_head::prev do
zwolniony timer.

Ten problem pojawił się wraz z niedawnym zatwierdzeniem, które przesunęło spłukiwanie sigqueue
z obszaru trzymanego przez zamek westchnienia.

Hyonwoo zaproponował rozwiązanie tego problemu za pomocą list_del_init_careful(), ale to nie to
tylko dokumenty dotyczące problemu. Po kilku dyskusjach i różnych próbach
aby go rozwiązać, Eric zauważył, że nie ma powodu do spłukiwania
task::pending późno w release_task() i należy to zrobić w
exit_signals() już.

Ponieważ nic nie jest w stanie zebrać i dostarczyć sygnałów, które czekają w kolejce do umierania
oczekującego zadania w kolejce, nie ma powodu go dalej opóźniać.

Należy jednak zadbać o to, aby po tym czasie nie można było do niego kolejkować żadnych sygnałów
punkt. exit_signals() ustawia PF_EXITING w task::flags, którego można użyć jako
wskaźnik tego.

Wyleczyć to:

- Zapobieganie kolejkowaniu sygnałów dla prywatnych sygnałów zadań (PIDTYPE_PID), gdy
zadanie ma ustawione PF_EXITING w __send_signal_locked() i in
posixtimer_send_sigqueue().

- Ochrona odblokowanego ustawienia PF_EXITING w exit_signals() dla
grupa zadań pusta, a skrzynka wyjścia grupy z blokadą westchnienia

- Zadanie płukania::oczekujące sygnały właśnie tam.

Zoptymalizuj to, przenosząc całą oczekującą listę do nagłówka listy na stosie
pod zamkiem westchnieniowym i uwolnij sygnały bez trzymania zamka.

Odbyło się sporo dyskusji na temat spłukiwania bez zamka i
Przypadek wykonawczy niebędący liderem w systemach słabo uporządkowanych. Problem w tym, że trzeci
strona, która próbuje wysłać sygnał timera posix, opiera się na wyszukiwaniu PID
znajdź docelowe zadanie, a to wyszukiwanie może skutkować pojawieniem się nowego lidera, kiedy
sygnał był pierwotnie skierowany do starego przywódcy. W przypadku, gdy
sygnał został ustawiony w kolejce na starego lidera, po czym kolor bezzamkowy podniósł a
zaniepokojenie następującą sytuacją:

stary_lider nowy_lider strona trzecia

Odp.: Flush_list() // list_del_in
---obcięty---

In the Linux kernel, the following vulnerability has been resolved:

signal: Prevent exec() race

Hyunwoo debugged the following KASAN UAF splat:

BUG: KASAN: slab-use-after-free in __send_signal_locked+0xb27/0xba0
Write of size 8 at addr ffff888007ed80c8 by task poc/79
...
Call Trace:
__send_signal_locked+0xb27/0xba0
do_send_sig_info+0xa7/0x160
do_send_specific+0x76/0xa0
__x64_sys_tgkill+0x193/0x270
...
Allocated by task 80:
do_timer_create+0x1a4/0x1030
__x64_sys_timer_create+0x145/0x190
...
Freed by task 12:
kmem_cache_free_bulk+0x1f8/0x4a0
kvfree_rcu_bulk+0x14f/0x1c0
kfree_rcu_work+0x128/0x1a0
...
Last potentially related work creation:
kvfree_call_rcu+0x39/0x390
__flush_itimer_signals+0x211/0x320
flush_itimer_signals+0x47/0x90
begin_new_exec+0xa6b/0x28c0

It turned out that this happens with a non-leader exec() as Hyunwoo
explained:

de_thread() calls exchange_tids() before release_task(leader), so the
struct pid held by a SIGEV_THREAD_ID timer created against the leader's tid
now points to the thread which called execve(). pid_task() returns that
thread and lock_task_sighand() on it succeeds.

If the timer signal is blocked, its sigqueue stays queued on the leader's
task::pending. The next expiry of that timer can then run while
release_task() flushes the queue.

posixtimer_send_sigqueue() checks whether the sigqueue is already queued
with a plain list_empty(), which only reads list_head::next.
list_del_init() is not atomic and INIT_LIST_HEAD() stores list_head::next
before list_head::prev, so the check can pass in between. list_add_tail()
queues the entry on the task::pending of the live thread, and the
list_head::prev store from the flush then overwrites the list_head::prev
link that list_add_tail() has just set.

__flush_itimer_signals() does not undo that either. With list_head::prev
pointing at the entry itself, its list_del_init() only stores the same
values again, so the entry is not removed from the list. It is still there
after the last reference is dropped and the timer is freed by RCU, and the
list_add_tail() of a later tgkill() follows that list_head::prev into the
freed timer.

This problem surfaced with the recent commit which moved the sigqueue flush
out of the sighand lock held region.

Hyonwoo proposed to fix this by using list_del_init_careful(), but that
just papers over the problem. After some disucssions and various attempts
to solve it, Eric pointed out that there is no reason to flush
task::pending late in release_task() and it should be done in
exit_signals() already.

As nothing can collect and deliver signals which are queued in a dying
task's pending queue, there is no reason to delay it further.

But it has to be ensured that no signals can be queued into it after that
point. exit_signals() sets PF_EXITING in task::flags, which can be used as
an indicator for this.

Cure it by:

- Preventing signal queueing for task private signals (PIDTYPE_PID) when
the task has PF_EXITING set in __send_signal_locked() and in
posixtimer_send_sigqueue().

- Protecting the unlocked setting of PF_EXITING in exit_signals() for the
task group empty and the group exit case with sighand lock

- Flushing task::pending signals right there.

Optimize that by moving the whole pending list to an on-stack list head
under sighand lock and free the signals without the lock held.

There has been quite some discussion about the lockless flush and the
non-leader exec case on weakly ordered systems. The problem is that a third
party which tries to send a posix timer signal relies on the PID lookup to
find the target task and that lookup might result in the new leader when
the signal was originaly directed to the old leader. In case that the
signal was queued on the old leader then the lockless flush raised a
concern over the following situation:

old_leader new_leader third party

A: flush_list() // list_del_in
---truncated---

>_ Referencje

Dane podatności pochodzą z oficjalnych źródeł (CVE® List / NVD). Opisy po polsku są tłumaczone automatycznie i mogą zawierać nieścisłości – na stronie rekordu można wyświetlić wersję angielską.

This product uses the NVD API but is not endorsed or certified by the NVD.

CVE Usage: MITRE hereby grants you a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable copyright license to reproduce, prepare derivative works of, publicly display, publicly perform, sublicense, and distribute Common Vulnerabilities and Exposures (CVE®). Any copy you make for such purposes is authorized provided that you reproduce MITRE's copyright designation and this license in any such copy. ALL DOCUMENTS AND THE INFORMATION CONTAINED THEREIN PROVIDED BY MITRE ARE PROVIDED ON AN "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND.

NVD Terms of Use / CVE® Terms of Use / nvd.nist.gov / cve.org

<< baza_cve