Vulnerability database

20,207 results · page 35 of 405

• Sep 24, 2026In the Linux kernel, the following vulnerability has been resolved: f2fs: embed f2fs_gc_kthread in f2fs_sb_info Instead of allocating f2fs_gc_kthread dynamicaCVE-2026-93285 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67

  In the Linux kernel, the following vulnerability has been resolved: f2fs: embed f2fs_gc_kthread in f2fs_sb_info Instead of allocating f2fs_gc_kthread dynamically, embed it in f2fs_sb_info. This simplifies lifetime management and prepares for fixing race conditions during teardown. - __sbi_store - remount|shutdown - f2fs_stop_gc_thread - access sbi->gc_thread - sbi->gc_thread = NULL - access sbi->gc_thread->f2fs_gc_task

  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 24, 2026In the Linux kernel, the following vulnerability has been resolved: drm/pagemap: dma-unmap pages before handling migration errors drm_pagemap_migrate_unmap_paCVE-2026-93284 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67High 8.8

  In the Linux kernel, the following vulnerability has been resolved: drm/pagemap: dma-unmap pages before handling migration errors drm_pagemap_migrate_unmap_pages() relies on the pages array to determine which pages require DMA unmapping. However, drm_pagemap_migration_unlock_put_pages() clears the array as part of its cleanup, leaving drm_pagemap_migrate_unmap_pages() with no valid page information if it is called afterward. Call drm_pagemap_migrate_unmap_pages() before drm_pagemap_migration_unlock_put_pages() so the pages array remains valid during DMA unmapping.

  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 24, 2026In the Linux kernel, the following vulnerability has been resolved: i3c: master: Fix device_register() error path When device_register() fails in i3c_master_rCVE-2026-93283 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67

  In the Linux kernel, the following vulnerability has been resolved: i3c: master: Fix device_register() error path When device_register() fails in i3c_master_register_new_i3c_devs(), put_device() is called to drop the reference taken by device_register(). That drops the last reference, so the device's release callback i3c_device_release() runs and frees the i3c_device. Two problems follow from that: i3c_device_release() does WARN_ON(i3cdev->desc), so it warns because desc->dev->desc still points back at the descriptor. Clear it before calling put_device(). After put_device() frees the i3c_device, desc->dev is left pointing at freed memory, so clear desc->dev as well. That prevents, for example, i3c_master_unregister_i3c_devs() seeing desc->dev as non-NULL and dereferencing 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 24, 2026In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix maximum allowed access checks The DACL permission check looks for an ACE matchiCVE-2026-93282 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67High 8.1

  In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix maximum allowed access checks The DACL permission check looks for an ACE matching the current user and falls back to the Everyone ACE. It does not consider an Authenticated Users ACE, even though an authenticated session is a member of that well-known group. As a result, opening a file whose access is granted through S-1-5-11 can incorrectly fail with STATUS_ACCESS_DENIED. Treat an Authenticated Users ACE as a fallback entry alongside Everyone. The maximal access calculation also combines access masks from every ACE, regardless of whether its SID applies to the current user. This can grant rights belonging to an unrelated principal. Process only ACEs applying to the user, Everyone, or Authenticated Users, and accumulate allowed and denied masks in ACL order. Preserve explicitly requested access bits so they are validated against the resulting maximal mask. When ACCESS_SYSTEM_SECURITY is denied, report STATUS_PRIVILEGE_NOT_HELD instead of the generic STATUS_ACCESS_DENIED. Access to the system ACL requires a security privilege that ksmbd does not grant. For regular files, include FILE_EXECUTE in maxi

  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 24, 2026In the Linux kernel, the following vulnerability has been resolved: wifi: rtw89: fix HE extended capability length check rtw89_mac_check_he_obss_narrow_bw_ru_CVE-2026-93281 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67

  In the Linux kernel, the following vulnerability has been resolved: wifi: rtw89: fix HE extended capability length check rtw89_mac_check_he_obss_narrow_bw_ru_iter() reads extended capability byte 10, but rejects only datalen values below 10. Byte 10 requires at least 11 bytes. Require datalen >= 11 before reading data[10].

  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 24, 2026In the Linux kernel, the following vulnerability has been resolved: greybus: audio: bound the topology section sizes against the fetched size gb_audio_gb_get_CVE-2026-93280 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67High 8.8

  In the Linux kernel, the following vulnerability has been resolved: greybus: audio: bound the topology section sizes against the fetched size gb_audio_gb_get_topology() fetches a topology blob of a module-supplied size, and gbaudio_tplg_parse_data() then walks it by adding the module-supplied size_dais, size_controls and size_widgets fields to form the control, widget and route section offsets. Those le32 sizes are never checked against the fetched blob, so a module reporting a small topology size but large section sizes makes the offsets point past the allocation, and parsing reads out of bounds. Reject a topology whose section sizes do not fit within the fetched size before it is parsed.

  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 24, 2026In the Linux kernel, the following vulnerability has been resolved: staging: octeon: add missing tasklet_kill in cvm_oct_tx_shutdown The TX cleanup tasklet caCVE-2026-93279 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67

  In the Linux kernel, the following vulnerability has been resolved: staging: octeon: add missing tasklet_kill in cvm_oct_tx_shutdown The TX cleanup tasklet can be scheduled by the watchdog IRQ handler to execute cvm_oct_tx_do_cleanup. There can be a pending tasklet in the queue which might run after the cvm_oct_remove() frees net_device structures, causing a use-after-free in cvm_oct_tx_do_cleanup() as it iterates cvm_oct_device[] which is an array of netdevice pointers. Add tasklet_kill() after free_irq() to ensure the tasklet is no longer scheduled or running before teardown proceeds.

  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 24, 2026In the Linux kernel, the following vulnerability has been resolved: staging: octeon: add missing napi_disable in cvm_oct_rx_shutdown cvm_oct_rx_shutdown callsCVE-2026-93278 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67

  In the Linux kernel, the following vulnerability has been resolved: staging: octeon: add missing napi_disable in cvm_oct_rx_shutdown cvm_oct_rx_shutdown calls free_irq and netif_napi_del without disabling the napi instance first. As the free_irq only waits for completion of hard interrupt handlers, the napi poll function could still be active. If cvm_oct_remove proceeds to free the plat structure (which holds the NAPI instances), the active poll function will access freed memory, resulting in a use-after-free crash.

  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 24, 2026In the Linux kernel, the following vulnerability has been resolved: RDMA/bnxt_re: Validate udata before executing commands The destroy callbacks currently zerCVE-2026-93277 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67High 7.8

  In the Linux kernel, the following vulnerability has been resolved: RDMA/bnxt_re: Validate udata before executing commands The destroy callbacks currently zero the udata output after tearing down driver resources. If the userspace access fails, uverbs preserves the uobject and allows the destroy callback to run again, even though the driver resource has already been freed. Call ib_no_udata_io() before teardown so udata failures are detected while the resource is still intact, then return success after teardown completes. As part of this change, move ib_respond_empty_udata() to the start of the create and modify flows. While this is not strictly required for general create flows, as the core layer unwinds uobjects on failure, it is necessary for create AH. In _rdma_create_ah(), the HW object is otherwise leaked.

  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 24, 2026In the Linux kernel, the following vulnerability has been resolved: phy: renesas: phy-rcar-gen3-usb2: Fix devm action registration for disabled VBUS regulator CVE-2026-93276 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67

  In the Linux kernel, the following vulnerability has been resolved: phy: renesas: phy-rcar-gen3-usb2: Fix devm action registration for disabled VBUS regulator devm_regulator_get_exclusive() initialises the regulator with enable_count = 1, requiring the consumer to disable it before release. The devm disable action was previously only registered when the caller explicitly requested enable, so when the regulator was left in its initial enabled state without an explicit enable call, the cleanup path skipped decrementing enable_count, triggering a WARN_ON during regulator release on device removal. Fix this by always registering the devm disable action based on the actual enabled state via regulator_is_enabled(), regardless of whether the caller requested an explicit enable. This covers both the explicitly enabled case and the initial state set by devm_regulator_get_exclusive().

  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 24, 2026In the Linux kernel, the following vulnerability has been resolved: perf/x86/intel/pt: Fix stop/start with no update If pt_event_stop() is called without PERFCVE-2026-93275 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67

  In the Linux kernel, the following vulnerability has been resolved: perf/x86/intel/pt: Fix stop/start with no update If pt_event_stop() is called without PERF_EF_UPDATE flag, then perf_aux_output_end() is not called. A subsequent call to pt_event_start() will call perf_aux_output_begin() again which violates the rule against nesting and triggers a WARNING in perf_aux_output_begin(). Originally, pt_event_stop() was never called without PERF_EF_UPDATE, because the only code paths to do so are from event overflow, and Intel PT does not do that. However the introduction of group throttling by commit 9734e25fbf5ae ("perf: Fix the throttle logic for a group") meant that an Intel PT event could be throttled if it was part of a group. Throttling calls PMU ->stop() / ->start() callbacks without flags. An example is when AUX area sampling is used. The following commands hit the issue: echo 10000 > /proc/sys/kernel/perf_event_max_sample_rate perf record -F32000 --aux-sample -e '{intel_pt//u,cycles:u}' \ -- bash -c 'for i in `seq 1 100000` ; do true ; done' Use PERF_HES_UPTODATE to track whether perf_aux_output_begin() and perf_aux_output_end() are balanced. A cleared PERF_HE

  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 24, 2026In the Linux kernel, the following vulnerability has been resolved: pinctrl: bcm2835: Don't remove an unregistered GPIO chip If the devm_pinctrl_register() fuCVE-2026-93274 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67

  In the Linux kernel, the following vulnerability has been resolved: pinctrl: bcm2835: Don't remove an unregistered GPIO chip If the devm_pinctrl_register() function fails, bcm2835_pinctrl_probe() calls gpiochip_remove() before gpiochip_add_data() has registered the GPIO chip. This means that upon failure the gpio_chip.gpiodev is NULL resulting in a null pointer dereference inside the gpiochip_remove() function. Remove the unnecessary function call to gpiochip_remove(). No GPIO cleanup is required because the GPIO chip has not yet been registered. Without this change there is potential for a kernel panic upon registration 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 24, 2026In the Linux kernel, the following vulnerability has been resolved: regulator: tps6594: Fix device node reference leaks in multiphase loop In tps6594_regulatoCVE-2026-93273 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67

  In the Linux kernel, the following vulnerability has been resolved: regulator: tps6594: Fix device node reference leaks in multiphase loop In tps6594_regulator_probe(), the multi-phase configuration loop calls of_find_node_by_name() to find buck nodes by name, and of_get_parent() twice to navigate to the PMIC parent node. None of the acquired node references (np, intermediate parent, np_pmic_parent) are ever released via of_node_put(), causing a reference leak on every loop iteration. Additionally, of_find_node_by_name() can return NULL, but the result was immediately passed to of_node_full_name() and of_get_parent() without a NULL check, which could lead to a NULL pointer dereference. Fix this by: - Adding a NULL check for np after of_find_node_by_name() - Storing the intermediate parent node in a local variable np_parent - Calling of_node_put() on np, np_parent and np_pmic_parent at the end of each loop iteration

  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 24, 2026In the Linux kernel, the following vulnerability has been resolved: remoteproc: qcom_wcnss: Fix handling the lack of PD regulators in v3 The changes introduceCVE-2026-93272 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67

  In the Linux kernel, the following vulnerability has been resolved: remoteproc: qcom_wcnss: Fix handling the lack of PD regulators in v3 The changes introduced to handle single power domain platforms have swapped the info pointer increment from num_pd_vregs to num_pds, which would shift the info pointer past the end of the array for pronto-v3, which does not list power domain regulators in vregs. This showed up as a difference between GCC- and LLVM-compiled kernels on SDM632 devices, where only with LLVM one would get the "regulator request with no identifier" error, because the out-of-bounds memory ended up being zeroed. Fix by skipping the increment when there are more power domains than regulators.

  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 24, 2026In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: cap out-of-range rx MCS instead of leaving bogus rate ath11k can receive HT/CVE-2026-93271 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67

  In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: cap out-of-range rx MCS instead of leaving bogus rate ath11k can receive HT/VHT/HE frames whose reported MCS is above the maximum that can be expressed in the corresponding mac80211 rate space (e.g. an HE frame reported with MCS 12, while HE tops out at MCS 11). The frame itself is valid and decodes correctly, but for such a frame ath11k_dp_rx_h_rate() leaves rx_status->rate_idx set to the out-of-range value and never assigns rx_status->encoding, so it stays RX_ENC_LEGACY from the ath11k_dp_rx_h_ppdu() initialization. Once that frame reaches mac80211 it trips the rate sanity check and the frame is dropped with a splat: ath11k_pci 0000:03:00.0: Received with invalid mcs in HE mode 12 WARNING: CPU: 0 PID: 0 at net/mac80211/rx.c:5433 ieee80211_rx_list+0xb0a/0xe90 [mac80211] Dropping the frame would discard otherwise valid data, so instead cap the reported MCS to the maximum the rate space can express and deliver the frame. Set rx_status->encoding before the range check and assign rate_idx from the capped value, so a frame with an out-of-range MCS no longer leaves partial or bogus rate metadata b

  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 24, 2026In the Linux kernel, the following vulnerability has been resolved: bpf: Disallow interpreter fallback for BPF_ADDR_PERCPU insn The BPF_MOV64_PERCPU_REG insn CVE-2026-93270 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67

  In the Linux kernel, the following vulnerability has been resolved: bpf: Disallow interpreter fallback for BPF_ADDR_PERCPU insn The BPF_MOV64_PERCPU_REG insn requires JIT to emit native code to for 'dst_reg = src_reg + <percpu_base_off>'. However, the interpreter ignores the 'off' at its ALU64_MOV_X label. The 'off' indicates the insn is BPF_MOV64_PERCPU_REG insn. Then, when the interpreter loads memory from the register, it will hit a page fault. [ 2.545572] BUG: unable to handle page fault for address: ffffffffacaaf034 [ 2.546485] #PF: supervisor read access in kernel mode [ 2.547167] #PF: error_code(0x0000) - not-present page [ 2.547850] PGD 134e63067 P4D 134e63067 PUD 134e64063 PMD 10021c063 PTE 800ffffeca550062 [ 2.548912] Oops: Oops: 0000 [#1] SMP PTI Set jit_required as true in order to disallow interpreter fallback in core.c::__bpf_prog_select_runtime(), if any BPF_ADDR_PERCPU insn is patched to the prog. BTW, rename the helper bpf_map_supports_cpu_flags() to bpf_map_is_percpu_map().

  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 24, 2026In the Linux kernel, the following vulnerability has been resolved: ext4: fix circular lock dependency in ext4_ext_migrate Move iput(tmp_inode) after ext4_wriCVE-2026-93269 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67

  In the Linux kernel, the following vulnerability has been resolved: ext4: fix circular lock dependency in ext4_ext_migrate Move iput(tmp_inode) after ext4_writepages_up_write() to avoid a circular lock dependency between s_writepages_rwsem and sb_internal (freeze protection). The deadlock scenario: CPU0 (EXT4_IOC_MIGRATE) CPU1 (orphan cleanup during mount) ---- ---- ext4_ext_migrate() ext4_writepages_down_write() s_writepages_rwsem (write) ext4_evict_inode() sb_start_intwrite() [sb_internal] ... ext4_writepages() s_writepages_rwsem (read) [BLOCKED] iput(tmp_inode) ext4_evict_inode() sb_start_intwrite() [BLOCKED] The tmp_inode is a temporary inode with nlink=0 created solely for building the extent tree. Its eviction does not require s_writepages_rwsem protection, so deferring iput() until after releasing the rwsem is safe.

  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 24, 2026In the Linux kernel, the following vulnerability has been resolved: ext4: skip extra isize expansion during mount to prevent deadlock ext4_try_to_expand_extraCVE-2026-93268 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67

  In the Linux kernel, the following vulnerability has been resolved: ext4: skip extra isize expansion during mount to prevent deadlock ext4_try_to_expand_extra_isize() is called from __ext4_mark_inode_dirty() while holding an active jbd2 handle. During mount (!SB_ACTIVE), the expand path may move xattrs to external blocks and release ea_inodes via iput(). When !SB_ACTIVE, iput() calls write_inode_now() which acquires s_writepages_rwsem, creating a circular lock dependency: s_writepages_rwsem --> jbd2_handle --> xattr_sem --> s_writepages_rwsem This can be triggered via: ext4_process_orphan() -> ext4_truncate() -> ext4_mark_inode_dirty() -> ext4_try_to_expand_extra_isize() or: ext4_evict_inode() -> ext4_mark_inode_dirty() -> ext4_try_to_expand_extra_isize() Skip expansion when !SB_ACTIVE. This is a minor loss of functionality (extra isize won't grow for these inodes during mount), which e2fsck can resolve later if needed.

  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 24, 2026In the Linux kernel, the following vulnerability has been resolved: RDMA/core: Fix potential use after free in uverbs_free_dmah() When accessing a dmah via thCVE-2026-93267 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67

  In the Linux kernel, the following vulnerability has been resolved: RDMA/core: Fix potential use after free in uverbs_free_dmah() When accessing a dmah via the netlink path the only synchronization mechanism for the said dmah is rdma_restrack_get(). Currently, rdma_restrack_del() is invoked at the end of uverbs_free_dmah(), which is too late, since by that point vendor-specific resources associated with the dmah might already be freed. This can leave a short window where the dmah remains accessible through restrack, leading to a potential use-after-free. Fix this by moving the rdma_restrack_begin_del() call to the start of uverbs_free_dmah(), ensuring that the dmah is removed from restrack before its internal resources are released. This guarantees that no new users hold references to a dmah that is in the process of destruction. In addition, this change preserves the intended inverted order between create and destroy routines: resources are added to restrack at the end of successful creation, and hence shall be removed from the restrack first thing during the destruction flow, which keeps the lifecycle management consistent and predictable.

  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 24, 2026In the Linux kernel, the following vulnerability has been resolved: arm64: RSI: fix field-spanning write warning in attestation token init The challenge is paCVE-2026-93266 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67

  In the Linux kernel, the following vulnerability has been resolved: arm64: RSI: fix field-spanning write warning in attestation token init The challenge is passed in registers a1 through a8. However, copying to &regs.a1 makes FORTIFY treat the destination as the single a1 field, resulting in a field-spanning write warning. [1] Overlay the SMCCC register structure with an RSI-specific argument layout and copy the challenge into an explicit 64-byte array. This keeps the existing a1-a8 argument encoding while giving the copy a correctly sized destination object. [1] memcpy: detected field-spanning write (size 64) of single field "&regs.a1" at ./arch/arm64/include/asm/rsi_cmds.h:119 (size 8) WARNING: ./arch/arm64/include/asm/rsi_cmds.h:119 at rsi_attestation_token_init+0xdc/0xf8 [arm_cca_guest], CPU#0: cat/3314

  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 24, 2026In the Linux kernel, the following vulnerability has been resolved: PCI/pwrctrl: tc9563: Fix parsing the integrated Ethernet MAC Endpoint node DSP3 has an intCVE-2026-93265 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67High 7.7

  In the Linux kernel, the following vulnerability has been resolved: PCI/pwrctrl: tc9563: Fix parsing the integrated Ethernet MAC Endpoint node DSP3 has an integrated Ethernet MAC Endpoint which has its own set of config registers for configuring settings such as ASPM. The Endpoint device has two physical functions and those two functions share the same settings. Parse the Endpoint node under DSP3 instead of parsing both functions. The existing parsing logic also has one OOB issue as parsing both functions will result in accessing past the tc9563_pwrctrl->cfg array.

  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 24, 2026In the Linux kernel, the following vulnerability has been resolved: RDMA/efa: Fix PBL chunk length computation On register MR, when creating the PBL, if it's CVE-2026-93264 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67

  In the Linux kernel, the following vulnerability has been resolved: RDMA/efa: Fix PBL chunk length computation On register MR, when creating the PBL, if it's an indirect PBL we create a chunk list to hold the PBL pages pointers. Each chunk is 4KB in size and can hold 510 addresses (EFA_PTRS_PER_CHUNK) and has a 12-byte control buffer at the end of it holding the next chunk's pointer and its length. If the PBL number of pages is a multiple of EFA_PTRS_PER_CHUNK, the calculated last chunk length is wrongly computed as 0, even though that chunk is fully populated with 510 real page pointers. This wrong length is used both to DMA map the chunk and is propagated to the device, causing the device to see the chunk as empty and reject the memory registration. Fix the calculation so it will be performed only if the number of pages isn't a multiple of EFA_PTRS_PER_CHUNK, if it is, its already handled in the above loop correctly. Also prevent out-of-bounds reach in the chunks array in such scenario.

  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 24, 2026In the Linux kernel, the following vulnerability has been resolved: clk: eswin: Zero-initialize stack-allocated clk_init_data eswin_clk_register_pll() and eswCVE-2026-93263 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67

  In the Linux kernel, the following vulnerability has been resolved: clk: eswin: Zero-initialize stack-allocated clk_init_data eswin_clk_register_pll() and eswin_register_clkdiv() declare a struct clk_init_data on the stack and only initialize some of its fields (parent_data respectively parent_hws). clk_core_populate_parent_map() checks parent_names first and parent_data second before falling back to parent_hws, so leftover stack garbage in the uninitialized fields hijacks parent resolution and the clk core dereferences a bogus pointer: Unable to handle kernel NULL pointer dereference at virtual address 000000000000000c Oops [#1] epc : __clk_register+0x31a/0x7f0 [<ffffffff805dc774>] __clk_register+0x31a/0x7f0 [<ffffffff805dcd76>] devm_clk_hw_register+0x2a/0x94 [<ffffffff805e319a>] eswin_register_clkdiv+0x80/0xd0 [<ffffffff805e34a0>] eswin_clk_register_clks+0x162/0x1a0 [<ffffffff805e3736>] eic7700_clk_probe+0x146/0x180 [<ffffffff8065d23c>] platform_probe+0x3c/0x7a Observed on EIC7700 hardware (with the driver backported to a 6.17 tree); whether the bug triggers depends entirely on what the stack happens to contain when the registration helpers run. Zero-initia

  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 24, 2026In the Linux kernel, the following vulnerability has been resolved: md/raid5-ppl: fix use-after-free in ppl_do_flush() The loop in ppl_do_flush() continues itCVE-2026-93262 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67High 7.8

  In the Linux kernel, the following vulnerability has been resolved: md/raid5-ppl: fix use-after-free in ppl_do_flush() The loop in ppl_do_flush() continues iterating after calling ppl_io_unit_finished(), touching io->pending_flushes and leading to a use-after-free. Add a break statement to stop the loop once io is freed.

  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 24, 2026In the Linux kernel, the following vulnerability has been resolved: locking/lockdep: Fix NULL pointer dereference in __lock_set_class() register_lock_class() CVE-2026-93261 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67

  In the Linux kernel, the following vulnerability has been resolved: locking/lockdep: Fix NULL pointer dereference in __lock_set_class() register_lock_class() can return NULL when the lock class pool is exhausted, graph_lock() fails, or key validation fails. However, __lock_set_class() uses the return value directly in pointer arithmetic without a NULL check: class = register_lock_class(lock, subclass, 0); hlock->class_idx = class - lock_classes; If class is NULL, this computes a wild offset that corrupts hlock->class_idx. The subsequent reacquire_held_locks() call will invoke hlock_class() with this corrupted index, leading to a NULL or out-of-bounds pointer dereference. Add the missing NULL check, consistent with how __lock_acquire() already handles this case at the same call site.

  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 24, 2026In the Linux kernel, the following vulnerability has been resolved: powerpc/xive: propagate IPI init errors to prevent use-after-free When xive_init_ipis() faCVE-2026-93260 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67High 7.4

  In the Linux kernel, the following vulnerability has been resolved: powerpc/xive: propagate IPI init errors to prevent use-after-free When xive_init_ipis() fails (e.g. irq_domain_alloc_irqs() fails), the error path frees the global xive_ipis array. However, xive_smp_probe() previously ignored this failure and proceeded to call xive_setup_cpu_ipi(), which dereferences the already-freed xive_ipis pointer -- a use-after-free. Now that xive_smp_probe() returns int (previous patch), propagate the error from xive_init_ipis() and xive_setup_cpu_ipi() through xive_smp_probe(). Check the return value in both pnv_smp_probe() and pSeries_smp_probe() so that IPI setup is aborted cleanly on failure, avoiding the use-after-free.

  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 24, 2026In the Linux kernel, the following vulnerability has been resolved: powerpc/irq: Fix missing r2 clobber in PCREL inline assembly In CONFIG_PPC_KERNEL_PCREL moCVE-2026-93259 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67

  In the Linux kernel, the following vulnerability has been resolved: powerpc/irq: Fix missing r2 clobber in PCREL inline assembly In CONFIG_PPC_KERNEL_PCREL mode, r2 is no longer reserved for the TOC pointer and is available as a caller-saved register [0]. Both call_do_irq() and call_do_softirq() use inline assembly to call functions with stack switching, but fail to list r2 in their clobber lists. This causes the compiler to assume r2 is preserved across these calls, leading to register corruption when the called functions (__do_irq and __do_softirq) clobber r2. As a result of this kernel crash during interrupt handling is seen and the kernel fails to boot: BUG: Unable to handle kernel data access on write at 0xc000000404697638 Faulting instruction address: 0xc0000000000181ec Oops: Kernel access of bad area, sig: 11 [#1] NIP [c0000000000181ec] __do_IRQ+0x6c/0xc0 With older GCC, the compiler would conservatively allocate callee-saved registers (like r31) for values spanning function calls, accidentally avoiding the bug: <__do_IRQ>: 00 00 00 60 nop a6 02 08 7c mflr r0 f8 ff e1 fb std r31,-8(r1) f0 ff c1 fb std r30,-16(r1) 2d 03 10 06 pla r31,53297316 ...

  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 24, 2026In the Linux kernel, the following vulnerability has been resolved: ocfs2: do not use make_bad_inode() in ocfs2_read_inode_block_full() This reverts commit 58CVE-2026-93258 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67

  In the Linux kernel, the following vulnerability has been resolved: ocfs2: do not use make_bad_inode() in ocfs2_read_inode_block_full() This reverts commit 58b6fcd2ab34 ("ocfs2: mark inode bad upon validation failure during read"). Since 'make_bad_inode()' resets inode type to S_IFREG, doing this for directory inode during active VFS lookup is likely to confuse the latter, including VFS_BUG_ON_INODE() triggered in this 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

• Sep 24, 2026In the Linux kernel, the following vulnerability has been resolved: block: handle nogenerate/noverify properly in fs-integrity Check the BIP_CHECK flags beforCVE-2026-93257 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67

  In the Linux kernel, the following vulnerability has been resolved: block: handle nogenerate/noverify properly in fs-integrity Check the BIP_CHECK flags before generating or verifying PI information, otherwise this can be incorrectly called for non-PI metadata and cause generation of incorrect metadata and crashed in the verification handler. The new behavior matches that of the block layer auto-generated metadata.

  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 24, 2026In the Linux kernel, the following vulnerability has been resolved: arm64: hibernate: mask DAIF before restoring hibernated kernel The arm64 hibernate code maCVE-2026-93256 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67

  In the Linux kernel, the following vulnerability has been resolved: arm64: hibernate: mask DAIF before restoring hibernated kernel The arm64 hibernate code manages the exception masking in an unsound way, leading to potential crashes and/or warnings during resume. When a hibernation image is saved in `swsusp_arch_suspend()`, all DAIF exceptions are masked (by virtue of `local_daif_save()`), and the suspended image is saved assuming that all DAIF exceptions will remain masked when the image is restored. When a hibernation image is resumed by `swsusp_arch_resume()`, only interrupts are masked (by virtue of `local_irq_disable()` in `resume_target_kernel()`). When pseudo-NMI is enabled the DAIF.IF bits will be clear, and regardless of pseudo-NMI the DAIF.DA bits will be clear. This means that there are two problems: (1) It is possible to take Debug, SError, or pseudo-NMI exceptions during the resume process. This is unsafe, as during the resume process both the old ane new kernels will tranisently be in an inconsistent state, and swsusp_arch_suspend_exit() won't retain an executable mapping of any exception vectors. Any exception taken here will be fatal and

  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 24, 2026In the Linux kernel, the following vulnerability has been resolved: btrfs: make sure EXTENT_BUFFER_READING is cleared under refs_lock [FALSE ALERTS] There is CVE-2026-93255 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67

  In the Linux kernel, the following vulnerability has been resolved: btrfs: make sure EXTENT_BUFFER_READING is cleared under refs_lock [FALSE ALERTS] There is a bug report that the warning inside invalidate_and_check_btree_folios() got triggered during btrfs/298: BTRFS info (device sdd): first mount of filesystem f9bf732a-a19b-44b9-99a7-614ddff168e2 BTRFS info (device sdd): using crc32c checksum algorithm BTRFS error (device sdd): failed to find fsid cb2fdb42-b638-4f2f-badd-4127467ba674 when attempting to open seed devices BTRFS error (device sdd): failed to read chunk tree: -2 ------------[ cut here ]------------ WARNING: disk-io.c:3342 at invalidate_and_check_btree_folios+0x260/0x3c0 [btrfs], CPU#4: mount/125993 CPU: 4 UID: 0 PID: 125993 Comm: mount Tainted: G W OE 7.1.0-rc7-custom+ #1 PREEMPT(full) Hardware name: QEMU KVM Virtual Machine, BIOS edk2-20250812-19.fc42 08/12/2025 Call trace: invalidate_and_check_btree_folios+0x260/0x3c0 [btrfs] (P) open_ctree+0x1f50/0x23b0 [btrfs] btrfs_get_tree+0x89c/0xc48 [btrfs] vfs_get_tree+0x30/0x110 vfs_cmd_create+0x58/0xe8 __arm64_sys_fsconfig+0x39c/0x518 invoke_syscall.constprop.0+0x48/0x120 el0_svc_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 24, 2026In the Linux kernel, the following vulnerability has been resolved: arm64: entry: Avoid unnecessary local_irq_disable() on kernel exit Currently, when exitingCVE-2026-93254 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67

  In the Linux kernel, the following vulnerability has been resolved: arm64: entry: Avoid unnecessary local_irq_disable() on kernel exit Currently, when exiting to kernel mode, we attempt involuntary preemption. The preemption logic expects IRQs to be disabled, which is why we call local_irq_disable() before attempting preemption. However, depending on the context, local_irq_disable() may be unnecessary: - __el1_irq(), the non-NMI EL1 IRQ path, already has IRQs disabled, so local_irq_disable() is redundant. - irqentry_exit_to_kernel_mode_preempt() immediately returns when exiting from an NMI-like context, so calling local_irq_disable() beforehand is unnecessary work. Furthermore, it confuses the pNMI state tracking when we are in a context with interrupts disabled and the GIC_PRIO_PSR_I_SET bit is set in the PMR, leading to a warning when CONFIG_ARM64_DEBUG_PRIORITY_MASKING=y: WARNING: ./arch/arm64/include/asm/irqflags.h:63 at arm64_exit_to_kernel_mode+0xb8/0xc0, CPU#40: retsnoop/31805 CPU: 40 UID: 0 PID: 31805 Comm: retsnoop Not tainted 7.2.0-rc6-next-20260805 #7 PREEMPTLAZY pstate: 234013c9 (nzCv DAIF +PAN -UAO +TCO +DIT +SSBS BTYPE=--) pc : arm64_e

  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 24, 2026In the Linux kernel, the following vulnerability has been resolved: sched/isolation: Defer freeing of cpumask memblock memory to initcall When testing a linuxCVE-2026-93253 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67

  In the Linux kernel, the following vulnerability has been resolved: sched/isolation: Defer freeing of cpumask memblock memory to initcall When testing a linux-next kernel with commit 59bd1d914bb5 ("memblock: warn when freeing reserved memory before memory map is initialized"), the following warning was hit when there was a "nohz_full" kernel boot parameter. Cannot free reserved memory because of deferred initialization of the memory map WARNING: mm/memblock.c:904 at __free_reserved_area+0xde/0xf0, CPU#0: swapper/0/0 : Call Trace: <TASK> memblock_phys_free+0xcb/0x100 housekeeping_init+0x14c/0x170 start_kernel+0x207/0x450 x86_64_start_reservations+0x24/0x30 x86_64_start_kernel+0xda/0xe0 common_startup_64+0x13e/0x141 </TASK> IOW, we shouldn't free memblock allocated memory so early in the boot process when memory map isn't fully initialized in deferred_init_memmap(). Fix it by saving the housekeeping cpumask memblock memory to be freed into a llist free list in housekeeping_init() and add a new housekeeping_late_init() helper to defer the actual freeing of memblock memory to when initcall's are being processed. The cpumask memblock memory is trea

  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 24, 2026In the Linux kernel, the following vulnerability has been resolved: ocfs2: fix circular locking dependency in ocfs2_init_acl() A lockdep warning indicates a cCVE-2026-93252 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67

  In the Linux kernel, the following vulnerability has been resolved: ocfs2: fix circular locking dependency in ocfs2_init_acl() A lockdep warning indicates a circular locking dependency between `&oi->ip_xattr_sem` and `&journal->j_trans_barrier`: WARNING: possible circular locking dependency detected is trying to acquire lock: (&oi->ip_xattr_sem){++++}-{4:4}, at: ocfs2_init_acl+0x2fd/0x7e0 fs/ocfs2/acl.c:367 but task is already holding lock: (&journal->j_trans_barrier){.+.+}-{4:4}, at: ocfs2_start_trans+0x3ab/0x700 fs/ocfs2/journal.c:369 The deadlock involves two code paths: Path 1 (setxattr) where `ocfs2_xattr_set()` acquires `ip_xattr_sem` (write) and then starts a transaction, which acquires `j_trans_barrier` (read); and Path 2 (mkdir/mknod) where `ocfs2_mknod()` starts a transaction (`j_trans_barrier` read) and then calls `ocfs2_init_acl()`, which attempts to acquire `ip_xattr_sem` (read) on the parent directory to retrieve the default ACL. Because rw_semaphores are subject to writer priority, a pending writer on `j_trans_barrier` (e.g., the journal commit thread) can cause Path 1 to block, while Path 2 is blocked waiting for Path 1 to release `ip_xattr_sem`. The patc

  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 24, 2026In the Linux kernel, the following vulnerability has been resolved: ACPI: bus: Introduce acpi_bus_get_primary_device() The function used for obtaining the firCVE-2026-93251 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67

  In the Linux kernel, the following vulnerability has been resolved: ACPI: bus: Introduce acpi_bus_get_primary_device() The function used for obtaining the first "physical" device for which the given ACPI one is the ACPI companion, acpi_get_first_physical_node(), may return a stale device pointer (mostly in theory) because acpi_unbind_one() may run as a whole after dropping the ACPI device's physical_node_lock in acpi_get_first_physical_node() and before it returns. The last reference to the "physical" device may be dropped then before the pointer to it is returned to the caller. If that happens and the acpi_get_first_physical_node() caller invokes get_device() on the pointer obtained from it, which is done by the majority of its callers, a use-after-free will occur. To prepare for addressing this problem, introduce a new function for getting the first "physical" device associated with the given ACPI one (the "primary physical device") that will also reference count the device in question before returning a pointer to it. Make that new function and acpi_get_first_physical_node() share the physical node list lookup code. No intentional functional impact.

  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 24, 2026In the Linux kernel, the following vulnerability has been resolved: vxlan: mdb: Fix use-after-free in vxlan_mdb_flush() vxlan_mdb_flush() iterates over the MDCVE-2026-93250 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67High 7.8

  In the Linux kernel, the following vulnerability has been resolved: vxlan: mdb: Fix use-after-free in vxlan_mdb_flush() vxlan_mdb_flush() iterates over the MDB entries using hlist_for_each_entry_safe(), which only tolerates the removal of the current entry. Contrary to the comment above the loop, the removal of an entry can trigger the removal of another entry. Flushing the remotes of a (*, G) entry also removes the (S, G) entries that were created for its source list, once they are left without remotes: vxlan_mdb_remotes_flush() -> vxlan_mdb_remote_del() -> vxlan_mdb_remote_srcs_del() -> vxlan_mdb_remote_src_del() -> vxlan_mdb_remote_src_fwd_del() -> __vxlan_mdb_del() -> vxlan_mdb_entry_put() Such an entry can be located after the (*, G) entry in the list, as vxlan_mdb_entry_get() returns an existing entry without moving it to the head of the list. This order is obtained by adding the (S, G) entry before the (*, G) entry, the latter with NLM_F_REPLACE, as the addition of the source otherwise fails with -EEXIST. The (S, G) entry is then the entry saved by hlist_for_each_entry_safe() and it is freed while the (*, G) entry is processe

  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 24, 2026In the Linux kernel, the following vulnerability has been resolved: spi: amlogic-spisg: Make sure clk_init_data is fully initialized The clk_init_data structuCVE-2026-93249 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67

  In the Linux kernel, the following vulnerability has been resolved: spi: amlogic-spisg: Make sure clk_init_data is fully initialized The clk_init_data structure contains several mutually-exclusive members for different methods to specify the possible parents of a clock, prompting drivers to initialize only the members they need. However, not initializing all members may cause subtle issues, which are only exposed when CONFIG_INIT_STACK_ALL_PATTERN or CONFIG_INIT_STACK_NONE is enabled. aml_spisg_clk_init() fills in init.parent_data, and assumes that init.parent_names is NULL. However, the latter in uninitialized, and thus may cause a crash. Make sure all members are fully initialized, to fix such bugs, and to avoid future breakage when converting drivers to a different method for specifying the parents.

  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 24, 2026In the Linux kernel, the following vulnerability has been resolved: drm/xe: don't WARN on kernel job timeout when device already wedged igt@xe_wedged@wedged-aCVE-2026-93248 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67

  In the Linux kernel, the following vulnerability has been resolved: drm/xe: don't WARN on kernel job timeout when device already wedged igt@xe_wedged@wedged-at-any-timeout wedges the device in mode 2 (UPON_ANY_HANG_NO_RESET) and then rebinds the driver. During unbind, a GSC proxy kernel submission can still time out; with the device wedged and the GuC CT stopped it can never complete, so its kernel job times out. Tile0: GT1: Kernel-submitted job timed out WARNING: drivers/gpu/drm/xe/xe_guc_submit.c:... at guc_exec_queue_timedout_job() Workqueue: gt-ordered-wq drm_sched_job_timedout Killed queues skip guc_submit_hint_wedged(), leaving 'wedged' false even though the device is already wedged. The timeout handler then treats the kernel queue timeout as unexpected and taints the kernel. Honour an already-wedged device even for killed queues so the expected teardown timeout no longer trips the WARN. (cherry picked from commit a1c1dbd0f047bb05de6aaf6abe9103031179bf19)

  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 24, 2026In the Linux kernel, the following vulnerability has been resolved: Bluetooth: mgmt: fix 'hdev->discovery.uuids' NULL dereference 'uuid_count' member of strucCVE-2026-93247 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67

  In the Linux kernel, the following vulnerability has been resolved: Bluetooth: mgmt: fix 'hdev->discovery.uuids' NULL dereference 'uuid_count' member of struct 'discovery_state' is assigned and read without any locks, so there is a chance of situation when uuid_count != 0, but uuids is NULL and there will be NULL pointer dereference. Possible race: 'hci_update_passive_scan_sync' 'hci_discovery_filter_clear' hdev->discovery.uuid_count = 0; <----------------------preempted-----------------------------> 'start_service_discovery' // Set uuid_count to value != 0 hdev->discovery.uuid_count = uuid_count; hdev->discovery.uuids = kmemdup(...); <----------------------preempted-----------------------------> spin_lock(&hdev->discovery.lock); kfree(hdev->discovery.uuids); hdev->discovery.uuids = NULL; spin_unlock(&hdev->discovery.lock); Now uuids == NULL and uuid_count != 0. So 'mgmt_device_found' -> 'is_filter_match' -> 'eir_has_uuids' receives non consistent discovery state, where NULL dereference of uuids happens. To fix it let's add discovery.lock arou

  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 24, 2026In the Linux kernel, the following vulnerability has been resolved: octeontx2-af: fix out-of-bounds read setting MSI-X irq affinity rvu_register_interrupts() CVE-2026-93246 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67

  In the Linux kernel, the following vulnerability has been resolved: octeontx2-af: fix out-of-bounds read setting MSI-X irq affinity rvu_register_interrupts() walks every MSI-X vector and uses strstr() to match "Mbox" or "FLR" in irq_name before pinning those interrupts to CPU 0. irq_name is a per-vector NAME_SIZE buffer, but not every slot is populated before this loop runs. strstr() keeps scanning until it finds a NUL terminator, so an uninitialized slot can trigger a KASAN slab-out-of-bounds read at boot when debug options are enabled. Use strnstr() with NAME_SIZE to bound the search within each vector's name buffer.

  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 24, 2026In the Linux kernel, the following vulnerability has been resolved: apparmor: policy_int make sure list heads are initialized before fail path If profile creaCVE-2026-93245 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67

  In the Linux kernel, the following vulnerability has been resolved: apparmor: policy_int make sure list heads are initialized before fail path If profile create fails before policy_init is complete the list heads are not properly initialized causing profile_free() sanity checks to trigger the following splat. AppArmor WARN aa_policy_destroy: (((!list_empty(&policy->profiles) && (&policy->profiles)->prev != ((void *) 0x122 + (0xdead000000000000UL))))): WARNING: security/apparmor/lib.c:509 at aa_policy_destroy+0x164/0x1b0 security/apparmor/lib.c:509, CPU#0: syz.0.17/5541 Modules linked in: CPU: 0 UID: 0 PID: 5541 Comm: syz.0.17 Not tainted syzkaller #0 PREEMPT(full) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 RIP: 0010:aa_policy_destroy+0x16b/0x1b0 security/apparmor/lib.c:509 Code: 85 ed 7e 4d e8 96 bc 37 fd 5b 41 5c 41 5e 41 5f 5d e9 19 27 4e 07 cc e8 83 bc 37 fd 48 8d 3d 0c f0 d3 0b 48 c7 c6 a4 eb 38 8e <67> 48 0f b9 3a e9 04 ff ff ff e8 66 bc 37 fd 48 8d 3d ff ef d3 0b RSP: 0018:ffffc9000345eaa0 EFLAGS: 00010293 RAX: ffffffff848f530d RBX: ffff88803f734800 RCX: ffff88801af2a580 RDX: 0000000000000000 RSI: ffffffff8e38eba4 RDI: ffffff

  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 24, 2026In the Linux kernel, the following vulnerability has been resolved: drm/sysfb: simpledrm: Improve stride validation Validate the computed stride against the mCVE-2026-93244 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67

  In the Linux kernel, the following vulnerability has been resolved: drm/sysfb: simpledrm: Improve stride validation Validate the computed stride against the maximum value INT_MAX.

  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 24, 2026In the Linux kernel, the following vulnerability has been resolved: mm/secretmem: properly account locked pages secretmem accounts folios by treating memory aCVE-2026-93243 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67

  In the Linux kernel, the following vulnerability has been resolved: mm/secretmem: properly account locked pages secretmem accounts folios by treating memory as if it were mlock()'d and thus limited by the RLIMIT_MEMLOCK limit. However the folios are unevictable and remain so until the inode is evicted, eliminating usual mlock() semantics - mapping folios then unmapping them does not clear their unevictable state, since it depends on AS_UNEVICTABLE, not PG_mlocked. A user can therefore easily work around the RLIMIT_MEMLOCK limit - simply map then unmap and VmLck no longer counts the secretmem range. Worse, folios are not accounted in the process's RSS, meaning the OOM killer won't know to kill the process. Repeatedly mapping/unmapping (or forking) can then result in the consumption of all available system memory with unevictable folios and cause system instability. A secretmem fd can be passed between processes and over fork so a per-process limit simply does not make sense, so follow the precedent set by io_uring, perf, skbuff, iommufd and xdp by tracking the number of locked pages in user_struct->locked_vm. Since the scope tracked is actually inode lifetime, the RLIMIT_MEM

  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 24, 2026In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Fix response queue over-consumption in __qla_consume_iocb() qla24xx_processCVE-2026-93242 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67

  In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Fix response queue over-consumption in __qla_consume_iocb() qla24xx_process_response_queue() advances ring_ptr past the head IOCB before dispatching, so by the time __qla_consume_iocb() runs, ring_ptr already points at the first continuation IOCB. The function however looped purex->entry_count times starting at ring_ptr. As entry_count includes the head, this consumed one entry too many: it stamped RESPONSE_PROCESSED on the next, unrelated IOCB and advanced the ring past it, silently dropping a legitimate firmware response. The head IOCB's signature was also never marked. Mark the head processed and account for it, then consume only the entry_count - 1 continuation IOCBs, matching __qla_copy_purex_to_buffer().

  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 24, 2026In the Linux kernel, the following vulnerability has been resolved: memcg: bypass the reclaim and oom killer for dying tasks once oom_reaper is done At Meta, CVE-2026-93241 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67

  In the Linux kernel, the following vulnerability has been resolved: memcg: bypass the reclaim and oom killer for dying tasks once oom_reaper is done At Meta, we are seeing instances where an OOM killed job is stuck in the exit path for several hours. In one particular case, the job was stuck for more than 8 hours and I had to manually remove the memory.max limits to allow the process to exit. The job was a single process job and had ~55 GiB memory.max and zswap enabled. It had almost 0 anon in memory and ~111 GiB in zswap compressed to ~51 GiB zswap pool (i.e. almost all of memory.current was zswap). Nothing was left on the LRUs to reclaim. On further inspection, I observed ~20k threads of that process stuck with the following stack: [<0>] mem_cgroup_out_of_memory+0x4e/0xa0 [<0>] charge_memcg+0x8bf/0x990 [<0>] mem_cgroup_swapin_charge_folio+0x4e/0x80 [<0>] __read_swap_cache_async+0x10c/0x260 [<0>] swapin_readahead+0x116/0x3f0 [<0>] do_swap_page+0x13c/0x1ce0 [<0>] handle_mm_fault+0x61d/0x11f0 [<0>] do_user_addr_fault+0x3e7/0x6d0 [<0>] exc_page_fault+0x8f/0x110 [<0>] asm_exc_page_fault+0x22/0x30 [<0>] __get_user_8+0x14/0x20 [<0>] futex_cleanup+0x27/0x1c0 [<0>] futex_exit_rel

  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 24, 2026In the Linux kernel, the following vulnerability has been resolved: memcg: make the v1 soft limit knob inert The v1 soft limit has been deprecated since v6.12CVE-2026-93240 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67

  In the Linux kernel, the following vulnerability has been resolved: memcg: make the v1 soft limit knob inert The v1 soft limit has been deprecated since v6.12 and nobody has reported depending on it. Start the removal by decoupling the interface from the implementation: keep memory.soft_limit_in_bytes, but ignore writes to it and always report the maximum value on read similar to what memory.kmem.limit_in_bytes already does. Writes are still parsed, so malformed input keeps returning -EINVAL. The knob now also behaves the same everywhere: it used to return -EOPNOTSUPP on PREEMPT_RT, where soft limit reclaim has always been disabled. This also fixes the syzbot report linked below. Soft limit reclaim is the only caller that runs shrink_lruvec() from kswapd against a specific memcg, so it is the only way to reach lru_gen_shrink_lruvec() and in turn set_mm_walk(), which warns when called from kswapd.

  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 24, 2026In the Linux kernel, the following vulnerability has been resolved: arm64: mm: Fix the lockless page-table walk in show_pte() show_pte() walks page tables locCVE-2026-93239 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67

  In the Linux kernel, the following vulnerability has been resolved: arm64: mm: Fix the lockless page-table walk in show_pte() show_pte() walks page tables locklessly and can run with interrupts enabled. A concurrent teardown can free a table page while it is being walked. It can also clear a parent entry after show_pte() checked it; the regular pXd_offset() helpers then reread the cleared entry and can derive a bogus lower-level pointer and fault again. Use the lockless offset helpers with the saved parent entries, as gup_fast() does, and pass the saved PMD to pte_offset_map(). For task page tables, arm64 selects MMU_GATHER_RCU_TABLE_FREE. Disable local interrupts around the walk to hold off RCU-deferred table frees and block the tlb_remove_table_sync_one() IPI until the walk is finished. Place the IRQ guard after the header print. This does not make the output a consistent snapshot, but prevents the task page-table walk from dereferencing a released table page or deriving a pointer from a different parent 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 24, 2026In the Linux kernel, the following vulnerability has been resolved: s390/vfio-ap: fix potential use of uninitialized apm_filtered bitmap The DECLARE_BITMAP(apCVE-2026-93238 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67

  In the Linux kernel, the following vulnerability has been resolved: s390/vfio-ap: fix potential use of uninitialized apm_filtered bitmap The DECLARE_BITMAP(apm_filtered, AP_DEVICES) macro allocates the bitmap on the stack without zero-initializing it. In vfio_ap_mdev_hot_plug_cfg(), the vfio_ap_mdev_filter_matrix() function is only called to initialize and populate apm_filtered if either filter_adapters or filter_domains is true. If the hot plug configuration change only adds control domains (meaning filter_cdoms is true, but filter_adapters and filter_domains are both false), vfio_ap_mdev_filter_matrix() is bypassed. Consequently, apm_filtered is passed to reset_queues_for_apids() with uninitialized stack garbage. This can cause reset_queues_for_apids() to interpret arbitrary stack garbage bits as valid APIDs to reset, potentially performing unintended guest hardware queue resets. Fix this by zero-initializing the apm_filtered bitmap at the beginning of vfio_ap_mdev_hot_plug_cfg() using bitmap_zero().

  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 24, 2026In the Linux kernel, the following vulnerability has been resolved: LoongArch: Add DIRECT_MAP_PHYSMEM_END definition get_free_mem_region() and mhp_get_pluggabCVE-2026-93237 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67High 7.8

  In the Linux kernel, the following vulnerability has been resolved: LoongArch: Add DIRECT_MAP_PHYSMEM_END definition get_free_mem_region() and mhp_get_pluggable_range() bound their search to DIRECT_MAP_PHYSMEM_END. LoongArch does not define it, so the fallback in include/linux/mm.h applies: under CONFIG_SPARSEMEM_VMEMMAP it is (1ULL << MAX_PHYSMEM_BITS) - 1, a compile-time constant that does not adapt to the CPU's physical address space bits (cpu_pabits, probed from CPUCFG1). The vmemmap window only covers physical space below 2^(cpu_pabits+1) (i.e. VMEMMAP_SIZE), so on CPUs with fewer physical address bits than MAX_PHYSMEM_BITS the fallback allows get_free_mem_region() to return a ZONE_DEVICE region outside the vmemmap window; vmemmap_populate() then wraps the memmap range around and maps it into low memory, silently corrupting the page tables. The same search also picked the top-of- address-space region that crashed memmap_init_zone_device() with amdkfd on Loongson-3C6000 in 6.16 [1]; the commit 2969b42c8f99 ("LoongArch/mm: align vmemmap to maximal folio size") keeps that region in bounds on current Loongson-3C6000 configs, but CPUs with smaller cpu_pabits (e.g. the Loongson-2

  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 24, 2026In the Linux kernel, the following vulnerability has been resolved: media: meson: vdec: fix NULL pointer deref in vdec_try_fmt_common When VIDIOC_TRY_FMT is cCVE-2026-93236 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67

  In the Linux kernel, the following vulnerability has been resolved: media: meson: vdec: fix NULL pointer deref in vdec_try_fmt_common When VIDIOC_TRY_FMT is called with an unsupported pixel format on the OUTPUT queue, vdec_try_fmt_common() falls back to V4L2_PIX_FMT_MPEG2. However, if a distro has locally patched MPEG2 support out (as it has been broken for some time) the platform format table does not contain MPEG2 so find_format() returns NULL and the subsequent dereference of fmt_out->max_width triggers a NULL pointer dereference. Fix this by falling back to the first format in the platform's format array instead of hardcoding V4L2_PIX_FMT_MPEG2. This is always valid since every platform defines at least one format.

  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.