Vulnerability database

21,993 results · page 65 of 440

• Aug 28, 2026In the Linux kernel, the following vulnerability has been resolved: riscv: drop __init from vec_check_unaligned_access_speed_all_cpus This function runs withiCVE-2026-80688 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67

  In the Linux kernel, the following vulnerability has been resolved: riscv: drop __init from vec_check_unaligned_access_speed_all_cpus This function runs within a kthread and need not necessarily finish before system finishes boot and free_initmem() unmaps the .init.text section. This function makes calls to SBI for probing unaligned access speed, and if this is slow for some reason (say some debug prints were added to SBI), the kthread can still be running at this point and result in an instruction page fault when trying to fetch from the freed region. [ 25.642087] Unable to handle kernel paging request at virtual address ffffffff80a04ef8 [ 25.646694] Current vec_check_unali pgtable: 4K pagesize, 48-bit VAs, pgdp=0x00004000316e9000 [ 25.653170] [ffffffff80a04ef8] pgd=000010004be7e401, p4d=000010004be7e401, pud=000010004be7e001, pmd=000010000c3000e3 [ 25.661244] Oops [#1] [ 25.662997] Modules linked in: [ 25.665357] CPU: 3 UID: 0 PID: 42 Comm: vec_check_unali Not tainted 7.0.0-tt-blackhole-asrinivasan-00007-g30ff73f18211 #570 PREEMPTLAZY [ 25.674669] Hardware name: Tenstorrent Blackhole (DT) [ 25.678545] epc : vec_check_unaligned_access_speed_all_cpus+0x18/0x2c [

  Product

  Linux

  What to do

  Apply the vendor’s update. The NVD record links to the advisory.

  Full record and what to do →NVD recordgit.kernel.orggit.kernel.org

• Aug 28, 2026In the Linux kernel, the following vulnerability has been resolved: iommufd/viommu: Release the igroup lock on the vdevice_size error path iommufd_vdevice_allCVE-2026-80687 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67

  In the Linux kernel, the following vulnerability has been resolved: iommufd/viommu: Release the igroup lock on the vdevice_size error path iommufd_vdevice_alloc_ioctl() takes idev->igroup->lock, then validates the driver's vdevice_size against the core structure size with a WARN_ON_ONCE. On failure that guard jumps to out_put_idev, below out_unlock_igroup, so it skips the mutex_unlock(), leaving the igroup lock held and deadlocking the next vDEVICE operation on that group. Jump to out_unlock_igroup instead.

  Product

  Linux

  What to do

  Apply the vendor’s update. The NVD record links to the advisory.

  Full record and what to do →NVD recordgit.kernel.orggit.kernel.org

• Aug 28, 2026In the Linux kernel, the following vulnerability has been resolved: mm: migrate_device: fix pte_pfn/pte_dirty called on non-present PTE pte_pfn() and pte_dirtCVE-2026-80686 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67

  In the Linux kernel, the following vulnerability has been resolved: mm: migrate_device: fix pte_pfn/pte_dirty called on non-present PTE pte_pfn() and pte_dirty() have undefined behaviour when called on a non-present PTE. In migrate_vma_collect_pmd(), these functions may be invoked on non-present entries (e.g., device-private entries), leading to potential crashes from pte_pfn() or incorrect dirty folio accounting from pte_dirty(). Fix both by guarding with pte_present() checks.

  Product

  Linux

  What to do

  Apply the vendor’s update. The NVD record links to the advisory.

  Full record and what to do →NVD recordgit.kernel.orggit.kernel.org

• Aug 28, 2026In the Linux kernel, the following vulnerability has been resolved: mm/util: don't read __page_2 for order-1 folios in snapshot_page() snapshot_page() currentCVE-2026-80685 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67High 7.1

  In the Linux kernel, the following vulnerability has been resolved: mm/util: don't read __page_2 for order-1 folios in snapshot_page() snapshot_page() currently reads __page_2 after checking nr_pages > 1, but it should only do so when nr_pages > 2. If an order-1 folio is allocated at the end of a vmemmap section, __page_2 will not exist and reading it will cause a fault. During DLPAR memory remove on a 22 TB ppc64le LPAR, snapshot_page() oopsed on the page isolation path while reading an order-1 folio's __page_2 from an adjacent absent section (unmapped vmemmap). Fix this to avoid reading memmap that doesn't exist (e.g., a vmemmap hole).

  Product

  Linux

  What to do

  Apply the vendor’s update. The NVD record links to the advisory.

  Full record and what to do →NVD recordgit.kernel.orggit.kernel.org

• Aug 28, 2026In the Linux kernel, the following vulnerability has been resolved: KVM: s390: pci: Fix NULL dereference on AIBV allocation failure The airq_iv_create() can rCVE-2026-80684 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67Critical 9.3

  In the Linux kernel, the following vulnerability has been resolved: KVM: s390: pci: Fix NULL dereference on AIBV allocation failure The airq_iv_create() can return NULL on failure, but the return value was never checked. If it fails, zdev->aibv will be NULL and fail when dereferenced in kvm_zpci_set_airq(). Add a NULL check and free the previously allocated AISB bit and zdev->aisb on failure.

  Product

  Linux

  What to do

  Apply the vendor’s update. The NVD record links to the advisory.

  Full record and what to do →NVD recordgit.kernel.orggit.kernel.org

• Aug 28, 2026In the Linux kernel, the following vulnerability has been resolved: Bluetooth: SCO: give the socket its own sco_conn reference sco_conn_del() drops a referencCVE-2026-80683 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67High 8.8

  In the Linux kernel, the following vulnerability has been resolved: Bluetooth: SCO: give the socket its own sco_conn reference sco_conn_del() drops a reference it does not own. It takes one transient reference via sco_conn_hold_unless_zero() and releases it with the sco_conn_put() that follows sco_sock_hold(); the additional put in the !sk branch releases a second one: conn = sco_conn_hold_unless_zero(conn); ... sk = sco_sock_hold(conn); sco_conn_unlock(conn); sco_conn_put(conn); if (!sk) { sco_conn_put(conn); return; } When close() races the controller's Disconnection Complete, sco_chan_del() clears conn->sk and drops the socket's reference while sco_conn_del() is running. sco_conn_del() then sees sk == NULL, its own put drops the count to zero and frees the conn, and the second put writes to the freed kref: BUG: KASAN: slab-use-after-free in sco_conn_put.part.0+0x1a/0x190 Write of size 4 at addr ffff8881099dec74 by task kworker/u17:3/413 Workqueue: hci1 hci_rx_work Call Trace: sco_conn_put.part.0+0x1a/0x190 hci_disconn_complete_evt+0x1ee/0x3e0 hci_event_packet+0x54a/0x650 hci_rx_work+0x3

  Product

  Linux

  What to do

  Apply the vendor’s update. The NVD record links to the advisory.

  Full record and what to do →NVD recordgit.kernel.orggit.kernel.org

• Aug 28, 2026In the Linux kernel, the following vulnerability has been resolved: riscv/mm: use physical alignment for vmemmap_start_pfn RISC-V computes vmemmap_start_pfn bCVE-2026-80682 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67High 7.8

  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 linke

  Product

  Linux

  What to do

  Apply the vendor’s update. The NVD record links to the advisory.

  Full record and what to do →NVD recordgit.kernel.orggit.kernel.org

• Aug 28, 2026In the Linux kernel, the following vulnerability has been resolved: vxlan: re-fetch eth header after route_shortcircuit() Before route_shortcircuit(), the ethCVE-2026-80681 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67Critical 9.8

  In the Linux kernel, the following vulnerability has been resolved: vxlan: re-fetch eth header after route_shortcircuit() Before route_shortcircuit(), the eth header pointer is cached from eth_hdr(skb). Inside route_shortcircuit(), pskb_may_pull() can be called, which may reallocate skb->head. In this case, returning to vxlan_xmit() leaves the cached eth pointer pointing to freed memory, leading to a use-after-free when dereferencing eth->h_dest. Fix this by updating eth = eth_hdr(skb) after calling route_shortcircuit().

  Product

  Linux

  What to do

  Apply the vendor’s update. The NVD record links to the advisory.

  Full record and what to do →NVD recordgit.kernel.orggit.kernel.org

• Aug 28, 2026In the Linux kernel, the following vulnerability has been resolved: i2c: amd-mp2: Unregister callback on adapter add failure amd_mp2_register_cb() stores the CVE-2026-80680 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67High 7.8

  In the Linux kernel, the following vulnerability has been resolved: i2c: amd-mp2: Unregister callback on adapter add failure amd_mp2_register_cb() stores the platform I2C context in the MP2 PCI driver's callback table before the adapter is registered. If i2c_add_adapter() fails, probe returns and devres frees the context, but the PCI driver can still dereference the stale pointer from its IRQ and system-sleep callbacks. Unregister the callback before returning the adapter registration error.

  Product

  Linux

  What to do

  Apply the vendor’s update. The NVD record links to the advisory.

  Full record and what to do →NVD recordgit.kernel.orggit.kernel.org

• Aug 28, 2026In the Linux kernel, the following vulnerability has been resolved: s390/dasd: Fix potential NULL pointer dereference dasd_release_space() checks the implemenCVE-2026-80679 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67

  In the Linux kernel, the following vulnerability has been resolved: s390/dasd: Fix potential NULL pointer dereference dasd_release_space() checks the implementation of the is_ese() discipline function before calling it to determine if a given device is an ESE DASD. The current usage of the logical AND operator will lead to a NULL pointer dereference as the function is called even if the function pointer is NULL. Fix this by using the logical OR operator.

  Product

  Linux

  What to do

  Apply the vendor’s update. The NVD record links to the advisory.

  Full record and what to do →NVD recordgit.kernel.orggit.kernel.org

• Aug 28, 2026In the Linux kernel, the following vulnerability has been resolved: i2c: imx: Fix slave registration race and error handling In i2c_imx_reg_slave(), the slaveCVE-2026-80678 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67High 8.4

  In the Linux kernel, the following vulnerability has been resolved: i2c: imx: Fix slave registration race and error handling In i2c_imx_reg_slave(), the slave pointer was assigned before pm_runtime_resume_and_get(). If pm_runtime_resume_and_get() failed, the error path returned without clearing i2c_imx->slave, leaving it non-NULL and causing all subsequent registration attempts to fail with -EBUSY. Additionally, because this driver uses a shared IRQ, the interrupt handler i2c_imx_isr() can execute concurrently and, after acquiring slave_lock, dereference i2c_imx->slave. The previous fix attempt added a lockless i2c_imx->slave = NULL on the error path, but that could race with the ISR under the lock and still cause a NULL pointer dereference. Fix both issues by deferring the assignment of i2c_imx->slave and i2c_imx->last_slave_event to after a successful resume, and by performing the assignment inside the slave_lock critical section. This guarantees that the slave pointer is never left stale on the error path and is always valid when observed by the interrupt handler.

  Product

  Linux

  What to do

  Apply the vendor’s update. The NVD record links to the advisory.

  Full record and what to do →NVD recordgit.kernel.orggit.kernel.org

• Aug 28, 2026In 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() CVE-2026-80677 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67High 7.8

  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().

  Product

  Linux

  What to do

  Apply the vendor’s update. The NVD record links to the advisory.

  Full record and what to do →NVD recordgit.kernel.orggit.kernel.org

• Aug 28, 2026In the Linux kernel, the following vulnerability has been resolved: Drivers: hv: vmbus: use generic driver_override infrastructure When a driver is probed thrCVE-2026-80676 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67

  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]

  Product

  Linux

  What to do

  Apply the vendor’s update. The NVD record links to the advisory.

  Full record and what to do →NVD recordgit.kernel.orggit.kernel.org

• Aug 28, 2026In the Linux kernel, the following vulnerability has been resolved: libbpf: Reject non-exclusive metadata maps in the signed loader The loader verifies map->sCVE-2026-80675 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67High 7.1

  In the Linux kernel, the following vulnerability has been resolved: libbpf: Reject non-exclusive metadata maps in the signed loader The loader verifies map->sha against the metadata hash in its instructions. map->sha is calculated when BPF_OBJ_GET_INFO_BY_FD is called on the frozen map. While the map is frozen, the /signed loader/ must also ensure the map is exclusive, as, without exclusivity (which a hostile host could just omit when loading the loader), another BPF program with map access can mutate the contents afterwards, so the check passes on stale data. With the extra check as part of the signed loader, it now refuses to move on with map->sha validation if the host set it up wrongly.

  Product

  Linux

  What to do

  Apply the vendor’s update. The NVD record links to the advisory.

  Full record and what to do →NVD recordgit.kernel.orggit.kernel.org

• Aug 28, 2026In the Linux kernel, the following vulnerability has been resolved: ntfs: validate resident attribute lists and harden the validator A base inode's $ATTRIBUTECVE-2026-80674 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67Critical 9.8

  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 ent

  Product

  Linux

  What to do

  Apply the vendor’s update. The NVD record links to the advisory.

  Full record and what to do →NVD recordgit.kernel.orggit.kernel.org

• Aug 28, 2026In the Linux kernel, the following vulnerability has been resolved: ntfs: bound the look-ahead attribute-list entry in ntfs_external_attr_find() When resolvinCVE-2026-80673 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67Critical 9.8

  In the Linux kernel, the following vulnerability has been resolved: ntfs: bound the look-ahead attribute-list entry in ntfs_external_attr_find() When resolving an attribute lookup with a non-zero @lowest_vcn, ntfs_external_attr_find() peeks at the next $ATTRIBUTE_LIST entry to decide whether to keep searching, but bounds that not-yet-validated entry only with "(u8 *)next_al_entry + 6 < al_end" (which proves just bytes 0..6 are in range) and "(u8 *)next_al_entry + length <= al_end" with an attacker-controlled, non-8-aligned length. It then reads next_al_entry->lowest_vcn (an __le64 at offset 8) and the name at next_al_entry->name_offset, both of which can lie past al_end -- the exact end of the kvmalloc'd attribute-list buffer (allocated at the on-disk attr_list_size, no rounding). A crafted on-disk $ATTRIBUTE_LIST whose last entry sits a few bytes before al_end therefore yields a slab out-of-bounds read when the inode is read. Validate the look-ahead entry with ntfs_attr_list_entry_is_valid() (added in patch 1/3) before dereferencing lowest_vcn and the name, so the same fixed-header, length and name bounds the main attribute-list walk uses now guard this read too.

  Product

  Linux

  What to do

  Apply the vendor’s update. The NVD record links to the advisory.

  Full record and what to do →NVD recordgit.kernel.orggit.kernel.org

• Aug 28, 2026In the Linux kernel, the following vulnerability has been resolved: ntfs: fix u16 truncation of restart-area length check ntfs_check_restart_area() validates CVE-2026-80672 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67High 8.8

  In the Linux kernel, the following vulnerability has been resolved: ntfs: fix u16 truncation of restart-area length check ntfs_check_restart_area() validates that the $LogFile restart area and its trailing log client record array fit within the system page size: u16 ra_ofs, ra_len, ca_ofs; ... ra_len = ca_ofs + le16_to_cpu(ra->log_clients) * sizeof(struct log_client_record); if (ra_ofs + ra_len > le32_to_cpu(rp->system_page_size) || ...) return false; ra_len is u16, but the right-hand side is computed in size_t (sizeof(struct log_client_record) == 160). Both ca_ofs and log_clients come straight from the on-disk restart area. With an on-disk log_clients of 410 the product 410 * 160 = 65600; adding ca_ofs and storing into the u16 ra_len truncates modulo 65536 (e.g. ca_ofs 64 gives ra_len 128), so the "fits in the page" check passes even though the client array described by log_clients extends far beyond the page. ntfs_check_log_client_array() then walks the array bounded only by the on-disk log_clients count: cr = ca + idx; if (cr->prev_client != LOGFILE_NO_CLIENT) ... For log_clients 410 i

  Product

  Linux

  What to do

  Apply the vendor’s update. The NVD record links to the advisory.

  Full record and what to do →NVD recordgit.kernel.orggit.kernel.org

• Aug 28, 2026In the Linux kernel, the following vulnerability has been resolved: perf sched: Fix register_pid() overflow, strcpy, and BUG_ON register_pid() has several issCVE-2026-80671 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67Critical 9.3

  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.

  Product

  Linux

  What to do

  Apply the vendor’s update. The NVD record links to the advisory.

  Full record and what to do →NVD recordgit.kernel.orggit.kernel.org

• Aug 28, 2026In the Linux kernel, the following vulnerability has been resolved: perf tools: Use perf_env__get_cpu_topology() in machine__resolve() machine__resolve() acceCVE-2026-80670 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67Critical 9.1

  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.

  Product

  Linux

  What to do

  Apply the vendor’s update. The NVD record links to the advisory.

  Full record and what to do →NVD recordgit.kernel.orggit.kernel.org

• Aug 28, 2026In the Linux kernel, the following vulnerability has been resolved: bpf: Disable xfrm_decode_session hook attachment BPF LSM programs can currently attach to CVE-2026-80669 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67

  In the Linux kernel, the following vulnerability has been resolved: bpf: Disable xfrm_decode_session hook attachment BPF LSM programs can currently attach to xfrm_decode_session(). That hook may return an error, but security_skb_classify_flow() calls it from a void path and triggers BUG_ON() if an error is returned. Disable BPF attachment to the hook to prevent a BPF LSM program from turning packet classification into a full panic.

  Product

  Linux

  What to do

  Apply the vendor’s update. The NVD record links to the advisory.

  Full record and what to do →NVD recordgit.kernel.orggit.kernel.org

• Aug 28, 2026In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_conntrack_expect: use conntrack GC to reap expectations This patch replaces CVE-2026-80668 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67Critical 9.8

  In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_conntrack_expect: use conntrack GC to reap expectations This patch replaces the timer API by GC worker approach for expectations, as it already happened in many other subsystems. Use the existing conntrack GC worker to iterate over the local list of expectations in the master conntrack to reap expired expectations. Check IPS_HELPER_BIT to run GC for expectations, set it on for nft_ct expectation which nevers sets it. Hold the expectation spinlock while iterating over the master conntrack expectation list to synchronize with nf_ct_remove_expectations(). This also performs runtime packet path garbage collection through the expectation insertion and lookup functions while walking over one of the chains of the global expectation hashtables. Unconfirmed conntrack entries are skipped since ct->ext can be reallocated and dying are skipped since those will be gone soon. Set on IPS_HELPER_BIT if the helper ct extension is added, then the new GC worker does not need to bump the ct refcount to check if the ct->ext helper is available. This removes the extra bump on the refcount for expectation timers, this a

  Product

  Linux

  What to do

  Apply the vendor’s update. The NVD record links to the advisory.

  Full record and what to do →NVD recordgit.kernel.orggit.kernel.org

• Aug 28, 2026In the Linux kernel, the following vulnerability has been resolved: net/mlx5: LAG, MPESW, Fix missing complete() on devcom error mlx5_mpesw_work() returned wiCVE-2026-80667 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67

  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.

  Product

  Linux

  What to do

  Apply the vendor’s update. The NVD record links to the advisory.

  Full record and what to do →NVD recordgit.kernel.orggit.kernel.org

• Aug 28, 2026In the Linux kernel, the following vulnerability has been resolved: Bluetooth: sco: Fix a race condition in sco_sock_timeout() sco_sock_timeout() runs asynchrCVE-2026-80666 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67

  In the Linux kernel, the following vulnerability has been resolved: Bluetooth: sco: Fix a race condition in sco_sock_timeout() sco_sock_timeout() runs asynchronously and lock_sock(sk). If the socket is closing while the timer is running, it holds the same lock (lock_sock(sk)) twice, leading to a deadlock. CPU 0 CPU 1 ==================== ====================== sco_sock_close() sco_sock_timeout() lock_sock(sk) // <-- LOCK __sco_sock_close() sco_chan_del() sco_conn_put() sco_conn_free() disable_delayed_work_sync() lock(sk) // <-- SAME LOCK Fix this by moving disable_delayed_work_sync() outside of lock_sock(sk), ensuring that no lock_sock(sk) is held before sco_sock_timeout(). Lockdep splat: WARNING: possible circular locking dependency detected 6.13.0-rc4 #7 Not tainted syz-executor292/9514 is trying to acquire lock: ffff8881115d5070 ((work_completion)(&(&conn->timeout_work)->work)){+.+.}-{0:0}, at: rcu_lock_acquire sect/v6.13-rc4/./include/linux/rcupdate.h:337 [inline] ffff8881115d5070 ((work_completion)(&(&conn->timeout_work)->work)){+.+.}-{0:0}, at: rcu_read_lock se

  Product

  Linux

  What to do

  Apply the vendor’s update. The NVD record links to the advisory.

  Full record and what to do →NVD recordgit.kernel.orggit.kernel.org

• Aug 28, 2026In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: nv: Inject SEA if kvm_translate_vncr() can't resolve PFN kvm_handle_vncr_abortCVE-2026-80665 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67High 7.1

  In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: nv: Inject SEA if kvm_translate_vncr() can't resolve PFN kvm_handle_vncr_abort() assumes that s1_walk_result conveys an abort when kvm_translate_vncr() returns -EFAULT. This is not always the case as it's possible to encounter 'late' failures on the output of S1 translation, e.g. a GFN outside of the memslots. Fix it by preparing an external abort before returning from kvm_translate_vncr(). Get rid of the BUG_ON() in the fault injection path while at it.

  Product

  Linux

  What to do

  Apply the vendor’s update. The NVD record links to the advisory.

  Full record and what to do →NVD recordgit.kernel.orggit.kernel.org

• Aug 28, 2026In the Linux kernel, the following vulnerability has been resolved: netfilter: xt_nat: reject unsupported target families xt_nat SNAT and DNAT target handlersCVE-2026-80664 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67High 7.3

  In the Linux kernel, the following vulnerability has been resolved: netfilter: xt_nat: reject unsupported target families xt_nat SNAT and DNAT target handlers assume IP-family conntrack state is present and can dereference a NULL pointer when instantiated from an unsupported family through nft_compat. A bridge-family compat rule can therefore trigger a NULL-dereference in nf_nat_setup_info(). Reject non-IP families in xt_nat_checkentry() so unsupported targets cannot be installed. Keep NFPROTO_INET allowed for valid inet NAT compat users and leave the runtime fast path unchanged. [ The crash was fixed via 9dbba7e694ec ("netfilter: nft_compat: ebtables emulation must reject non-bridge targets"), so this patch is no longer critical. Nevertheless, NAT is only relevant for ipv4/ipv6, so this extra family check is a good idea in any case. ]

  Product

  Linux

  What to do

  Apply the vendor’s update. The NVD record links to the advisory.

  Full record and what to do →NVD recordgit.kernel.orggit.kernel.org

• Aug 28, 2026In the Linux kernel, the following vulnerability has been resolved: tools/power/x86/intel-speed-select: Harden daemon pidfile open Avoid symlink-based pidfileCVE-2026-80663 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67High 7.1

  In the Linux kernel, the following vulnerability has been resolved: tools/power/x86/intel-speed-select: Harden daemon pidfile open Avoid symlink-based pidfile clobbering by opening the pidfile with O_NOFOLLOW and validating it with fstat() before locking/writing. The daemon currently uses a fixed pidfile path under /tmp. A local unprivileged user can pre-create a symlink at that path and cause a root-run daemon instance to write into an attacker-chosen file.

  Product

  Linux

  What to do

  Apply the vendor’s update. The NVD record links to the advisory.

  Full record and what to do →NVD recordgit.kernel.orggit.kernel.org

• Aug 28, 2026In 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 CapabCVE-2026-80662 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67High 7.1

  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

  Product

  Linux

  What to do

  Apply the vendor’s update. The NVD record links to the advisory.

  Full record and what to do →NVD recordgit.kernel.orggit.kernel.org

• Aug 28, 2026In the Linux kernel, the following vulnerability has been resolved: ufs: core: tracing: Do not dereference pointers in TP_printk() The trace events in driversCVE-2026-80661 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67High 7.8

  In the Linux kernel, the following vulnerability has been resolved: ufs: core: tracing: Do not dereference pointers in TP_printk() The trace events in drivers/ufs/core/ufs_trace.h were converted to take a pointer to the hba structure as an argument for the tracepoint and then in TP_printk() the printing of the dev_name from the ring buffer was converted to using the dev dereferenced pointer from the hba saved pointer. This is not allowed as the TP_printk() is executed at the time the trace event is read from /sys/kernel/tracing/trace file. That can happen literally, seconds, minutes, hours, weeks, days, or even months later! There is no guarantee that the hba pointer will still exist by the time it is dereferenced when the "trace" file is read. Instead, save the device name from the hba pointer at the time the tracepoint is called and place it into the ring buffer event. Then the TP_printk() can read the name directly from the ring buffer and remove the possibility that it will read a freed pointer and crash the kernel. This was detected when testing the trace event code that looks for TP_printk() parameters doing illegal derferences[1] [1] https://lore.kernel.org/all/2026063

  Product

  Linux

  What to do

  Apply the vendor’s update. The NVD record links to the advisory.

  Full record and what to do →NVD recordgit.kernel.orggit.kernel.org

• Aug 28, 2026In the Linux kernel, the following vulnerability has been resolved: hwmon: (occ) unregister sysfs devices outside occ lock occ_active(false) and occ_shutdown(CVE-2026-80660 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67

  In the Linux kernel, the following vulnerability has been resolved: hwmon: (occ) unregister sysfs devices outside occ lock occ_active(false) and occ_shutdown() unregister sysfs-backed devices while occ->lock is held. hwmon_device_unregister() and sysfs_remove_group() can wait for active sysfs callbacks to drain, and those callbacks can enter the OCC update path and try to take occ->lock again. That gives the unregister paths the lock ordering occ->lock -> sysfs callback drain, while a callback has the opposite edge sysfs callback -> occ->lock. This issue was found by our static analysis tool and then manually reviewed against the current tree. The grounded PoC kept the real unregister and callback carrier: occ_shutdown() hwmon_device_unregister() occ_show_temp_1() occ_update_response() Lockdep reported the circular dependency with occ_shutdown() already holding the OCC mutex and hwmon_device_unregister() waiting on the sysfs side: WARNING: possible circular locking dependency detected ... (sysfs_lock) ... at: hwmon_device_unregister+0x12/0x30 [vuln_msv] ... (&test_occ.lock) ... at: occ_shutdown.constprop.0+0xe/0x40 [vuln_msv] occ_update_response.isra.0+0xb/

  Product

  Linux

  What to do

  Apply the vendor’s update. The NVD record links to the advisory.

  Full record and what to do →NVD recordgit.kernel.orggit.kernel.org

• Aug 28, 2026In the Linux kernel, the following vulnerability has been resolved: mmc: vub300: defer reset until cmd_mutex is unlocked vub300_cmndwork_thread() holds cmd_muCVE-2026-80659 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67

  In the Linux kernel, the following vulnerability has been resolved: mmc: vub300: defer reset until cmd_mutex is unlocked vub300_cmndwork_thread() holds cmd_mutex while it sends a command and waits for the command response. If the response wait times out, __vub300_command_response() kills the command URBs and then synchronously resets the USB device through usb_reset_device(). That reset path re-enters the driver through vub300_pre_reset(), which also takes cmd_mutex. The worker therefore tries to acquire the same mutex recursively while it is still holding it from the command path. This issue was found by our static analysis tool and then manually reviewed against the current tree. The grounded PoC kept the real worker and timeout/reset carrier: vub300_cmndwork_thread() __vub300_command_response() usb_lock_device_for_reset() usb_reset_device() vub300_pre_reset() Lockdep reported the same-task recursive acquisition on cmd_mutex: WARNING: possible recursive locking detected ... (&test_vub300.cmd_mutex) ... at: usb_reset_device... [vuln_msv] ... (&test_vub300.cmd_mutex) ... at: vub300_cmndwork_thread+0x12/0x20 [vuln_msv] Workqueue: vub300_cmd_wq vub300_cmnd

  Product

  Linux

  What to do

  Apply the vendor’s update. The NVD record links to the advisory.

  Full record and what to do →NVD recordgit.kernel.orggit.kernel.org

• Aug 28, 2026In the Linux kernel, the following vulnerability has been resolved: drm/rockchip: dw_dp: Fix null-ptr-deref in dw_dp_remove() Attempting to access driver dataCVE-2026-80658 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67

  In the Linux kernel, the following vulnerability has been resolved: drm/rockchip: dw_dp: Fix null-ptr-deref in dw_dp_remove() Attempting to access driver data in the platform driver ->remove() callback may lead to a null pointer dereference since there is no guaranty that the component ->bind() callback invoking platform_set_drvdata() was executed. A common scenario is when Rockchip DRM driver didn't manage to run component_bind_all() because of an (unrelated) error causing early return from rockchip_drm_bind(). Drop the unnecessary call to platform_get_drvdata() and, instead, reference the target device structure via platform_device.

  Product

  Linux

  What to do

  Apply the vendor’s update. The NVD record links to the advisory.

  Full record and what to do →NVD recordgit.kernel.orggit.kernel.org

• Aug 28, 2026In the Linux kernel, the following vulnerability has been resolved: accel/amdxdna: Guard management mailbox channel cleanup against NULL pointer The managemenCVE-2026-80657 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67

  In the Linux kernel, the following vulnerability has been resolved: accel/amdxdna: Guard management mailbox channel cleanup against NULL pointer The management mailbox channel cleanup helpers can be called from error handling paths when mgmt_chann has already been destroyed. Add NULL checks to xdna_mailbox_free_channel() and xdna_mailbox_stop_channel() so the cleanup path safely returns instead of dereferencing a NULL mailbox channel pointer.

  Product

  Linux

  What to do

  Apply the vendor’s update. The NVD record links to the advisory.

  Full record and what to do →NVD recordgit.kernel.orggit.kernel.org

• Aug 28, 2026In the Linux kernel, the following vulnerability has been resolved: hfsplus: Add a sanity check for btree node size Syzbot reported an uninit-value bug in [1]CVE-2026-80656 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67High 7.8

  In the Linux kernel, the following vulnerability has been resolved: hfsplus: Add a sanity check for btree node size Syzbot reported an uninit-value bug in [1] with a corrupted HFS+ image, during the file system mounting process, specifically while loading the catalog, a corrupted node_size value of 1 caused the rec_off argument passed to hfs_bnode_read_u16() (within hfs_bnode_find()) to be excessively large. Consequently, the function failed to return a valid value to initialize the off variable, triggering the bug [1]. Every node starts from BTree node descriptor: struct hfs_bnode_desc. So, the size of node cannot be lesser than that. However, technical specification declares that: "The node size (which is expressed in bytes) must be power of two, from 512 through 32,768, inclusive." Add a check for btree node size base on technical specification. [1] BUG: KMSAN: uninit-value in hfsplus_bnode_find+0x141c/0x1600 fs/hfsplus/bnode.c:584 hfsplus_bnode_find+0x141c/0x1600 fs/hfsplus/bnode.c:584 hfsplus_btree_open+0x169a/0x1e40 fs/hfsplus/btree.c:382 hfsplus_fill_super+0x111f/0x2770 fs/hfsplus/super.c:553 get_tree_bdev_flags+0x6e6/0x920 fs/super.c:1694 get_tree_bdev+0x38/0x50 fs

  Product

  Linux

  What to do

  Apply the vendor’s update. The NVD record links to the advisory.

  Full record and what to do →NVD recordgit.kernel.orggit.kernel.org

• Aug 28, 2026In the Linux kernel, the following vulnerability has been resolved: soc: xilinx: Fix race condition in event registration The zynqmp_power driver registers haCVE-2026-80655 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67

  In the Linux kernel, the following vulnerability has been resolved: soc: xilinx: Fix race condition in event registration The zynqmp_power driver registers handlers for suspend and subsystem restart events using register_event(). However, the work structures (zynqmp_pm_init_suspend_work and zynqmp_pm_init_restart_work) used by these handlers were allocated and initialized after the registration call. This created a race window where, if the firmware triggered an event immediately after registration but before allocation, the callback (suspend_event_callback or subsystem_restart_event_callback) would dereference a NULL pointer in work_pending(), leading to a crash. Fix this by allocating and initializing the work structures before registering the events.

  Product

  Linux

  What to do

  Apply the vendor’s update. The NVD record links to the advisory.

  Full record and what to do →NVD recordgit.kernel.orggit.kernel.org

• Aug 28, 2026In the Linux kernel, the following vulnerability has been resolved: soc: xilinx: Shutdown and free rx mailbox channel A mbox rx channel is requested using mboCVE-2026-80654 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67

  In the Linux kernel, the following vulnerability has been resolved: soc: xilinx: Shutdown and free rx mailbox channel A mbox rx channel is requested using mbox_request_channel_byname() in probe. In remove callback, the rx mailbox channel is cleaned up when the rx_chan is NULL due to incorrect condition check. The mailbox channel is not shutdown and it can receive messages even after the device removal. This leads to use after free. Also the channel resources are not freed. Fix this by checking the rx_chan correctly.

  Product

  Linux

  What to do

  Apply the vendor’s update. The NVD record links to the advisory.

  Full record and what to do →NVD recordgit.kernel.orggit.kernel.org

• Aug 28, 2026In the Linux kernel, the following vulnerability has been resolved: scsi: hisi_sas: Add slave_destroy interface for v3 hw WARNING is triggered when executing CVE-2026-80653 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67High 8.4

  In the Linux kernel, the following vulnerability has been resolved: scsi: hisi_sas: Add slave_destroy interface for v3 hw WARNING is triggered when executing link reset of remote PHY and rmmod SAS driver simultaneously. Following is the WARNING log: WARNING: CPU: 61 PID: 21818 at drivers/base/core.c:1347 __device_links_no_driver+0xb4/0xc0 Call trace: __device_links_no_driver+0xb4/0xc0 device_links_driver_cleanup+0xb0/0xfc __device_release_driver+0x198/0x23c device_release_driver+0x38/0x50 bus_remove_device+0x130/0x140 device_del+0x184/0x434 __scsi_remove_device+0x118/0x150 scsi_remove_target+0x1bc/0x240 sas_rphy_remove+0x90/0x94 sas_rphy_delete+0x24/0x3c sas_destruct_devices+0x64/0xa0 [libsas] sas_revalidate_domain+0xe4/0x150 [libsas] process_one_work+0x1e0/0x46c worker_thread+0x15c/0x464 kthread+0x160/0x170 ret_from_fork+0x10/0x20 ---[ end trace 71e059eb58f85d4a ]--- During SAS phy up, link->status is set to DL_STATE_AVAILABLE in device_links_driver_bound, then this setting influences __device_links_no_driver() before driver rmmod and caused WARNING. Add the slave_destroy interface to make sure link is removed after flush workque.

  Product

  Linux

  What to do

  Apply the vendor’s update. The NVD record links to the advisory.

  Full record and what to do →NVD recordgit.kernel.orggit.kernel.org

• Aug 28, 2026In the Linux kernel, the following vulnerability has been resolved: crypto: ccp - Treat zero-length cert chain as query for blob lengths When handling a PDH eCVE-2026-80652 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67

  In the Linux kernel, the following vulnerability has been resolved: crypto: ccp - Treat zero-length cert chain as query for blob lengths When handling a PDH export, treat a zero-length userspace cert chain buffer as a request to query the length of the relevant blobs. Failure to account for the zero-length buffer trips a BUG_ON() when running with CONFIG_DEBUG_VIRTUAL=y due to trying to get the physical address of the ZERO_SIZE_PTR (returned by kzalloc() on the bogus allocation). kernel BUG at arch/x86/mm/physaddr.c:28 ! Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI CPU: 30 UID: 0 PID: 28580 Comm: syz.2.18 Kdump: loaded Tainted: G W 6.18.16-smp-DEV #1 NONE Tainted: [W]=WARN Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 12.62.0-0 11/19/2025 RIP: 0010:__phys_addr+0x16a/0x180 arch/x86/mm/physaddr.c:28 RSP: 0018:ffffc9008329fc80 EFLAGS: 00010293 RAX: ffffffff8179110a RBX: 0000778000000010 RCX: ffff8884e6992600 RDX: 0000000000000000 RSI: 0000000080000010 RDI: 0000778000000010 RBP: ffffc9008329fdf0 R08: 0000000000000dc0 R09: 00000000ffffffff R10: dffffc0000000000 R11: fffffbfff126d297 R12: dffffc0000000000 R13: 1ffff92010

  Product

  Linux

  What to do

  Apply the vendor’s update. The NVD record links to the advisory.

  Full record and what to do →NVD recordgit.kernel.orggit.kernel.org

• Aug 28, 2026In the Linux kernel, the following vulnerability has been resolved: crypto: ccp/sev-dev-tsm - bail out early when pdev->bus is NULL dsm_create() initially cheCVE-2026-80651 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67

  In the Linux kernel, the following vulnerability has been resolved: crypto: ccp/sev-dev-tsm - bail out early when pdev->bus is NULL dsm_create() initially checks pdev->bus when computing segment_id: u8 segment_id = pdev->bus ? pci_domain_nr(pdev->bus) : 0; But the next two lines unconditionally dereference pdev->bus via pcie_find_root_port() and especially pci_dev_id(pdev), which expands to PCI_DEVID(dev->bus->number, dev->devfn). If pdev->bus is in fact NULL, segment_id is initialised to 0 but the very next statement crashes the kernel. smatch flags this: drivers/crypto/ccp/sev-dev-tsm.c:253 dsm_create() error: we previously assumed 'pdev->bus' could be null (see line 251) Make the NULL handling consistent: if pdev->bus is NULL the device has no PCI context to work with and SEV TIO setup cannot proceed, so return -ENODEV before any of the bus-dependent lookups. The remaining initialisation now runs only on the path where pdev->bus is known to be valid. No change for callers where pdev->bus is non-NULL, which is the only case where dsm_create() did meaningful work before this change.

  Product

  Linux

  What to do

  Apply the vendor’s update. The NVD record links to the advisory.

  Full record and what to do →NVD recordgit.kernel.orggit.kernel.org

• Aug 28, 2026In the Linux kernel, the following vulnerability has been resolved: media: atomisp: gc2235: fix UAF and memory leak gc2235_probe() handles its error paths incCVE-2026-80650 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67

  In the Linux kernel, the following vulnerability has been resolved: media: atomisp: gc2235: fix UAF and memory leak gc2235_probe() handles its error paths incorrectly. If media_entity_pads_init() fails, gc2235_remove() is called, which tears down the subdev and frees dev, but then still falls through to atomisp_register_i2c_module(). This results in use-after-free. If atomisp_register_i2c_module() fails, the media entity and control handler are left initialized and dev is leaked. gc2235_remove() unconditionally calls media_entity_cleanup() and v4l2_ctrl_handler_free(), but these are not initialized at every error path in gc2235_probe(). Replace gc2235_remove() calls in the probe error paths with explicit unwind labels that free only the resources initialized at each point of failure, in reverse order of initialization.

  Product

  Linux

  What to do

  Apply the vendor’s update. The NVD record links to the advisory.

  Full record and what to do →NVD recordgit.kernel.orggit.kernel.org

• Aug 28, 2026In the Linux kernel, the following vulnerability has been resolved: firmware: arm_scmi: Fix OOB in scmi_power_name_get() scmi_power_name_get() does not validaCVE-2026-80649 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67High 7.8

  In the Linux kernel, the following vulnerability has been resolved: firmware: arm_scmi: Fix OOB in scmi_power_name_get() scmi_power_name_get() does not validate the domain number passed by the external caller, which may lead to an out-of-bounds access. Fix this by returning "unknown" for invalid domains, like scmi_reset_name_get() does.

  Product

  Linux

  What to do

  Apply the vendor’s update. The NVD record links to the advisory.

  Full record and what to do →NVD recordgit.kernel.orggit.kernel.org

• Aug 28, 2026In the Linux kernel, the following vulnerability has been resolved: pinctrl: spacemit: fix NULL check in spacemit_pin_set_config spacemit_pin_set_config() looCVE-2026-80648 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67

  In the Linux kernel, the following vulnerability has been resolved: pinctrl: spacemit: fix NULL check in spacemit_pin_set_config spacemit_pin_set_config() looks up the per-pin descriptor with spacemit_get_pin() then checks the wrong variable for failure: const struct spacemit_pin *spin = spacemit_get_pin(pctrl, pin); ... if (!pin) return -EINVAL; reg = spacemit_pin_to_reg(pctrl, spin->pin); pin is an unsigned int pin id, where 0 (GPIO_0 / gmac0_rxdv on K3) is a valid pin, so rejecting it here drops the PAD config write for the first pin of every group. On K3 Pico-ITX the GMAC RGMII group lists pin 0 as its first entry, so its drive-strength / bias configuration was silently ignored. The intended guard is against spacemit_get_pin() returning NULL when the pin id isn't in the SoC's pin table. Check spin instead, which both restores PAD setup for pin 0 and prevents a NULL deref on spin->pin.

  Product

  Linux

  What to do

  Apply the vendor’s update. The NVD record links to the advisory.

  Full record and what to do →NVD recordgit.kernel.orggit.kernel.org

• Aug 28, 2026In the Linux kernel, the following vulnerability has been resolved: RDMA/hns: Fix warning in poll cq direct mode CQs allocated by ib_alloc_cq() always have a CVE-2026-80647 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67

  In the Linux kernel, the following vulnerability has been resolved: RDMA/hns: Fix warning in poll cq direct mode CQs allocated by ib_alloc_cq() always have a comp_handler. Though in direct mode this handler is never expected to be called, it is still called when the driver is reset, triggering the following WARN_ONCE(): Call trace: ib_cq_completion_direct+0x38/0x60 hns_roce_cq_completion+0x54/0x90 (hns_roce_hw_v2] hns_roce_handle_device_err+Ox1c8/0x340 [hns_roce_hw_v2] hns_roce_hw_v2_uninit_instance.constprop.0+0x34/0x70 [hns_roce_hw_v2] hns_roce_hw_v2_reset_notify+0xc4/0xe0 [hns_roce_hw_v2] hclge_notify_roce_client+0x60/0xbc [hclge] hclge_reset_rebuild+0x48/0x34c [hclge] hclge_reset_subtask+0xcc/0xec [hclge] hclge_reset_service_task+0x80/0x160 [hclge] hclge_service_task+0x50/0x80 (hclge] process_one_work+0x1cc/0x4d0 worker_thread+0x154/0x414 kthread+0x104/0x144 ret_from_fork+0x10/0x18

  Product

  Linux

  What to do

  Apply the vendor’s update. The NVD record links to the advisory.

  Full record and what to do →NVD recordgit.kernel.orggit.kernel.org

• Aug 28, 2026In the Linux kernel, the following vulnerability has been resolved: ipv6: guard against possible NULL deref in __in6_dev_stats_get() dev_get_by_index_rcu() coCVE-2026-80646 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67High 7.5

  In the Linux kernel, the following vulnerability has been resolved: ipv6: guard against possible NULL deref in __in6_dev_stats_get() dev_get_by_index_rcu() could return NULL if the original physical device is unregistered. Found by Sashiko.

  Product

  Linux

  What to do

  Apply the vendor’s update. The NVD record links to the advisory.

  Full record and what to do →NVD recordgit.kernel.orggit.kernel.org

• Aug 28, 2026In the Linux kernel, the following vulnerability has been resolved: rapidio/tsi721: prevent a bad dereference in tsi721_db_dpc() With a list_for_each() loop, CVE-2026-80645 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67High 8.1

  In the Linux kernel, the following vulnerability has been resolved: rapidio/tsi721: prevent a bad dereference in tsi721_db_dpc() With a list_for_each() loop, if we don't find the item we are looking for in the list, then the loop exits with the iterator, which is "dbell" in this loop, pointing to invalid memory. This code uses the "found" variable to determine if we have found the doorbell we are looking for or not. However, the problem that the "found" variable needs to be set to false at the start of each iteration, otherwise after the first correct doorbell, then everything is marked as found. Reset the "found" to false at the start of the iteration and move the variable inside the loop.

  Product

  Linux

  What to do

  Apply the vendor’s update. The NVD record links to the advisory.

  Full record and what to do →NVD recordgit.kernel.orggit.kernel.org

• Aug 28, 2026In the Linux kernel, the following vulnerability has been resolved: ocfs2: don't BUG_ON an invalid journal dinode [BUG] A fuzzed OCFS2 image can corrupt the cCVE-2026-80644 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67

  In the Linux kernel, the following vulnerability has been resolved: ocfs2: don't BUG_ON an invalid journal dinode [BUG] A fuzzed OCFS2 image can corrupt the current slot journal dinode while mount is still in progress. The mount path first reports the invalid journal block and then crashes in shutdown: kernel BUG at fs/ocfs2/journal.c:1034! Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI RIP: 0010:ocfs2_journal_toggle_dirty+0x2d6/0x340 fs/ocfs2/journal.c:1034 Call Trace: ocfs2_journal_shutdown+0x414/0xc30 fs/ocfs2/journal.c:1116 ocfs2_mount_volume fs/ocfs2/super.c:1785 [inline] ocfs2_fill_super+0x30a9/0x3cd0 fs/ocfs2/super.c:1083 get_tree_bdev_flags+0x38b/0x640 fs/super.c:1698 get_tree_bdev+0x24/0x40 fs/super.c:1721 ocfs2_get_tree+0x21/0x30 fs/ocfs2/super.c:1184 vfs_get_tree+0x9a/0x370 fs/super.c:1758 fc_mount fs/namespace.c:1199 [inline] do_new_mount_fc fs/namespace.c:3642 [inline] do_new_mount fs/namespace.c:3718 [inline] path_mount+0x5b8/0x1ea0 fs/namespace.c:4028 do_mount fs/namespace.c:4041 [inline] __do_sys_mount fs/namespace.c:4229 [inline] __se_sys_mount fs/namespace.c:4206 [inline] __x64_sys_mount+0x282/0x320 fs/namespace.c:4206 ... [CAUSE] ocfs2_journa

  Product

  Linux

  What to do

  Apply the vendor’s update. The NVD record links to the advisory.

  Full record and what to do →NVD recordgit.kernel.orggit.kernel.org

• Aug 28, 2026In the Linux kernel, the following vulnerability has been resolved: EDAC/igen6: Fix call trace due to missing release() When unloading the igen6_edac driver, CVE-2026-80643 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67

  In the Linux kernel, the following vulnerability has been resolved: EDAC/igen6: Fix call trace due to missing release() When unloading the igen6_edac driver, there is a call trace: Device '(null)' does not have a release() function, it is broken and must be fixed. See Documentation/core-api/kobject.rst. WARNING: drivers/base/core.c:2567 at device_release+0x84/0x90, CPU#5: rmmod/127209 ... RIP: 0010:device_release+0x84/0x90 Call Trace: <TASK> kobject_put+0x8c/0x220 put_device+0x17/0x30 igen6_unregister_mcis+0xa2/0xe0 [igen6_edac] igen6_remove+0x82/0xb0 [igen6_edac] ... Fix the call trace by providing empty release() functions for the memory controller devices.

  Product

  Linux

  What to do

  Apply the vendor’s update. The NVD record links to the advisory.

  Full record and what to do →NVD recordgit.kernel.orggit.kernel.org

• Aug 28, 2026In the Linux kernel, the following vulnerability has been resolved: liveupdate: Reference count incoming FLB data Increment the incoming FLB refcount in liveuCVE-2026-80642 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67

  In the Linux kernel, the following vulnerability has been resolved: liveupdate: Reference count incoming FLB data Increment the incoming FLB refcount in liveupdate_flb_get_incoming() so that the FLB structure cannot be freed while the caller is actively using it. Add an additional liveupdate_flb_put_incoming() function so the caller can explicitly indicate when it is done using the FLB data. During a Live Update, a subsystem might need to hold onto the incoming File-Lifecycle-Bound (FLB) data for an extended period, such as during device enumeration. Incrementing the reference count guarantees that the data remains valid and accessible until the subsystem releases it, preventing future use-after-free bugs.

  Product

  Linux

  What to do

  Apply the vendor’s update. The NVD record links to the advisory.

  Full record and what to do →NVD recordgit.kernel.orggit.kernel.org

• Aug 28, 2026In the Linux kernel, the following vulnerability has been resolved: wifi: wlcore: enable the right set of ciphers The firmware version number check for IGTK iCVE-2026-80641 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67

  In the Linux kernel, the following vulnerability has been resolved: wifi: wlcore: enable the right set of ciphers The firmware version number check for IGTK introduced in commit c34dbc5900b0 ("wifi: wlcore: Add support for IGTK key") lets the amount of ciphers decrease on every boot of a too old firmware and that is practically happening. It also does not take into account other chips than the wl18xx. On some wl128x, the following can be observed when connecting via nm to a common ap: [ 484.113311] wlcore: WARNING could not set keys [ 484.117828] wlcore: ERROR Could not add or replace key [ 484.123016] wlan0: failed to set key (5, ff:ff:ff:ff:ff:ff) to hardware (-5) [ 484.123046] wlcore: Hardware recovery in progress. FW ver: Rev 7.3.10.0.142 [ 484.139923] wlcore: pc: 0x0, hint_sts: 0x00000048 count: 1 [ 484.145721] wlcore: down [ 484.148986] ieee80211 phy0: Hardware restart was requested [ 484.610473] wlcore: firmware booted (Rev 7.3.10.0.142) [ 484.633758] wlcore: Association completed. [ 484.690490] wlcore: ERROR command execute failure 14 [ 484.690490] ------------[ cut here ]------------ [ 484.700195] WARNING: drivers/net/wireless/ti/wlcore/main.c:872 at wl12xx

  Product

  Linux

  What to do

  Apply the vendor’s update. The NVD record links to the advisory.

  Full record and what to do →NVD recordgit.kernel.orggit.kernel.org

• Aug 28, 2026In the Linux kernel, the following vulnerability has been resolved: cxl/fwctl: Fix __fortify_panic Fix a runtime assertion in cxlctl_get_supported_features().CVE-2026-80640 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67

  In the Linux kernel, the following vulnerability has been resolved: cxl/fwctl: Fix __fortify_panic Fix a runtime assertion in cxlctl_get_supported_features(). Fortify complains that it is potentially overflowing the entries array per __counted_by_le(num_entries). Quiet the false positive by initializing @num_entries earlier. memcpy: detected buffer overflow: 48 byte write of buffer size 0 WARNING: lib/string_helpers.c:1036 at __fortify_report+0x4d/0xa0, CPU#7: fwctl/1398 RIP: 0010:__fortify_report+0x50/0xa0 Call Trace: __fortify_panic+0xd/0xf cxlctl_get_supported_features.cold+0x23/0x35 [cxl_core]

  Product

  Linux

  What to do

  Apply the vendor’s update. The NVD record links to the advisory.

  Full record and what to do →NVD recordgit.kernel.orggit.kernel.org

• Aug 28, 2026In the Linux kernel, the following vulnerability has been resolved: cxl/test: Fix __fortify_panic Fix a runtime assertion in setup_xor_mapping().CVE-2026-80639 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67

  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. ]

  Product

  Linux

  What to do

  Apply the vendor’s update. The NVD record links to the advisory.

  Full record and what to do →NVD recordgit.kernel.orggit.kernel.org

Where this comes from: the exploited list is CISA’s Known Exploited Vulnerabilities catalog. Everything else is the whole National Vulnerability Database, where each record is published by the team that found the bug (Wordfence, Patchstack, WPScan, the vendors themselves and others); we show who. Exploit odds are FIRST’s EPSS, updated daily. Titles and categories are ours, so check the linked record before acting on a detail. For a write-up of the big ones, see our advisories. Every vendor, and every WordPress plugin and theme with a recorded flaw, also has its own page. All of it is free to reuse as JSON, CSV or RSS.