| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| Improper handling of exceptional conditions in the quota subsystem of Apache ZooKeeper allows an attacker able to write under the /zookeeper/quota subtree — unauthenticated on default deployments, where that subtree is world-writable — to crash the server's critical request-processing thread and render the on-disk data directory permanently unbootable.
This issue affects Apache ZooKeeper up to and including 3.9.6. Users are recommended to upgrade to version 3.8.8 or 3.9.7, which fixes the issue. |
| Improper state validation in GPU in Google Chrome prior to 157.0.8103.38 allowed a remote attacker who had compromised the renderer process to potentially execute arbitrary code outside the sandbox via a crafted HTML page. (Chromium security severity: High) |
| In Eclipse ThreadX NetX Duo versions up to and including 6.5.2.202603, the RTSP server returns a raw parser error for a malformed Session header and never releases the response packet it allocated. An unauthenticated client can drain the server's packet pool with a few dozen requests, stopping the RTSP server and, where the pool is shared, the rest of the network stack until the device restarts. |
| Improper state validation in Core in Google Chrome prior to 156.0.8078.47 allowed a remote attacker leveraging social engineering to spoof UI elements via a crafted HTML page. (Chromium security severity: Low) |
| A race condition vulnerability exists in the API of HPE Networking Fabric Composer. Successful exploitation could allow an authenticated attacker with low privileges to corrupt the configuration state of the affected system. |
| An arbitrary file write vulnerability exists in the underlying operating system of HPE Networking Fabric Composer. Successful exploitation could allow an authenticated local attacker to create or overwrite arbitrary files on the affected system with elevated privileges. |
| SD JWT JS is a JavaScript implementation of the Selective Disclosure JWT (SD-JWT) specification. In version 0.19.0 and earlier, `@sd-jwt/decode`, also used by `@sd-jwt/core`, silently drops a tampered Disclosure whose digest no longer matches the Issuer-signed `_sd` array and returns a reduced claim set, reporting success while the Issuer signature remains valid. Both a tampered Disclosure that remains valid JSON and a Disclosure containing invalid UTF-8 bytes reach this silent-drop behavior. In the latter case, the `TextDecoder / Buffer` decoding path substitutes U+FFFD replacement characters, recovering syntactically valid disclosure data instead of rejecting the malformed input. This violates RFC 9901 section 7.1 step 5, which requires rejection of unreferenced Disclosures, and section 7.1 step 3 / section 4.2.1, which require rejection of invalid Disclosures. A malicious holder can exploit this omission primitive, including through `SDJwtInstance.verify()` when key binding is required. An on-path attacker can also tamper with a Disclosure when the relying party does not enforce key binding; enforced key binding rejects on-path tampering because it invalidates the KB-JWT `sd_hash` binding. If the relying party defaults to allowing access when a constraining age, role, or restriction claim is absent, the silent claim reduction can change an authorization decision without an error. This issue is fixed in `@sd-jwt/core` version 0.20.0; no patched version of the standalone `@sd-jwt/decode` package is identified. |
| Improper state validation in FileSystem in Google Chrome prior to 157.0.8103.38 allowed a remote attacker leveraging social engineering to bypass system access restrictions via a crafted HTML page. (Chromium security severity: Medium) |
| Improper state validation in XML in Google Chrome prior to 157.0.8103.38 allowed a remote attacker to bypass web origin policy via a crafted HTML page. (Chromium security severity: Low) |
| Improper state validation in Performance in Google Chrome prior to 156.0.8078.47 allowed a local attacker to read memory via a local program. (Chromium security severity: Medium) |
| A vulnerability in the CLI of Cisco IOS XE Software could allow an authenticated, local attacker with privilege level 15 to elevate privileges to root on the underlying operating system of an affected device.
This vulnerability is due to insufficient input validation when processing specific configuration commands. An attacker could exploit this vulnerability by including crafted input in specific configuration commands. A successful exploit could allow the attacker to elevate privileges to root on the underlying operating system of an affected device. The security impact rating (SIR) of this advisory has been raised to High because an attacker could gain access to the underlying operating system of the affected device and perform potentially undetected actions.
Note: The attacker must have privileges to enter configuration mode on the affected device. This is usually referred to as privilege level 15. |
| In the Linux kernel, the following vulnerability has been resolved:
io_uring: wake ring pollers for local task_work
With IORING_SETUP_DEFER_TASKRUN completions are queued as local work, and
only become CQEs when the submitter enters the kernel to wait for events.
For an application that finds out via poll() or epoll on the ring fd when
it is time to do that, io_uring_poll() reports EPOLLIN if local work is
pending.
That only helps if the work is there at the time of the call. When
DEFER_TASKRUN was added, io_req_local_work_add() did io_cqring_wake(),
which took care of tasks sleeping in poll() as well. Then polling got a
wait queue of its own, ->poll_wq, and the wake up in
io_req_local_work_add() was replaced by waking the submitter directly.
Since then ->poll_wq is only woken when CQEs are committed, which for
such a ring is done by the very task that is waiting to be told to:
submitter completion
poll(ring_fd)
io_uring_poll() // nothing yet
schedule()
io_req_local_work_add()
// ->cq_wait_nr: nobody waits
// sleeps on
Wake ->poll_wq when the first entry is put on the work list. Like for the
eventfd, that must not be done right away if the work is queued from a
wake up handler, as the chain of wake ups could get back to the wait
queue whose lock is held. Use an RCU callback in that case, with a
reference to the ring. |
| In the Linux kernel, the following vulnerability has been resolved:
io_uring/mpscq: disable preemption while pushing
A push makes the node the new tail, and then links it to its predecessor.
In between the queue isn't empty, but mpscq_pop() can't get at the node.
The consumers deal with that by trying again, with a cond_resched() in
the loop to give a preempted producer the chance to finish.
cond_resched() doesn't do that if the consumer has a higher priority than
the producer and both have to use the same CPU:
producer (SCHED_OTHER) consumer (SCHED_FIFO), same CPU
io_req_local_work_add()
mpscq_push()
prev = xchg(&q->tail, node)
<preempted> io_cqring_wait()
__io_run_local_work()
again:
cond_resched() // nothing to do
mpscq_pop() // NULL
// work pending, no events yet
goto again
The producer can be any task that is able to queue task_work for the
ring: an io-wq worker, or somebody who sends a message with
IORING_OP_MSG_RING. The consumer spins, holding ->uring_lock, until the
scheduler takes pity on the fair class, which takes about a second with
the default settings of the fair server, and forever without it. The
loops in tctx_task_work_run() and io_cancel_local_task_work() have the
same problem.
Don't allow preemption between the two steps. That bounds the time the
window is open on the CPU of the producer by what interrupts take, and a
consumer that waits for that is on another CPU. The cost is a
preempt_disable()/preempt_enable() pair per push. |
| 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. |
| darylldoyle svg-sanitizer from 1.0.0 before 1.1.0 contains a regular expression denial of service vulnerability in the image-set pattern of stripRemoteCssTokens() when removeRemoteReferences is enabled. Attackers can submit SVGs with many unclosed image-set tokens to exhaust CPU, or trigger PCRE limits causing sanitize() to throw a TypeError and leave unsanitized content. |
| In multiple locations, there is a possible denial of service due to a logic error in the code. This could lead to remote denial of service with no additional execution privileges needed. User interaction is not needed for exploitation. |
| In multiple locations, there is a possible permission bypass due to a missing permission check. This could lead to local information disclosure with no additional execution privileges needed. User interaction is not needed for exploitation. |
| Improper Check for Unusual or Exceptional Conditions vulnerability in the pattern and patternProperties keywords in lud jsv allows an unauthenticated remote attacker to bypass schema validation via a string that matches a schema regex only after heavy backtracking. JSV.Helpers.RegexExt.bounded_match?/2 runs schema regexes with a backtracking budget but calls :re.run/3 without :report_errors, so a match that exhausts the budget returns the same :nomatch as a real non-match. A key that matches a patternProperties regex is then checked against additionalProperties or not at all, and a string that matches a not subschema with a pattern is accepted. Before the budget existed, Regex.match?/2 failed the same way at Erlang's default match limit.
Only schemas whose regex explores a catastrophic branch before the branch that matches are affected. The attacker controls the data, not the schema, and linear patterns never exhaust the budget.
This issue affects jsv: from 0.1.0 before 0.26.2. |
| Mattermost versions 11.7.x <= 11.7.11 fail to validate null elements when decoding playbook import conditions which allows an authenticated attacker to crash the Playbooks plugin instance-wide via a crafted import request containing a null condition. Mattermost Advisory ID: MMSA-2026-00709 |
| In Modem, there is a possible information disclosure due to side channel information disclosure. This could lead to remote denial of service, if a UE has connected to a rogue base station controlled by the attacker, with no additional execution privileges needed. User interaction is not needed for exploitation. Patch ID: MOLY01879164; Issue ID: MSV-9846. |
