Export limit exceeded: 409245 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (25322 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-72037 | 1 Linux | 1 Linux Kernel | 2026-08-18 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: net: lan743x: Initialize eth_syslock spinlock before use lan743x_hardware_init() calls pci11x1x_strap_get_status() during the PCI11x1x probe sequence. That helper acquires the Ethernet subsystem hardware lock via lan743x_hs_syslock_acquire(), which relies on adapter->eth_syslock_spinlock to serialize access. The spinlock is currently initialized only after the strap status is read. With CONFIG_DEBUG_SPINLOCK enabled, taking the zeroed initialized spinlock can trip the spinlock debug check. Fix by initializing adapter->eth_syslock_spinlock before reading the strap status so the probe path never attempts to lock an uninitialized spinlock. | ||||
| CVE-2026-72043 | 1 Linux | 1 Linux Kernel | 2026-08-18 | 7.1 High |
| In the Linux kernel, the following vulnerability has been resolved: LoongArch: Fix missing dirty page tracking in {pte,pmd}_wrprotect() When hardware page table walker (PTW) is enabled on LoongArch, the CPU may set _PAGE_DIRTY directly in the page table entry during a write TLB miss, without going through the software TLB store handler. The software TLB store handler (tlbex.S:254) sets both _PAGE_DIRTY and_PAGE_MODIFIED together: ori t0, t0, (_PAGE_VALID | _PAGE_DIRTY | _PAGE_MODIFIED) Since hardware PTW only sets _PAGE_DIRTY, the software-only bit, i.e. _PAGE_MODIFIED is left unchanged. This creates a window where a PTE has _PAGE_DIRTY set (hardware knows the page is dirty) but _PAGE_MODIFIED clear (software is unaware). When fork()/clone() triggers copy-on-write, __copy_present_ptes() calls pte_wrprotect(), which unconditionally clears both the _PAGE_WRITE and _PAGE_DIRTY bits: pte_val(pte) &= ~(_PAGE_WRITE | _PAGE_DIRTY); Since _PAGE_MODIFIED was never set, the dirtiness information is lost completely. Subsequently, when memory pressure triggers page reclaim, page_mkclean() / try_to_unmap() sees the page as clean (i.e. pte_dirty() returns false) and the page may be freed without writeback, causing data corruption. Fix this by propagating the _PAGE_DIRTY bit to the _PAGE_MODIFIED bit in both pte_wrprotect() and pmd_wrprotect() before clearing writeable bits: if (pte_val(pte) & _PAGE_DIRTY) pte_val(pte) |= _PAGE_MODIFIED; The pmd_wrprotect() fix handles the CONFIG_TRANSPARENT_HUGEPAGE case, where pmd entries need the same treatment. This ensures the software dirty tracking bit (checked by pte_dirty() and pmd_dirty(), which read both the _PAGE_DIRTY and _PAGE_MODIFIED bits) is preserved across fork COW write-protection. The issue was found by the LTP madvise09 test case, which exercises page reclaim after "madvise(MADV_FREE), write and fork" operation sequence on private anonymous mappings. | ||||
| CVE-2026-72046 | 1 Linux | 1 Linux Kernel | 2026-08-18 | 9.8 Critical |
| In the Linux kernel, the following vulnerability has been resolved: gve: fix header buffer corruption with header-split and HW-GRO The DQO RX datapath programs a per-buffer-queue-descriptor header_buf_addr at post time and reads the split header back at completion time. Both the post and the read currently index the header buffer by queue position rather than by the buffer's identity: - post (gve_rx_post_buffers_dqo): header_buf_addr is computed from bufq->tail - read (gve_rx_dqo): the header is read from desc_idx (the completion queue head index) This relies on the buffer-queue index and the completion-queue index being equal for the start of every packet, i.e. on the device consuming posted buffers and returning completions in the exact same order. That assumption does not hold once HW-GRO is enabled with multiple flows: coalesced segments are accepted and completed in an order that may differ from the order buffers were posted, and segments from different flows may interleave. That results in two problems: 1. Wrong header slot on read. Because the read offset is derived from the completion index (desc_idx) while the device wrote the header to the address programmed for the buffer's buf_id, the driver can copy a header belonging to a different packet. This shows up as throughput drop (about 30% drop and large numbers of TCP retransmissions) with header-split and HW-GRO both enabled and many streams. 2. Header buffer reused while still owned by the device. The driver advances bufq->head by one per completion and re-posts buffers based on that. Arrival of N RX completions only guarantees that at least N RX buffer descriptors have been read by the device. It does not guarantee that the device has relinquished the ownership of all the buffers corresponding to those N descriptors. With out-of-order completions (e.g. the completion for a packet copied into buffer N arrives before the completion for a packet copied into buffer N-1), the driver can re-post and overwrite a header buffer that the device is still going to write into, corrupting the header of a packet whose completion has not yet been processed. Fix both issues by indexing the header buffer by buf_id on both the post and read paths. Reading from buf_id's slot is therefore always correct regardless of completion ordering (fixes problem 1). Indexing by buf_id also ties each header slot to the lifetime of its buffer state. A buffer state is only returned to the free/recycle lists when its own completion (buf_id) is processed, so its header slot can only be re-posted after the device is done with it. This makes header slot reuse safe under out-of-order completions (fixes problem 2). Allocate (gve_rx_alloc_hdr_bufs) and free (gve_rx_free_hdr_bufs) the header buffers based on num_buf_states to match the buf_id indexing. | ||||
| CVE-2026-72048 | 1 Linux | 1 Linux Kernel | 2026-08-18 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: ieee802154: ca8210: fix cas_ctl leak on spi_async failure ca8210_spi_transfer() allocates cas_ctl with kzalloc_obj(GFP_ATOMIC) and relies entirely on the SPI completion callback ca8210_spi_transfer_complete() to free it. The spi_async() API only invokes the completion callback on successful submission. On failure it returns a negative error code without ever queuing the callback, which leaves cas_ctl and its embedded spi_message and spi_transfer orphaned. Every kfree(cas_ctl) in the driver is inside the completion callback, so there is no other reclamation path. ca8210_spi_transfer() is called from ca8210_spi_exchange(), the interrupt handler ca8210_interrupt_handler(), and from the retry path inside the completion callback itself. The exchange and interrupt handler paths loop on -EBUSY, so under sustained SPI bus contention every retry iteration leaks a fresh cas_ctl (~600 bytes per occurrence). Fix it by freeing cas_ctl on the spi_async() error path. While here, correct the misleading error string: the function calls spi_async(), not spi_sync(). | ||||
| CVE-2026-72050 | 1 Linux | 1 Linux Kernel | 2026-08-18 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: octeontx2-af: Free BPID bitmap on setup failure nix_setup_bpids() allocates bp->bpids with rvu_alloc_bitmap(), which uses a plain kcalloc(). If any of the following devm_kcalloc() allocations for the BPID mapping arrays fails, the function returns without freeing the bitmap. Free the BPID bitmap before returning from those error paths. | ||||
| CVE-2026-72056 | 1 Linux | 1 Linux Kernel | 2026-08-18 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: net: ena: clean up XDP TX queues when regular TX setup fails create_queues_with_size_backoff() creates XDP TX queues before setting up the regular TX path. If the subsequent allocation or creation of regular TX queues fails, the error handling paths omit the teardown of the XDP TX queues, leading to a resource leak. Fix this by explicitly destroying the XDP TX queue subset at the two missing failure points. The bug was first flagged by an experimental analysis tool we are developing for kernel memory-management bugs while analyzing v6.13-rc1. The tool is still under development and is not yet publicly available. Manual inspection confirms that the bug is still present in v7.1-rc7. An x86_64 allyesconfig build showed no new warnings. As we do not have an ENA device to test with, no runtime testing was able to be performed. | ||||
| CVE-2026-72059 | 1 Linux | 1 Linux Kernel | 2026-08-18 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: net: wwan: t7xx: destroy DMA pool on CLDMA late init failure t7xx_cldma_late_init() creates md_ctrl->gpd_dmapool before initializing the TX and RX rings. If any ring initialization fails, the error path frees the already initialized rings but leaves the DMA pool allocated. Destroy md_ctrl->gpd_dmapool on the late-init failure path to avoid leaking the DMA pool. | ||||
| CVE-2026-72060 | 1 Linux | 1 Linux Kernel | 2026-08-18 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: net: ethernet: ti: icssg: guard PA stat lookups icssg_ndo_get_stats64() unconditionally calls emac_get_stat_by_name() with FW PA stat names regardless of whether the PA stats block is present on the hardware. emac_get_stat_by_name() already guards the PA stats lookup with `if (emac->prueth->pa_stats)`; when that pointer is NULL the lookup falls through to netdev_err() and returns -EINVAL. Because ndo_get_stats64 is polled regularly by the networking stack this produces thousands of log entries of the form: icssg-prueth icssg1-eth end0: Invalid stats FW_RX_ERROR A secondary consequence is that the int(-EINVAL) return value is implicitly widened to a near-ULLONG_MAX unsigned value when accumulated into the __u64 fields of rtnl_link_stats64, silently corrupting the rx_errors, rx_dropped and tx_dropped counters reported by `ip -s link`. Every other PA-aware code path in the driver is already guarded with the same `if (emac->prueth->pa_stats)` check. Apply the same guard here. | ||||
| CVE-2026-72086 | 1 Linux | 1 Linux Kernel | 2026-08-18 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: scsi: xen: scsiback: Free the command tag on the TMR submit-failure path scsiback_device_action() obtains a command tag in scsiback_get_pend_req() and submits a task-management request with target_submit_tmr(). When target_submit_tmr() fails it returns < 0 and scsiback jumps to the err: label, which sends a response but frees nothing, leaking the tag. Impact: a pvSCSI guest can leak the command tags of a LUN's session, stopping the LUN, by issuing VSCSIIF_ACT_SCSI_ABORT or RESET requests whenever target_submit_tmr() fails. transport_generic_free_cmd() cannot be used here. By the time target_submit_tmr() returns an error it has already run __target_init_cmd() (so se_cmd->cmd_kref is one, not zero), and on its target_get_sess_cmd() error path it has freed se_cmd->se_tmr_req via core_tmr_release_req() while leaving SCF_SCSI_TMR_CDB set and the pointer dangling. Letting the command release run target_free_cmd_mem() would then double-free se_tmr_req. Use the same helper, which returns just the tag, on this path too. | ||||
| CVE-2026-72106 | 1 Linux | 1 Linux Kernel | 2026-08-18 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: dm-ioctl: fix a possible overflow in list_version_get_info sizeof(tt->version) is 12 bytes, but the code writes 16 bytes into the output buffer - info->vers->version[0], info->vers->version[1], info->vers->version[2] and info->vers->next. This can cause buffer overflow. Fix this buffer overflow by replacing "sizeof(tt->version)" with "sizeof(struct dm_target_versions)". | ||||
| CVE-2026-72126 | 1 Linux | 1 Linux Kernel | 2026-08-18 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: can: isotp: use unconditional synchronize_rcu() in isotp_release() isotp_notify() unregisters the (RCU) CAN filters via can_rx_unregister() and clears so->bound without waiting for a grace period. isotp_release() uses so->bound to decide whether it needs to call synchronize_rcu() before cancelling so->rxtimer, so when NETDEV_UNREGISTER runs first it skips that synchronize_rcu() and can cancel the timer while an in-flight isotp_rcv() is still executing and about to re-arm it via isotp_send_fc(), leading to a use-after-free timer callback on the freed socket. sakisho-bot remarked a problem with rtnl_lock held in isotp_notify(), therefore make isotp_release() always call synchronize_rcu() before cancelling the timers, regardless of so->bound. This still closes the original race (isotp_notify() clearing so->bound without waiting for in-flight isotp_rcv() callers before isotp_release() cancels the RX timer) without adding any RCU wait to the netdevice notifier path. | ||||
| CVE-2026-72073 | 1 Linux | 1 Linux Kernel | 2026-08-18 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: mmc: vub300: fix use-after-free on probe failure The vub300 driver lifetime-manages its controller state using vub300->kref, with vub300_delete() freeing the mmc host when the last reference is dropped. The probe error path after the inactivity timer has been armed still bypasses that lifetime rule, however, and falls through to mmc_free_host() directly if mmc_add_host() fails. The race window is between arming the inactivity timer and reaching the probe error unwind after mmc_add_host() fails: probe thread timer/workqueue ------------ --------------- kref_init(&vub300->kref) ref = 1 kref_get(&vub300->kref) ref = 2, timer ref add_timer(inactivity_timer) fires after one second | | race window |<----------------------------------------------------> | mmc_add_host(mmc) inactivity timer fires vub300_queue_dead_work() kref_get() ref = 3 queue_work(deadwork) mmc_add_host() fails timer_delete_sync() mmc_free_host(mmc) frees vub300 deadwork runs use-after-free The inactivity timeout is one second, so this would require mmc_add_host() to both fail and take more than one second to do so. This is unlikely to happen in practice, but the error path is still wrong. timer_delete_sync() only waits for the timer callback itself. It does not flush deadwork that the callback may already have queued. As a result, queued deadwork can still hold a kref while the probe error path directly frees the backing mmc host, including the vub300 storage. Fix this by using the same lifetime mechanism as disconnect. Clear vub300->interface so that the timer callback and any queued deadwork return early and drop their references, then drop the initial probe reference and return without falling through to err_free_host. | ||||
| CVE-2026-72076 | 1 Linux | 1 Linux Kernel | 2026-08-18 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: Input: ims-pcu - fix out-of-bounds read in ims_pcu_irq() debug logging The debug logging in ims_pcu_irq() unconditionally prints data from pcu->urb_in_buf. However, if the interrupt fired for pcu->urb_ctrl, the actual data resides in pcu->urb_ctrl_buf. If urb->actual_length for the control URB exceeds pcu->max_in_size, this leads to an out-of-bounds read. Fix this by printing from the correct buffer associated with the URB. | ||||
| 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-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-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(). | ||||