Veille CVE

Vendredi 24 juillet 2026

16 CVE

Critique 1 Élevée 6 Moyenne 9 Faible 0 Non évaluée 0 Exploitées (KEV) Tri : plus récentes « kernel » ✕
  1. CVE-2026-42343 6.3 Moyenne

    labring FastGPT

    FastGPT is an AI Agent building platform. In versions 4.14.13 and prior, the code-sandbox component suffers from insufficient resource isolation and uncontrolled resource consumption. The service relies solely on an application-level soft limit (a 500ms polling interval) for memory management and lacks strict OS-level constraints such as cgroups or kernel-level namespaces. This architectural weakness allows attackers to easily bypass memory checks via time-window attacks, or exhaust the entire JavaScript worker pool via concurrent CPU-intensive requests, resulting in a complete Denial of Service (DoS) for legitimate users. At time of publication, there are no publicly available patches.

  2. CVE-2026-38765 7.8 Élevée

    An issue in Unistal Systems Pvt. Ltd.Protegent 360 v2.0.0.4 allows a local attacker to escalate privileges via the kernel driver pgsecdl.sys

  3. CVE-2026-53332 5.5 Moyenne

    Linux · Linux linux kernel

    In the Linux kernel, the following vulnerability has been resolved: slimbus: qcom-ngd-ctrl: Register callbacks after creating the ngd When the remoteproc starts in parallel with the NGD driver being probed, or the remoteproc is already up when the PDR lookup is being registered, or in the theoretical event that we get an interrupt from the hardware, these callbacks will operate on uninitialized data. This result in issues to boot the affected boards. One such example can be seen in the following fault, where qcom_slim_ngd_ssr_pdr_notify() schedules work on the NULL ngd_up_work. [ 21.858578] ------------[ cut here ]------------ [ 21.858745] WARNING: kernel/workqueue.c:2338 at __queue_work+0x5e0/0x790, CPU#2: kworker/2:2/116 ... [ 21.859251] Call trace: [ 21.859255] __queue_work+0x5e0/0x790 (P) [ 21.859265] queue_work_on+0x6c/0xf0 [ 21.859273] qcom_slim_ngd_ssr_pdr_notify+0x110/0x150 [slim_qcom_ngd_ctrl] [ 21.859304] qcom_slim_ngd_ssr_notify+0x24/0x40 [slim_qcom_ngd_ctrl] [ 21.859318] notifier_call_chain+0xa4/0x230 [ 21.859329] srcu_notifier_call_chain+0x64/0xb8 [ 21.859338] ssr_notify_start+0x40/0x78 [qcom_common] [ 21.859355] rproc_start+0x130/0x230 [ 21.859367] rproc_boot+0x3d4/0x518 ... Move the enablement of interrupts, and the registration of SSR and PDR until after the NGD device has been registered. This could be further refined by moving initialization to the control driver probe and by removing the platform driver model from the picture.

  4. CVE-2026-53163 5.5 Moyenne

    Linux · Linux linux kernel

    In the Linux kernel, the following vulnerability has been resolved: locking/rtmutex: Skip remove_waiter() when waiter is not enqueued syzbot triggered the following splat in remove_waiter() via FUTEX_CMP_REQUEUE_PI: KASAN: null-ptr-deref in range [0x0000000000000a88-0x0000000000000a8f] class_raw_spinlock_constructor remove_waiter+0x159/0x1200 kernel/locking/rtmutex.c:1561 rt_mutex_start_proxy_lock+0x103/0x120 futex_requeue+0x10e4/0x20d0 __x64_sys_futex+0x34f/0x4d0 task_blocks_on_rt_mutex() does not arm the waiter upon deadlock detection, leaving waiter->task nil, where 3bfdc63936dd ("rtmutex: Use waiter::task instead of current in remove_waiter()") made this fatal. Furthermore, rt_mutex_start_proxy_lock() should not be calling into remove_waiter() upon a successfully grabbing the rtmutex. 1a1fb985f2e2 ("futex: Handle early deadlock return correctly"), moved the remove_waiter() out of __rt_mutex_start_proxy_lock() (where 'ret' was only ever 0 or < 0) into the wrapper. Tighten this check to account for try_to_take_rt_mutex().

  5. CVE-2026-53027 5.5 Moyenne

    Linux · Linux linux kernel

    In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: fix missing run load for vcn0 in attr_data_get_block_locked() When a compressed or sparse attribute has its clusters frame-aligned, vcn is rounded down to the frame start using cmask, which can result in vcn != vcn0. In this case, vcn and vcn0 may reside in different attribute segments. The code already handles the case where vcn is in a different segment by loading its runs before allocation. However, it fails to load runs for vcn0 when vcn0 resides in a different segment than vcn. This causes run_lookup_entry() to return SPARSE_LCN for vcn0 since its segment was never loaded into the in-memory run list, triggering the WARN_ON(1). Fix this by adding a missing check for vcn0 after the existing vcn segment check. If vcn0 falls outside the current segment range [svcn, evcn1), find and load the attribute segment containing vcn0 before performing the run lookup. The following scenario triggers the bug: attr_data_get_block_locked() vcn = vcn0 & cmask <- vcn != vcn0 after frame alignment load runs for vcn segment <- vcn0 segment not loaded! attr_allocate_clusters() <- allocation succeeds run_lookup_entry(vcn0) <- vcn0 not in run -> SPARSE_LCN WARN_ON(1) <- bug fires here!

  6. CVE-2026-43119 5.5 Moyenne

    Linux · Linux linux kernel

    In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_sync: annotate data-races around hdev->req_status __hci_cmd_sync_sk() sets hdev->req_status under hdev->req_lock: hdev->req_status = HCI_REQ_PEND; However, several other functions read or write hdev->req_status without holding any lock: - hci_send_cmd_sync() reads req_status in hci_cmd_work (workqueue) - hci_cmd_sync_complete() reads/writes from HCI event completion - hci_cmd_sync_cancel() / hci_cmd_sync_cancel_sync() read/write - hci_abort_conn() reads in connection abort path Since __hci_cmd_sync_sk() runs on hdev->req_workqueue while hci_send_cmd_sync() runs on hdev->workqueue, these are different workqueues that can execute concurrently on different CPUs. The plain C accesses constitute a data race. Add READ_ONCE()/WRITE_ONCE() annotations on all concurrent accesses to hdev->req_status to prevent potential compiler optimizations that could affect correctness (e.g., load fusing in the wait_event condition or store reordering).

  7. CVE-2026-31703 7.8 Élevée

    Linux · Red Hat Enterprise Linux 10 · Red Hat Enterprise Linux 6 · Red Hat Enterprise Linux 7

    In the Linux kernel, the following vulnerability has been resolved: writeback: Fix use after free in inode_switch_wbs_work_fn() inode_switch_wbs_work_fn() has a loop like: wb_get(new_wb); while (1) { list = llist_del_all(&new_wb->switch_wbs_ctxs); /* Nothing to do? */ if (!list) break; ... process the items ... } Now adding of items to the list looks like: wb_queue_isw() if (llist_add(&isw->list, &wb->switch_wbs_ctxs)) queue_work(isw_wq, &wb->switch_work); Because inode_switch_wbs_work_fn() loops when processing isw items, it can happen that wb->switch_work is pending while wb->switch_wbs_ctxs is empty. This is a problem because in that case wb can get freed (no isw items -> no wb reference) while the work is still pending causing use-after-free issues. We cannot just fix this by cancelling work when freeing wb because that could still trigger problematic 0 -> 1 transitions on wb refcount due to wb_get() in inode_switch_wbs_work_fn(). It could be all handled with more careful code but that seems unnecessarily complex so let's avoid that until it is proven that the looping actually brings practical benefit. Just remove the loop from inode_switch_wbs_work_fn() instead. That way when wb_queue_isw() queues work, we are guaranteed we have added the first item to wb->switch_wbs_ctxs and nobody is going to remove it (and drop the wb reference it holds) until the queued work runs.

  8. CVE-2026-50252 9.3 Critique

    NLnet Labs Unbound · Nlnetlabs unbound

    In NLnet Labs Unbound 1.4.22 up to and including 1.25.1, UDP source port is randomized and intended to serve as a secret value that increases the entropy of DNS transactions. When resolver load balancing policies depend on the source port while their outcome is revealed this secrecy is undermined. The vulnerability arises when the load balancing policy is consistent with respect to the incoming source UDP port and IP address while heavily depending on the incoming source UDP port as a randomization source. When the SO_REUSEPORT configuration option is enabled ('so-reuseport: yes') in Unbound (by default), it meets these conditions, making it vulnerable for DNS cache poisoning attacks. Upon startup, Unbound randomly partitions the available UDP source port space into disjoint subsets of (almost) equal size, assigning each subset to a specific worker thread. When an incoming DNS query is received, the kernel’s SO_REUSEPORT load balancing mechanism deterministically assigns the query to a socket associated with a particular thread. All outgoing DNS queries generated during the resolution of that request use source ports selected exclusively from the port subset assigned to the corresponding thread. Since these port subsets are disjoint across threads, the source port observed in a resolver’s outgoing query to an authoritative name server serves as a reliable indicator of the worker thread that processed the original client query. A malicious actor can acquire the mapping between incoming UDP source ports (for a given fixed source IP address) and Unbound worker threads and leverage it to conduct DNS cache poisoning attacks by effectively lowering the random port population per thread.

  9. CVE-2026-50251 5.3 Moyenne

    NLnet Labs Unbound · Nlnetlabs unbound

    In NLnet Labs Unbound up to and including version 1.25.1, when 'unwanted-reply-threshold' is enabled (set to any value greater than zero), glue records of 0.0.0.0/::0 can short-circuit Unbound, on systems that can direct such traffic, by issuing DNS queries and receiving seemingly unwanted replies since the remote IP does not match the original source IP of 0.0.0.0/::0. This behavior keeps on looping for the glue records and pushing the counter to the configured 'unwanted-reply-threshold' that triggers a defensive cache clear. A malicious actor who controls a delegation that returns in-bailiwick glue of 0.0.0.0/::0 can drive the counter to the limit of 'unwanted-reply-threshold' to the threshold and trigger a cache clean of the message and rrset caches; at will, indefinitely, without sending a single spoofed packet. The iterator uses the 0.0.0.0/::0 glue, and a system that can route this (e.g., Linux kernel routes the datagram over loopback), Unbound's own listener answers from 127.0.0.1. Because of the mismatch of 0.0.0.0 and 127.0.0.1, in this example, Unbound accounts the reply as an unwanted (probably spoofed) answer. The counter resets to zero on every cache flush, so the attack loops forever.

  10. CVE-2026-12217 7.8 Élevée

    DVDFab Virtual Drive

    A security vulnerability has been detected in DVDFab Virtual Drive 2.0.0.5. Impacted is an unknown function in the library dvdfabio.sys of the component Signed Kernel Driver. The manipulation leads to improper privilege management. An attack has to be approached locally. The exploit has been disclosed publicly and may be used. The vendor was contacted early about this disclosure but did not respond in any way.

  11. CVE-2026-24199 4.7 Moyenne

    NVIDIA GeForce · NVIDIA RTX, Quadro, NVS · NVIDIA Tesla · NVIDIA Guest driver

    NVIDIA Display Driver for Linux contains a vulnerability in a kernel module, where a user could cause a race condition by reordering compiler or processor memory instructions. A successful exploit of this vulnerability might lead to denial of service.

  12. CVE-2026-24194 7.8 Élevée

    NVIDIA GeForce · NVIDIA RTX, Quadro, NVS · NVIDIA Tesla · NVIDIA Guest driver

    NVIDIA Display Driver for Linux contains a vulnerability in a kernel mode layer handler, where a user could cause improper permission handling. A successful exploit of this vulnerability might lead to denial of service, escalation of privileges, information disclosure, data tampering, and code execution.

  13. CVE-2026-24190 7.8 Élevée

    NVIDIA GeForce · NVIDIA RTX, Quadro, NVS · NVIDIA Tesla · Nvidia gpu display driver

    NVIDIA Display Driver for Windows and Linux contains a vulnerability in the kernel mode layer, where a user could cause improper access to GPU resources. A successful exploit of this vulnerability might lead to denial of service, escalation of privileges, information disclosure, data tampering, and code execution.

  14. CVE-2025-33221 6.0 Moyenne

    NVIDIA GeForce · NVIDIA RTX, Quadro, NVS · NVIDIA Tesla · NVIDIA Guest driver

    NVIDIA Display Driver for Windows and Linux contains a vulnerability in the kernel driver, where a user could cause an incorrect permission assignment for a critical resource. A successful exploit of this vulnerability might lead to data tampering and denial of service.

  15. CVE-2026-48697 7.4 Élevée

    Pavel-odintsov fastnetmon

    FastNetMon Community Edition through 1.2.9 does not verify TLS certificates on outbound HTTPS connections. The execute_web_request_secure() function in src/fast_library.cpp creates a boost::asio::ssl::context with tls_client mode and calls set_default_verify_paths() to load CA certificates, but never calls set_verify_mode(boost::asio::ssl::verify_peer). Without this call, OpenSSL performs the TLS handshake without validating the server's certificate chain, making all HTTPS connections vulnerable to man-in-the-middle attacks. This function is used for telemetry reporting to community-stats.fastnetmon.com, which sends system information including CPU model, kernel version, traffic statistics, and software configuration. An attacker can intercept and modify this data or redirect it to a malicious server.

  16. CVE-2026-8235 5.5 Moyenne

    8421bit MiniClaw

    A vulnerability was detected in 8421bit MiniClaw 0.8.0/0.9.0. This issue affects the function resolveSkillScriptPath of the file src/kernel.ts of the component System Command Handler. The manipulation results in os command injection. The exploit is now public and may be used. The patch is identified as 223c16a1088e138838dcbd18cd65a37c35ac5a84. It is best practice to apply a patch to resolve this issue.