Denial of service in Apache ZooKeeper 3.7.0 through 3.9.6 lets an authenticated remote client crash a server with a single small multiRead request that forces the JVM to allocate a much larger in-memory response, ending in OutOfMemoryError. The flaw is rated high severity (vendor CVSS 4.0 7.1; assessed CVSS 3.1 AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H), is availability-only, and requires a valid client session plus a sizable znode that can be referenced repeatedly. No public exploit code or CISA KEV entry was identified at time of analysis.
Persistent denial of service in Apache ZooKeeper 3.8.0 through 3.8.7 and 3.9.0 through 3.9.6 lets remote attackers crash the transaction-apply thread by writing crafted quota-node data under /zookeeper/quota, a subtree that is world-writable on default deployments and therefore reachable without authentication. The harm persists after restart because the on-disk data directory becomes permanently unbootable, so recovery requires restoring or rebuilding rather than simply restarting the service. Upgrading to 3.8.8 or 3.9.7 fixes the issue; no public exploit identified at time of analysis.
Improper authorization in Apache ZooKeeper 3.8.0 through 3.8.7 and 3.9.0 through 3.9.6 lets a client that has already authenticated via SASL on the client port claim an arbitrary authorization identity (authzid) whenever its own principal is not matched by the configured zookeeper.security.auth_to_local rules, because the server grants the requested authzid and only logs the failed canonicalization instead of rejecting the connection. The client then inherits whatever sasl ACL permissions that impersonated identity holds, and gains full superuser access to the entire data tree if the claimed identity matches a configured zookeeper.superUser; with default rules the exploitable principals are those from a Kerberos realm other than the server's default realm, such as a cross-realm trusted realm. Exploitation is gated on SASL being enabled on the client port and the attacker holding a valid but non-canonicalized principal (authenticated, per the PR:L vector), and no public exploit identified at time of analysis; fixed releases are 3.8.8 and 3.9.7.
ACL enforcement bypass in Apache ZooKeeper 3.8.x and 3.9.x occurs when setACL changes are not published to the node's outstanding change record, allowing a request authorized against the old ACL to commit after the revocation. An authenticated client that already holds the permission being revoked can use the race to commit writes or deletes or to re-grant permissions, and the vendor notes an unauthenticated path during a transition from OPEN_ACL_UNSAFE to a restrictive ACL. No public exploit identified at time of analysis; impact is integrity-only, and the fixed releases are 3.8.8 and 3.9.7.
Apache Juneau through 9.2.0 is affected by CVE-2026-73100, one of a batch of vulnerabilities resolved together in the 9.2.1 release dated 2026-11-03. The supplied vendor advisory lists the CVE identifier in its title but does not describe the flaw's mechanism, the module it lives in, or the configuration and access preconditions it requires, so impact, attack vector and severity remain unconfirmed from available data. No public exploit code and no CISA KEV entry were identified at time of analysis, and no EPSS or CVSS scoring is available.
Apache Juneau 9.2.1, published 2026-11-03, closes a batch of security defects in the Java marshalling and REST framework that affect every release through 9.2.0, and CVE-2026-73101 is one of the identifiers covered by that release advisory. The published text does not give CVE-2026-73101 its own description, so the affected feature, trigger and preconditions for this specific identifier remain undetermined; the concrete issues that are described in the same advisory span parser memory exhaustion, path traversal in DirectoryResource, HTML-doc cross-site scripting and a content query-parameter body override. Anyone running org.apache.juneau artifacts, including the juneau-shaded-* and other aggregate artifacts that embed the affected modules, should treat exposure as unresolved until they move to 9.2.1; no public exploit code and no confirmed active exploitation are associated with this identifier in the available data, and the priority signal is awaiting_data with no EPSS, KEV or CVSS scoring supplied.
Unbounded memory allocation in Apache Juneau's MessagePack parser (org.apache.juneau:juneau-marshall and juneau-rest-server, through 9.2.0) lets an unauthenticated remote client force a multi-gigabyte buffer allocation from a request body of only a few bytes, producing an OutOfMemoryError denial of service. MsgPackParser is part of the REST server's default BasicUniversalConfig, so default REST resources that accept untrusted input are exposed without any special configuration. The vendor fixed this in 9.2.1 by capping input-declared lengths at a configurable maximum (16 MiB by default); no public exploit was identified at the time of analysis, and the vulnerability has not been confirmed as actively exploited (CISA KEV).
Apache Juneau through 9.2.0 is named in an aggregated November 2026 advisory for CVE-2026-73117, but the supplied sources do not describe this CVE's vulnerability class, affected module, exploitation prerequisites or impact; only the shared fixed version is confirmed. The advisory's individual write-ups cover CVE-2026-73095, CVE-2026-121489, CVE-2026-96677 and CVE-2026-73099, not this CVE. No public exploit or CISA KEV entry is identified in the supplied data, and impact remains unassessed until the official CVE record is available.
Cross-site request forgery in Apache Juneau REST server through 9.2.0 lets a remote attacker use a victim's browser to deliver an attacker-chosen request body to state-changing endpoints. The content query parameter that replaces the request body is enabled by default and, before the fix, was honored on every HTTP method including GET, so protections that depend on HTTP method or expected content type can be bypassed without an anti-CSRF token. Exploitation requires victim interaction and a target endpoint lacking token-based CSRF protection; the vendor rates it important, the assessed CVSS 3.1 vector is AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:N, and no public exploit was identified at time of analysis.
Reflected cross-site scripting in Apache Juneau's HTML-doc chrome (through 9.2.0) lets attacker-controlled request data reach a victim's browser unencoded when an application has placed a request-derived Simple Variable Language variable (RQ, RH, RF, or RP) into an HTML-format HtmlDocConfig chrome field. The vendor notes that default chrome does not interpolate those variables, so only applications that opt into that configuration are exposed, and the article body was already HTML-encoded. Users should upgrade to 9.2.1, which HTML-encodes substitutions in HTML chrome regions and leaves request variables unresolved in script and style fields; no public exploit code was identified at time of analysis.
Apache Juneau through 9.2.0 is affected by CVE-2026-73098, one of a batch of vulnerabilities resolved in the 9.2.1 release published on 2026-11-03, but the advisory text supplied here does not include a description for this specific identifier, so the vulnerable feature, attack vector and impact cannot be stated. No CVSS vector, EPSS score, CISA KEV entry or public PoC reference is available, and the vuln.today decision label is awaiting_data; exploitation status is therefore no public exploit identified at time of analysis, which reflects absence of data rather than confirmation that none exists. Affected artifacts include the juneau-* modules and the shaded aggregate artifacts that embed them, all of which must be upgraded to 9.2.1.
CVE-2026-73116 is an Apache Juneau security identifier for which the supplied oss-security advisory provides no component, mechanism, or impact detail; the advisory states that all issues it lists affect Juneau through 9.2.0 and are fixed in 9.2.1, including juneau-shaded-* and other aggregate artifacts. Deployments using affected Juneau versions should treat the identifier as uncharacterized until the vendor or NVD record supplies specifics. No public exploit code or CISA KEV entry was identified at time of analysis.
Path traversal in Apache Juneau's microservice DirectoryResource (juneau-microservice-core and juneau-commons through 9.2.0) lets an unauthenticated remote client use parent-directory segments in the request path to read, delete or write files outside the configured root directory, anywhere the server process has filesystem access. Exploitation is gated on non-default configuration: the resource must be reachable by untrusted clients and at least one of allowViews, allowDeletes or allowUploads must be explicitly enabled - all three are off by default, so default deployments are unaffected - and the achievable impact is bounded by which flag is enabled and by the server process's permissions. Apache fixed the issue in Juneau 9.2.1 by resolving each path against the root directory and returning 403 Forbidden for any path that escapes it; no public exploit code was identified at time of analysis (no KEV entry, no EPSS score and no PoC reference provided, decision label awaiting_data).
In Eclipse Mnestix AAS Generator versions 0.1.0 up until but excluding 1.5.0, a practical upper bound on the client-supplied count parameter of the GET /api/v1/IdGenerator/submodelIds/{count} and GET /api/v2/IdGenerator/submodelIds/{count} endpoints is not enforced. The service generates and retains identifiers in memory before returning a response. A remote unauthenticated attacker can submit a large count to cause excessive memory consumption, potentially resulting in denial of service. Exploitation requires network access to the endpoint and successful retrieval of the ID-generation configuration from the configured backend repository.
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/napi: make stale entries time out after 60s With dynamic tracking a NAPI id that hasn't been seen for a minute is meant to be dropped from the list the ring busy polls. The timeout is added to jiffies, but it is defined as 60 * SEC_CONVERSION, and SEC_CONVERSION isn't the number of jiffies in a second. It is the internal factor of __timespec64_to_jiffies(), HZ scaled up by SEC_JIFFIE_SC bits. For HZ=1000 that is 1000 << 22, which puts the timeout at about eight years. On 32-bit the multiplication overflows. So entries are never removed, and every id that a socket of the ring ever had keeps being polled on each wait.
In the Linux kernel, the following vulnerability has been resolved: io_uring/zcrx: fix buffer offsets in areas above 4GB io_zcrx_queue_cqe() computes the offset of the buffer in its area from net_iov_idx(), which is an unsigned int, so the shift is done in 32 bits and only the result is widened to the u64 that goes into the CQE. An area can be up to 1TB in size. For every niov beyond the first 4GB the CQE points the application at a buffer 4GB, or a multiple of that, below the one which has the data. It reads the wrong data, and then returns a buffer it doesn't own via the refill queue while the real one is never given back.
In the Linux kernel, the following vulnerability has been resolved: io_uring/openclose: keep the lock in io_pipe_fixed() io_pipe_fixed() installs both ends of the pipe in the fixed file table, drops ->uring_lock, and copies the slot numbers to the application. If that faults, it takes the lock again and removes whatever is in these slots. If the request is run by io-wq the lock really is dropped in between, and the slots are visible to everybody else. By the time the error path gets to them, they may have been closed and reused, by IORING_OP_CLOSE and a direct open or accept, or by IORING_REGISTER_FILES_UPDATE. Then a file is removed from the table that has nothing to do with the failed request. Do the copy with the lock held. Faulting in user memory under ->uring_lock is fine, the registration paths do it all the time.
In the Linux kernel, the following vulnerability has been resolved: io_uring/poll: avoid retry wakeup loss when dropping ownership If a wakeup sets IO_POLL_RETRY_FLAG between the owning task consuming the existing instance of IO_POLL_RETRY_FLAG and the loop check of io_poll_check_events(), then we stall on processing the request until an unrelated wakeup comes along. Using atomic_cmpxchg instead of atomic_sub_return to guarantee both the count v and poll_refs are 0 and no wake-ups are missed.
In the Linux kernel, the following vulnerability has been resolved: io_uring/timeout: don't lose a cancel as io-wq arms a timeout An IORING_OP_TIMEOUT run by io-wq, because of IOSQE_ASYNC, has the same problem as poll, futex and waitid. io_wq_submit_work() looks at IO_WQ_WORK_CANCEL once, before it issues the request. A cancel in between flags the work, gets -EALREADY, and searches ->timeout_list in vain, while the worker then adds the request and starts the timer: io-wq worker io_try_cancel() io_wq_submit_work() IO_WQ_WORK_CANCEL isn't set io_async_cancel_one() sets IO_WQ_WORK_CANCEL = -EALREADY io_timeout_cancel() = -ENOENT io_timeout() adds the request to ->timeout_list hrtimer_start() = IOU_ISSUE_SKIP_COMPLETE Nobody looks at the flag again, and the timeout runs its course. At ring exit, io_uring_try_cancel_requests() cancels io-wq work and then kills the timeouts the same way, so an exiting task can get stuck for the full duration of such a timeout. Look at the flag under ->timeout_lock, which the search takes as well, and fail the request if it is set. If the search came first, the flag is visible. If it comes later, it finds the request on the list.
In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: correct reservation fence slots for userq per-vm BOs eviction It fixes both the move overflow and the eviction fence add for evicting these per-vm BOs.
In the Linux kernel, the following vulnerability has been resolved: ntfs: fix resident conversion in ntfs_new_attr_flags When setting sparse/compressed flags on a resident attribute, the function skipped the resident-to-non-resident conversion and terminated.
In the Linux kernel, the following vulnerability has been resolved: soc/tegra: pmc: Fix uninitialised clock rate For legacy 32-bit Tegra devices, the warning in the tegra_pmc_enter_suspend_mode() function is being triggered because the early_pmc->rate variable is never configured and hence, always 0. This issue started occurring after updating the PMC driver to create the PMC context dynamically which causes the 'rate' to be set in the new dynamic context, but missed updating the rate in the early PMC context. Fix this by initialising the early_pmc->rate variable for 32-bit Tegra devices when the rate for the PMC context is initialised. [treding@nvidia.com: move assignment to existing #ifdef block]
In the Linux kernel, the following vulnerability has been resolved: x86/hyperv: Avoid using per-cpu output page in hv_apicid_to_vp_index() hv_apicid_to_vp_index() currently uses the per-cpu hypercall input and output pages. This function is called when running in VTL2 and when running in an SEV-SNP CoCo VM with no paravisor. In the former case, the output page is allocated, but in the latter case it is not, so the hypervisor stores the output VP index in memory that has not been allocated by the guest. Fix this by using the input page for both input and output. The hypercall has very small input and output, so sharing the same page for both is straightforward. An alternative fix is to allocate the per-cpu output page when running in an SEV-SNP CoCo guest, but this uses significantly more memory, particularly with larger vCPUs counts.
In the Linux kernel, the following vulnerability has been resolved: gpio: shared: gracefully handle no-device lookup of shared GPIOs We use platform lookup tables for shared GPIOs. This mechanism needs a struct device to work so fwnode-based lookup with no device associated currently causes a NULL-pointer deference. Adding this functionality will require a larger rework and it has never worked anyway so add a check that allows the kernel to gracefully handle this situation with an error ahead of implementing that functionality as a new feature.
In the Linux kernel, the following vulnerability has been resolved: dm cache: fix issue with background work locking dm cache used a rw_semaphore for background_work_lock. Write locks on rw_semaphores have strict owner semantics, but there was no guarantee that the process that locked background_work_lock was the same process that unlocked it. This can be easily seen using a kernel compiled with CONFIG_DEBUG_RWSEMS. Given a dm cache device <cache>, run: 'dmsetup suspend <cache> && dmsetup resume <cache>'. This will trigger a kernel warning: DEBUG_RWSEMS_WARN_ON((rwsem_owner(sem) != current) && !rwsem_test_oflags(sem, RWSEM_NONSPINNABLE)) triggered by cache_resume(). To fix this, switch from a rw_semaphore to a spinlock and a wait queue. dm cache already has a wait queue and associated counter, migration_wait and nr_allocated_migrations, that was getting woken up when background work was getting completed, but wasn't actually used by anything. This is replaced by the background_work queue and counter.
In the Linux kernel, the following vulnerability has been resolved: io_uring/io-wq: don't hide a link from cancellations A task that exits cancels its tracked requests and waits until they are gone. io_uring_cancel_generic() looks everywhere a request can be, and goes to sleep if it found nothing to cancel. It is woken up each time one of the requests of the task is completed by task work or freed. When io-wq is done with a request that has a link, there is a time in which the next request of the link can't be found: io_worker_handle_work() io_assign_current_work(worker, NULL) io_wq_free_work(work) io_req_find_next() // takes the link off the request io_free_req() // task work for the task io_assign_current_work(worker, linked) io_run_task_work() cond_resched() worker->cur_work = linked It is not pending, it is not the current work of a worker, and it is not yet on the list that it is about to be parked on. If the pass that the exiting task makes because of io_free_req() falls into that time, it finds nothing and the task goes to sleep. The worker then runs the link, which IO_WQ_BIT_EXIT doesn't prevent for bounded work. If that parks the request nothing is completed or freed, and nobody wakes up the task. If it is the process that exits it can't be killed any more either. NOP, IOSQE_ASYNC | IOSQE_IO_LINK FUTEX_WAIT, FUTEX2_PRIVATE exit of the thread, or of the process, up to 63us later With four of these per round 5 to 8 of 10,000 rounds hang (4 CPUs, KVM): io_uring_cancel_generic do_exit Commit f8b632e89a10 ("io_uring: tighten task exit cancellations") is about the same gap, and makes the task look again for whatever happens before io_free_req(). Free the request once the link is the current work of the worker, or pending. Whoever is woken up by that can find the link, until it is parked where cancellations look as well. To do so split io_wq_free_work() in two.
In the Linux kernel, the following vulnerability has been resolved: io_uring: don't flood a cancelling task with task_work io_ring_exit_work() asks each task which has used the ring to remove its tctx node, by task_work, and repeats that until the list is empty. io_tctx_exit_cb() doesn't touch the node while the task is in io_uring_cancel_generic(), which removes all the nodes at its end. So the work item queues the callback again as soon as it has completed, for nothing. That is more than a waste of time. task_work_run() only returns when it finds the list empty. If the rings are released from inside the cancellation, because requests of other rings held the last references to their files, up to 64 work items keep sending callbacks to the one task which is running them. It never finds the list empty, never gets back to the cancellation, the nodes stay, and so it goes on: a task with 60 pairs of rings which poll each other ran 280000 callbacks in 5 seconds, 20 seconds after exit_group(). It ends when all the senders happen to be late at the same time. Until then the task keeps a CPU and the work items busy. An exiting task can't be killed meanwhile. execve() cancels the requests in the same way, so a live task can get stuck there as well, for minutes. If it takes more than five, the work items run into the WARN_ON_ONCE(time_after(jiffies, timeout)) of io_ring_exit_work(). No privilege is needed for any of this. If the callback has met a task in cancellation, wait a little before it is sent again. Nobody has to wake the work item up for that: either the node is gone by then, or it is the turn of the next round.
In the Linux kernel, the following vulnerability has been resolved: io_uring/cancel: rearm local work wake up before sleep io_uring_try_cancel_requests() sets ->cq_wait_nr to 1 so that the next io_req_local_work_add() wakes the cancelling task. The add that takes the count to zero is the only one that wakes, later ones see a count <= 0 and return. io_uring_cancel_generic() however only becomes TASK_INTERRUPTIBLE much later, so the one wake up can be spent on a running task. That is fine as long as the entry of that add is still queued, as the io_local_work_pending() check then skips the sleep. It is not if the add was delayed after queueing its entry: CPU0 (submitter in exec or exit) CPU1 (io_req_local_work_add) mpscq_push(req A) io_uring_try_cancel_requests() io_run_local_work() // runs req A io_uring_try_cancel_requests() atomic_set(&ctx->cq_wait_nr, 1) atomic_read(&ctx->cq_wait_nr) == 1 count taken, wake_up_state() // task is running, no-op prepare_to_wait(TASK_INTERRUPTIBLE) io_local_work_pending() == false schedule() mpscq_push(req B) cq_wait_nr <= 0, return Only the sleeping task can run req B, so it is stuck in execve() until a signal happens to wake it. An exiting task doesn't even get that. Arm the count again once the task state is set and before the work list is checked, for the rings whose local work this task is the one to run.
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: Drivers: hv: Avoid infinite retry loop in init_vp_index() There is a retry loop in init_vp_index() where the CPUs from a certain node are stripped out if they have already been in the allocated cpumask or not in HK_TYPE_MANAGED_IRQ housekeeping cpumask. If there is no CPU left, the allocated cpumask is ignored and the process is retried again. However, if the HK_TYPE_MANAGED_IRQ housekeeping cpumask turns out not to contain any CPU in that particular node, that will become an infinite retry loop. This particular problem was reported by sashiko [1]. This should rarely happen, but we still need to guard against this. Fix this infinite loop problem by also skipping NUMA node that has no housekeeping CPU in the inner while loop of init_vp_index(). Also update the early abort check to check for the absence of online housekeeping CPUs instead of just the emptiness of the cpumask. As the outer for loop will only be reached if the housekeeping cpumask has at least one online CPU, a NUMA node with housekeeping CPUs will eventually be found.
In the Linux kernel, the following vulnerability has been resolved: printk: Postpone kthread startup There have been various bug reports related to SMP systems hanging on boot. The reports vary but seem to have some overlap with regard to missed IPI's during SMP setup. The reports also show that reverting NBCON console usage allows the bugs to disappear. The NBCON kthreads for console printing are started very early during boot using early_initcall(). Since these kthreads are asynchronously enabling/disabling interrupts during early boot, they may be interfering with early SMP setup on some hardware platforms. Starting the console printing kthreads later has shown to avoid the hanging on systems that could previously reproduce the issue. Postpone kthread starting until after all arch initcalls have completed.
In the Linux kernel, the following vulnerability has been resolved: pid_namespace: make zap_pid_ns_processes() freezable When the init of a pid namespace exits, zap_pid_ns_processes() waits until all other pids in the namespace are freed. A tracer outside the namespace that does not reap its traced zombies keeps those pids allocated, so this wait has no upper bound, and while it lasts every suspend attempt fails: Freezing user space processes failed after 20.006 seconds (2 tasks refusing to freeze, wq_busy=0): Neither wait is freezable. The first loop sleeps in do_wait(), which returns -ERESTARTSYS on the freezer's fake signal; the loop then clears TIF_SIGPENDING and waits again without ever freezing. The final loop sleeps in TASK_INTERRUPTIBLE, and since nothing clears TIF_SIGPENDING there, schedule() returns immediately after the first freeze attempt and the task spins until the wait ends. Sleep in TASK_INTERRUPTIBLE | TASK_FREEZABLE in do_wait(), so that the freezer can freeze tasks waiting there directly, and in TASK_IDLE | TASK_FREEZABLE in the final loop, like coredump_task_exit() does. This was hit with Chromium-based browsers: crashpad ptrace-attaches the threads of a crashed renderer, which is a pid namespace init, and does not reap those killed during the dump.
In the Linux kernel, the following vulnerability has been resolved: i2c: xiic: restore non-managed runtime PM to fix clk WARN flood The devres conversion replaced manual pm_runtime_enable()/disable() with devm_pm_runtime_set_active_enabled() and dropped the remove-time runtime PM teardown. The managed release tears runtime PM down in the wrong order: it calls pm_runtime_dont_use_autosuspend() before pm_runtime_disable(), i.e. while runtime PM is still enabled, and devres is LIFO so the devm_clk_get_enabled() release runs afterwards. At remove(), pm_runtime_put_sync() leaves the device active with the autosuspend timer armed. Clearing use_autosuspend then makes rpm_idle() suspend immediately, and xiic_i2c_runtime_suspend() clk_disable()s the clock. The later devm_clk_get_enabled() release clk_disable_unprepare()s the already-disabled clock, so clk_core_disable() WARNs ("clkN already disabled") on every teardown. Drop the managed helper and restore the non-managed runtime PM setup and teardown, so runtime PM is enabled once in probe and disabled once in remove and the clock enable count stays balanced. Order the remove teardown so runtime PM is disabled before the usage count is dropped: pm_runtime_disable() followed by pm_runtime_put_noidle() instead of pm_runtime_put_sync(). Dropping the count first with autosuspend still enabled arms the autosuspend timer, and a preemption before pm_runtime_disable() lets it expire, suspend the device and clk_disable() the clock, which the devm release then disables again - the same WARN. Restore the non-managed IRQ request as well. The probe error paths now unwind runtime PM by hand via goto, and a devm-registered handler is only freed later during devres unwind, so it would stay live across the manual teardown (and across any future failing step added after it). Request the IRQ with request_threaded_irq() and free it explicitly in the probe error path and in remove. The probe error path also clears use_autosuspend, to match the teardown in remove().
In the Linux kernel, the following vulnerability has been resolved: tracing: Do not initialize tracefs work if tracing is disabled If trace buffer allocation fails during early boot (e.g. in early_trace_init() -> allocate_trace_buffers()), tracing_disabled is left set to 1 and the global trace array events list remains uninitialized. Later during boot, tracer_init_tracefs() (invoked via fs_initcall) queues tracerfs_init_work asynchronously without checking if tracing was disabled. When tracer_init_tracefs_work_func() runs, it calls event_trace_init() and init_tracer_tracefs(&global_trace, NULL) unconditionally. This leads to __find_event_file() dereferencing an uninitialized tr->events list, causing an early boot NULL pointer dereference Oops: BUG: Kernel NULL pointer dereference on read at 0x00000010 Faulting instruction address: 0xc000000000485be0 Oops: Kernel access of bad area, sig: 7 [#1] ... NIP [c000000000485be0] __find_event_file+0x70/0x3c0 LR [c000000000448874] init_tracer_tracefs+0x274/0xc80 Call Trace: init_tracer_tracefs+0x274/0xc80 tracer_init_tracefs_work_func+0x50/0x320 process_one_work+0x1e8/0x5c0 worker_thread+0x1dc/0x3d0 kthread+0x194/0x1b0 start_kernel_thread+0x14/0x18 Check tracing_disabled at the beginning of tracer_init_tracefs_work_func() and return immediately if tracing is disabled or failed to initialize, preventing the crash.
In the Linux kernel, the following vulnerability has been resolved: KEYS: Fix key_reject_and_link() race with keyring restriction The restrict_link check in key_reject_and_link() is done before taking the keyring semaphore, racing with a concurrent keyring_restrict() that installs the restriction while holding the semaphore in write mode. Move the check to after __key_link_lock(), so it is done under the semaphore, matching the pattern used in __key_create_or_update().
In the Linux kernel, the following vulnerability has been resolved: pid_namespace: prevent TIF_NOTIFY_SIGNAL from interrupting the reaper Since commit 7fea700e04bd ("zap_pid_ns_processes: clear TIF_NOTIFY_SIGNAL along with TIF_SIGPENDING") zap_pid_ns_processes() clears TIF_NOTIFY_SIGNAL before every kernel_wait4() call. Otherwise kernel_wait4() doesn't sleep and returns -ERESTARTSYS if signal_pending() is true and the reaper busy-waits. But clearing TIF_NOTIFY_SIGNAL doesn't fix it. It can get raised again. For example, klp_send_signals() sets it raw against any task that hasn't transitioned yet. And it keeps sending it until the livepatch finishes. The sleep loop waiting for pid_allocated to drop has the same problem and it doesn't even clear anything. So a schedule() in TASK_INTERRUPTIBLE returns immediately. Use a no_notify_signal guard. signal_pending() will ignore TIF_NOTIFY_SIGNAL and the pid namespace reaper sleeps until a child exits or free_pid() wakes it.
In the Linux kernel, the following vulnerability has been resolved: io-wq: order the exit bit against worker creation task work io_wq_exit_workers() cancels task work for queued worker creation with task_work_cancel_match(). That has a plain load of task->task_works. io_queue_worker_create() adds the new entry and tests IO_WQ_BIT_EXIT to cancel it if the workqueue is already on its way out. That must be ordered. task_work_add() has a full barrier via cmpxchg(). But io_wq_exit_start() sets the bit with set_bit() which doesn't have any memory ordering. So afaict, on weakly ordered architectures the exiting task may load task_works before the store of the bit is visible. The other side tests the bit before the store is visible as well. So the entry remains queued with worker_refs and the exiting task waits on worker_done indefinitely. If the task still has rings then io_uring_del_tctx_node() provides the barrier via test_and_set_bit() in io_wq_set_exit_on_idle(). When it has closed all rings though that barrier is gone. Add the barrier after the set_bit().
Denial of service in Apache HertzBeat 1.7.1 through 1.9.0 allows authenticated users with monitor-template creation privileges to consume excessive collector CPU by supplying XPath expressions through metrics.aliasFields that bypass the validation applied to parseScript. The flaw is a follow-up to an incomplete fix for CVE-2026-24343 and is fixed in Apache HertzBeat 1.9.1. No public exploit code was identified at time of analysis; the issue has low availability impact under CVSS 3.1 (AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L) and the priority decision is monitor.
In esmf-sdk-py-aspect-model-loader versions 2.1.2 to 2.2.1, the Aspect Model loader resolves cross-file model references by extracting the third and fourth colon-separated components of any urn:samm:… namespace declared in a parsed Turtle file to build a directory to scan. A model file containing @prefix x: <urn:samm:../../../foo:bar#> or @prefix x: <urn:samm:/abs/path:bar#> causes the loader to glob and parse *.ttl files from arbitrary directories outside the intended models root, merging their contents into the returned graph.
Catalyst::Plugin::Authentication versions before 0.10029 for Perl allow timing attacks on stored passwords via eq comparisons in the legacy password verifier. CVE-2026-5091 was fixed in the realm-based verifier. The legacy verifier, used by the deprecated login method, compares clear-text passwords, crypt hashes and base64 digests with eq, so the comparison time depends on how many leading bytes match. A remote attacker can use response-time differences to guess the stored password or hash.
Whale Browser before 5.39.412.57 allows an attacker to bypass the iframe sandbox in a dual-tab environment.
An issue in im3x Scriptables through v2-dev branch allows attackers to inject arbitrary OS commands via uploading a file with a crafted filename to the /sync endpoint.
CVE-2026-97889 is an Ubuntu-sourced vulnerability record for which no description, CVSS score, CVSS vector or CWE classification has been published, so the affected component, the trigger and the resulting impact cannot be identified from the available data. The only attributable detail is the reporting vendor, Ubuntu, which indicates the entry is expected to be resolved through an Ubuntu Security Notice covering one or more Ubuntu packages; neither the package name nor the release series is disclosed. No public exploit code has been identified at time of analysis, there is no CISA KEV listing, and the record carries a vuln.today priority of 'this_month', so risk cannot be meaningfully quantified until the vendor publishes the technical specifics.
A hardcoded session secret key in codeskyblue gohttpserver through v1.3.0 allows attackers to impersonate any user, bypass OpenID Connect authentication and access all controls via forged session cookies.