Export limit exceeded: 22833 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (22833 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-80718 | 1 Linux | 1 Linux Kernel | 2026-08-31 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: mm/percpu-km: fix bitmap overflow and accounting in pcpu_create_chunk() In pcpu_create_chunk(), nr_pages is the total contiguous backing allocation, i.e., nr_units * pcpu_unit_pages, but pcpu_chunk_populated() uses it to set chunk->populated, whose size is pcpu_unit_pages, bitmap. Since bit N in chunk->populated means page offset N inside every unit is backed. When nr_units > 1, the function writes beyond chunk->populated. Fix it by using chunk->nr_pages. It also fixes the global pcpu_nr_empty_pop_pages accounting, since pcpu_balance_free() only iterates up to chunk->nr_pages. Commit a63d4ac4ab609 ("percpu: make percpu-km set chunk->populated bitmap properly") introduced the bitmap overflow issue. Later, commit b539b87fed37f ("percpu: implmeent pcpu_nr_empty_pop_pages and chunk->nr_populated") added pcpu_nr_empty_pop_pages and caused the accounting issue. | ||||
| CVE-2026-80671 | 1 Linux | 1 Linux Kernel | 2026-08-31 | 9.3 Critical |
| In the Linux kernel, the following vulnerability has been resolved: perf sched: Fix register_pid() overflow, strcpy, and BUG_ON register_pid() has several issues when processing untrusted perf.data: 1. Integer overflow: (pid + 1) * sizeof(struct task_desc *) can wrap to a small value on 32-bit systems when pid is large (e.g. 0x40000000), causing realloc to return a tiny buffer followed by out-of-bounds writes in the initialization loop. 2. Heap buffer overflow: strcpy(task->comm, comm) copies the untrusted comm string into a fixed 20-byte COMM_LEN buffer with no length check. 3. BUG_ON on allocation failure: perf.data is untrusted input, so allocation failures should be handled gracefully rather than killing the process. 4. Realloc of sched->tasks assigned directly back, leaking the old pointer on failure; nr_tasks incremented before the realloc, leaving corrupted state on failure. Cap pid at PID_MAX_LIMIT (4194304, matching the kernel's maximum on 64-bit), replace strcpy with strlcpy, guard against NULL comm, replace BUG_ON with NULL returns using safe realloc patterns, and add NULL checks in callers that dereference the result. | ||||
| CVE-2026-80618 | 1 Linux | 1 Linux Kernel | 2026-08-31 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: Avoid double-unpin of DOORBELL/MMIO BOs on free amdgpu_amdkfd_gpuvm_free_memory_of_gpu() unpinned DOORBELL and MMIO remap BOs (which are pinned at allocation time) before checking whether the BO is still mapped to the GPU. When the BO is still mapped, the function returns -EBUSY and leaves the BO alive, but it has already been unpinned. The BO is then unpinned again when it is finally freed during process teardown, triggering a ttm_bo_unpin() underflow warning: WARNING: CPU: 18 PID: 15066 at ttm/ttm_bo.c:650 amdttm_bo_unpin+0x6d/0x80 [amdttm] Workqueue: kfd_process_wq kfd_process_wq_release [amdgpu] RIP: 0010:amdttm_bo_unpin+0x6d/0x80 [amdttm] Call Trace: amdgpu_bo_unpin+0x1a/0x90 [amdgpu] amdgpu_amdkfd_gpuvm_unpin_bo+0x31/0xb0 [amdgpu] amdgpu_amdkfd_gpuvm_free_memory_of_gpu+0x3bf/0x460 [amdgpu] kfd_process_free_outstanding_kfd_bos+0xd4/0x170 [amdgpu] kfd_process_wq_release+0x109/0x1b0 [amdgpu] process_one_work+0x1e2/0x3b0 worker_thread+0x50/0x3a0 kthread+0xdd/0x100 ret_from_fork+0x29/0x50 Move the unpin after the mapped_to_gpu_memory check so it only happens once we are committed to freeing the BO. (cherry picked from commit 927c5b2defb9b09856444d94bebfd056a002bd75) | ||||
| CVE-2026-80670 | 1 Linux | 1 Linux Kernel | 2026-08-31 | 9.1 Critical |
| In the Linux kernel, the following vulnerability has been resolved: perf tools: Use perf_env__get_cpu_topology() in machine__resolve() machine__resolve() accesses env->cpu[al->cpu].socket_id after checking al->cpu >= 0 and env->cpu != NULL, but without validating al->cpu against env->nr_cpus_avail. Since al->cpu comes from the untrusted perf.data sample, a crafted file with a large CPU index causes an out-of-bounds heap read. Use perf_env__get_cpu_topology() which validates both NULL and bounds. Also bounds-check al->cpu before the cast to struct perf_cpu (int16_t): without this, values like 65536 silently truncate to 0, bypassing the accessor's internal check and returning CPU 0's topology. | ||||
| CVE-2026-80676 | 1 Linux | 1 Linux Kernel | 2026-08-31 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: Drivers: hv: vmbus: use generic driver_override infrastructure When a driver is probed through __driver_attach(), the bus' match() callback is called without the device lock held, thus accessing the driver_override field without a lock, which can cause a UAF. Fix this by using the driver-core driver_override infrastructure taking care of proper locking internally. Note that calling match() from __driver_attach() without the device lock held is intentional. [1] | ||||
| CVE-2026-80677 | 1 Linux | 1 Linux Kernel | 2026-08-31 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: driver core: use READ_ONCE() for dev->driver in dev_has_sync_state() dev_has_sync_state() reads dev->driver twice without holding device_lock() -- once for the NULL check and once to dereference ->sync_state. Some callers only hold device_links_write_lock, which doesn't prevent a concurrent unbind from clearing dev->driver via device_unbind_cleanup(). Fix it by reading dev->driver exactly once with READ_ONCE(), pairing with the WRITE_ONCE() in device_set_driver(). | ||||
| CVE-2026-80682 | 1 Linux | 1 Linux Kernel | 2026-08-31 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: riscv/mm: use physical alignment for vmemmap_start_pfn RISC-V computes vmemmap_start_pfn by rounding phys_ram_base down to VMEMMAP_ADDR_ALIGN. That alignment must therefore be expressed in the physical-address domain. Commit 476849b0fba4 ("riscv/mm: align vmemmap to maximal folio size") attempted to account for the maximal folio alignment by feeding MAX_FOLIO_VMEMMAP_ALIGN directly into VMEMMAP_ADDR_ALIGN. However, MAX_FOLIO_VMEMMAP_ALIGN is measured in bytes of struct page storage, whereas VMEMMAP_ADDR_ALIGN is used to align a physical address. The mask-based compound_info encoding requires pfn_to_page(0) to be naturally aligned to MAX_FOLIO_VMEMMAP_ALIGN. Commit 9f94db4c7eaa ("mm/sparse: check memmap alignment for compound_info_has_mask()") added a check for that requirement and exposed the unit mismatch on systems such as QEMU virt, where the DRAM base is not aligned to MAX_FOLIO_NR_PAGES * PAGE_SIZE. Here is the log: [ 0.000000][ C0] ------------[ cut here ]------------ [ 0.000000][ C0] WARNING: mm/sparse.c:365 at sparse_init+0x58a/0x6fe, CPU#0: swapper/0 [ 0.000000][ C0] Modules linked in: [ 0.000000][ C0] CPU: 0 UID: 0 PID: 0 Comm: swapper Not tainted 7.2.0-rc3-g1d8304bdd65f #2 PREEMPT [ 0.000000][ C0] Hardware name: riscv-virtio,qemu (DT) [ 0.000000][ C0] epc : sparse_init+0x58a/0x6fe [ 0.000000][ C0] ra : sparse_init+0x58a/0x6fe [ 0.000000][ C0] epc : ffffffff86851c88 ra : ffffffff86851c88 sp : ffffffff88807a30 [ 0.000000][ C0] gp : ffffffff8a3bf240 tp : ffffffff88842080 t0 : ff600000ffab6000 [ 0.000000][ C0] t1 : 000000017fab6000 t2 : 65203a6573726363 s0 : ffffffff88807bc0 [ 0.000000][ C0] s1 : 000000000e000000 a0 : 0000000000000007 a1 : 0000000000000000 [ 0.000000][ C0] a2 : 0000000000000002 a3 : ffffffff86851c88 a4 : 0000000000000000 [ 0.000000][ C0] a5 : ffffffff88843080 a6 : 0000000000000003 a7 : 0000000000000000 [ 0.000000][ C0] s2 : ff60000000000000 s3 : 0040000000000000 s4 : 0004000000000000 [ 0.000000][ C0] s5 : ffffffff8a4d92e0 s6 : ff600000ffab55e0 s7 : ffffffff88384d00 [ 0.000000][ C0] s8 : 0000000000000003 s9 : ffffffff88384cc1 s10: ffffffff88384cc0 [ 0.000000][ C0] s11: ffffffff8a4daae0 t3 : ffffffff915e8b20 t4 : ffffffff915e8b20 [ 0.000000][ C0] t5 : ffffffff915e8b20 t6 : ffffffff915e8bc8 ssp : 0000000000000000 [ 0.000000][ C0] status: 0000000200000100 badaddr: ffffffff86851c88 cause: 0000000000000003 [ 0.000000][ C0] [<ffffffff86851c88>] sparse_init+0x58a/0x6fe [ 0.000000][ C0] [<ffffffff8683d396>] mm_core_init_early+0x116/0x1e30 [ 0.000000][ C0] [<ffffffff86801edc>] start_kernel+0xd2/0x848 Convert MAX_FOLIO_VMEMMAP_ALIGN to the equivalent physical alignment before using it in VMEMMAP_ADDR_ALIGN. This keeps the existing round_down() logic while making the resulting vmemmap base satisfy the mask-alignment requirement. | ||||
| CVE-2026-80694 | 1 Linux | 1 Linux Kernel | 2026-08-31 | 9.8 Critical |
| In the Linux kernel, the following vulnerability has been resolved: net: ethernet: mtk_eth_soc: pass eth to mtk_handle_irq_rx in poll_controller mtk_handle_irq_rx expects a struct mtk_eth * (matching the request_irq cookie), but mtk_poll_controller incorrectly passed the net_device *. Calling ndo_poll_controller with CONFIG_NET_POLL_CONTROLLER enabled would then crash. | ||||
| CVE-2026-80700 | 1 Linux | 1 Linux Kernel | 2026-08-31 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: drm/vmwgfx: validate external BO copy bounds for both stride paths vmw_external_bo_copy() trusts caller-supplied offsets, strides, and heights and operates on imported dma-buf vmaps: - The equal-stride memcpy() bound was clamped after subtracting the offsets from dst_size and src_size; an offset larger than the BO size wraps the unsigned subtraction to a huge value and the resulting memcpy() runs off the end of the vmap. dst_stride * height is also a u32 multiplication that can overflow. - The non-equal-stride row-by-row path had no bound at all. The loop touches bytes through offset + (height - 1) * stride + width_in_bytes, with only a WARN_ON(dst_stride < width_in_bytes), and could likewise step past the end of either mapping. The offsets and strides are derived from STDU/SOU plane state, so a configured CRTC submitting a crafted atomic commit on an imported framebuffer can reach this path. Validate the exact row-copy endpoint against each BO's size up front using check_mul_overflow() and check_add_overflow(). Use the bulk memcpy() path only when width_in_bytes covers the whole stride; otherwise copy one row at a time so partial-row updates near the bottom of a framebuffer remain valid. Also reject zero strides and stride < width_in_bytes, both of which the row-by-row path cannot represent safely. | ||||
| CVE-2026-80725 | 1 Linux | 1 Linux Kernel | 2026-08-31 | 7.0 High |
| In the Linux kernel, the following vulnerability has been resolved: net: gro: properly validate BIG TCP aggregation criteria When GRO attempts to aggregate packets beyond GRO_LEGACY_MAX_SIZE (64KB), BIG TCP should only be permitted for plain IPv4 TCP and plain IPv6 TCP (with sufficient MAC header room to insert the temporary HBH jumbo header). However, commit b1a78b9b9886 ("net: add support for ipv4 big tcp") loosened the check in skb_gro_receive(), leading to several issues: 1. skb_gro_receive() checked skb_headroom(p) instead of the actual space before the MAC header (p->mac_header). Because skb_headroom(p) includes mac_len, crafted frames (e.g. injected via AF_PACKET) can pass the check with p->mac_header < 8 bytes. When ipv6_gro_complete() inserts the temporary HBH jumbo header, the memmove() starts before skb->head, causing an out-of-bounds write and wrapping skb->mac_header. 2. It allowed non-IP protocols such as software VLAN (ETH_P_8021Q / ETH_P_8021AD) to aggregate beyond 64KB because p->protocol != ETH_P_IPV6 was true. 3. It checked p->encapsulation instead of NAPI_GRO_CB(skb)->encap_mark, allowing encapsulated flows (e.g. SIT / IPv6-in-IPv4) to aggregate beyond 64KB. Fix skb_gro_receive() to strictly enforce: - NAPI_GRO_CB(skb)->proto == IPPROTO_TCP - Not encapsulated (!NAPI_GRO_CB(skb)->encap_mark && !p->encapsulation) - Protocol must be either ETH_P_IP or ETH_P_IPV6 - If ETH_P_IPV6, p->mac_header must be at least sizeof(struct hop_jumbo_hdr) Returning -E2BIG from skb_gro_receive() ensures that packets which cannot become BIG TCP are cleanly flushed at <= 64KB and delivered intact without dropping. This issue does not exist in mainline (7.0+) because the subsystem was rewritten in commit 81be30c1f5f2 ("net/ipv6: Drop HBH for BIG TCP on RX side"), making this fix relevant only for older stable branches like 6.18.y. | ||||
| CVE-2026-80598 | 1 Linux | 1 Linux Kernel | 2026-08-31 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: ntfs3: fix out-of-bounds read in decompress_lznt decompress_lznt() does not validate array index bounds before accessing the decompression table. A corrupted NTFS3 image with invalid compressed data can trigger an out-of-bounds read. Add index bounds checking to prevent the OOB access. | ||||
| CVE-2026-80604 | 1 Linux | 1 Linux Kernel | 2026-08-31 | 8.8 High |
| In the Linux kernel, the following vulnerability has been resolved: HID: core: Fix OOB read in hid_get_report for numbered reports When a caller passes a size of 0 to hid_report_raw_event() for a numbered report, the function originally called hid_get_report() before performing any size validation. Inside hid_get_report(), if the report is numbered (report_enum->numbered is true), it unconditionally dereferences data[0] to extract the report ID. With a size of 0, this results in an out-of-bounds read or kernel panic. Fix this by moving the numbered report size validation check before the call to hid_get_report(), ensuring that size is at least 1 before dereferencing the data pointer. | ||||
| CVE-2026-80619 | 1 Linux | 1 Linux Kernel | 2026-08-31 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: apparmor: fix potential UAF in aa_replace_profiles The function aa_replace_profiles was accessing udata->size after calling aa_put_loaddata(udata), causing a potential UAF. Fixed this by saving the size to a local variable before dropping the reference. | ||||
| CVE-2026-80629 | 1 Linux | 1 Linux Kernel | 2026-08-31 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: octeontx2-af: npc: Fix size of entry2cntr_map KASAN prints below splat. This is caused by allocating counter for reserved mcam entry for cpt 2nd pass entry. But mcam->entry2cntr_map is not allocated for reserved entries. BUG: KASAN: slab-out-of-bounds in npc_map_mcam_entry_and_cntr+0xb0/0x1a0 Write of size 2 at addr ffff0001033e7ffe by task kworker/0:1/14 CPU: 0 PID: 14 Comm: kworker/0:1 Not tainted 6.1.67 #1 Hardware name: Marvell CN106XX board (DT) Workqueue: events work_for_cpu_fn Call trace: dump_backtrace.part.0+0xe4/0xf0 show_stack+0x18/0x30 dump_stack_lvl+0x88/0xb4 print_report+0x154/0x458 kasan_report+0xb8/0x194 __asan_store2+0x7c/0xa0 npc_map_mcam_entry_and_cntr+0xb0/0x1a0 rvu_mbox_handler_npc_mcam_write_entry+0x268/0x280 npc_install_flow+0x840/0xfe0 rvu_npc_install_cpt_pass2_entry+0x138/0x190 rvu_nix_init+0x148c/0x2880 rvu_probe+0x1800/0x30b0 local_pci_probe+0x78/0xe0 work_for_cpu_fn+0x30/0x50 process_one_work+0x4cc/0x97c worker_thread+0x360/0x630 kthread+0x1a0/0x1b0 ret_from_fork+0x10/0x20 | ||||
| CVE-2026-80639 | 1 Linux | 1 Linux Kernel | 2026-08-31 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: cxl/test: Fix __fortify_panic Fix a runtime assertion in setup_xor_mapping(). Fortify complains that it is potentially overflowing the xormaps array per __counted_by(nr_maps). Quiet the false positive by initializing @nr_maps earlier. memcpy: detected buffer overflow: 32 byte write of buffer size 0 WARNING: lib/string_helpers.c:1036 at __fortify_report+0x4d/0xa0, CPU#8: modprobe/2728 Call Trace: __fortify_panic+0xd/0xf setup_xor_mapping+0x6c/0xa0 [cxl_translate] [ dj: Fixed up @nr_entries to @nr_maps in commit log. ] | ||||
| CVE-2026-80662 | 1 Linux | 1 Linux Kernel | 2026-08-31 | 7.1 High |
| In the Linux kernel, the following vulnerability has been resolved: cxl: Fix CXL_HEADERLOG_SIZE to match RAS Capability size The CXL r4.0 8.2.4.17.7 RAS Capability Structure has total length 0x58 bytes (CXL_RAS_CAPABILITY_LENGTH); the Header Log occupies the trailing 64 bytes at offset 0x18. CXL_HEADERLOG_SIZE was defined as SZ_512, eight times the actual on-device size. header_log_copy() reads CXL_HEADERLOG_SIZE_U32 (128) dwords from the RAS capability iomap, overrunning the 88-byte mapping by 448 bytes. The cxl_aer_uncorrectable_error trace event memcpy()s CXL_HEADERLOG_SIZE (512) bytes from its source. For the CPER caller the source is struct cxl_ras_capability_regs::header_log[16] (64 bytes) embedded in a stack-local cxl_cper_prot_err_work_data, so the memcpy reads 448 bytes of kernel stack into the trace event ring buffer where userspace can read it via tracefs. Set CXL_HEADERLOG_SIZE to 64 and derive CXL_HEADERLOG_SIZE_U32 from it, bringing all iomap readers into agreement on 16 dwords. Userspace tools such as rasdaemon have grown a dependency on the buggy 512-byte (128 u32) header_log layout in the cxl_aer_uncorrectable_error trace event. Add CXL_HEADERLOG_TRACE_SIZE_U32 = 128 and use it for the trace event __array and its memcpy to preserve that ABI. Both callers now pass a zero-filled u32[CXL_HEADERLOG_TRACE_SIZE_U32] staging buffer with only the first CXL_HEADERLOG_SIZE_U32 (16) entries populated from hardware; the remaining 112 u32s are zero-padded, keeping the 512-byte trace ring buffer layout intact. [ dj: Replaced 64 with SZ_64 per RichardC ] | ||||
| CVE-2026-80667 | 1 Linux | 1 Linux Kernel | 2026-08-31 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: net/mlx5: LAG, MPESW, Fix missing complete() on devcom error mlx5_mpesw_work() returned without calling complete() when mlx5_lag_get_devcom_comp() returned NULL. A caller that queued the work and waited on mpesww->comp would block indefinitely. Funnel the early-return path through a new "complete" label so the waiter is always woken. | ||||
| CVE-2026-80674 | 1 Linux | 1 Linux Kernel | 2026-08-31 | 9.8 Critical |
| In the Linux kernel, the following vulnerability has been resolved: ntfs: validate resident attribute lists and harden the validator A base inode's $ATTRIBUTE_LIST is sanity-checked by load_attribute_list() only on the non-resident path; ntfs_read_locked_inode() copies a *resident* attribute list into ni->attr_list with a plain memcpy() and no validation at all. Every subsequent walk of ni->attr_list -- ntfs_external_attr_find(), ntfs_inode_attach_all_extents() and ntfs_attrlist_need() -- then trusts the entries are well-formed and reads attr_list_entry fixed-header fields (lowest_vcn at offset 8, mft_reference at offset 16, and the name) with bounds that assume validation already happened. A crafted resident attribute list therefore reaches those walks unvalidated and can drive out-of-bounds reads of the attribute-list buffer. load_attribute_list() itself reads ale->name_offset (offset 7), ale->mft_reference (offset 16) and the name length under only an "al < al_start + size" bound, so its own validation loop can over-read the fixed header of a truncated trailing entry by a few bytes. Factor the per-entry validation into ntfs_attr_list_entry_is_valid(), which requires each entry's fixed header (offsetof(struct attr_list_entry, name)) to be in range before any field is dereferenced, that ale->length is a multiple of 8 covering the fixed header plus the name, and that the entry is in use and carries a live MFT reference. ntfs_attr_list_is_valid() walks the buffer with it and checks the entries tile it exactly. Use the list validator in load_attribute_list() (replacing the open-coded loop, closing its own over-read) and on the resident path in ntfs_read_locked_inode() (which previously skipped validation entirely); patches 2/3 reuse the per-entry helper at the other two attribute-list walks. | ||||
| CVE-2026-80711 | 1 Linux | 1 Linux Kernel | 2026-08-31 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: power: supply: max17040: handle missing status supplier MAX17040 does not report charger state itself, so the driver forwards POWER_SUPPLY_PROP_STATUS to a supplier power supply. If no supplier is registered, power_supply_get_property_from_supplier() returns -ENODEV and leaves the output value untouched. max17040_get_property() currently ignores that error and returns success, so userspace can read an uninitialized status value from the battery power supply. This happens on systems that use the fuel gauge without a charger supplier relationship in firmware. Return POWER_SUPPLY_STATUS_UNKNOWN when no supplier provides STATUS, and propagate other supplier lookup errors. | ||||
| CVE-2026-80633 | 1 Linux | 1 Linux Kernel | 2026-08-31 | 8.8 High |
| In the Linux kernel, the following vulnerability has been resolved: iommufd: Take dma_resv lock before dma_buf_unpin() in release path dma_buf_unpin() requires the caller to hold the exporter's dma_resv lock: void dma_buf_unpin(struct dma_buf_attachment *attach) { ... dma_resv_assert_held(dmabuf->resv); ... } iopt_release_pages() calls dma_buf_unpin() without taking that lock, so every iommufd_ioas_destroy()/iommufd_ioas_unmap() that releases the last reference on a DMABUF-backed iopt_pages triggers a WARN. This was hit while running tools/testing/selftests/iommu/iommufd: WARNING: drivers/dma-buf/dma-buf.c:1137 at dma_buf_unpin+0x62/0x70 RIP: 0010:dma_buf_unpin+0x62/0x70 Call Trace: <TASK> dma_buf_unpin+0x62/0x70 iopt_release_pages+0xe4/0x190 iopt_unmap_iova_range+0x1c7/0x290 iopt_unmap_all+0x1a/0x30 iommufd_ioas_destroy+0x1d/0x50 iommufd_fops_release+0x93/0x150 __fput+0xfc/0x2c0 __x64_sys_close+0x3d/0x80 do_syscall_64+0x65/0x180 </TASK> Take the dma_resv lock around dma_buf_unpin() in iopt_release_pages(), matching the iopt_map_dmabuf() convention. dma_buf_detach() acquires the reservation lock internally, so it must remain outside the locked region. | ||||