PT-2026-135517
CVE-2026-99228
·
Publicado
2026-11-02
·
Atualizado
2026-11-02
Descrição por
Pontuação
N/A
Não disponívelNão há classificações de severidade ou métricas disponíveis. Quando houver, atualizaremos as informações correspondentes na página.
In the Linux kernel, the following vulnerability has been resolved:
io uring/io-wq: don't lose the signal that ends work
When a thread exits, only its tracked requests are cancelled. Then its
io-wq is torn down. io wq exit workers() signals every worker, to get it
out of an interruptible sleep, and waits for all of them to exit. Before
they do, they go through the work that is left. Unbounded work is
cancelled. Bounded work is run, as it is expected to end by itself.
Not all of it does. An open has no file yet, so it counts as bounded, and
the open of a FIFO waits for the other end. That is what the signal is for.
But the workers are signalled once, and a worker that hasn't started the
work by then loses the signal:
io wq exit workers() io worker handle work()
io wq worker wake()
set TIF NOTIFY SIGNAL
io assign current work()
io run task work()
clear TIF NOTIFY SIGNAL
io wq submit work()
fifo open()
wait for partner()
wait for completion timeout()
The thread never gets out of do exit():
IORING OP OPENAT of a FIFO without a writer, IOSQE ASYNC
exit of the thread that has submitted it
hangs in more than 9 of 10 attempts (4 CPUs, KVM), until the process is
killed.
Set TIF NOTIFY SIGNAL for bounded work that is started with IO WQ BIT EXIT
set. The bit is set before the workers are signalled, and it is tested
after the flag has been cleared, with clear notify signal() providing the
barrier. So either the flag stays, or the bit is seen.
Work that is started while the io-wq exits is treated like work that is
being run at that time: it isn't interrupted unless it waits
interruptibly.
Encontrou algum problema na descrição? Tem algo a acrescentar? Fique à vontade para nos escrever 👾