Vulnerability database

21,994 results · page 36 of 440

• Sep 17, 2026In the Linux kernel, the following vulnerability has been resolved: platform/surface: acpi-notify: Check ACPI companion before use Since every platform driverCVE-2026-93114 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67

  In the Linux kernel, the following vulnerability has been resolved: platform/surface: acpi-notify: Check ACPI companion before use Since every platform driver can be forced to match a device that doesn't match its list of device IDs because of device_match_driver_override(), platform drivers that rely on the existence of a device's ACPI companion object should verify its presence. san_probe() dereferences the result of ACPI_COMPANION() when installing the GSBUS address space handler, so force-binding the driver to a device without an ACPI companion leads to a NULL pointer dereference. The dereference was introduced when the probe function was switched from ACPI_HANDLE() to ACPI_COMPANION(). Check the ACPI companion against NULL and return -ENODEV when it is missing, like commit e4865a56d013 ("ACPI: driver: Check ACPI_COMPANION() against NULL during probe") does for the core ACPI platform drivers.

  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

• Sep 17, 2026In the Linux kernel, the following vulnerability has been resolved: clk: qcom: camcc-sc8280xp: unregister CAMCC_GDSC_CLK With the introduction of sync_state sCVE-2026-93113 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67

  In the Linux kernel, the following vulnerability has been resolved: clk: qcom: camcc-sc8280xp: unregister CAMCC_GDSC_CLK With the introduction of sync_state support in the clk and pmdomain subsystems, the following warning happens when the unused clocks are shutdown in camcc-sc8280xp: [ 15.408367] titan_top_gdsc status stuck at 'on' [ 15.408429] WARNING: drivers/clk/qcom/gdsc.c:178 at gdsc_toggle_logic+0x14c/0x160, CPU#2: kworker/u32:1/14 [ 15.408462] Modules linked in: bnep vfat fat ath11k_pci(+) ath11k mac80211 cfg80211 mhi libarc4 snd_soc_wcd938x snd_soc_wcd938x_sdw snd_soc_wcd_classh hci_uart snd_soc_wcd_common snd_soc_sc8280xp soundwire_qcom snd_soc_wcd_mbhc snd_soc_qcom_sdw slimbus snd_soc_qcom_common regmap_sdw btqca btrtl qcom_camss soundwire_bus btbcm btintel snd_soc_sdca snd_soc_lpass_wsa_macro bluetooth snd_soc_lpass_tx_macro snd_soc_lpass_va_macro snd_soc_lpass_rx_macro snd_soc_hdmi_codec snd_soc_lpass_macro_common videobuf2_dma_sg ov5675 v4l2_fwnode videobuf2_memops qcom_spmi_adc5 snd_soc_core qcom_spmi_adc_tm5 videobuf2_v4l2 snd_seq snd_seq_device videobuf2_common v4l2_async qcom_vadc_common qcom_spmi_temp_alarm pm8941_pwrkey industria

  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

• Sep 17, 2026In the Linux kernel, the following vulnerability has been resolved: bpf: Require a BPF cpumask for bpf_cpumask_populate() bpf_cpumask_populate() writes to itsCVE-2026-93112 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67High 7.1

  In the Linux kernel, the following vulnerability has been resolved: bpf: Require a BPF cpumask for bpf_cpumask_populate() bpf_cpumask_populate() writes to its destination with bitmap_copy(), but the destination is typed as struct cpumask *. That allows the verifier to accept borrowed cpumask pointers returned by read-only kfuncs, such as scx_bpf_get_online_cpumask(), as a writable destination. Make the destination a struct bpf_cpumask * so populate follows the same ownership rule as the other mutating cpumask kfuncs. Query kfuncs continue to accept const struct cpumask * inputs.

  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

• Sep 17, 2026In the Linux kernel, the following vulnerability has been resolved: bpf: Mark tracing_multi trampolines as ftrace managed Since tracing_multi link does not seCVE-2026-93111 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67High 7.8

  In the Linux kernel, the following vulnerability has been resolved: bpf: Mark tracing_multi trampolines as ftrace managed Since tracing_multi link does not set ftrace_managed, it would fail to release the tracing_multi link when attaching tracing_multi link and then attaching fentry link. [ 3.714215] WARNING: kernel/bpf/trampoline.c:1727 at bpf_trampoline_multi_detach+0x20b/0x240, CPU#1: test_progs/97 ... [ 3.733170] bpf_tracing_multi_link_release+0x14/0x30 [ 3.733890] bpf_link_free+0x58/0x130 [ 3.734414] bpf_link_release+0x23/0x30 Fix it by setting 'ftrace_managed = true' in register_fentry_multi().

  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

• Sep 17, 2026In the Linux kernel, the following vulnerability has been resolved: RDMA/core: Wait for RCU callbacks before unloading ib_core put_gid_ndev() is queued with cCVE-2026-93110 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67

  In the Linux kernel, the following vulnerability has been resolved: RDMA/core: Wait for RCU callbacks before unloading ib_core put_gid_ndev() is queued with call_rcu() and implemented in ib_core. Stopping the workqueues does not drain callbacks already queued, so RCU could invoke it after the module code has been unloaded. synchronize_rcu() does not wait for callbacks. Wait for them after all producers have stopped.

  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

• Sep 17, 2026In the Linux kernel, the following vulnerability has been resolved: RDMA/mlx5: Drain RCU callbacks during module teardown devx_free_subscription() can remain CVE-2026-93109 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67

  In the Linux kernel, the following vulnerability has been resolved: RDMA/mlx5: Drain RCU callbacks during module teardown devx_free_subscription() can remain queued after the last DevX event file drops its module reference or an auxiliary driver detaches its devices. mlx5_ib can then unload before the callback runs. Registration error unwind has the same risk because driver registration can attach existing devices before failing. Wait after all drivers have stopped.

  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

• Sep 17, 2026In the Linux kernel, the following vulnerability has been resolved: RDMA/ipoib: Drain RCU callbacks during module teardown IPoIB reclamation completions can bCVE-2026-93108 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67

  In the Linux kernel, the following vulnerability has been resolved: RDMA/ipoib: Drain RCU callbacks during module teardown IPoIB reclamation completions can be signaled from inside an RCU callback. Teardown can wake before the callback returns and unload ib_ipoib while its code is still executing. Client registration failure can also remove already-added devices and queue callbacks. Wait after client and workqueue teardown.

  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

• Sep 17, 2026In the Linux kernel, the following vulnerability has been resolved: RDMA/rxe: Avoid reprocessing the current packet after the QP enters the error state When dCVE-2026-93107 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67High 8.2

  In the Linux kernel, the following vulnerability has been resolved: RDMA/rxe: Avoid reprocessing the current packet after the QP enters the error state When do_complete() finds the QP in the error state it returns RESPST_CHK_RESOURCE. Before commit 49dc9c1f0c7e ("RDMA/rxe: Cleanup reset state handling in rxe_resp.c") this was the flush loop: check_resource() had an error-state branch that fetched each remaining recv WQE and completed it with IB_WC_WR_FLUSH_ERR, without touching the current packet. That commit removed the error-state branch from check_resource() (draining is now done at rxe_receiver() entry) but kept the do_complete() error-state return. As a result, when a QP moves to the error state while a packet is being completed - e.g. an rdma_cm disconnect racing with receive processing - the responder state machine loops back into the request processing chain with the already-completed packet still in hand: check_resource() fetches a fresh recv WQE, execute()/send_data_in() copies the same packet payload again, do_complete() posts another IB_WC_SUCCESS CQE (qp->resp.status is still 0), and control returns to the error-state check. The loop re-executes the same packet o

  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

• Sep 17, 2026In the Linux kernel, the following vulnerability has been resolved: crash_dump: release keyring reference at the correct time restore_dm_crypt_keys_to_thread_CVE-2026-93106 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67

  In the Linux kernel, the following vulnerability has been resolved: crash_dump: release keyring reference at the correct time restore_dm_crypt_keys_to_thread_keyring() gets a reference to the user keyring before restoring the saved dm-crypt keys. The same keyring reference is then passed to add_key_to_keyring() for each saved key, but add_key_to_keyring() drops that reference on every call. This is only balanced when exactly one key is restored. With multiple keys, the keyring reference is dropped too many times and may trigger a refcount underflow or use-after-free. When more than five keys are restored, a refcount underflow/use-after-free warning can be triggered. The early error paths after lookup_user_key() also return without dropping the keyring reference. Keep ownership of the keyring reference in restore_dm_crypt_keys_to_thread_keyring(), drop it once on all exit paths, and make add_key_to_keyring() only use the reference without consuming 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

• Sep 17, 2026In the Linux kernel, the following vulnerability has been resolved: esp: do not unref managed frag pages in esp_ssg_unref() esp_ssg_unref() releases the page CVE-2026-93105 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67High 7.8

  In the Linux kernel, the following vulnerability has been resolved: esp: do not unref managed frag pages in esp_ssg_unref() esp_ssg_unref() releases the page references held on the source scatterlist after the AEAD operation completes. It calls skb_page_unref() on every frag page for an out-of-place transform (req->src != req->dst), and in the error path of esp_output_tail() (already_unref == true) on the request's own scatterlist. This is wrong when the skb carries managed frags (SKBFL_MANAGED_FRAG_REFS). Managed frags are owned by a zerocopy ubuf and the skb does not hold a per-frag page reference; io_uring SEND_ZC with a registered buffer attaches the bvec pages this way via io_sg_from_iter(). The rest of the stack honours this invariant: skb_release_data() skips the per-frag unref when SKBFL_MANAGED_FRAG_REFS is set, and skb_zcopy_managed() is the guard used at the other unref sites. esp_ssg_unref() is missing that guard, so for a managed-frag skb it drops a page reference the skb never acquired. This can underflow the page reference count and free a page that is still in use. Guard the function with skb_zcopy_managed() so both unref paths are skipped for managed-frag

  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

• Sep 17, 2026In the Linux kernel, the following vulnerability has been resolved: RDMA/rvt: Return NULL after port allocation failure rvt_alloc_device() deallocates the IB CVE-2026-93104 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67

  In the Linux kernel, the following vulnerability has been resolved: RDMA/rvt: Return NULL after port allocation failure rvt_alloc_device() deallocates the IB device when its port array cannot be allocated but then returns the pointer to the released allocation. Callers treat any non-NULL value as valid and dereference it, resulting in a use-after-free. Return NULL immediately after deallocation so callers can propagate the allocation 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

• Sep 17, 2026In the Linux kernel, the following vulnerability has been resolved: RDMA/hfi1: Preserve unit 0 on allocation failure hfi1_free_devdata() assumes that the deviCVE-2026-93103 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67

  In the Linux kernel, the following vulnerability has been resolved: RDMA/hfi1: Preserve unit 0 on allocation failure hfi1_free_devdata() assumes that the device was inserted into the unit table and unconditionally erases dd->unit. If xa_alloc_irq() fails, the zero-initialized unit remains zero, so full cleanup can remove an unrelated device from index 0. Release only the rdmavt allocation and return immediately while the unit table has not acquired the 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

• Sep 17, 2026In the Linux kernel, the following vulnerability has been resolved: RDMA/hfi1: Free RX data on late probe failure hfi1_init_dd() allocates the shared AIP/VNICCVE-2026-93102 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67

  In the Linux kernel, the following vulnerability has been resolved: RDMA/hfi1: Free RX data on late probe failure hfi1_init_dd() allocates the shared AIP/VNIC RX support before returning. If hfi1_init() or hfi1_register_ib_device() later fails, init_one() tears down the device data without calling hfi1_free_rx(). This leaks netdev_rx and its dummy netdev. Free the RX support after IB unregistration and before postinit_cleanup(), as done on normal device removal.

  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

• Sep 17, 2026In the Linux kernel, the following vulnerability has been resolved: media: v4l2-async: Unregister sub-device if asc_list is empty When my em28xx USB device thCVE-2026-93101 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67

  In the Linux kernel, the following vulnerability has been resolved: media: v4l2-async: Unregister sub-device if asc_list is empty When my em28xx USB device that uses the i2c tvp5150 driver is disconnected, it crashes. The cause is that the tvp5150 i2c module uses v4l2_async, but the em28xx driver does not since it predates v4l2_async. In that corner case sd->asc_list is empty, so v4l2_async_unregister_subdev() never calls v4l2_device_unregister_subdev(). Modify the code so that, if sd->asc_list is empty, v4l2_device_unregister_subdev() is still called.

  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

• Sep 17, 2026In the Linux kernel, the following vulnerability has been resolved: fs/resctrl: Prevent use-after-free in rdtgroup_kn_put() A struct rdtgroup is reference couCVE-2026-93100 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67

  In the Linux kernel, the following vulnerability has been resolved: fs/resctrl: Prevent use-after-free in rdtgroup_kn_put() A struct rdtgroup is reference counted via rdtgroup::waitcount. Callers that need the structure to remain valid across a sleep (while waiting on acquiring rdtgroup_mutex) take a reference with rdtgroup_kn_get() and release it with rdtgroup_kn_put(). The release path is intended to serve as the fallback freer: if the count drops to zero and the group has already been marked RDT_DELETED, rdtgroup_kn_put() frees the structure. The bulk teardown paths free_all_child_rdtgrp() and rmdir_all_sub() resulting from a resctrl directory remove or resctrl fs unmount act as the primary freer: they hold rdtgroup_mutex and free each rdtgroup whose waitcount is zero, otherwise they set RDT_DELETED and leave the freeing to the last waiter. These two freers race. rdtgroup_kn_put() commits waitcount == 0 with atomic_dec_and_test() outside rdtgroup_mutex, then reads rdtgroup::flags. Between those two operations a concurrent caller of free_all_child_rdtgrp() or rmdir_all_sub() (which holds the mutex) can observe waitcount == 0 via atomic_read(), call rdtgroup_remove(), and kfr

  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

• Sep 17, 2026In the Linux kernel, the following vulnerability has been resolved: fs/resctrl: Fix UAF from worker threads when domains are removed The mbm_handle_overflow()CVE-2026-93099 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67

  In the Linux kernel, the following vulnerability has been resolved: fs/resctrl: Fix UAF from worker threads when domains are removed The mbm_handle_overflow() and cqm_handle_limbo() workers read event counters and may sleep while doing so. They are scheduled via delayed_work embedded in struct rdt_l3_mon_domain. Architecture allocates and frees these domains from CPU hotplug callbacks under cpus_write_lock(), and the workers acquire cpus_read_lock() to keep the domain alive across their access. A use-after-free can occur when a worker is blocked waiting for cpus_read_lock() while the hotplug core holds cpus_write_lock(): the architecture frees the rdt_l3_mon_domain that contains the worker's work_struct. When the worker unblocks, the container_of() it performs on the embedded work pointer dereferences freed memory. Drop cpus_read_lock() from the workers and instead drain pending and in-flight work synchronously before the architecture can free the domain. Since architecture offlines the domain under cpus_write_lock() after it has been unlinked from the RCU list and a grace period has elapsed, no new work can be scheduled. The cancel only needs to wait out existing work. Drop

  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

• Sep 17, 2026In the Linux kernel, the following vulnerability has been resolved: rpmsg: glink: fix deadlock in endpoint destroy during driver detach During driver detach, CVE-2026-93098 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67

  In the Linux kernel, the following vulnerability has been resolved: rpmsg: glink: fix deadlock in endpoint destroy during driver detach During driver detach, the device core holds the device mutex throughout the driver's remove callback chain. When the rpmsg endpoint is destroyed as part of that teardown, the GLINK endpoint destroy implementation attempts to unregister the underlying rpmsg device. That unregistration calls device_del(), which tries to re-acquire the same device mutex already held higher up the stack, causing rmmod to hang indefinitely. The deadlock manifests with the following call chain: [<0>] device_del+0x44/0x414  <- tries to acquire same mutex [<0>] device_unregister+0x18/0x34 [<0>] rpmsg_unregister_device+0x28/0x4c [<0>] qcom_glink_remove_rpmsg_device+0x70/0xc0 [<0>] qcom_glink_destroy_ept+0x58/0xbc [<0>] rpmsg_dev_remove+0x50/0x60 [<0>] device_remove+0x4c/0x80 [<0>] device_release_driver_internal+0x1cc/0x228 <- acquires device mutex [<0>] driver_detach+0x4c/0x98 [<0>] bus_remove_driver+0x6c/0xbc [<0>] driver_unregister+0x30/0x60 [<0>] unregister_rpmsg_driver+0x10/0x1c [<0>] fastrpc_exit+0x28/0x38 [fastrpc] [<0>] __arm64_sys_delete_module+0x1b8/0x294 [<0

  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

• Sep 17, 2026In the Linux kernel, the following vulnerability has been resolved: cxl/mbox: Break poison list loop on an empty payload A device that returns count == 0 withCVE-2026-93097 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67

  In the Linux kernel, the following vulnerability has been resolved: cxl/mbox: Break poison list loop on an empty payload A device that returns count == 0 with CXL_POISON_FLAG_MORE set on every iteration never advances nr_records, so the max_errors guard never trips and the do/while loops forever while holding poison.mutex. That hangs the sysfs-triggered scan thread and blocks all subsequent poison operations on the device. The existing "Protect against an uncleared _FLAG_MORE" guard was intended to bound a misbehaving device but does not cover the count == 0 case. Stop the loop on an empty payload so a malfunctioning or malicious device cannot wedge the poison scan.

  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

• Sep 17, 2026In the Linux kernel, the following vulnerability has been resolved: cxl/features: Serialize multi-part Get/Set Feature transfers A Get or Set Feature payload CVE-2026-93096 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67

  In the Linux kernel, the following vulnerability has been resolved: cxl/features: Serialize multi-part Get/Set Feature transfers A Get or Set Feature payload larger than the mailbox payload size is split into several mailbox commands. mbox_mutex only serializes individual mailbox commands and is dropped between iterations of these loops. Nothing serializes the multi-part transfer as a whole. cxl_get_feature() and cxl_set_feature() are reachable concurrently from fwctl (per-fd RPCs run under a read-held registration lock) and from the EDAC scrub/ECS/repair paths, so two transfers to the same mailbox can interleave their parts and corrupt the device's transfer context. Add a per-mailbox feat_mutex and hold it across the whole transfer in both functions. It nests outside mbox_mutex (which is taken inside cxl_internal_send_cmd()), and is taken nowhere else, so no lock-ordering inversion is introduced.

  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

• Sep 17, 2026In the Linux kernel, the following vulnerability has been resolved: hfsplus: validate thread record before delete key rebuild hfsplus_delete_cat() is called wCVE-2026-93095 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67High 7.8

  In the Linux kernel, the following vulnerability has been resolved: hfsplus: validate thread record before delete key rebuild hfsplus_delete_cat() is called with str == NULL when the last open reference to an unlinked HFS+ hardlink backing inode is closed. In that case, the function finds the catalog thread by CNID and rebuilds the catalog key from thread.nodeName. That reconstruction path reads thread.nodeName.length directly from the catalog B-tree into fd.search_key and then copies length * 2 bytes into fd.search_key->cat.name.unicode. It does not first check that the found record is a thread record or that its size matches the thread name. A corrupted image can therefore provide an oversized thread name length and make hfs_bnode_read() write past the catalog search-key allocation. Read the CNID record through hfsplus_brec_read_cat(), which bounds the record read to sizeof(hfsplus_cat_entry) and verifies that a thread record's size exactly matches nodeName.length. Together, these checks ensure an accepted thread name fits HFSPLUS_MAX_STRLEN. Reject non-thread records before building the delete key from the validated thread name. Share the thread-record-type helper between

  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

• Sep 17, 2026In the Linux kernel, the following vulnerability has been resolved: wifi: ath12k: fix dp_link_peer dangling references on AP vdev rollback ath12k_mac_vdev_creCVE-2026-93094 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67

  In the Linux kernel, the following vulnerability has been resolved: wifi: ath12k: fix dp_link_peer dangling references on AP vdev rollback ath12k_mac_vdev_create() for an AP vdev creates the bss self-peer via ath12k_peer_create(), which finishes by calling ath12k_dp_link_peer_assign() to publish the dp_link_peer in the dp_hw->dp_peers[peerid_index] RCU table, in the dp_peer's link_peers[] array, and in the per-addr rhashtable. If a step after ath12k_peer_create() fails the function jumps to err_peer_del, which open-codes a WMI peer_delete and waits for the unmap / delete_resp events. The wait_for_peer_delete_done() path relies on ath12k_dp_link_peer_unmap_event() freeing the dp_link_peer when the unmap arrives, but err_peer_del never calls ath12k_dp_link_peer_unassign() first. The published references in the dp_hw RCU table, dp_peer->link_peers[] and the rhashtable are left pointing at the dp_link_peer that unmap_event then frees, producing dangling pointers and use-after-free on subsequent lookups. Replace the open-coded sequence with a call to ath12k_peer_delete(), which already does ath12k_dp_link_peer_unassign() before sending the WMI command. This drops the published refer

  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

• Sep 17, 2026In the Linux kernel, the following vulnerability has been resolved: firmware: arm_scmi: Publish channel state before callbacks Transport setup can enable callCVE-2026-93093 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67

  In the Linux kernel, the following vulnerability has been resolved: firmware: arm_scmi: Publish channel state before callbacks Transport setup can enable callbacks before the setup routine returns. mailbox_chan_setup() registers the mailbox client with mbox_request_channel(), and the mailbox controller startup path can enable interrupt delivery before SCMI mailbox channel state has been published. Similarly, smc_chan_setup() requests the optional A2P completion IRQ before the SMC transport has made its cinfo pointer visible. If a pending or spurious callback fires in those windows, the transport RX callback can dereference a NULL transport cinfo pointer. Publishing only the transport-private pointer is not sufficient either: an early callback can enter the SCMI core before scmi_chan_setup() has assigned cinfo->handle. The core derives scmi_info from cinfo->handle in the RX path, so a NULL handle can still fault even when the transport-private cinfo is valid. Assign cinfo->handle before invoking the transport setup callback. Publish the mailbox and SMC transport-private channel state before requesting the mailbox channels or IRQ, and clear the early-published pointers again on s

  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

• Sep 17, 2026In the Linux kernel, the following vulnerability has been resolved: firmware: arm_scmi: Unregister device notifier before IDR teardown The requested-devices nCVE-2026-93092 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67

  In the Linux kernel, the following vulnerability has been resolved: firmware: arm_scmi: Unregister device notifier before IDR teardown The requested-devices notifier looks up protocol fwnodes from the active_protocols IDR. During remove, unregister the notifier before releasing and destroying active_protocols so no notifier callback can race with the IDR teardown. Keep the bus notifier registered until after the protocol state is torn down, matching the existing remove ordering for SCMI bus users.

  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

• Sep 17, 2026In the Linux kernel, the following vulnerability has been resolved: firmware: arm_scmi: Quiesce notifications before teardown scmi_notification_exit() clears CVE-2026-93091 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67

  In the Linux kernel, the following vulnerability has been resolved: firmware: arm_scmi: Quiesce notifications before teardown scmi_notification_exit() clears and releases the notification instance, but transport callbacks can still deliver incoming notifications until the TX/RX channels are freed. During remove, an RX interrupt in that window can enter scmi_notify() while notification state is being torn down and then dereference freed memory. The same ordering exists on the probe error path after notification initialization. The notification late-init worker has a separate lifetime issue: protocol event registration queues ni->init_work on the system workqueue, so destroying ni->notify_wq does not drain that work. If the devres group is released while init_work is still pending or running, the late-init worker can dereference the freed notification instance. Quiesce the notification core before TX/RX channels are torn down, then clean up the channels before releasing the notification core resources. Use disable_work_sync() so future late-init queueing is rejected and any already queued or running late-init work has completed before channel teardown starts.

  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

• Sep 17, 2026In the Linux kernel, the following vulnerability has been resolved: firmware: arm_scmi: Clean up channels on setup failure scmi_channels_setup() can fail afteCVE-2026-93090 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67

  In the Linux kernel, the following vulnerability has been resolved: firmware: arm_scmi: Clean up channels on setup failure scmi_channels_setup() can fail after the common BASE channel or earlier protocol channels have already been registered in the TX/RX IDRs. Route this failure through the existing channel cleanup label so the transport channels, transport devices and IDR state created before the failure are released before the probe error path frees the SCMI instance ID.

  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

• Sep 17, 2026In the Linux kernel, the following vulnerability has been resolved: firmware: arm_scmi: Free transport channel on IDR failure If transport channel setup succeCVE-2026-93089 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67

  In the Linux kernel, the following vulnerability has been resolved: firmware: arm_scmi: Free transport channel on IDR failure If transport channel setup succeeds but the following IDR insertion fails, the error path destroys the transport device and frees the channel info without invoking the transport cleanup callback. Call chan_free() before destroying the device so transport specific resources such as IRQs, mailbox channels and mapped shared memory are released consistently with the normal teardown path.

  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

• Sep 17, 2026In the Linux kernel, the following vulnerability has been resolved: firmware: arm_scmi: Avoid IDR updates while cleaning channels scmi_cleanup_channels() walkCVE-2026-93086 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67

  In the Linux kernel, the following vulnerability has been resolved: firmware: arm_scmi: Avoid IDR updates while cleaning channels scmi_cleanup_channels() walks the TX/RX channel IDRs with idr_for_each() to free transport resources and destroy the dedicated transport devices before calling idr_destroy(). The destroy callback removed each entry from the same IDR being walked. That is not needed for this cleanup path, and it is unsafe because idr_for_each() has not advanced its radix-tree iterator while the callback is running. Removing the current entry from the callback can invalidate the iterator state. The callback also cannot be protected by rcu_read_lock(), because scmi_device_destroy() may sleep. Leave IDR teardown to the following idr_destroy() call and keep the callback limited to device destruction.

  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

• Sep 17, 2026In the Linux kernel, the following vulnerability has been resolved: firmware: arm_scmi: Reject out of range DT protocol IDs SCMI protocol IDs carried in messaCVE-2026-93085 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67

  In the Linux kernel, the following vulnerability has been resolved: firmware: arm_scmi: Reject out of range DT protocol IDs SCMI protocol IDs carried in message headers are limited by MSG_PROTOCOL_ID_MASK. The DT parsing paths noticed protocol IDs outside that range, but only logged an error and then kept processing the invalid value. That lets a malformed 32-bit DT reg value reach helpers which take a u8 protocol ID, where it can be truncated and/or treated as a different protocol. For channel setup, two different out-of-range values can also be used as distinct IDR keys while aliasing the generated SCMI protocol identity. Skip DT protocol nodes whose reg value does not fit the SCMI protocol ID field before setting up channels or creating protocol 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

• Sep 17, 2026In the Linux kernel, the following vulnerability has been resolved: firmware: arm_scmi: Drop handle on protocol bind failures The SCMI bus notifier acquires aCVE-2026-93084 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67

  In the Linux kernel, the following vulnerability has been resolved: firmware: arm_scmi: Drop handle on protocol bind failures The SCMI bus notifier acquires an SCMI handle when the driver core emits BUS_NOTIFY_BIND_DRIVER, before invoking the protocol driver probe callback. The protocol probe path only checks whether sdev->handle is set. If device_link_add() fails after the handle has been acquired, the protocol device can still bind with a valid handle but without the dependency link to the SCMI parent. A concurrent parent unbind can then miss the child and tear down the SCMI instance while the child still holds a handle into it. If the protocol driver probe later fails, for example with -EPROBE_DEFER, the driver core emits BUS_NOTIFY_DRIVER_NOT_BOUND rather than BUS_NOTIFY_UNBOUND_DRIVER. The SCMI notifier only released the handle on BUS_NOTIFY_UNBOUND_DRIVER, so each failed protocol-device bind leaked the SCMI instance users refcount and left sdev->handle set after the failed probe. Make the link helper report failure and drop the acquired handle if the link cannot be created. Also handle BUS_NOTIFY_DRIVER_NOT_BOUND in the same cleanup path used for unbind so failed probes

  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

• Sep 17, 2026In the Linux kernel, the following vulnerability has been resolved: firmware: arm_scmi: Unwind TX receiver mailbox setup failure mailbox_chan_setup() can requCVE-2026-93083 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67

  In the Linux kernel, the following vulnerability has been resolved: firmware: arm_scmi: Unwind TX receiver mailbox setup failure mailbox_chan_setup() can request an additional unidirectional TX receiver channel after successfully acquiring the primary channel. If that second request fails, the function returns immediately and leaves the primary channel allocated. Unwind the primary mailbox channel before returning the error so probe deferral or other setup failures do not leave the channel busy for later probe attempts.

  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

• Sep 17, 2026In the Linux kernel, the following vulnerability has been resolved: firmware: arm_scmi: Unwind P2A receiver mailbox setup failure mailbox_chan_setup() can reqCVE-2026-93082 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67

  In the Linux kernel, the following vulnerability has been resolved: firmware: arm_scmi: Unwind P2A receiver mailbox setup failure mailbox_chan_setup() can request an additional P2A receiver channel after successfully acquiring the primary P2A channel. If that later request fails, the function returns immediately and leaves the primary channel allocated. Unwind the primary mailbox channel before returning the error so probe deferral or other setup failures do not leave the channel busy for later probe attempts.

  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

• Sep 17, 2026In the Linux kernel, the following vulnerability has been resolved: firmware: arm_scmi: Fix SCMI device destroy lifetimes scmi_child_dev_find() drops the refeCVE-2026-93081 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67

  In the Linux kernel, the following vulnerability has been resolved: firmware: arm_scmi: Fix SCMI device destroy lifetimes scmi_child_dev_find() drops the reference returned by device_find_child() before returning the scmi_device pointer. A concurrent unregister can then release the device while the destroy path is still using the returned pointer. Make the lookup helper return the device_find_child() reference and keep it until scmi_device_destroy() has finished unregistering the child. Also split device_unregister() in __scmi_device_destroy() so the SCMI bus ID is not made reusable until after device_del() has removed the old scmi_dev.N name from sysfs. This avoids a new SCMI device reusing the same ID while the old device is still registered. The final device release callback is also a possible cleanup path when SCMI children are deleted by driver core recursion rather than __scmi_device_destroy(). Release the SCMI bus ID from a common helper used by destroy, register-failure and final-release paths, and clear scmi_dev->id after freeing it so the final release cannot free the same ID again.

  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

• Sep 17, 2026In the Linux kernel, the following vulnerability has been resolved: firmware: arm_scmi: Fix transport device teardown lookup SCMI transport devices are delibeCVE-2026-93080 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67

  In the Linux kernel, the following vulnerability has been resolved: firmware: arm_scmi: Fix transport device teardown lookup SCMI transport devices are deliberately excluded from normal SCMI bus matching so protocol drivers cannot bind to the internal transport children. However, scmi_device_destroy() uses the same protocol/name lookup to find devices that must be unregistered during channel teardown. Split the match helper so driver matching still skips transport devices, while explicit child lookup can find them for teardown. Use a shared transport-device name prefix macro for both matching and name generation. Since transport-device names are derived from direction and protocol ID, reject duplicate protocol channel setup before creating or finding a transport device. This prevents malformed firmware with duplicate protocol child nodes from reusing an existing transport device and then destroying it when the duplicate IDR insertion fails.

  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

• Sep 17, 2026In the Linux kernel, the following vulnerability has been resolved: cxl/features: Reject Get Feature count larger than the output buffer cxlctl_get_feature() CVE-2026-93079 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67High 7.8

  In the Linux kernel, the following vulnerability has been resolved: cxl/features: Reject Get Feature count larger than the output buffer cxlctl_get_feature() sizes its output buffer from the user's fwctl_rpc.out_len, but the device is told to write cxl_mbox_get_feat_in.count bytes into rpc_out->payload, which is a separate user-controlled value. Nothing bounds count against out_len, so a small out_len with a large count overflows the kvzalloc()'d buffer. A heap OOB write reachable from FWCTL_RPC. Reject requests where count exceeds the available payload room, before allocating.

  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

• Sep 17, 2026In the Linux kernel, the following vulnerability has been resolved: cxl/features: Reject Set Features output buffer smaller than the header cxlctl_set_featureCVE-2026-93078 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67

  In the Linux kernel, the following vulnerability has been resolved: cxl/features: Reject Set Features output buffer smaller than the header cxlctl_set_feature() sizes its output buffer from the user's fwctl_rpc.out_len but never checks it is large enough to hold even the fwctl_rpc_cxl_out header. With out_len == 0 , kvzalloc() returns ZERO_SIZE_PTR, which passes the !rpc_out check, the subsequent rpc_out->size = 0 then writes through the poison pointer. Reject requests whose output buffer can't hold the response header, before allocating. The Set Feature reply carries no payload, so the header is all that is required.

  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

• Sep 17, 2026In the Linux kernel, the following vulnerability has been resolved: cxl/features: Clamp Get Feature output size to the remaining buffer cxl_get_feature() readCVE-2026-93077 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67

  In the Linux kernel, the following vulnerability has been resolved: cxl/features: Clamp Get Feature output size to the remaining buffer cxl_get_feature() reads a feature in a loop but passes a fixed size_out as the output capacity every iteration. On the last partial iteration the buffer has less room left, so a device that returns more than asked can overflow feat_out. Use the per-iter size data_to_rd_size, which already tracks the remaining room, as the output capacity.

  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

• Sep 17, 2026In the Linux kernel, the following vulnerability has been resolved: dax/fsdev: clear vmemmap_shift when binding static pgmap Clear pgmap->vmemmap_shift for stCVE-2026-93076 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67

  In the Linux kernel, the following vulnerability has been resolved: dax/fsdev: clear vmemmap_shift when binding static pgmap Clear pgmap->vmemmap_shift for static DAX devices. When rebinding a static device from device_dax (which may set vmemmap_shift based on alignment) to fsdev_dax, the stale vmemmap_shift persists on the shared pgmap. Explicitly zero it before devm_memremap_pages() so the vmemmap is built for order-0 folios as fsdev requires.

  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

• Sep 17, 2026In the Linux kernel, the following vulnerability has been resolved: dax/fsdev: clear pgmap ops and owner on unbind fsdev_dax_probe() sets pgmap->ops = &fsdev_CVE-2026-93075 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67

  In the Linux kernel, the following vulnerability has been resolved: dax/fsdev: clear pgmap ops and owner on unbind fsdev_dax_probe() sets pgmap->ops = &fsdev_pagemap_ops and pgmap->owner = dev_dax, but nothing ever clears them. For a dynamic device the pgmap is devm-allocated and freed on unbind, so this is harmless. For a static device the pgmap is the shared, long-lived one owned by the dax bus (kill_dev_dax() only NULLs dev_dax->pgmap for the non-static case), and device.c's probe sets only pgmap->type, never clearing ops/owner. So after fsdev unbinds a static device the stale fsdev_pagemap_ops survives on the shared pgmap. If the device is then rebound to device_dax (MEMORY_DEVICE_GENERIC, which installs no ->memory_failure), or the fsdev_dax module is unloaded, a subsequent memory_failure on that pgmap dispatches through the stale -- and possibly freed -- handler. Register a devm action that clears pgmap->ops and pgmap->owner on unbind, symmetric with setting them at probe, so the pgmap carries no fsdev state once fsdev is detached.

  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

• Sep 17, 2026In the Linux kernel, the following vulnerability has been resolved: dax/fsdev: use __va(phys) for kaddr in direct_access Use __va(phys) instead of virt_addr +CVE-2026-93074 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67High 7.8

  In the Linux kernel, the following vulnerability has been resolved: dax/fsdev: use __va(phys) for kaddr in direct_access Use __va(phys) instead of virt_addr + linear_offset for the kaddr return in __fsdev_dax_direct_access(). The previous code added a device-linear byte offset to virt_addr (which is __va of ranges[0]), but for multi-range devices with physical gaps between ranges, this linear arithmetic crosses the gap and produces a wrong kernel virtual address. Using __va(phys) where phys comes from dax_pgoff_to_phys() is correct for any range layout because the direct map translates each physical address independently. This leaves dev_dax->virt_addr write-only, so remove the field (suggested by Dave Jiang).

  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

• Sep 17, 2026In the Linux kernel, the following vulnerability has been resolved: dax: read holder_ops once in dax_holder_notify_failure() dax_holder_notify_failure() readsCVE-2026-93073 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67

  In the Linux kernel, the following vulnerability has been resolved: dax: read holder_ops once in dax_holder_notify_failure() dax_holder_notify_failure() reads dax_dev->holder_ops twice without READ_ONCE() -- once for the NULL check and once for the indirect notify_failure() call. A concurrent fs_put_dax() can clear holder_ops between the two reads, so the check can observe a non-NULL pointer while the call dereferences NULL. (kill_dax() also clears holder_ops, but only after synchronize_srcu(), so it cannot race a reader that is inside dax_read_lock(); fs_put_dax() does no such synchronization.) Fetch holder_ops once into a local with READ_ONCE() so the NULL check and the indirect call observe the same value.

  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

• Sep 17, 2026In the Linux kernel, the following vulnerability has been resolved: irqchip/renesas-irqc: Fix generic interrupt chip leak on remove The driver allocates domaiCVE-2026-93072 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67

  In the Linux kernel, the following vulnerability has been resolved: irqchip/renesas-irqc: Fix generic interrupt chip leak on remove The driver allocates domain generic chips probe. However, on driver removal, the generic chips are not automatically freed when the interrupt domain is removed because the domain flags do not include IRQ_DOMAIN_FLAG_DESTROY_GC. This causes both the domain generic chips structure and the associated generic chips to be leaked. Additionally, the generic chips remain on the global list and may later be accessed by generic interrupt chip suspend, resume, or shutdown callbacks after the driver has been removed, potentially resulting in a use-after-free and kernel crash. Fix the resource leak by setting IRQ_DOMAIN_FLAG_DESTROY_GC on the interrupt domain; this lets the interrupt domain core automatically release all generic chips when irq_domain_remove() is invoked, removing the need for manual cleanup calls in error paths and remove callback.

  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

• Sep 17, 2026In the Linux kernel, the following vulnerability has been resolved: media: bcm2835-unicam: Fix asc leaked in error/remove path v4l2_async_nf_add_fwnode_remoteCVE-2026-93071 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67

  In the Linux kernel, the following vulnerability has been resolved: media: bcm2835-unicam: Fix asc leaked in error/remove path v4l2_async_nf_add_fwnode_remote() allocates the asc, which is freed when v4l2_async_nf_cleanup() is called. Call v4l2_async_nf_cleanup() properly in the driver paths. Discovered with kmemleak after rmmod: unreferenced object 0xffff000084526b80 (size 64): comm "modprobe", pid 185, jiffies 4295013512 hex dump (first 32 bytes): 01 00 00 00 00 00 00 00 e8 0d ff bf 00 00 ff ff ................ 40 83 bc 84 00 00 ff ff 60 83 bc 84 00 00 ff ff @.......`....... backtrace (crc ac584083): [<00000000ffb081a7>] kmemleak_alloc+0x38/0x44 [<00000000d2fd9301>] __kmalloc+0x1b0/0x250 [<000000004dd5354d>] __v4l2_async_nf_add_fwnode+0x28/0x9c [<0000000067587657>] __v4l2_async_nf_add_fwnode_remote+0x3c/0x64

  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

• Sep 17, 2026In the Linux kernel, the following vulnerability has been resolved: media: ipu6: Do not free aux device pdata after init ipu6_bus_initialize_device() stores tCVE-2026-93070 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67High 7.8

  In the Linux kernel, the following vulnerability has been resolved: media: ipu6: Do not free aux device pdata after init ipu6_bus_initialize_device() stores the isys/psys pdata pointer in struct ipu6_bus_device and initializes the auxiliary device. After that point, error unwinding must drop the auxiliary device reference and let ipu6_bus_release() free both the bus device and adev->pdata. The isys and psys init paths already call put_device() when MMU initialization fails, and ipu6_bus_add_device() calls auxiliary_device_uninit() on auxiliary_device_add() failure. Both paths therefore run the bus release callback. The extra kfree(pdata) in the callers can release the same object a second time. Remove the manual pdata frees after the auxiliary device has been initialized. This issue was found by a static analysis checker and confirmed by manual source review.

  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

• Sep 17, 2026In the Linux kernel, the following vulnerability has been resolved: OPP: Fix cleanup ordering Commit 173e02d67494 ("OPP: Initialize scope-based pointers inlinCVE-2026-93069 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67

  In the Linux kernel, the following vulnerability has been resolved: OPP: Fix cleanup ordering Commit 173e02d67494 ("OPP: Initialize scope-based pointers inline") added initialization for all pointers. In some cases, the ordering was changed so that *opp_table was initialized after *opp. This also changes the order of the registered cleanup functions. When the cleanup happens, this can cause use-after-free errors when the last reference is released and the release function _opp_kref_release tries to access the already freed opp->opp_table. Initialize *opp_table before *opp again to fix this and ensure the correct cleanup order.

  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

• Sep 17, 2026In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix DM I2C teardown race DM I2C adapters can remain visible to userspace CVE-2026-93068 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67

  In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix DM I2C teardown race DM I2C adapters can remain visible to userspace while DM teardown is already in progress. A concurrent i2c-dev transfer may then enter amdgpu_dm_i2c_xfer() after the backing DM state has been torn down, leading to a NULL pointer dereference. Create a devres group around the DM I2C adapter lifetime and release it at the start of dm_hw_fini(), before HPD, IRQ, and DM state are torn down. This removes the I2C adapters first and waits for in-flight users to drain before the structures used by amdgpu_dm_i2c_xfer() disappear. This fixes a teardown ordering race seen during device removal: BUG: kernel NULL pointer dereference RIP: amdgpu_dm_i2c_xfer+0x122/0x1c0 [amdgpu] Call Trace: __i2c_transfer i2c_transfer i2cdev_ioctl_rdwr

  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

• Sep 17, 2026In the Linux kernel, the following vulnerability has been resolved: drm/bridge: tc358767: clamp the reported AUX read size to the request tc_aux_transfer() clCVE-2026-93067 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67

  In the Linux kernel, the following vulnerability has been resolved: drm/bridge: tc358767: clamp the reported AUX read size to the request tc_aux_transfer() clamps an AUX read to the payload limit: size_t size = min_t(size_t, DP_AUX_MAX_PAYLOAD_BYTES - 1, msg->size); After the transfer it replaces size with the byte count the controller reports in AUX_BYTES: if (size) size = FIELD_GET(AUX_BYTES, auxstatus); AUX_BYTES is GENMASK(15, 8), so it can be up to 255. Nothing clamps it back to the request. tc_aux_read_data() reads that many bytes into the 16-byte auxrdata stack buffer, then copies them into the caller buffer. A reported count of 255 makes the read run to 256 bytes and overruns both. The controller should never report more than it was asked to transfer, so this is defense in depth rather than a live hole. The reported count is only lightly trusted, and the check is cheap. Clamp it back to the request, the same way ti-sn65dsi86 does in commit aca58eac52b8 ("drm/bridge: ti-sn65dsi86: Never store more than msg->size bytes in AUX xfer").

  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

• Sep 17, 2026In the Linux kernel, the following vulnerability has been resolved: x86/mm/pat: Take cpa_lock around large-page collapse Loading and unloading modules concurrCVE-2026-93066 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67

  In the Linux kernel, the following vulnerability has been resolved: x86/mm/pat: Take cpa_lock around large-page collapse Loading and unloading modules concurrently on several CPUs on a KASAN build, with a short delay injected at the CPA page-table lookup to widen the window, faults within minutes: BUG: KASAN: use-after-free in __change_page_attr+0x7cc/0x7e0 Write of size 8 at addr ffff888181139718 by task modprobe ... The buggy address belongs to the physical page: pfn:0x181139 ... page_type: f2(table) cpa_collapse_large_pages() rebuilds a leaf PMD from its 4K PTEs and frees the old PTE-table pages, while __change_page_attr() fetches a PTE pointer from a lockless lookup_address_in_pgd_attr() and writes it with set_pte_atomic() only later. When module text is served from a shared large ROX mapping the two run on the same PMD: CPU A (module load) CPU B (module finalize) ------------------- ----------------------- execmem_make_temp_rw set_memory_nx __change_page_attr split 2M -> 4K table P kpte = &P[i] (lockless) execmem_restore_rox set_memory_rox (C

  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

• Sep 17, 2026In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: fix counter type in iwl_fwrt_dump_error_logs The loop counter 'count' was dCVE-2026-93065 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67

  In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: fix counter type in iwl_fwrt_dump_error_logs The loop counter 'count' was declared as u8 while num_pc is u32. If firmware advertises more than 255 PC entries the counter wraps back to zero and the loop never terminates potentially causing an infinite loop or reading past the allocated pc_data array. Change the declaration to u32 to match num_pc.

  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

• Sep 17, 2026In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: fix off-by-one in TXF key sanitiser iwl_mvm_frob_txf_key_iter() tracksCVE-2026-93064 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67

  In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: fix off-by-one in TXF key sanitiser iwl_mvm_frob_txf_key_iter() tracks the last matched byte position in loop variable 'i'. When a full key match is found (match == keylen), 'i' points at the last byte of the matched key. The memset start offset should therefore be i + 1 - keylen, not i - keylen; the current code zeroes one byte before the match and leaves the final key byte un-sanitised.

  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

• Sep 17, 2026In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mei: check SAP message length before reading it Verify the SAP message sizeCVE-2026-93063 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67High 8.4

  In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mei: check SAP message length before reading it Verify the SAP message size is not larger than the local buffer before reading the message to avoid buffer overflow.

  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.