Export limit exceeded: 378796 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Export limit exceeded: 378796 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (378796 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-72078 | 1 Linux | 1 Linux Kernel | 2026-08-18 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: Input: ims-pcu - validate control endpoint type The driver currently assumes that the first endpoint of the control interface is an interrupt IN endpoint without verifying it. A malicious device could provide a different endpoint type, which would then be passed to usb_fill_int_urb(), potentially leading to kernel warnings or undefined behavior. Verify that the control endpoint is an interrupt IN endpoint. | ||||
| CVE-2026-72080 | 1 Linux | 1 Linux Kernel | 2026-08-18 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: fs/resctrl: Fix use-after-free during unmount During unmount or failure teardown all mon_data structures that contain monitoring event file private data are freed after which kernfs nodes are removed. However, the RDT_DELETED flag is never set for the statically allocated default resource group. A concurrent reader of an event file associated with the default resource group may, after dropping kernfs active protection, block on rdtgroup_mutex while unmount proceeds to free the file private data and destroy the kernfs node without waiting for the reader. When the mutex is released, the reader wakes up, observes that RDT_DELETED is not set for the default group, and dereferences the already-freed file private data. The scenario can be depicted as follows: CPU0 CPU1 /* * Default resource group's * monitoring data accessible via * kernfs file with kernfs_node::priv * pointing to a struct mon_data. * User opens the file for reading. */ rdtgroup_mondata_show() /* arch encounters fatal error */ rdtgroup_kn_lock_live() resctrl_exit() atomic_inc(&rdtgroup_default.waitcount) cpus_read_lock() kernfs_break_active_protection(kn) mutex_lock(&rdtgroup_mutex) cpus_read_lock() resctrl_fs_teardown() mutex_lock(&rdtgroup_mutex) rmdir_all_sub() mon_put_kn_priv() /* Delete all mon_data structures */ rdtgroup_destroy_root() kernfs_destroy_root() rdtgroup_default.kn = NULL mutex_unlock(&rdtgroup_mutex) /* * rdtgroup_default.flags is empty so * rdtgroup_kn_lock_live() returns * &rdtgroup_default */ md = of->kn->priv; /* md points to freed mon_data */ Set RDT_DELETED for the default group unconditionally since the flag does not lead to the freeing of this statically allocated group. Do not allow a new resctrl mount if there are any waiters on default group of previous mount. A new mount will re-initialize the default group that would appear to waiters from previous mount as though the default group is accessible causing them to access the mon_data structures from the previous mount that have been removed. | ||||
| CVE-2026-72082 | 1 Linux | 1 Linux Kernel | 2026-08-18 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: scsi: elx: efct: Fix refcount leak in efct_hw_io_abort() When efct_hw_reqtag_alloc() fails in efct_hw_io_abort(), the error path returns -ENOSPC without releasing the reference obtained via kref_get_unless_zero() earlier in the function. All other error paths correctly drop the reference. This causes a permanent reference leak on the io_to_abort object. Additionally, the abort_in_progress flag is left set to true on this path, which means future abort attempts for the same I/O will immediately return -EINPROGRESS even though the abort was never submitted, effectively blocking recovery. Fix this by adding the missing kref_put() call and reset abort_in_progress to false, matching the cleanup done in the efct_hw_wq_write() failure path below. | ||||
| CVE-2026-72096 | 1 Linux | 1 Linux Kernel | 2026-08-18 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: dm-verity: make error counter atomic The error counter "v->corrupted_errs" was not atomic, thus it could be subject to race conditions. The call to dm_audit_log_target("max-corrupted-errors") may be skipped due to the races. | ||||
| CVE-2026-72109 | 1 Linux | 1 Linux Kernel | 2026-08-18 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: net: sparx5: unregister blocking notifier on init failure sparx5_register_notifier_blocks() registers the switchdev blocking notifier before allocating the ordered workqueue. If the workqueue allocation fails, the error path unregisters the switchdev and netdevice notifiers, but leaves the blocking notifier registered. Add a separate error label for the workqueue allocation failure path and unregister the switchdev blocking notifier there. | ||||
| CVE-2026-72361 | 1 Linux | 1 Linux Kernel | 2026-08-18 | 7.0 High |
| In the Linux kernel, the following vulnerability has been resolved: drm/xe/hw_engine: Fix double-free of managed BO in error path The error path in hw_engine_init() explicitly frees a BO allocated with xe_managed_bo_create_pin_map() via xe_bo_unpin_map_no_vm(). Since the managed BO already has a devm cleanup action registered, this causes a double-free when devm unwinds during probe failure. Remove the explicit free and let devm handle it, consistent with all other xe_managed_bo_create_pin_map() callers. (cherry picked from commit e459a3bdeb117be496d7f229e2ea1f6c9fe4080b) | ||||
| CVE-2026-72411 | 1 Linux | 1 Linux Kernel | 2026-08-18 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: net: dsa: mxl862xx: fix use-after-free of DSA ports in crc_err_work Upon an MDIO CRC error mxl862xx_crc_err_work_fn() walks the DSA ports and closes the CPU port conduits: dsa_switch_for_each_cpu_port(dp, priv->ds) dev_close(dp->conduit); mxl862xx_remove() unregisters the switch before cancelling this work: set_bit(MXL862XX_FLAG_WORK_STOPPED, &priv->flags); cancel_delayed_work_sync(&priv->stats_work); dsa_unregister_switch(ds); mxl862xx_host_shutdown(priv); dsa_unregister_switch() frees the dsa_port objects. If a CRC error schedules the work during teardown it can run after the ports have been freed and dereference freed memory. Guard the port walk with MXL862XX_FLAG_WORK_STOPPED, which is already set before dsa_unregister_switch(). DSA tears the ports down under rtnl_lock(), so checking the flag under rtnl_lock() means the work either runs before teardown and sees valid ports, or runs afterwards, observes the flag and skips the walk. This mirrors the host_flood_work handler, which skips torn-down ports under rtnl_lock(). | ||||
| CVE-2026-72445 | 1 Linux | 1 Linux Kernel | 2026-08-18 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: qcom: clear opened when stream enable fails On enable, subs->opened is set before the service_interval is validated; an invalid interval jumps to the response label without clearing it, so the substream is wedged at -EBUSY until a disable or disconnect. Clear subs->opened on the enable error path. | ||||
| CVE-2026-72486 | 1 Linux | 1 Linux Kernel | 2026-08-18 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: mailbox: mtk-adsp: fix UAF during device teardown When the SOF audio driver fails to initialize (e.g. firmware boot timeout), its devres unwind frees the snd_sof_dev object that the mailbox client (mtk-adsp-ipc) reaches via chan->cl->rx_callback. The mtk-adsp-mailbox shutdown clears the mailbox command registers but leaves the IRQ line unmasked, so a late interrupt can still queue a threaded handler after mbox_free_channel() had cleared chan->cl, and mbox_chan_received_data() would then trigger UAF: BUG: KASAN: slab-use-after-free in sof_ipc3_validate_fw_version sof_ipc3_validate_fw_version sof_ipc3_do_rx_work sof_ipc3_rx_msg mt8196_dsp_handle_request mtk_adsp_ipc_recv mbox_chan_received_data mtk_adsp_mbox_isr irq_thread_fn Freed by task ...: kfree devres_release_all really_probe ... (sof-audio-of-mt8196 probe failure) The crash was observed roughly three seconds after the failed probe. disable_irq() in shutdown and enable_irq() in startup. disable_irq() also waits for any in-flight interrupts, so by the time mbox_free_channel() proceeds to clear chan->cl no rx_callback can run. In addition, request the IRQ with IRQF_NO_AUTOEN so it stays masked between probe and the first client bind — otherwise an early interrupt can crash on chan->cl == NULL in mbox_chan_received_data(). | ||||
| CVE-2026-74448 | 1 Linux | 1 Linux Kernel | 2026-08-18 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: fix QID bit leak in pqm_create_queue() When MES is enabled and amdgpu_amdkfd_alloc_kernel_mem() fails during the first queue creation for a process, pqm_create_queue() returns early via 'return retval' without going through the err_create_queue cleanup label. This means clear_bit(*qid, pqm->queue_slot_bitmap) is never called, leaving the reserved QID bit permanently set in queue_slot_bitmap. Over time this leaks QID slots, potentially exhausting all available queue slots. Fix this by replacing 'return retval' with 'goto err_allocate_pqn' so that clear_bit() is always called on the error path without touching the uninitialized pqn pointer. AILIKFD-813 (cherry picked from commit a107f74c38edbb80d6ab64dcaeeb292c14e9779f) | ||||
| CVE-2026-74475 | 1 Linux | 1 Linux Kernel | 2026-08-18 | 10 Critical |
| In the Linux kernel, the following vulnerability has been resolved: vxlan: use neigh_ha_snapshot() in route_shortcircuit() The neighbour hardware address n->ha can be updated asynchronously by the neighbour subsystem, protected by n->ha_lock seqlock. Reading n->ha without holding the seqlock loop can lead to torn reads or reading a partially updated MAC address. Use neigh_ha_snapshot() in route_shortcircuit() to safely copy n->ha under read_seqbegin()/read_seqretry() lock protection before using it. Note that arp_reduce() and neigh_reduce() seem to have the same issue left for future patches. | ||||
| CVE-2026-74508 | 1 Linux | 1 Linux Kernel | 2026-08-18 | 8.8 High |
| In the Linux kernel, the following vulnerability has been resolved: Bluetooth: HIDP: reject frames without a transaction header hidp_recv_ctrl_frame() and hidp_recv_intr_frame() read skb->data[0] before checking that the L2CAP SDU contains a transaction header. A connected HIDP peer can send an empty basic-mode SDU and make both paths use an uninitialized byte from skb tailroom. KMSAN reports the use in hidp_session_run(), with the uninitialized value originating in __alloc_skb() through vhci_write(). The control path produces two reports and the interrupt path produces one. The byte can also be controlled by a malformed lower-layer packet. If an HCI ACL packet contains an L2CAP PDU with a declared zero-length payload followed by an extra 0x15 byte, l2cap_recv_acldata() reduces skb->len to the declared PDU length before dispatch. The current HIDP path nevertheless consumes the extra byte as HIDP_TRANS_HID_CONTROL | HIDP_CTRL_VIRTUAL_CABLE_UNPLUG and terminates the HIDP session. With this change, the same packet is discarded and a subsequent feature report request succeeds. Pull the transaction header with skb_pull_data() and discard frames that do not contain it. | ||||
| CVE-2026-74528 | 1 Linux | 1 Linux Kernel | 2026-08-18 | 8 High |
| In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_sync: hold conn in hci_past_sync() callback Avoids giving freed pointers to hci_conn_valid(), which kmalloc may have reused. Hold refcount to avoid that. | ||||
| CVE-2026-74555 | 1 Linux | 1 Linux Kernel | 2026-08-18 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: scsi: libsas: Fix HA resume deadlock and hisi_sas disk-wake race Commit fbefe22811c3 ("scsi: libsas: Don't always drain event workqueue for HA resume") introduced sas_resume_ha_no_sync() to avoid a deadlock: the PHYE_RESUME_TIMEOUT handler, running on the HA event workqueue, calls sas_deform_port() -> sas_destruct_devices(), which removes SCSI devices and waits for the host to become runtime-active. But the host cannot resume until sas_resume_ha() -> sas_drain_work() returns, and the drain is blocked on that very handler. However skipping the drain reintroduces a race: hisi_sas returns from resume before all PHY UP work and libsas discovery work finish. The controller may then autosuspend while disks are still waking up. The disks issue IO to a suspended controller, the IO fails, and the disks get disabled. Fix the deadlock at its source by moving the PHYE_RESUME_TIMEOUT notification to after sas_drain_work(). By then the host resume is about to complete, so device removal through device_link no longer blocks on the resume and the cycle is broken. With the deadlock gone, restore sas_resume_ha() (the draining variant) in hisi_sas and remove sas_resume_ha_no_sync(). The reorder is safe for the other libsas consumers (isci, pm8001, aic94xx, mvsas). During suspend, sas_suspend_devices() calls sas_notify_lldd_dev_gone() for each device, which sets dev->lldd_dev to NULL. When scsi_unblock_requests re-enables I/O in resume, any I/O to a timed-out phy's disk is immediately rejected by the LLDD before reaching hardware: isci returns SAS_DEVICE_UNKNOWN (mapped to DID_BAD_TARGET), and pm8001 returns SAS_PHY_DOWN (mapped to DID_NO_CONNECT). Both complete directly via scsi_done() without entering SCSI EH. This is identical in both the old and new ordering since lldd_dev_gone runs during suspend, before resume. The reorder only affects when the PHYE_RESUME_TIMEOUT handler runs (synchronized by sas_drain_work() vs. asynchronous after resume returns), not whether I/O can reach the device. aic94xx and mvsas do not register any PM ops and never reach this code path. | ||||
| CVE-2026-74561 | 1 Linux | 1 Linux Kernel | 2026-08-18 | 8.8 High |
| In the Linux kernel, the following vulnerability has been resolved: nexthop: avoid unlocked f6i_list walk in nh_rt_cache_flush nh_rt_cache_flush() walks nh->f6i_list during an RTNL-serialized nexthop replace without holding nh->lock, racing the unlocked IPv6 route add/delete that mutate the list under nh->lock and free fib6_info entries (nh_rt_cache_flush() is inlined into rtm_new_nexthop()): BUG: KASAN: slab-use-after-free in nh_rt_cache_flush (net/ipv4/nexthop.c:2243) Read of size 8 at addr ffff888012953e18 by task exploit/146 nh_rt_cache_flush (net/ipv4/nexthop.c:2243) replace_nexthop (net/ipv4/nexthop.c:2610) rtm_new_nexthop (net/ipv4/nexthop.c:3323) rtnetlink_rcv_msg (net/core/rtnetlink.c:7076) Unlike the other f6i_list walks, this one bumps each route's sernum via fib6_update_sernum_upto_root(), which needs tb6_lock; taking nh->lock around it would invert the established tb6_lock -> nh->lock order and deadlock. As the only purpose is to invalidate cached dsts, bump the IPv6 sernum for the whole netns with rt_genid_bump_ipv6() instead, mirroring the rt_cache_flush() already done for IPv4 just above. | ||||
| CVE-2026-74562 | 1 Linux | 1 Linux Kernel | 2026-08-18 | 8.8 High |
| In the Linux kernel, the following vulnerability has been resolved: nexthop: take nh->lock for f6i_list walks in replace check and notify fib6_check_nh_list() and __nexthop_replace_notify() walk nh->f6i_list during an RTNL-serialized nexthop replace without holding nh->lock. IPv6 RTM_NEWROUTE/RTM_DELROUTE run without RTNL and mutate that list under nh->lock (fib6_add_rt2node_nh(), fib6_purge_rt()), so both walks race a concurrent route delete that unlinks and frees a fib6_info: BUG: KASAN: slab-use-after-free in rt6_fill_node.isra.0 (net/ipv6/route.c:5799) Read of size 4 at addr ffff888014607e64 by task exploit/143 rt6_fill_node.isra.0 (net/ipv6/route.c:5799) fib6_rt_update (net/ipv6/route.c:6412) __nexthop_replace_notify (net/ipv4/nexthop.c:2542) rtm_new_nexthop (net/ipv4/nexthop.c:2554) rtnetlink_rcv_msg (net/core/rtnetlink.c:7076) BUG: KASAN: slab-use-after-free in fib6_check_nh_list (net/ipv4/nexthop.c:1605) Read of size 8 at addr ffff888014a7d068 by task exploit/142 fib6_check_nh_list (net/ipv4/nexthop.c:1605) rtm_new_nexthop (net/ipv4/nexthop.c:2575) rtnetlink_rcv_msg (net/core/rtnetlink.c:7076) Both walks only read the entries and take no tb6_lock, so protect them with nh->lock; fib6_rt_update() uses gfp_any(), which returns GFP_ATOMIC under the lock. | ||||
| CVE-2026-74579 | 1 Linux | 1 Linux Kernel | 2026-08-18 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_payload: fix mask build for partial field offload nft_payload_offload_mask() builds the offload match mask for a payload expression that covers only part of a header field. For a partial IPv6 address match (field_len = 16, priv_len = 1) that shift is 1 << 120, which is undefined on the 32-bit int operand. It also trims only one word, so the remaining words stay 0xffffffff (and when priv_len is a multiple of 4 the trim is skipped entirely), leaving the mask covering more bytes than the rule matches. UBSAN: shift-out-of-bounds in net/netfilter/nft_payload.c:278:20 shift exponent 120 is too large for 32-bit type 'int' ... The match is byte-granular and struct nft_data is zero-initialised, so the correct mask is simply the first priv_len bytes set to 0xff. Set those bytes directly and drop the word/shift trimming; this removes the undefined shift and no longer over-masks the trailing bytes. | ||||
| CVE-2026-72083 | 1 Linux | 1 Linux Kernel | 2026-08-18 | 9.8 Critical |
| In the Linux kernel, the following vulnerability has been resolved: scsi: target: core: Fix iSCSI ISID use-after-free in REGISTER AND MOVE core_scsi3_emulate_pro_register_and_move() maps the PERSISTENT RESERVE OUT parameter list with transport_kmap_data_sg() and parses the destination TransportID with target_parse_pr_out_transport_id(). For an iSCSI TransportID (FORMAT CODE 01b), iscsi_parse_pr_out_transport_id() returns the ISID in iport_ptr as a raw pointer into that mapped buffer. The function then unmaps the buffer with transport_kunmap_data_sg() before dereferencing iport_ptr in strcmp(), __core_scsi3_locate_pr_reg() and core_scsi3_alloc_registration(). When the parameter list spans more than one page (PARAMETER LIST LENGTH > 4096), transport_kmap_data_sg() uses vmap() and transport_kunmap_data_sg() does vunmap(), so the kernel virtual address backing iport_ptr is torn down and every subsequent dereference is a use-after-free read of the unmapped region. Keep the parameter list mapped until iport_ptr is no longer needed: drop the early transport_kunmap_data_sg() and unmap once on the success path, right before returning. The error paths already unmap through the existing "if (buf) transport_kunmap_data_sg(cmd)" at the out: label, which now runs on every post-map error exit because buf is no longer cleared early. Only reads of the mapping happen while spinlocks are held; the map and unmap calls remain outside any lock. The sibling caller core_scsi3_decode_spec_i_port() already uses the buffer before unmapping it and is left unchanged. | ||||
| CVE-2026-72085 | 1 Linux | 1 Linux Kernel | 2026-08-18 | 9.3 Critical |
| In the Linux kernel, the following vulnerability has been resolved: scsi: xen: scsiback: Free unsubmitted command instead of double-putting it scsiback_get_pend_req() obtains a command tag and returns a vscsibk_pend whose embedded se_cmd has only been memset to 0, so its cmd_kref is 0; the se_cmd is initialised (kref_init() via target_init_cmd()) only later, in scsiback_cmd_exec(), on the successful VSCSIIF_ACT_SCSI_CDB path. The two error paths in scsiback_do_cmd_fn() taken before the command is submitted -- a failed scsiback_gnttab_data_map() and an unknown ring_req.act -- call transport_generic_free_cmd(&pending_req->se_cmd, 0), which kref_put()s a refcount of 0. That underflows it ("refcount_t: underflow; use-after-free") and, as the release function is not run, leaks the command tag. Impact: a pvSCSI guest can leak every command tag of a LUN's session, stopping the LUN, by submitting requests with a bad grant reference or an unknown request type; under panic_on_warn the refcount underflow panics the host. Add a helper that just returns the tag with target_free_tag() and sends the error response. It frees the tag while the v2p reference still pins the session, and snapshots the response fields beforehand because freeing the tag can let another ring reuse the pending_req slot. | ||||
| CVE-2026-72088 | 1 Linux | 1 Linux Kernel | 2026-08-18 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: scsi: hpsa: Fix DMA mapping leak on IOACCEL2 reset path If phys_disk->in_reset is set, the function returns directly without undoing the resources acquired for the command. Add the missing error cleanup by unmapping the IOACCEL2 SG chain block when needed, unmapping the SCSI command, and dropping the outstanding IOACCEL command count before returning. | ||||