Export limit exceeded: 15627 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Export limit exceeded: 25765 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (25765 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-80959 | 1 Linux | 1 Linux Kernel | 2026-09-13 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: dm-pcache: bound the persisted tail-position offset cache_pos_decode() takes the persisted key_tail and dirty_tail seg_off from the cache device and addresses within the segment with it. A seg_off at or past the segment data_size, controllable by whoever supplies the device (CAP_SYS_ADMIN), reads past the segment data. Reject a decoded seg_off that is not below the segment data_size. | ||||
| CVE-2026-80958 | 1 Linux | 1 Linux Kernel | 2026-09-13 | 7.1 High |
| In the Linux kernel, the following vulnerability has been resolved: dm-pcache: clamp the tail kset read to the segment data region The tail-kset read in cache_replay(), the writeback worker and the GC worker bounds its length by PCACHE_SEG_SIZE - seg_off, the raw segment size rather than the data region. A tail near the segment end reads past the segment data into the following control area. Clamp the read to cache_seg_remain(), the data region. | ||||
| CVE-2026-80955 | 1 Linux | 1 Linux Kernel | 2026-09-13 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: dm-pcache: fix use-after-free and invalid seg operations in kset_replay() In kset_replay, when key->seg_gen is stale (key->seg_gen < key->cache_pos.cache_seg->gen), cache_key_put(key) is called but then key->cache_pos.cache_seg is accessed as the argument to cache_seg_get(). This is a use-after-free on the freed key memory. Although mempool recycled memory is not immediately reclaimed or overwritten in practice, this is still a potential UAF bug. Additionally, for expired invalid keys, setting the cache->seg_map bit and calling cache_seg_get() is unreasonable since the corresponding segment data is no longer valid. Fix both issues by moving cache_seg_get() and __set_bit() after the gen check, so they only execute for valid keys, and using continue to skip invalid keys. | ||||
| CVE-2026-80954 | 1 Linux | 1 Linux Kernel | 2026-09-13 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: i3c: Fix unlocked dereference of dev->desc in i3c_device_get_supported_xfer_mode() i3c_device_get_supported_xfer_mode() uses dev->desc to obtain the master controller. However, dev->desc must not be dereferenced unless bus->lock is held, and this function does not take that lock. The function only needs access to the master controller associated with the device's bus. Use dev->bus instead, which is always valid for the lifetime of the device and does not require dereferencing dev->desc. | ||||
| CVE-2026-80953 | 1 Linux | 1 Linux Kernel | 2026-09-13 | 8.4 High |
| In the Linux kernel, the following vulnerability has been resolved: i3c: master: adi: initialize the lock before enabling interrupts adi_i3c_master_probe() requests the IRQ and unmasks REG_IRQ_PENDING_CMDR before the controller's IBI state, transfer queue list and transfer queue lock are initialized. A pending CMDR interrupt can therefore run adi_i3c_master_irq() and take master->xferqueue.lock before the dynamic lock has been initialized. This issue was found by our static analysis tool and then manually reviewed against the current tree. The grounded PoC kept the probe ordering and the IRQ path adi_i3c_master_probe() -> adi_i3c_master_irq() -> xferqueue.lock, with a pending CMDR interrupt arriving after REG_IRQ_PENDING_CMDR is unmasked. Lockdep reported: INFO: trying to register non-static key. you didn't initialize this object before use? lock_acquire+0xbb/0x290 _raw_spin_lock_irqsave+0x36/0x60 adi_i3c_master_irq+0x32/0x56 [vuln_msv] adi_i3c_master_probe+0x5a/0xf47 [vuln_msv] Initialize the transfer queue and IBI state before requesting and unmasking the IRQ. | ||||
| CVE-2026-80950 | 1 Linux | 1 Linux Kernel | 2026-09-13 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: i3c: renesas: Check that the transfer is valid before accessing it The Renesas I3C driver uses an asynchronous model to transfer data. It prepares a struct renesas_i3c_xfer, enqueues it, and waits for completion. The interrupt handler dequeues the transfer, updates/uses it, and signals the waiting thread. If the completion times out, the waiting thread dequeues the transfer and free it. If an interrupt fires after that, the handler may access freed memory, leading to crashes. Check that the transfer is still valid before accessing it in the interrupt handler. With it clear any status flags and disable all the interrupts to avoid triggering the same interrupts again. | ||||
| CVE-2026-80943 | 1 Linux | 1 Linux Kernel | 2026-09-13 | 7.6 High |
| In the Linux kernel, the following vulnerability has been resolved: wifi: rtlwifi: rtl8192du: check QoS TID before indexing tids rtl92du_tx_fill_desc() uses ieee80211_get_tid() to read the QoS TID from the 802.11 header and then uses it as an index into sta_entry->tids[]. ieee80211_get_tid() returns the low 4-bit QoS TID value, so the result can be in the range 0..15. rtlwifi only allocates MAX_TID_COUNT entries for sta_entry->tids[], and MAX_TID_COUNT is 9. A QoS TID greater than 8 therefore indexes past the aggregation state array. Keep the default RTL_AGG_STOP state for out-of-range TIDs, matching rtl92cu_tx_fill_desc(). This issue was detected by our static analysis tool and confirmed by manual audit. UBSAN validation for the same bug pattern reports an array-index-out-of-bounds access with index 10 for type 'rtl_tid_data [9]'. | ||||
| CVE-2026-80936 | 1 Linux | 1 Linux Kernel | 2026-09-13 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7925: cancel mlo_pm_work on stop mt7925 queues mlo_pm_work with a 5 second delay during multi-link power-save setup and never cancels it on the stop path. If the device is torn down inside that window, the work outlives the teardown and its timer fires afterwards, trying to queue onto the workqueue that is already gone: workqueue: cannot queue mt7925_mlo_pm_work [mt7925_common] on wq phy0 WARNING: kernel/workqueue.c:2283 at __queue_work+0x59/0xa0, CPU#1: swapper/1/0 call_timer_fn+0x2a/0x140 __run_timers+0x203/0x330 run_timer_softirq+0x86/0xf0 mt7921 already has its own stop callback, so add one for mt7925 that cancels the work before calling mt792x_stop(). mt7925_ops backs both the PCIe and USB drivers, so this covers both. | ||||
| CVE-2026-80929 | 1 Linux | 1 Linux Kernel | 2026-09-13 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: sysctl: move the "cad_pid" entry from pid_table[] to kern_reboot_table[] cad_pid is global, and kill_cad_pid() is only used in the root namespace. However, due to pid_table_root_permissions(), a non-root user can unshare pid/user namespaces and modify it from the child namespace. This makes no sense and is simply wrong. Move it to kern_reboot_table[] where it logically belongs; this ensures that only GLOBAL_ROOT_UID can read/modify this sysctl. Note that this patch doesn't preserve "#ifdef CONFIG_PROC_SYSCTL" around the "cad_pid"; CONFIG_PROC_SYSCTL selects CONFIG_SYSCTL, so it is always set when kern_reboot_table[] is compiled. | ||||
| CVE-2026-89629 | 1 Linux | 1 Linux Kernel | 2026-09-12 | 5.3 Medium |
| In the Linux kernel, the following vulnerability has been resolved: HID: corsair-void: Check size of status and firmware events before reading them Malformed status and firmware events could cause an out-of-bounds read since the size wasn't being checked. Check the size and warn on unexpected values to avoid this. | ||||
| CVE-2026-89745 | 1 Linux | 1 Linux Kernel | 2026-09-12 | 4.4 Medium |
| In the Linux kernel, the following vulnerability has been resolved: debugfs: Fix lockdown check for mmap_prepare Commit 651fdda8406d ("relay: update relay to use mmap_prepare") changed the `mmap` file operation to `mmap_prepare` for relayfs, but the lockdown check in debugfs was not updated accordingly. This prevents debugfs from being locked down when the kernel is in integrity mode if a file uses `mmap_prepare` but not `mmap`. Since the conversion to `mmap_prepare` across the kernel is not yet complete, update the lockdown check to look for both `mmap` and `mmap_prepare` to ensure comprehensive coverage. | ||||
| CVE-2026-89514 | 1 Linux | 1 Linux Kernel | 2026-09-12 | 4.4 Medium |
| In the Linux kernel, the following vulnerability has been resolved: scsi: fnic: Use GFP_ATOMIC for VLAN alloc under spinlock fnic_fcoe_process_vlan_resp() allocates a VLAN descriptor with kzalloc_obj() (default GFP_KERNEL) while holding vlans_lock via spin_lock_irqsave(). GFP_KERNEL may sleep, which is not allowed in this atomic context and can trigger a sleeping-from-invalid-context warning or deadlock. Pass GFP_ATOMIC so the allocation is safe under the IRQ-safe spinlock. | ||||
| CVE-2026-89716 | 1 Linux | 1 Linux Kernel | 2026-09-12 | 4.4 Medium |
| In the Linux kernel, the following vulnerability has been resolved: zram: validate deflate params We must validate user-supplied deflate winbits before we pass it to zlib_deflate_workspacesize(), which triggers BUG_ON() if winbits value is outside of valid ranges. | ||||
| CVE-2026-89727 | 1 Linux | 1 Linux Kernel | 2026-09-12 | 4.7 Medium |
| In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: GICv2: Don't WARN on out-of-range GICV_DIR INTID vgic_v2_deactivate() passes the INTID a guest wrote to GICV_DIR straight to vgic_get_vcpu_irq(), and treats a failed lookup as a "can't happen" condition with WARN_ON_ONCE(). The guest can make it happen at will, though: for any INTID outside of the implemented SGI, PPI and SPI ranges the lookup returns NULL, since GICv2 has no LPIs. A guest running with EOImode==1 writing such an INTID to GICV_DIR triggers the WARN, and panics hosts running with panic_on_warn. Drop the WARN and ignore failed lookups. | ||||
| CVE-2026-89556 | 1 Linux | 1 Linux Kernel | 2026-09-12 | 4.7 Medium |
| In the Linux kernel, the following vulnerability has been resolved: module: validate string table section types In elf_validity_cache_sechdrs, section sizes and offsets are validated, unless the section type is SHT_NULL or SHT_NOBITS. Later, elf_validity_cache_secstrings and elf_validity_cache_index_str access the section name table (.shstrtab) and symbol string table (.strtab) headers without first ensuring that their types are SHT_STRTAB. If a section type is SHT_NULL or SHT_NOBITS, sh_offset has not been validated and may reference out-of-bounds memory when dereferenced in elf_validity_cache_secstrings or elf_validity_cache_strtab. Validate that both string section headers are of type SHT_STRTAB before caching them. | ||||
| CVE-2026-89715 | 1 Linux | 1 Linux Kernel | 2026-09-12 | 5.3 Medium |
| In the Linux kernel, the following vulnerability has been resolved: NFS/localio: fix ref leak on nfs_uuid_add_file failure When nfs_uuid_add_file() races with nfs_uuid_put() tearing down uuid->net, it returns -ENXIO without publishing nfl->nfs_uuid via rcu_assign_pointer(). nfs_open_local_fh() then enters its error branch and only releases the slot's file ref and its paired net ref plus its own entry-time net ref, while the close path is a no-op: nfs_close_local_fh() nfs_uuid = rcu_dereference(nfl->nfs_uuid); if (!nfs_uuid) { rcu_read_unlock(); return; } /* always */ nfsd_open_local_fh() returns localio holding a caller-owned +1 nfsd_file reference (from nfsd_file_get() after nfsd_file_acquire_local()) and an entry-time nfsd_net reference (from its first nfsd_net_try_get()) embedded as nf->nf_net. Both are leaked on the failure path, pinning one nfsd_file (and the underlying struct file, dentry, inode) and one nfsd_net_ref per occurrence, which blocks nfsd_net and netns teardown. Fix by releasing the caller-owned file ref and its net ref through the existing helper, using a stack-local RCU pointer so the helper can xchg it out, then returning -ENXIO so callers do not dereference a localio whose slot has been cleared: struct nfsd_file __rcu *tmp = RCU_INITIALIZER(localio); nfs_to_nfsd_file_put_local(pnf); nfs_to_nfsd_file_put_local(&tmp); localio = ERR_PTR(-ENXIO); The trailing nfs_to_nfsd_net_put(net) continues to release the outer net ref, so all three nfsd_net_try_get() increments are balanced on the error branch. | ||||
| CVE-2026-89770 | 1 Linux | 1 Linux Kernel | 2026-09-12 | 4.7 Medium |
| In the Linux kernel, the following vulnerability has been resolved: iomap: don't free integrity payload that doesn't exist fs_bio_integrity_alloc might not allocate a bio integrity payload if PI verification is disabled on the block device. Check for that case before calling fs_bio_integrity_free in iomap_bio_read_folio_range_sync to avoid a NULL pointer dereferences. Make the branch cover the PI verification as well - while fs_bio_integrity_verify works without an integrity payload, it requires one to actually do useful work. | ||||
| CVE-2026-89728 | 1 Linux | 1 Linux Kernel | 2026-09-12 | 4.7 Medium |
| In the Linux kernel, the following vulnerability has been resolved: i3c: renesas: Fix out-of-bounds access for newdevs mask When software initiates DAA (Dynamic Address Assignment), the controller reports the result via the NRSPQP (Normal Response Queue Port Register). The data length field of the response descriptor, which is accessible through the NRSPQP register, indicates the number of devices remaining after DAA. Consequently, when the bus is empty, this field contains the maximum number of devices supported by the controller (8 for the Renesas I3C controller). Adjust the condition that computes the newly discovered devices bitmask to prevent an out-of-bounds when the I3C bus is empty. | ||||
| CVE-2026-89734 | 1 Linux | 1 Linux Kernel | 2026-09-12 | 4.7 Medium |
| In the Linux kernel, the following vulnerability has been resolved: usb: gadget: uvc: Fix null pointer dereference in uvcg_video_init() In uvcg_video_init(), if kthread_run_worker() fails, the error logged uses uvcg_err(), however, the pointer it uses: video->uvc is not assigned at this point, triggering a null pointer dereference. Fix this by directly using uvc->func which is assigned already. | ||||
| CVE-2026-80788 | 1 Linux | 1 Linux Kernel | 2026-09-12 | 6.2 Medium |
| In the Linux kernel, the following vulnerability has been resolved: nvmet-tcp: Do not WARN on remotely-controlled oversized SGL allocations When fuzzing the nvme target code, I tripped a kernel warning in nvmet_tcp_map_data() because the length passed into the allocator is controlled by the remote initiator. A remote initiator that sends a command with an SGL claiming a huge number, can create a scatterlist and iovec allocation of over 1 million entries, which causes the backing kmalloc call to exceed MAX_PAGE_ORDER and then the page allocator will trip on a WARN_ON_ONCE_GFP() message: WARNING: mm/page_alloc.c:5280 __alloc_frozen_pages_noprof Workqueue: nvmet_tcp_wq nvmet_tcp_io_work ... sgl_alloc_order nvmet_tcp_map_data nvmet_tcp_try_recv_pdu As it's never good to trip a kernel warning remotely due to many systems having panic-on-warn enabled, let's silence it by just add GFP_NOWARN to the allocation flags. | ||||