CVE-2026-120061 is a stack-based buffer overflow vulnerability in the psqlODBC driver for PostgreSQL. The issue arises from improper handling of ODBC escape sequences in SQL text, where argument offsets for {fn} escapes are written into a fixed-size stack array without bounds checking. This can lead to stack overflow and memory corruption. Additionally, certain escape sequences ({d}, {t}, {ts}, {escape}) write one byte beyond a 128-byte stack buffer. Applications forwarding untrusted SQL text to the driver are at risk. Versions before 18.00.0006 are affected.
In the Linux kernel, the following vulnerability has been resolved:
io_uring/waitid: own the request before clearing ->head
io_waitid_remove_wq() only takes the wait queue lock if ->head is set.
io_waitid_wait() clears ->head first thing, before it tries to become the
owner of the request by bumping ->refs. If somebody else owns the request
at that point, nothing keeps it from completing the request while the
wake up handler is still going to touch it:
CPU0 (io_waitid_wait) CPU1 (io_waitid, holds a ref)
list_del_init(&wait->entry)
smp_store_release(&iw->head, NULL)
__do_wait() finds another child
io_waitid_remove_wq()
// ->head == NULL, no locking
io_waitid_finish(), IOU_COMPLETE
// request freed and reused
atomic_fetch_inc(&iw->refs)
The same goes for __io_waitid_cancel() if it claims the request in that
window. ->refs is part of the per opcode data of the request, so this
increments whatever the next user of the request keeps there. If that
happens to be zero, the handler concludes that it owns the request, and
queues io_waitid_cb() for it. With the window held open by a delay, and
the request reused for a receive that is waiting for data:
BUG: KASAN: slab-use-after-free in __wake_up_common+0x1ca/0x1f0
__wake_up_sync_key+0x36/0x50
sock_def_readable+0xf1/0x420
unix_stream_sendmsg+0x60b/0x1110
Allocated by task 87:
io_arm_apoll+0x1ed/0x940
Freed by task 87:
__io_submit_flush_completions+0x118d/0x1a10
tctx_task_work_run+0x327/0x950
Only clear ->head once the handler owns the request. If it doesn't, the
owner finds ->head set and has to wait for the lock, which is held by the
caller of the handler. Deleting the already deleted entry again is
harmless.
In the Linux kernel, the following vulnerability has been resolved:
io_uring/cmd: don't leave list poison in ->hash_node
io_uring_cmd_del_cancelable() uses hlist_del() to take a command off
->cancelable_uring_cmd, which leaves LIST_POISON1/2 behind in
->hash_node. Requests are recycled through the request cache without
being reinitialised, and not every user of ->hash_node sets it up before
it is used:
If a vectored futex wait is woken while futex_wait_multiple_setup() is
still queueing the futexes, io_futexv_wait() doesn't add the request to
->futex_list, and leaves the completion to the task_work queued by the
wake up. io_futexv_complete() ends in __io_futex_complete(), whose
hlist_del_init() 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
uring_cmd in its previous life, e.g. a ublk FETCH_REQ, it writes through
LIST_POISON2:
Oops: general protection fault, probably for non-canonical address
KASAN: maybe wild-memory-access in range [0xdead000000000120-...]
RIP: 0010:io_futexv_complete+0x219/0x420
Call Trace:
tctx_task_work_run+0x804/0x950
tctx_task_work+0x71/0xa0
task_work_run+0x118/0x200
Leave the node unhashed.
In the Linux kernel, the following vulnerability has been resolved:
io_uring/wait: don't spin on a stuck overflow list
As long as IO_CHECK_CQ_OVERFLOW_BIT is set, io_cqring_wait_schedule()
returns right away, before it gets to look at signals or arms the timeout,
for io_cqring_wait() to flush the overflow list. If that doesn't empty the
list, and the CQ ring doesn't hold the number of events the caller wants,
the loop starts over, with the same result. The task spins in the kernel,
and can't be killed.
The assumption is that this can't happen: if CQEs can't be flushed, the
ring is full, and min_events is capped to the size of the ring. But:
- With IORING_SETUP_CQE_MIXED a 32b CQE needs two contiguous entries. It
is stuck on the list if a single one is free, and then the ring holds
less than cq_entries events. A single threaded application that asks
for as many events as the ring has entries never gets out of
io_uring_enter().
- Whether the ring is full is up to the CQ head, which the application
can write to. While one thread waits for events on an empty ring,
another one can move the head back so that the ring looks full and
have a CQE overflow. The waiter can't be stopped any more, not even by
SIGKILL.
Only the application can make room in the CQ ring. Return to it if the
list could not be flushed.
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.
In the Linux kernel, the following vulnerability has been resolved:
coredump: hold RCU while releasing parked threads
coredump_finish() releases the parked threads by clearing ->task in
their core_thread entry and calling wake_up_process() on each of them.
It does that without holding a reference on the task and without being
inside rcu.
But calling wake_up_process(task) without rcu here isn't safe. A parked
thread doesn't need that wakeup to leave. A spurious wakeup or a
preemption after the store is enough for the task to go away.
So if the coredump client is preempted between the store and
wake_up_process() the thread can exit and be freed in the meantime and
try_to_wake_up() takes pi_lock in freed memory.
Hold rcu across the loop.
php2shell comprises two PHP vulnerabilities (CVE-2026-109618 and CVE-2026-109619) that allow unauthenticated remote code execution. Exploitation requires tailoring the attack to the specific PHP environment, making widespread mass exploitation difficult. However, network appliances running identical builds are vulnerable to a single calibrated exploit. Exploitation has been confirmed in the wild, including attacks on PAN-OS firewall management servers. Patching is available and strongly recommended, especially for internet-facing management interfaces and end-of-life PHP versions.
Wasmtime 46.0.0 before 48.0.6 and 49.0.0 before 49.0.3 panics when the host reads a component model stream as a different Rust item type than it was created with, because the host-to-host read path asserts matching TypeIds instead of returning an error. Guest code can return a host-created StreamReader<U> that the embedder reads as StreamReader<T>, where both types map to the same component model type, crashing the embedding process.
This vulnerability involves the Microsoft driver component 'hv' where the VMBus connection state is improperly reset on error or exit paths. The issue is identified in version 3.0 of the affected software. No CVSS score or detailed impact information is provided.
This vulnerability involves the net/rds component where the rdma_cm improperly destroys an identifier that RDS still owns upon a route failure. The issue is identified in Microsoft product version 3.0. No CVSS score or detailed impact information is provided.
This vulnerability, identified as CVE-2026-99178, involves the x86 KVM component where asynchronous page fault flags are improperly consumed during a kernel page fault in a non-maskable interrupt (NMI) context. The advisory does not provide detailed technical or impact information beyond this description.
This vulnerability concerns the amdgpu driver component in Microsoft software, specifically related to improper handling of runtime power management references in the amdgpu_gpr function. The issue involves dropping the runtime PM reference twice, which may lead to unintended behavior. The affected version explicitly stated is version 3.0. No CVSS score or detailed impact information is provided.
CVE-2026-99147 is a vulnerability related to the drm/exec component where a prelocked object is improperly handled by being immediately added to the array of locked objects. The advisory provides no further technical details or impact information.
This vulnerability involves the xfs filesystem where buffer locks are held across a sync transaction commit in the function xfs_sync_sb_buf. The issue is identified in version 3.0 of the affected software. No CVSS score or detailed impact information is provided.
CVE-2026-99130 is a vulnerability related to the io_uring subsystem, specifically in the cancel operation where the system may spin on local work that the task cannot run. The advisory references Microsoft products and support lifecycle but provides no detailed technical or impact information.
CVE-2026-99117 is a vulnerability related to the network bridge multicast handling in Microsoft software version 3.0. The issue involves improper truncation of the port group walk during teardown, which may affect network operations. No detailed impact or exploitation information is provided.