Total
395450 CVE
| CVE | Vendors | Products | Updated | CVSS v2 | CVSS v3 |
|---|---|---|---|---|---|
| CVE-2026-93139 | 2026-09-17 | N/A | N/A | ||
| In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/mes: Fix hung_queue_db_array loop limit for multi-XCC The loop iterated only AMDGPU_MAX_MES_PIPES times, leaving entries uninitialized for multi-XCC GPUs. This causes null pointer dereferences when accessing arrays indexed by XCC ID >= 2. Extend the loop to cover all XCCs (AMDGPU_MAX_MES_PIPES * num_xcc), matching other per-XCC arrays. | |||||
| CVE-2026-93136 | 2026-09-17 | N/A | N/A | ||
| In the Linux kernel, the following vulnerability has been resolved: bus: mhi: ep: Fix device refcount leak in the error path of MHI device creation mhi_ep_create_device() takes one device reference for the UL channel and another for the DL channel after allocating the transfer device. These references are normally released by mhi_ep_destroy_device() before the device itself is removed. If dev_set_name() or device_add() fails, the error path currently drops only one reference. The remaining channel references keep the device from being released and leave the channels associated with a device that was never registered. Route both failures through a common unwind path that drops the DL channel reference, the UL channel reference, and the initial reference from device_initialize(). | |||||
| CVE-2026-93135 | 2026-09-17 | N/A | N/A | ||
| In the Linux kernel, the following vulnerability has been resolved: bpf: Reject programs with inlined helpers if JIT is not available When an architecture (such as LoongArch, ARM64, and RISC-V) implements bpf_jit_inlines_helper_call(), the verifier skips rewriting the helper call offset (insn->imm) in bpf_do_misc_fixups(). This is because the helper is expected to be inlined by the JIT compiler later. Therefore, insn->imm remains as the raw helper enum ID. However, if JIT is disabled at runtime (net.core.bpf_jit_enable=0) or if JIT compilation fails dynamically (e.g., due to OOM), the program falls back to the BPF interpreter. When the interpreter executes (__bpf_call_base + insn->imm) with the unpatched raw ID, it jumps into an invalid address space, triggering an instruction alignment fault or a kernel panic. Although these helpers have valid C implementations in the kernel, the omission of offset rewriting makes runtime interpreter fallback fatal. Fix this by setting 'prog->jit_required = 1' when helper call rewriting is skipped for JIT inlining. This ensures that such programs are safely rejected if JIT is not available, preventing the runtime kernel panic. | |||||
| CVE-2026-93134 | 2026-09-17 | N/A | N/A | ||
| In the Linux kernel, the following vulnerability has been resolved: printk: Fix possible console use-after-free When emitting a record via legacy printing, it is possible that a handover to another legacy printing context occurs. When a context has performed a handover, the console SRCU read lock is released and the pointer to the console struct might now be invalid. Therefore, after calling nbcon_legacy_emit_next_record() or console_emit_next_record(), it is necessary to check if a handover occurred _before_ further @con usage. Sashiko pointed out that console_flush_one_record() was not doing this. In console_flush_one_record(), after emitting a record, move the further usage of @con after the handover check. | |||||
| CVE-2026-93133 | 2026-09-17 | N/A | N/A | ||
| In the Linux kernel, the following vulnerability has been resolved: ACPI: RISC-V: Check acpi_get_handle() status in riscv_acpi_add_prt_dep() In riscv_acpi_add_prt_dep(), the acpi_get_handle() call can fail which would leave link_handle uninitialized. Fix it by checking the acpi_get_handle() return status and skip the entry if it fails. | |||||
| CVE-2026-93132 | 2026-09-17 | N/A | N/A | ||
| In the Linux kernel, the following vulnerability has been resolved: ACPI: RISC-V: Fix riscv_acpi_add_prt_dep() loop handling The loop in riscv_acpi_add_prt_dep() includes error conditions that are handled in a dubious - if not outright wrong - way, by continuining the loop (which skips and misses the entry pointer update to point to the next entry). Rewrite the loop as a for loop (that handles the continuation correctly) and wrap the condition and update statements using helper functions to make it cleaner. | |||||
| CVE-2026-93131 | 2026-09-17 | N/A | N/A | ||
| In the Linux kernel, the following vulnerability has been resolved: platform/x86: dell-privacy: Fix race condition Accessing priv->features_present needs to happen with the list mutex being held, otherwise priv can be freed at any moment. | |||||
| CVE-2026-93130 | 2026-09-17 | N/A | N/A | ||
| In the Linux kernel, the following vulnerability has been resolved: platform/x86: dell-wmi-base: Fix resource leak on module load failure We need to properly clean up the SMBIOS request and the privacy driver when the module load fails. | |||||
| CVE-2026-93129 | 2026-09-17 | N/A | N/A | ||
| In the Linux kernel, the following vulnerability has been resolved: platform/x86: dell-wmi-base: Fix handling of ultra performance key The commit message of commit 5fbd827eb9c2 ("platform/x86: dell-wmi: Recognise or support new switches") states that the ultra performance key contains additional data after the type and code fields. The event data passed to dell_wmi_process_key() is already parsed, so "buffer" already starts after those two fields. Use the correct index for accessing the first data field to avoid a potential buffer overread. | |||||
| CVE-2026-93128 | 2026-09-17 | N/A | N/A | ||
| In the Linux kernel, the following vulnerability has been resolved: platform/x86: lg-laptop: Fix LED resource handling The event notification callback might access kbd_backlight even when it was not successfully registered with the LED subsystem. The same happens inside acpi_remove(), where the LED devices are unregistered unconditionally. Fix this by tracking the availability of the kbd_backlight LED device and use devm_led_classdev_register() to let devres take care of unregistering the LED devices during removal. For this the parent device of the LED devices is changed to the native platform device. | |||||
| CVE-2026-93126 | 2026-09-17 | N/A | N/A | ||
| In the Linux kernel, the following vulnerability has been resolved: remoteproc: qcom_q6v5_adsp: Fix reference leak for device node When calling of_parse_phandle_with_args(), the caller is responsible to call of_node_put() to release the reference of device node. In adsp_map_carveout, it does not release the reference. | |||||
| CVE-2026-93124 | 2026-09-17 | N/A | N/A | ||
| In the Linux kernel, the following vulnerability has been resolved: platform/x86: asus-wireless: Fail probe when there is no ACPI match Every platform driver can be forced to match a device that does not match its list of device IDs because of device_match_driver_override(), so platform drivers that rely on the existence of a device ACPI companion object need to verify its presence. asus_wireless_probe() returns success when acpi_match_acpi_device() finds no match, leaving behind an input device that never reports anything because the notify handler is not installed. Worse, when the driver is force-bound to a device without an ACPI companion, probe still succeeds and stores a NULL companion pointer, which asus_wireless_remove() later passes to acpi_dev_remove_notify_handler(), leading to a NULL pointer dereference on unbind. Return -ENODEV when the device does not match the ID table. This also covers the missing-companion case, because acpi_match_acpi_device() rejects a NULL device. Perform the check before allocating any driver state, instead of after the input device has already been registered. | |||||
| CVE-2026-93123 | 2026-09-17 | N/A | N/A | ||
| In the Linux kernel, the following vulnerability has been resolved: serial: qcom-geni: do not advance stale DMA completions The qcom GENI serial DMA TX completion path advances the transmit fifo by the number of bytes recorded in port->tx_remaining. If uart_flush_buffer() runs after the hardware has completed a DMA transfer but before the DMA completion interrupt has been handled, the serial core resets the transmit fifo while port->tx_remaining still describes the old DMA transfer. A previous fix avoided advancing an empty fifo by checking that the fifo length is at least tx_remaining. That still does not distinguish the old DMA payload from new bytes written after the flush. If userspace writes new data before the stale DMA completion interrupt is handled, the fifo can again contain at least tx_remaining bytes and the stale completion can advance and discard those new bytes. Mark an in-flight DMA transfer stale when the transmit fifo is flushed. The later completion still unprepares the original DMA mapping using the saved length, but it no longer advances the transmit fifo. | |||||
| CVE-2026-93120 | 2026-09-17 | N/A | N/A | ||
| In the Linux kernel, the following vulnerability has been resolved: usb: gadget: configfs: fix out-of-bounds read of qw_sign os_desc_qw_sign_show() passes OS_STRING_QW_SIGN_LEN as the input length to utf16s_to_utf8s(), but that argument counts UTF-16 code units while OS_STRING_QW_SIGN_LEN (14) is the byte size of qw_sign[]. The array holds only OS_STRING_QW_SIGN_LEN / 2 (7) code units, so the conversion reads up to 7 units (14 bytes) past the end of qw_sign[] into the following members of struct gadget_info when the stored signature fills the array without a NUL terminator, exposing those bytes through the configfs attribute. The store path halves the count for its input bound but passes the full byte count as the utf8s_to_utf16s() output limit; use the destination code-unit count in both directions. | |||||
| CVE-2026-93119 | 2026-09-17 | N/A | N/A | ||
| In the Linux kernel, the following vulnerability has been resolved: usb: ljca: bound bank_num in ljca_enumerate_gpio() ljca_enumerate_gpio() reads desc->bank_num from the device and loops valid_pin[i] = get_unaligned_le32(...) for i < bank_num. valid_pin[] holds only LJCA_MAX_GPIO_NUM / 32 = 2 entries. Two checks run before the loop. The reply length must match struct_size(desc, bank_desc, bank_num). The product pins_per_bank * bank_num must not exceed LJCA_MAX_GPIO_NUM. Neither one bounds bank_num against the size of valid_pin[]. The reply is capped at LJCA_MAX_PAYLOAD_SIZE (60) bytes, so the struct_size check limits bank_num to 9. A device that reports bank_num 9 with pins_per_bank 7 still passes both checks. gpio_num is 63 and the reply is 56 bytes. The loop then writes nine u32 into the two entry array and overruns valid_pin[] on the stack. A broken or malicious LJCA device can therefore overflow the stack. Reject a bank_num that does not fit valid_pin[]. | |||||
| CVE-2026-93118 | 2026-09-17 | N/A | N/A | ||
| In the Linux kernel, the following vulnerability has been resolved: usb: gadget: aspeed_udc: check endpoint DMA allocation ast_udc_probe() allocates a coherent DMA buffer used as the backing store for endpoint buffers. ast_udc_init_ep() derives per-endpoint buffer pointers from udc->ep0_buf, so a failed allocation is dereferenced during probe. Check the allocation before endpoint setup. The existing probe error path called ast_udc_remove(), which unregisters the gadget unconditionally and is not safe before usb_add_gadget_udc() succeeds. Add a local cleanup helper for probe failures so pre-registration failures only unwind the resources that were actually initialized. This was found by a local static analysis checker for unchecked allocator returns while scanning Linux 6.16. The change was checked by applying it to current mainline and by running checkpatch. I do not have access to Aspeed UDC hardware, so no runtime testing was performed. | |||||
| CVE-2026-93117 | 2026-09-17 | N/A | N/A | ||
| In the Linux kernel, the following vulnerability has been resolved: usb: fix UAF when probe runs concurrent to dyn ID removal Dynamic IDs are only guaranteed to be valid when usb_dynids_lock is held, as remove_id_store can free the node. Thus, make a copy in usb_probe_interface. Clarify the documentation that the id parameter is only valid during the probe. USB serial has the same pattern, but it does not need fixing as the IDs cannot be removed via sysfs. | |||||
| CVE-2026-93115 | 2026-09-17 | N/A | N/A | ||
| In the Linux kernel, the following vulnerability has been resolved: platform/mellanox: mlxbf-pmc: Check ACPI_COMPANION() against NULL 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(), so platform drivers that rely on the existence of a device's ACPI companion object need to verify its presence. mlxbf_pmc_probe() passes the result of ACPI_COMPANION() to acpi_device_hid(), which dereferences it, so force-binding the driver to a device without an ACPI companion leads to a NULL pointer dereference. Accordingly, add a requisite ACPI_COMPANION() check against NULL to the mlxbf-pmc driver and return -ENODEV when the companion is missing. | |||||
| CVE-2026-93114 | 2026-09-17 | N/A | N/A | ||
| 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. | |||||
| CVE-2026-93113 | 2026-09-17 | N/A | N/A | ||
| 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 industrialio videodev snd_compress rfkill ac97_bus snd_pcm_dmaengine qcom_tsens mc qcom_edac snd_pcm pci_pwrctrl_pwrseq qcom_cpufreq_hw snd_timer snd qcomtee soundcore tee leds_gpio joydev binfmt_misc zram lz4hc_compress governor_simpleondemand panel_edp msm xhci_plat_hcd nvme nvme_core dwc3 qcom_pm8008_regulator [ 15.408688] ucsi_glink nvme_keyring nvme_auth pmic_glink_altmode udc_core typec_ucsi aux_hpd_bridge qcom_battmgr ulpi ubwc_config socinfo ocmem drm_gpuvm qcom_q6v5_pas drm_exec qcom_pil_info leds_qcom_lpg gpu_sched led_class_multicolor rtc_pm8xxx qcom_pbs qcom_common drm_display_helper qcom_pon qcom_glink_smem qcom_glink ghash_ce pwrseq_qcom_wcn gpio_sbu_mux qcom_stats phy_qcom_qmp_combo qcom_q6v5 gf128mul cec dispcc_sc8280xp phy_qcom_edp camcc_sc8280xp i2c_qcom_cci qcom_sysmon drm_dp_aux_bus mdt_loader aux_bridge qcom_pm8008 i2c_hid_of_elan dwc3_qcom_legacy llcc_qcom icc_bwmon gpi typec qcom_refgen_regulator phy_qcom_qmp_usb nvmem_qfprom qcom_ipcc phy_qcom_snps_femto_v2 gpucc_sc8280xp pinctrl_sc8280xp_lpass_lpi qcom_hwspinlock pinctrl_lpass_lpi lpasscc_sc8280xp qrtr qcom_aoss pmic_glink pdr_interface phy_qcom_qmp_pcie qcom_smd qcom_pdr_msg icc_osm_l3 qcom_wdt qmi_helpers qcom_rng smp2p rpmsg_core gpio_keys pwm_bl smem hid_multitouch fuse i2c_dev [ 15.408928] CPU: 2 UID: 0 PID: 14 Comm: kworker/u32:1 Not tainted 7.1.0+ #2 PREEMPT(lazy) [ 15.408937] Hardware name: LENOVO 21BX0016US/21BX0016US, BIOS N3HET88W (1.60 ) 03/14/2024 [ 15.408942] Workqueue: pm pm_runtime_work [ 15.408959] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 15.408967] pc : gdsc_toggle_logic+0x14c/0x160 [ 15.408978] lr : gdsc_toggle_logic+0x14c/0x160 [ 15.408987] sp : ffff8000800f3b40 [ 15.408991] x29: ffff8000800f3b40 x28: 0000000000000000 x27: 0000000000000000 [ 15.409003] x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000000 [ 15.409014] x23: 0000000000000000 x22: 0000000000000001 x21: ffffa33f298fca88 [ 15.409024] x20: 0000000000000000 x19: ffffa33f298fc5b0 x18: 00cd15db75dacefd [ 15.409035] x17: 000000040044ffff x16: ffffa33f3b1a3d88 x15: 726f776b80000002 [ 15.409045] x14: ffffffffffffffff x13: 0000000000000028 x12: 0101010101010101 [ 15.409056] x11: 7f7f7f7f7f7f7f7f x10: fefeff3039313274 x9 : ffffa33f3a5edafc [ 15.409067] x8 : ffff8000800f3780 x7 : 0000000000000001 x6 : 0000000000000001 [ 15.409078] x5 : ffff000bf3ca1288 x4 : 0000000000000000 x3 : ffff5cccb6a3f000 [ 15.409088] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff000080ae0000 [ 15.409098] Call trace: [ 15.409103] gdsc_toggle_logic+0x14c/0x160 (P) [ 15.409115] gdsc_disable+0x4c/0x190 [ 15.409126] _genp ---truncated--- | |||||