Export limit exceeded: 399604 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (1029 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-98007 | 1 Linux | 1 Linux Kernel | 2026-09-26 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: bpf: Reject non-scalar bpf_loop iteration counts bpf_loop() declares its nr_loops argument as ARG_ANYTHING. Privileged programs may pass pointer values to such arguments, so check_func_arg() lets a pointer-valued R1 reach the helper-specific checks. Since commit bb124da69c47 ("bpf: keep track of max number of bpf_loop callback iterations"), the verifier marks R1 precise and reads its upper bound to limit callback simulation. Precision backtracking only accepts scalar registers, so passing a pointer instead triggers the "backtracking misuse" verifier warning. Kernels with panic_on_warn enabled subsequently panic. Introduce ARG_SCALAR for helper arguments that only accept scalar values and use it for bpf_loop() nr_loops. Generic helper argument validation then rejects pointers before loop inlining and precision processing. | ||||
| CVE-2026-97566 | 1 Linux | 1 Linux Kernel | 2026-09-25 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: mptcp: pm: kernel: drop pending ADD_ADDR when removing ID0 The in-kernel MPTCP path manager can leave a stale ADD_ADDR announcement entry alive when removing the id 0 endpoint. This happens because the id 0 removal path does not tear down pending announcements, unlike the non-zero id path. When the PM later reselects id 0 after adding another signal endpoint, it finds the stale anno_list entry and hits WARN_ON_ONCE(mptcp_pm_is_kernel()) in mptcp_pm_announced_alloc(). Root cause: asymmetry between removal paths. - Non-zero id path: mptcp_nl_remove_subflow_and_signal_addr() calls mptcp_pm_remove_announced() to clean up. - Id 0 path: mptcp_nl_remove_id_zero_address() skips cleanup entirely. Fix by making the id 0 path symmetric: call mptcp_pm_announced_remove() and decrement add_addr_signaled before queuing the RM_ADDR. Subtle detail: signal endpoints are stored in anno_list with port 0, but msk_local carries the connection's local port. In other words, entries linked to ID0 paths should have port == 0. A follow-up patch will ensure that. mptcp_pm_announced_remove() uses use_port=true for comparison. So clear the port before the lookup. | ||||
| CVE-2026-97975 | 1 Linux | 1 Linux Kernel | 2026-09-25 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_sysfs: Fix NULL pointer dereference in device_del() A NULL pointer dereference in klist_put() occurs when a child device (such as a BNEP network device in bnep_session) is concurrently being unregistered while hci_conn_del_sysfs() reparents child devices. This is caused by a race condition between hci_conn_del_sysfs() and concurrent child device unregistration (e.g. bnep_session calling unregister_netdev()). During device unregistration, device_del() snapshots a non-NULL parent pointer. Concurrently, hci_conn_del_sysfs() finds the child device using device_find_any_child() and calls device_move() to reparent it to NULL, which removes the node from its parent's klist and clears knode_parent. Subsequently, device_del() calls klist_del(&dev->p->knode_parent) using the stale parent snapshot, causing klist_put() to dereference knode_klist(n)->put on an already removed node, resulting in a NULL pointer dereference. This race was introduced by commit 27aabf27fd01 ("Bluetooth: fix use-after-free in device_for_each_child()"), which replaced device_find_child(..., __match_tty) with device_find_any_child() in hci_conn_del_sysfs(). That change was intended to avoid a use-after-free where conn->dev outlived its parent hdev->dev when child devices held references to conn->dev, because conn->dev only held a reference to hdev->dev while registered in sysfs. Fix the issue properly by taking an explicit reference to the parent device with get_device(&hdev->dev) in hci_conn_init_sysfs() and dropping it with put_device(parent) in bt_link_release() when the conn device is freed. This ensures that hdev->dev remains valid for the entire lifecycle of conn->dev, resolving the underlying use-after-free. With the parent reference held properly, restore the __match_tty filter in hci_conn_del_sysfs() so that device_move() is only invoked on persistent RFCOMM TTY devices as originally intended, eliminating the race condition with unregistering network devices. | ||||
| CVE-2026-97534 | 1 Linux | 1 Linux Kernel | 2026-09-25 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: f2fs: accurately adjust free_sections during free_segment_range In free_segment_range(), MAIN_SECS(sbi) is temporarily reduced by `secs` to restrict block allocation to the safe remaining main area while valid blocks in the truncated range are evacuated by GC. However, FREE_I(sbi)->free_sections tracks the total number of free sections across the whole filesystem. If any sections within the truncated range were already free upon entering free_segment_range(), failing to deduct them from free_sections causes the filesystem to overestimate available free sections in the active, reduced main area. This leads to inconsistent free section accounting during GC data migration and can trigger unexpected allocation failures or assertion errors when space is tight. Fix this by calculating the number of already-free sections in the truncated range, deducting them from free_sections upon entering free_segment_range(), and restoring them on exit. | ||||
| CVE-2026-98148 | 1 Linux | 1 Linux Kernel | 2026-09-25 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: drm/gud: validate GUD_ROTATION_0 is present in supported rotations The rotation argument to drm_plane_create_rotation_property() is set to DRM_MODE_ROTATE_0, and the device reported rotation bitmask is used as the supported_rotations argument. The driver never validates that GUD_ROTATION_0 is present, so a device that omits it from its GUD_PROPERTY_ROTATION triggers the WARN_ON(rotation & ~supported_rotations) in drm_plane_create_rotation_property() Fix this by skipping the creation of rotation property if the device doesn't have the GUD_ROTATION_0 bit | ||||
| CVE-2026-98151 | 1 Linux | 1 Linux Kernel | 2026-09-25 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: bpf: Fix REG INVARIANTS VIOLATION on speculative pointer arithmetic Take the following unprivileged program as an example: r0 = bpf_map_lookup_elem(...) /* PTR_TO_MAP_VALUE, offset 0 */ ... 14: r0 += r1 /* r1 is a bounded scalar */ 15: r9 = r0 Loading it triggers a verifier warning from reg_bounds_sanity_check(): verifier bug: REG INVARIANTS VIOLATION (alu): const subreg tnum out of sync with range bounds r64={.base=0x0, .size=0x0} r32={.base=0x0, .size=0xffffffff} var_off=(0x0, 0x0) What happens: 1. Processing insn 14 (r0 += r1) in adjust_ptr_min_max_vals(), the new offset is computed into dst_reg's var_off and 32/64-bit ranges. 2. Because pointer registers do not track 32-bit subregister bounds, __mark_reg32_unbounded() first sets r32 to the full range; r32 is re-derived from the offset at the end of the function by reg_bounds_sync(). 3. On the unprivileged path, sanitize_ptr_alu() is called and, via sanitize_speculative_path() -> push_stack(), snapshots the current register state and schedules the next instruction (insn 15) to be verified directly as a speculative path. 4. That snapshot is taken between step 2 and the final reg_bounds_sync(): at this point dst_reg's var_off still holds the (const) original offset while r32 has just been blanked to the full range, i.e. the two are out of sync. When the speculative path later verifies insn 15 (r9 = r0), the inconsistent state reaches reg_bounds_sanity_check() and trips the warning. var_off and the 32-bit range must always be consistent. There are two ways to keep the snapshot consistent: 1. sync var_off and r32 before the snapshot so they match, or 2. leave r32 at its original (already consistent) value and blank it only after the snapshot. The whole point of sanitize_ptr_alu() is to insert a harmless masking sequence that keeps the access in bounds under speculation, so the state it snapshots should faithfully represent that. Take approach 2: move __mark_reg32_unbounded() to after sanitize_ptr_alu(), so the speculative snapshot keeps the pointer's original, consistent r32. The non-speculative path is unchanged: r32 is still blanked before the offset is applied and re-derived by reg_bounds_sync(). | ||||
| CVE-2026-97443 | 1 Linux | 1 Linux Kernel | 2026-09-25 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: perf/ftrace: Fix WARNING in __unregister_ftrace_function perf_ftrace_function_unregister() unconditionally calls unregister_ftrace_function() without checking whether the ftrace_ops was ever successfully registered. This triggers a WARN_ON in __unregister_ftrace_function() when the ops doesn't have FTRACE_OPS_FL_ENABLED set. This can happen during perf_event_alloc() error cleanup when perf_trace_destroy() is called via __free_event() on an event whose ftrace_ops registration failed or was already torn down by perf_try_init_event()'s err_destroy path. The call path is: perf_event_alloc() error cleanup -> __free_event() -> event->destroy() [tp_perf_event_destroy] -> perf_trace_destroy() -> perf_trace_event_close() -> TRACE_REG_PERF_CLOSE -> perf_ftrace_function_unregister() -> unregister_ftrace_function() -> __unregister_ftrace_function() -> WARN_ON(!(ops->flags & FTRACE_OPS_FL_ENABLED)) Fix this by checking FTRACE_OPS_FL_ENABLED before attempting to unregister. If the ops is not enabled, just free the filter and return success. | ||||
| CVE-2026-93275 | 1 Linux | 1 Linux Kernel | 2026-09-25 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: perf/x86/intel/pt: Fix stop/start with no update If pt_event_stop() is called without PERF_EF_UPDATE flag, then perf_aux_output_end() is not called. A subsequent call to pt_event_start() will call perf_aux_output_begin() again which violates the rule against nesting and triggers a WARNING in perf_aux_output_begin(). Originally, pt_event_stop() was never called without PERF_EF_UPDATE, because the only code paths to do so are from event overflow, and Intel PT does not do that. However the introduction of group throttling by commit 9734e25fbf5ae ("perf: Fix the throttle logic for a group") meant that an Intel PT event could be throttled if it was part of a group. Throttling calls PMU ->stop() / ->start() callbacks without flags. An example is when AUX area sampling is used. The following commands hit the issue: echo 10000 > /proc/sys/kernel/perf_event_max_sample_rate perf record -F32000 --aux-sample -e '{intel_pt//u,cycles:u}' \ -- bash -c 'for i in `seq 1 100000` ; do true ; done' Use PERF_HES_UPTODATE to track whether perf_aux_output_begin() and perf_aux_output_end() are balanced. A cleared PERF_HES_UPTODATE bit indicates that an AUX output context is still open. Amend pt_event_start() / pt_event_stop() accordingly so that begin/end stay balanced: - In non-snapshot mode, stop() always closes the buffer (the buffer may have run out of space, and that accounting is done by the update), so a following start() opens a fresh one as before. - In snapshot/overwrite mode, stop() without PERF_EF_UPDATE leaves the buffer open so that pt_event_snapshot_aux() can still copy from it, and start() then only re-enables tracing instead of calling perf_aux_output_begin() again. Note that pt_event_del() calls pt_event_stop() with PERF_EF_UPDATE flag set (as is required by the documentation), so a final call to perf_aux_output_end() is assured. | ||||
| CVE-2026-8843 | 1 Mongodb | 2 Mongodb, Mongodb Server | 2026-09-24 | 6.5 Medium |
| Creating a "2dsphere_bucket" index on a non-timeseries bucket collection will succeed, but any subsequent attempt to insert a document which triggers updating that index will crash the server. A similar issue occurs when creating "queryable_encrypted_range" indices. This issue affects MongoDB Server v7.0 versions prior to 7.0.32, v8.0 versions prior to 8.0.21 and v8.2 versions prior to 8.2.6 | ||||
| CVE-2026-95622 | 2026-09-24 | 6.5 Medium | ||
| A flaw was found in ModemManager. When parsing a Cell Broadcast Message, some 3GPP data-coding-scheme values (8-bit and reserved character sets) are not handled. The process hits a reachable assertion and aborts. An attacker who can deliver a crafted Cell Broadcast PDU over the radio network, or via a modem AT channel, can cause ModemManager to exit. Repeated aborts can exhaust systemd's default start limit and leave the service failed. | ||||
| CVE-2026-88341 | 1 Virustotal | 1 Yara | 2026-09-23 | 5.5 Medium |
| A reachable assertion vulnerability exists in YARA 4.5.8 when loading crafted .yrc compiled rule files. An attacker can provide a malicious file with an invalid arena configuration (num_buffers=0) that triggers an assertion failure in yr_arena_get_ptr(), causing the application to terminate. | ||||
| CVE-2026-94623 | 1 Vllm | 1 Vllm | 2026-09-22 | 7.5 High |
| vLLM through 0.29.0 contains a denial of service vulnerability in the NIXL connector's prefix caching implementation that fails to properly validate block counts across multi-prompt completion requests in prefill/decode disaggregated deployments. Attackers can trigger an assertion failure in NixlBaseConnectorWorker._apply_prefix_caching by submitting completion requests with multiple prompts of varying lengths, causing the decode worker to terminate and become unavailable until restarted. | ||||
| CVE-2026-93592 | 1 Vllm | 1 Vllm | 2026-09-22 | 7.5 High |
| vLLM versions before 0.28.0 fail to validate the lower bound of token IDs in the /v1/embeddings and /pooling endpoints, allowing unauthenticated attackers to crash the engine by submitting negative token IDs. A single request with a negative token ID triggers a CUDA device-side assertion that poisons the GPU context, causing all subsequent requests to fail until the process restarts. | ||||
| CVE-2026-91147 | 1 Redhat | 3 Enterprise Linux, Openshift Dev Spaces, Openshift Devspaces | 2026-09-22 | 5.9 Medium |
| A flaw was found in `cockpit-ws`. This vulnerability allows a remote, unauthenticated attacker to cause a Denial of Service (DoS) by sending a specially crafted request. When the `WebService.UrlRoot` is configured and a request is made to the exact URL-root prefix without a trailing slash, `cockpit-ws` can terminate unexpectedly. This issue leads to the unavailability of the Cockpit web service. | ||||
| CVE-2026-84450 | 1 Struktur | 1 Libheif | 2026-09-21 | 4.3 Medium |
| libheif is a HEIF and AVIF file format decoder and encoder. From 1.19.0 until 1.23.3, a crafted image item containing a clap property and an ispe width or height greater than INT32_MAX + 1 can reach crop calculations through heif_image_handle_get_image_tiling(). Box_clap::left_rounded() or Box_clap::top_rounded() passes the image dimension minus one to Fraction::Fraction(), whose uint32_t constructor uses an assertion as input validation, causing assert-enabled builds to abort. Release builds can instead compute invalid crop geometry, and the tiling API returns dimensions that the normal decode security limits reject. This issue is fixed in version 1.23.3. | ||||
| CVE-2026-75894 | 1 Osmocom | 1 Osmo-iuh | 2026-09-21 | 7.5 High |
| In osmo-iuh from 0.1.0 through 1.8.0 a reachable assertion was found in the ranap_handle_co_dt() function via a arbitrarily sized NAS-PDU that leads to process crash and remote denial of service. | ||||
| CVE-2026-79379 | 1 Bestechnic | 1 Bes2300 | 2026-09-21 | 6.5 Medium |
| A buffer overflow in the SBC_DecodeFrames() function of Bestechnic Co., Ltd BES2300 Bluetooth Audio SoC firmware v3.x and earlier and fixed in v.5.0 allows attackers to cause a Denial of Service (DoS) via sending a crafted frame. | ||||
| CVE-2026-91951 | 1 Freerdp | 1 Freerdp | 2026-09-20 | 6.5 Medium |
| FreeRDP versions before 3.31.0 contain an out-of-bounds write vulnerability in the urbdrc client channel's urb_send_current_frame_number_result() function. A malicious RDP server can send a crafted 28-byte USB redirection message to trigger a 4-byte write past the allocated 16-byte buffer, causing denial of service when verbose asserts are enabled. | ||||
| CVE-2026-73438 | 1 Arista | 1 Eos | 2026-09-18 | 5.3 Medium |
| On affected platforms running Arista EOS with Open Shortest Path First version 3 (OSPFv3) configured, an unauthenticated attacker on the same OSPFv3 broadcast domain can send a specially crafted set of packets that can cause the Ospf3 agent to restart unexpectedly. The crash results in the loss of all OSPFv3 adjacencies on the affected device and may disrupt routing across the broader OSPF domain until the agent recovers. This issue was reported externally by Dravanet Inc., and Arista is not aware of any malicious exploitation of this vulnerability in customer networks. | ||||
| CVE-2026-91961 | 1 Freerdp | 1 Freerdp | 2026-09-18 | 6.5 Medium |
| FreeRDP before 3.31.0 contains a denial-of-service vulnerability in the URBDRC control-transfer request path that fails to validate OutputBufferSize before forwarding to the libusb backend. A malicious RDP server can send a control-transfer request with OutputBufferSize set to 65536, triggering a reachable assertion that terminates the client process. | ||||