DEBIAN-CVE-2026-99230: Debian/linux vulnerability

Q: What sequence is required to trigger the fault?

A recycled io_uring request must previously have been used as a cancelable uring_cmd, such as a ublk FETCH_REQ. It must then be reused for a vectored futex wait that is woken while futex_wait_multiple_setup() is still queueing futexes.

Q: What is the observable impact if the issue is triggered?

The kernel can write through a poisoned hash-node pointer and raise a general protection fault. Reported diagnostics include KASAN wild-memory-access messages and a stack trace involving io_futexv_complete(), task_work, and tctx_task_work_run().

Q: How can I recognize a potentially related crash?

Look for an Oops or general protection fault with an address in the LIST_POISON range, such as 0xdead000000000120, together with io_futexv_complete() in the instruction pointer or call trace. The affected path may also include __io_futex_complete() and task-work handling functions.

Published Nov 2, 2026

Updated

In the Linux kernel, the following vulnerability has been resolved: iouring/cmd: don't leave list poison in ->hashnode iouringcmddelcancelable() uses hlistdel() to take a command off ->cancelableuringcmd, which leaves LISTPOISON1/2 behind in ->hashnode. Requests are recycled through the request cache without being reinitialised, and not every user of ->hashnode sets it up before it is used: If a vectored futex wait is woken while futexwaitmultiplesetup() is still queueing the futexes, iofutexvwait() doesn't add the request to ->futexlist, and leaves the completion to the taskwork queued by the wake up. iofutexvcomplete() ends in iofutexcomplete(), whose hlistdelinit() is fine for a request that is unhashed, which is how all other users of the node leave it. If the request was a cancelable uringcmd in its previous life, e.g. a ublk FETCHREQ, it writes through LISTPOISON2: Oops: general protection fault, probably for non-canonical address KASAN: maybe wild-memory-access in range [0xdead000000000120-...] RIP: 0010:iofutexvcomplete+0x219/0x420 Call Trace: tctxtaskworkrun+0x804/0x950 tctxtaskwork+0x71/0xa0 taskworkrun+0x118/0x200 Leave the node unhashed.

Affected Software

2 affected componentsFixes available

debian/linux<6.12.115-1

6.12.115-1

debian/linux*

Event History

Nov 2, 2026

CVE Published

via OSV·04:17 PM

Data Sourced

via OSV·04:17 PM

DescriptionAffected Software

Frequently Asked Questions

What sequence is required to trigger the fault?

A recycled io_uring request must previously have been used as a cancelable uring_cmd, such as a ublk FETCH_REQ. It must then be reused for a vectored futex wait that is woken while futex_wait_multiple_setup() is still queueing futexes.

What is the observable impact if the issue is triggered?

The kernel can write through a poisoned hash-node pointer and raise a general protection fault. Reported diagnostics include KASAN wild-memory-access messages and a stack trace involving io_futexv_complete(), task_work, and tctx_task_work_run().

How can I recognize a potentially related crash?

Look for an Oops or general protection fault with an address in the LIST_POISON range, such as 0xdead000000000120, together with io_futexv_complete() in the instruction pointer or call trace. The affected path may also include __io_futex_complete() and task-work handling functions.

DEBIAN-CVE-2026-99230: Debian/linux vulnerability

Affected Software

Event History

Frequently Asked Questions

What sequence is required to trigger the fault?

What is the observable impact if the issue is triggered?

How can I recognize a potentially related crash?

Company

Resources

Contact

Frequently Asked Questions

What sequence is required to trigger the fault?

What is the observable impact if the issue is triggered?

How can I recognize a potentially related crash?