Vulnerability database

18,668 results · page 36 of 374

• Sep 17, 2026In the Linux kernel, the following vulnerability has been resolved: sched/fair: Fix overflow in update_tg_cfs_runnable() A divide-by-zero crash is observed whCVE-2026-93182 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67

  In the Linux kernel, the following vulnerability has been resolved: sched/fair: Fix overflow in update_tg_cfs_runnable() A divide-by-zero crash is observed when running hackbench: [14697.488452] CPU: 112 UID: 0 PID: 124791 Comm: hackbench Not tainted 7.1.0-rc2+ [14697.492627] RIP: 0010:propagate_entity_load_avg+0x35f/0x3e0 [14697.506799] <TASK> [14697.507411] __dequeue_task+0x2b4/0xc70 [14697.508677] dequeue_task_fair+0x36/0x370 [14697.509047] dequeue_task+0x101/0x2f0 [14697.509426] __schedule+0x1b1/0x1a00 [14697.510868] anon_pipe_read+0x3da/0x450 [14697.511400] vfs_read+0x361/0x390 [14697.512053] __x64_sys_read+0x19/0x30 The divide-by-zero happens here: if (scale_load_down(gcfs_rq->load.weight)) { load_sum = div_u64(gcfs_rq->avg.load_sum, scale_load_down(gcfs_rq->load.weight)); } gcfs_rq->load.weight is an insane large value and is truncated to the lower 32 bits by div_u64, which happen to be 0. Using AI for investigation, the cause is a u32 overflow in update_tg_cfs_runnable(), and flat pickup became a victim when using tg_tasks(): u32 new_sum, divider; ... new_sum = se->avg.runnab

  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: perf/x86/intel/uncore: Fix uncore_box ref/unref ordering In uncore_event_cpu_online(), uncCVE-2026-93181 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67

  In the Linux kernel, the following vulnerability has been resolved: perf/x86/intel/uncore: Fix uncore_box ref/unref ordering In uncore_event_cpu_online(), uncore_box_ref() was called before uncore_change_context(). uncore_box_ref() gates on box->cpu >= 0, but box->cpu is still -1 at that point because uncore_change_context() has not run yet. As a result, the box is never initialized on the first CPU to come online in a die, leaving it permanently uninitialized in the single-CPU-per-die case. Thus, box->refcnt is one count below the true value, and in the CPU offline path, the box will be torn down on the second-to-last CPU. In uncore_event_cpu_offline(), uncore_box_unref() was called after uncore_change_context(), so box->cpu is already -1 when the collector CPU goes offline, which prevents it from tearing down the box. Fix by swapping the call order in both paths so that uncore_box_{ref,unref}() runs at the point where box->cpu reflects the correct context. Move allocate_boxes() out of uncore_box_ref() to enable this reordering.

  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/panthor: Fix NPD issue on partial unmap of an evicted BO This commit fixes the NULL poCVE-2026-93180 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67

  In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Fix NPD issue on partial unmap of an evicted BO This commit fixes the NULL pointer dereference issue that would have happened on the split of GPU mapping due to partial unmap of an evicted BO. There is a logic to handle the partial unmap of huge pages when the GPU mapping is split. That logic was not being completely skipped for the VMA of an evicted BO and that resulted in a NPD possibility for the 'bo->backing.pages' pointer, which is set to NULL when pages of a BO are released on eviction. Following dump was seen when a partial unmap was exercised for an evicted BO. Unable to handle kernel paging request at virtual address 0000000000002000 Mem abort info: ESR = 0x0000000096000004 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x04: level 0 translation fault Data abort info: ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 CM = 0, WnR = 0, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 user pgtable: 4k pages, 48-bit VAs, pgdp=00000008842e8000 [0000000000002000] pgd=0000000000000000, p4d=0000000000000000 Internal error: Oops: 00000

  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/powerplay: fix VoltageObjectInfo zero-stride loop and OOB read Reject voltage objeCVE-2026-93179 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67

  In the Linux kernel, the following vulnerability has been resolved: drm/amd/powerplay: fix VoltageObjectInfo zero-stride loop and OOB read Reject voltage objects whose usSize is smaller than the header or would advance the cursor past the table end, preventing an infinite loop or heap OOB read when the VBIOS supplies a malformed VoltageObjectInfo table.

  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/amdgpu/pm/powerplay: bounds-check voltage index in SMU7 lookup vddInd and vddcInd fielCVE-2026-93178 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67High 7.1

  In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/pm/powerplay: bounds-check voltage index in SMU7 lookup vddInd and vddcInd fields from VBIOS-parsed tables are used to index into voltage lookup tables without a bounds check. Return -EINVAL when any index is out of range.

  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/amdgpu/pm/powerplay: bounds-check voltage index in Vega10 lookup vddInd, vddciInd and CVE-2026-93177 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67High 7.3

  In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/pm/powerplay: bounds-check voltage index in Vega10 lookup vddInd, vddciInd and mvddInd from VBIOS-parsed tables index into vddc, vddci and vddmem lookup tables without bounds checks across nine sites. Return -EINVAL when any index is out of range.

  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 dangling pointer in plane reset function amdgpu_dm_plane_drm_plane_reCVE-2026-93176 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67High 7

  In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix dangling pointer in plane reset function amdgpu_dm_plane_drm_plane_reset() frees the old state before allocating a new one. If kzalloc() fails, the function returns without updating the state pointer, leaving a dangling pointer to already freed memory. Fix this by allocating the new state first. On allocation failure, the old state remains untouched and the function safely returns. Found by Linux Verification Center (linuxtesting.org) with SVACE. [adjust for movement around current amd-staging-drm-next]

  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 dangling pointer in CRTC reset function amdgpu_dm_crtc_reset_state() CVE-2026-93175 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67High 7.8

  In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix dangling pointer in CRTC reset function amdgpu_dm_crtc_reset_state() frees the old state before allocating a new one. If kzalloc() fails, the function returns without updating the state pointer, leaving a dangling pointer to already freed memory. Fix this by allocating the new state first. On allocation failure, the old state remains untouched and the function safely returns. Found by Linux Verification Center (linuxtesting.org) with SVACE. [adjust for movement around current amd-staging-drm-next]

  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: Copy per-CPU map value padding in copy_map_value_long() In kernel, per-CPU map elemenCVE-2026-93174 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67

  In the Linux kernel, the following vulnerability has been resolved: bpf: Copy per-CPU map value padding in copy_map_value_long() In kernel, per-CPU map elements are stored with round_up(map->value_size, 8) bytes. On UAPI lookup paths, it copies the rounded size for each CPU into a temporary buffer. However, copy_map_value_long() passes 'map->value_size' to bpf_obj_memcpy(). When the map has special fields, bpf_obj_memcpy() copies around those fields with memcpy(), and does not copy the tail padding between 'map->value_size' and round_up(map->value_size, 8). The temporary UAPI lookup buffers are allocated without __GFP_ZERO. As a result, when the per-CPU map's value size is not equal to round_up(map->value_size, 8), UAPI LOOKUP_ELEM and its variants can return stale heap contents from that padding to user space. The same issue applies to bpf_iter for per-CPU maps. Pass round_up(map->value_size, 8) to bpf_obj_memcpy() from copy_map_value_long(), so per-CPU maps both with and without special fields copy the entire per-CPU slot. Remove the now redundant round_up() from bpf_obj_memcpy()'s long_memcpy 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: bpf,lsm: Drop bpf_prog_free from sleepable_lsm_hooks __bpf_prog_put_rcu() is the call_rcu(CVE-2026-93173 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67

  In the Linux kernel, the following vulnerability has been resolved: bpf,lsm: Drop bpf_prog_free from sleepable_lsm_hooks __bpf_prog_put_rcu() is the call_rcu() callback for non-sleepable programs. security_bpf_prog_free() called from there fires bpf_prog_free in softirq; if a sleepable LSM prog is attached to that hook, might_fault() BUGs: BUG: sleeping function called from invalid context in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 5038 preempt_count: 101, expected: 0 Call Trace: <IRQ> __bpf_prog_enter_sleepable+0x1cd/0x320 kernel/bpf/trampoline.c:1255 bpf_trampoline_6442549705+0x53/0xd7 security_bpf_prog_free+0xde/0x130 security/security.c:5465 __bpf_prog_put_rcu+0xab/0xd0 kernel/bpf/syscall.c:2365 rcu_do_batch kernel/rcu/tree.c:2617 [inline] handle_softirqs+0x236/0x800 kernel/softirq.c:622 </IRQ> The call_rcu/call_rcu_tasks_trace split reflects the freed program's sleepability, not that of any attached observer. security_bpf_prog_free() also frees prog->aux->security, which has to stay after the grace period, so drop bpf_prog_free from sleepable_lsm_hooks rather than move the call. Non-sleepable observers still run there.

  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: mm/mm_init: handle alloc_percpu failure in free_area_init_core_hotplug We miss a failed alCVE-2026-93172 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67

  In the Linux kernel, the following vulnerability has been resolved: mm/mm_init: handle alloc_percpu failure in free_area_init_core_hotplug We miss a failed allocation check for pgdat->per_cpu_nodestats, which results in a NULL deref when we offset into the per-cpu area. Propagate -ENOMEM up the stack and leave per_cpu_nodestats pointing at boot_nodestats so a later online can retry the allocation. hotadd_init_pgdat() returns NULL on failure, which __try_online_node() already maps to -ENOMEM. On failure nothing needs to be unwound: - the node is never marked online - per_cpu_nodestats is left pointing at boot_nodestats - __add_memory_resource() cleans up pending memblock resources - later online attempts retry the per_cpu_nodestats allocation

  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: leds: lp5860: Fix a potential double-unlock In lp5860_device_init(), if lp5860_init_dt() fCVE-2026-93171 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67

  In the Linux kernel, the following vulnerability has been resolved: leds: lp5860: Fix a potential double-unlock In lp5860_device_init(), if lp5860_init_dt() fails, an already unlocked mutex is unlocked another time. Slightly rework how the lock is taken/released to avoid this potential double unlock.

  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: dmaengine: xilinx_dma: Fix channel idle state management in AXIDMA and MCDMA interrupt handCVE-2026-93170 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67High 7.8

  In the Linux kernel, the following vulnerability has been resolved: dmaengine: xilinx_dma: Fix channel idle state management in AXIDMA and MCDMA interrupt handlers Fix a race condition in AXIDMA and MCDMA irq handlers where the channel could be incorrectly marked as idle and attempt spurious transfers when descriptors are still being processed. The issue occurs when: 1. Multiple descriptors are queued and active. 2. An interrupt fires after completing some descriptors. 3. xilinx_dma_complete_descriptor() moves completed descriptors to done_list. 4. Channel is marked idle and start_transfer() is called even though active_list still contains unprocessed descriptors. 5. This leads to premature transfer attempts and potential descriptor corruption or missed completions. Only mark the channel as idle and start new transfers when the active list is actually empty, ensuring proper channel state management and avoiding spurious transfer 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: dmaengine: zynqmp_dma: fix race between runtime PM and device removal In zynqmp_dma_removeCVE-2026-93169 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67

  In the Linux kernel, the following vulnerability has been resolved: dmaengine: zynqmp_dma: fix race between runtime PM and device removal In zynqmp_dma_remove(), runtime PM was disabled only after checking state and doing a manual suspend. This can race with runtime PM in the remove/unbind (rmmod) path. Disable runtime PM first, then suspend only if the device is not already suspended. To prevent any further runtime PM transitions.

  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: dmaengine: xilinx_dma: Fix CPU stall in xilinx_dma_poll_timeout Currently when calling xilCVE-2026-93168 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67

  In the Linux kernel, the following vulnerability has been resolved: dmaengine: xilinx_dma: Fix CPU stall in xilinx_dma_poll_timeout Currently when calling xilinx_dma_poll_timeout with delay_us=0 and a condition that is never fulfilled, the CPU busy-waits for prolonged time and the timeout triggers only with a massive delay causing a CPU stall. This happens due to a huge underestimation of wall clock time in poll_timeout_us_atomic. Commit 7349a69cf312 ("iopoll: Do not use timekeeping in read_poll_timeout_atomic()") changed the behavior to no longer use ktime_get at the expense of underestimation of wall clock time which appears to be very large for delay_us=0. Instead of timing out after approximately XILINX_DMA_LOOP_COUNT microseconds, the timeout takes XILINX_DMA_LOOP_COUNT * 1000 * (time that the overhead of the for loop in poll_timeout_us_atomic takes) which is in the range of several minutes for XILINX_DMA_LOOP_COUNT=1000000. Fix this by using a non-zero value for delay_us. Use delay_us=10 to keep the delay in the hot path of starting DMA transfers minimal but still avoid CPU stalls in case of unexpected hardware failures. One-off measurement with delay_us=0 causes the cpu

  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: csky: Fix a4/a5 restoration in syscall trace path The syscall trace path reloads syscall aCVE-2026-93167 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67

  In the Linux kernel, the following vulnerability has been resolved: csky: Fix a4/a5 restoration in syscall trace path The syscall trace path reloads syscall arguments from pt_regs before calling the syscall handler. On C-SKY ABIv2, the 5th and 6th syscall arguments are prepared as stack arguments before invoking syscallid. The current code adjusts sp before loading LSAVE_A4 and LSAVE_A5. Since those offsets are relative to the original pt_regs base, loading them after changing sp fetches the wrong slots. As a result, traced syscalls that use the 5th or 6th argument may receive corrupted arguments. This is visible with mmap2(), which takes six arguments. A small PTRACE_SYSCALL reproducer opens a file and maps one page with: mmap(NULL, 4096, PROT_READ | PROT_EXEC, MAP_PRIVATE, fd, 0) Before the fix, the traced child fails the mmap and exits with 12. After the fix, the mapping succeeds and the child exits with 0. Fix the trace path by loading a4/a5 from pt_regs before changing sp. Tested on: ck860f, linux-4.19.15, C-SKY abiv2

  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: rtw89: debug: fix off by on in rtw89_ppdu_str() This > comparison should be >= to avCVE-2026-93166 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67

  In the Linux kernel, the following vulnerability has been resolved: wifi: rtw89: debug: fix off by on in rtw89_ppdu_str() This > comparison should be >= to avoid an out of bounds access.

  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: platform/chrome: sensorhub: Fix memory overread in ring handler `max_response` and `sensorCVE-2026-93165 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67High 7.7

  In the Linux kernel, the following vulnerability has been resolved: platform/chrome: sensorhub: Fix memory overread in ring handler `max_response` and `sensor_num` are read from different EC commands: - `max_response` is from cros_ec_get_proto_info(). ec_dev->max_response = info->max_response_packet_size - sizeof(struct ec_host_response); - `sensor_num` is from cros_ec_get_sensor_count(). sensor_num = cros_ec_get_sensor_count(ec); With a malfunctioning EC firmware, it is possible that the `msg->insize` (i.e., `fifo_info_length` in the context) could be clamped in cros_ec_cmd_xfer() because `msg->insize` is greater than `max_response`. int fifo_info_length = sizeof(struct ec_response_motion_sense_fifo_info) + sizeof(u16) * sensorhub->sensor_num; This means the number of read bytes could be less than expected. As a result, the subsequent memcpy() in cros_ec_sensorhub_ring_handler() overreads the `resp->fifo_info` buffer. Check the return value of cros_ec_cmd_xfer_status() and abort if the number of bytes read does not match the expected length.

  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: uprobes/x86: Move optimized uprobe from nop5 to nop10 Andrii reported an issue with optimiCVE-2026-93164 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67

  In the Linux kernel, the following vulnerability has been resolved: uprobes/x86: Move optimized uprobe from nop5 to nop10 Andrii reported an issue with optimized uprobes [1] that can clobber redzone area with call instruction storing return address on stack where user code may keep temporary data without adjusting rsp. Fixing this by moving the optimized uprobes on top of 10-bytes nop instruction, so we can squeeze another instruction to escape the redzone area before doing the call, like: lea -0x80(%rsp), %rsp call tramp Note the lea instruction is used to adjust the rsp register without changing the flags. We use nop10 and following transformation to optimized instructions above and back as suggested by Peterz [2]. Optimize path (int3_update_optimize): 1) Initial state after set_swbp() installed the uprobe: cc 2e 0f 1f 84 00 00 00 00 00 From offset 0 this is INT3 followed by the tail of the original 10-byte NOP. After a previous unoptimization bytes 5..9 may still contain the old call instruction, which remains valid for threads already there. 2) Rewrite the LEA tail and call displacement: cc [8d 64 24 80 e8 d0 d1 d2 d3] Fr

  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: hwrng: core - fix rng list on registration error hwrng_register(rng) does the following: CVE-2026-93163 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67

  In the Linux kernel, the following vulnerability has been resolved: hwrng: core - fix rng list on registration error hwrng_register(rng) does the following: 1. Checks if rng has name and read methods set 2. Checks if the name already exists 3. Adds rng to global rng_list 4. May try to set rng to current_rng If step 4 fails, it returns an error. However, it does not remove the rng from rng_list, causing a dangling reference which can result in use-after-free if the caller frees rng, since registration failed. Add a list_del_init() cleanup step.

  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: crypto: qat - cancel work on re-enable SR-IOV timeout The QAT reset worker queues SR-IOV rCVE-2026-93162 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67

  In the Linux kernel, the following vulnerability has been resolved: crypto: qat - cancel work on re-enable SR-IOV timeout The QAT reset worker queues SR-IOV reenable work using a work_struct and completion embedded in an on-stack adf_sriov_dev_data. If the completion wait times out, the reset worker can return while device_sriov_wq still holds or executes the stack-backed work item. Cancel the work on the device_sriov_wq on timeout before the stack frame unwinds.

  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: crypto: qat - clear AES key schedule from stack qat_alg_xts_reverse_key() expands the forwCVE-2026-93161 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67

  In the Linux kernel, the following vulnerability has been resolved: crypto: qat - clear AES key schedule from stack qat_alg_xts_reverse_key() expands the forward XTS AES key on the stack. That schedule contains key material and can remain in the stack frame. Clear the temporary crypto_aes_ctx with memzero_explicit() after the copy.

  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: crypto: atmel-ecc - reject hardware ECDH without a public key The hardware ECDH path in atCVE-2026-93160 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67

  In the Linux kernel, the following vulnerability has been resolved: crypto: atmel-ecc - reject hardware ECDH without a public key The hardware ECDH path in atmel_ecdh_compute_shared_secret() uses the private key stored in the device. However, the public key is cached only after atmel_ecdh_set_secret() successfully generated that private key for the current tfm. atmel_ecdh_generate_public_key() already rejects requests when no public key is cached. Add the same check to atmel_ecdh_compute_shared_secret() to prevent the device from using a private key that was not generated for the current tfm.

  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: crypto: atmel-sha204a - fix heap info leak on I2C transfer failure The nonblocking RNG patCVE-2026-93159 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67

  In the Linux kernel, the following vulnerability has been resolved: crypto: atmel-sha204a - fix heap info leak on I2C transfer failure The nonblocking RNG path allocates a work_data structure to track the state of an in-flight asynchronous I2C request. This pointer is stored in rng->priv and later consumed by the read path once the transaction completes. If the underlying I2C transfer fails, the completion callback is invoked with a non-zero status. In this case, the allocated work_data is not usable for producing RNG output and must not remain associated with the hwrng state. Previously, the failure path only logged a warning but left the pointer state uncleared, which can result in subsequent read attempts observing stale state and interpreting it as valid completion data. Fix this by freeing the pending work_data. The I2C transaction reports an error. This ensures that failed requests do not leave residual state behind that could be interpreted as valid RNG data on later reads. Clearing rng->priv is done at the subsequent call to nonblocking read.

  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: crypto: sa2ul - stop probe if context pool creation fails sa_ul_probe() calls sa_init_mem(CVE-2026-93158 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67

  In the Linux kernel, the following vulnerability has been resolved: crypto: sa2ul - stop probe if context pool creation fails sa_ul_probe() calls sa_init_mem() to create the DMA pool used for security context buffers, but ignores its return value. If pool creation fails, probe still continues with DMA setup, algorithm registration and child population even though later request setup depends on that pool. Stop probing when sa_init_mem() fails, and route that failure to the PM cleanup path without attempting to destroy an uncreated DMA pool.

  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: hwrng: xilinx-trng - propagate timeout before any data is read xtrng_readblock32() polls fCVE-2026-93157 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67

  In the Linux kernel, the following vulnerability has been resolved: hwrng: xilinx-trng - propagate timeout before any data is read xtrng_readblock32() polls for 16-byte chunks but returns the number of bytes read even when the first poll times out. Its caller then treats a zero return as a short successful read, and partial reads for full 32-byte blocks can make the tail copy use a fixed block offset rather than the amount already produced. Return the poll error when no data has been read, preserve partial positive returns after some data is available, stop the generator on all collection exits, and append tail bytes at the current output count.

  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: crypto: rk3288 - fail ahash requests on HASH idle timeout rk_hash_run() waits for RK_CRYPTCVE-2026-93156 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67

  In the Linux kernel, the following vulnerability has been resolved: crypto: rk3288 - fail ahash requests on HASH idle timeout rk_hash_run() waits for RK_CRYPTO_HASH_STS to become idle after the final DMA transfer, but ignores the poll result. If the hash engine never becomes idle, the driver still reads the digest registers and finalizes the request with the previous success value. Store the poll result and finalize the request with the timeout error before reading the digest registers.

  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: crypto: keembay - Fix AEAD unregister count in error path register_aes_algs() registers thCVE-2026-93155 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67

  In the Linux kernel, the following vulnerability has been resolved: crypto: keembay - Fix AEAD unregister count in error path register_aes_algs() registers the AEAD algorithms before registering the skcipher algorithms. If skcipher registration fails, the function unwinds the earlier AEAD registration with crypto_engine_unregister_aeads(), but it passes ARRAY_SIZE(algs), which is the skcipher table size. Use ARRAY_SIZE(algs_aead) for the AEAD unwind path so the unregister helper iterates over the same table that was registered. Also clarify the nearby comment: the crypto registration helpers clean up algorithms registered within the same call, while this function must still unwind earlier successful registration steps.

  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/irdma: Add refcounting to user ring MRs Prevent userspace from deregistering the MRs CVE-2026-93154 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67High 7.8

  In the Linux kernel, the following vulnerability has been resolved: RDMA/irdma: Add refcounting to user ring MRs Prevent userspace from deregistering the MRs that back QP/CQ/SRQ rings by bumping the MR's refcount upon association.

  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/bng_re: return a timeout when firmware responses stall __wait_for_resp() documents thCVE-2026-93153 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67

  In the Linux kernel, the following vulnerability has been resolved: RDMA/bng_re: return a timeout when firmware responses stall __wait_for_resp() documents that it returns a non-zero error when a firmware command does not complete, and bng_re_rcfw_send_message() already marks the firmware as stalled when the helper returns -ENODEV. However, the helper ignores wait_event_timeout() expiry. If the response slot remains in use after the timeout and after the polled CREQ service attempt, the loop starts another full timeout period and can repeat forever. Return -ENODEV after a timed out wait that still has no response. The existing caller then marks FIRMWARE_STALL_DETECTED and returns -ETIMEDOUT to the command issuer.

  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: nvme-apple: Use acquire/release for queue enabled state apple_nvme_init_queue() initializeCVE-2026-93152 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67

  In the Linux kernel, the following vulnerability has been resolved: nvme-apple: Use acquire/release for queue enabled state apple_nvme_init_queue() initializes queue state and then marks the queue enabled. The interrupt and request paths check enabled before using that queue state. The old wmb() after WRITE_ONCE(enabled, true) does not publish the earlier initialization before enabled becomes visible. Use a release store when enabling the queue and acquire loads when testing it. Although the shutdown-side enabled accesses are not used for publishing queue initialization, use helpers for them as well for consistency.

  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: nvmet-rdma: fix response resource leak on queue teardown When an nvme target with rdma traCVE-2026-93151 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67High 7.5

  In the Linux kernel, the following vulnerability has been resolved: nvmet-rdma: fix response resource leak on queue teardown When an nvme target with rdma transport is removed while I/Os are in flight, a response can be posted but its send completion is never delivered before the connection is torn down. As a result nvmet_rdma_send_done() and nvmet_rdma_release_rsp() are never called for the response, and this leaks the allocated RDMA read/write context and request SGLs. These leaks are recreated by running blktests nvme/061 with the rdma transport and the siw driver. Kernel kmemleak feature reports them as follows: unreferenced object 0xffff88812bc490c0 (size 32): comm "kworker/2:1H", pid 409, jiffies 4307744490 backtrace (crc 89afd339): __kmalloc_noprof+0x5f9/0x890 sgl_alloc_order+0x7b/0x380 nvmet_req_alloc_sgls+0x290/0x4f0 [nvmet] nvmet_rdma_map_sgl_keyed+0x241/0x12e0 [nvmet_rdma] nvmet_rdma_handle_command+0x73e/0xb80 [nvmet_rdma] __ib_process_cq+0x149/0x4c0 [ib_core] ib_cq_poll_work+0x49/0x160 [ib_core] process_one_work+0x8b2/0x1640 worker_thread+0x5fd/0xfe0 kthread+0x367/0x460 ret_from_fork+0x655/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: cgroup/cpuset: Make nr_deadline_tasks an atomic_t The nr_deadline_tasks variable in the cpCVE-2026-93150 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67

  In the Linux kernel, the following vulnerability has been resolved: cgroup/cpuset: Make nr_deadline_tasks an atomic_t The nr_deadline_tasks variable in the cpuset structure was introduced by commit 6c24849f5515 ("sched/cpuset: Keep track of SCHED_DEADLINE task in cpusets"). It is reported by sashiko [1] that nr_deadline_tasks can currently be modified by inc_dl_tasks_cs() under rq->lock and by cpuset_attach() under cpuset_mutex. So if both updates happen simultaneously, the nr_deadline_tasks variable can be corrupted leading to incorrect operations down the road. Fix that by changing its type to atomic_t so that nr_deadline_tasks are always atomically updated. This fix patch is a low hanging fruit. It can handle some of the races between a concurrent sched_setscheduler() and cpuset_can_attach()/cpuset_attach() calls, but not all of them like the other issue raised by sashiko [2]. This will be handled hopefully in a future follow up patch. [1] https://sashiko.dev/#/patchset/20260626181923.133658-1-longman%40redhat.com [2] https://sashiko.dev/#/patchset/20260630033344.352702-1-longman%40redhat.com

  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: mac80211_hwsim: avoid NULL skb in stop queue drain mac80211_hwsim_stop() drops any fCVE-2026-93149 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67

  In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211_hwsim: avoid NULL skb in stop queue drain mac80211_hwsim_stop() drops any frames left in data->pending. The loop currently checks skb_queue_empty() and then dequeues separately. That split is racy with TX status handling, which can remove a pending frame under the queue lock. If the last entry is removed after the empty check, skb_dequeue() returns NULL and the stop path passes that NULL skb to ieee80211_free_txskb(). Use skb_dequeue() as the loop condition instead. The dequeue result is the object that stop owns and frees, and a concurrent status completion that empties the queue simply makes the loop terminate.

  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: Reject MEM_ALLOC BTF accesses past object bounds BTF struct walks relax the struct-siCVE-2026-93148 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67High 7.8

  In the Linux kernel, the following vulnerability has been resolved: bpf: Reject MEM_ALLOC BTF accesses past object bounds BTF struct walks relax the struct-size check for accesses through a trailing flexible array. That is valid for ordinary BTF type walking, but PTR_TO_BTF_ID | MEM_ALLOC values point to objects allocated with the static BTF type size. When walking a MEM_ALLOC object, reject the access before applying the flexible-array relaxation if the access range extends past the struct size. Apply the same policy to struct ID matching so kfunc and kptr type checks do not walk past the allocated object bounds either.

  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: s390/bpf: Replace ly instruction with llgf cpu_nr is a 32 bit value and BPF_REG_0 is a 64 CVE-2026-93147 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67High 7.8

  In the Linux kernel, the following vulnerability has been resolved: s390/bpf: Replace ly instruction with llgf cpu_nr is a 32 bit value and BPF_REG_0 is a 64 bit register, when ly loads the cpu_nr into BPF_REG_0 it does not zero the upper bits, but llgf does.

  Product

  Linux

  What to do

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

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

• Sep 17, 2026In the Linux kernel, the following vulnerability has been resolved: time/namespace: Validate nanosecond field in proc_timens_set_offset() The function validatCVE-2026-93146 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67

  In the Linux kernel, the following vulnerability has been resolved: time/namespace: Validate nanosecond field in proc_timens_set_offset() The function validates tv_sec to be within [-KTIME_SEC_MAX, KTIME_SEC_MAX] but never validates that tv_nsec is within the valid range of [0, NSEC_PER_SEC-1] before using it in timespec64_add(). timespec64_add() expects both timespec64 structures to have normalized values with tv_nsec in the range [0, 999999999]. If off->val.tv_nsec contains invalid values (negative or >= NSEC_PER_SEC), it could lead to incorrect calculations or unexpected behavior. Add validation to ensure tv_nsec is within the valid range before performing the addition.

  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: gdsc: tear down per-domain genpds in gdsc_unregister() gdsc_unregister() removeCVE-2026-93145 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67

  In the Linux kernel, the following vulnerability has been resolved: clk: qcom: gdsc: tear down per-domain genpds in gdsc_unregister() gdsc_unregister() removes the OF provider entry and tears down the parent/subdomain wiring, but never calls pm_genpd_remove() on the individual generic_pm_domain structures registered by gdsc_init(): void gdsc_unregister(struct gdsc_desc *desc) { struct device *dev = desc->dev; size_t num = desc->num; gdsc_pm_subdomain_remove(desc, num); of_genpd_del_provider(dev->of_node); } That leaves dangling entries on the global gpd_list. After a provider unbind/rebind cycle (deferred-probe replay during early boot, real module unload of a clk driver that owns GDSCs, or an OF-overlay tear- down) the next gdsc_init() will end up trying to re-register a name that is still in the list and pm_genpd_init() returns -EEXIST. While we are here, flip the order so the consumer-facing OF provider entry is the first thing removed -- otherwise a fresh of_genpd_get_from_provider() call racing with the teardown could attach to a domain that is mid-removal. Iterate the scs[] array and pm_genpd_remove() each registered domain after the subdomain links are torn

  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: Reject writes through untrusted BTF pointers check_ptr_to_btf_access() lets program-tCVE-2026-93144 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67High 7.8

  In the Linux kernel, the following vulnerability has been resolved: bpf: Reject writes through untrusted BTF pointers check_ptr_to_btf_access() lets program-type btf_struct_access callbacks validate writes before the default BTF access path rejects non-read accesses. That bypasses the read-only policy for untrusted BTF pointers created by helpers such as bpf_rdonly_cast(). Reject non-read accesses through PTR_UNTRUSTED BTF pointers at the common entry point, before the callback branch to handle all cases.

  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: staging: media: ipu7: fix pm_runtime refcount leak in ipu7_resume() ipu7_resume() calls pmCVE-2026-93143 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67

  In the Linux kernel, the following vulnerability has been resolved: staging: media: ipu7: fix pm_runtime refcount leak in ipu7_resume() ipu7_resume() calls pm_runtime_get_sync() before resuming the device. If the runtime PM resume fails, the usage count remains incremented, but the error path returns without dropping the reference. Use pm_runtime_resume_and_get() instead, which balances the usage count on failure and avoids the leak. Keep returning 0 on error, as resume callbacks should not propagate failures to the PM core, matching the behaviour of the ipu6 driver.

  Product

  Linux

  What to do

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

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

• Sep 17, 2026In the Linux kernel, the following vulnerability has been resolved: thermal/drivers/rcar: Fix error checking in probe() This code accidentally calls thermal_zCVE-2026-93142 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67

  In the Linux kernel, the following vulnerability has been resolved: thermal/drivers/rcar: Fix error checking in probe() This code accidentally calls thermal_zone_device_enable() before checking whether thermal_zone_device_register_with_trips() failed. Move the call until later to avoid an error pointer dereference of "priv->zone". The driver works differently depending on if we are using OF thermal or not. We use thermal_add_hwmon_sysfs() if we are using OF thermal and call thermal_zone_device_enable() if not. We can share same error check for if either of these fail. Moving the thermal_zone_device_enable() call is a bit cleaner as well. The original code used a three step process to cleanup: 1. Call thermal_zone_device_unregister() to cleanup. 2. Set priv->zone to an error pointer to preserve the error code. 3. Set priv->zone to NULL to avoid a second call to thermal_zone_device_unregister() in the rcar_thermal_remove() function. Now we can just do a direct goto error_unregister and rcar_thermal_remove() handles the cleanup properly.

  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: usb: gadget: r8a66597: avoid double free of ep0_req in probe error path If usb_add_gadget_CVE-2026-93141 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67

  In the Linux kernel, the following vulnerability has been resolved: usb: gadget: r8a66597: avoid double free of ep0_req in probe error path If usb_add_gadget_udc() fails, r8a66597_probe() jumps to err_add_udc and frees ep0_req, then falls through to clean_up2 where ep0_req is freed again when it is non-NULL. Remove the redundant free from err_add_udc and keep the cleanup in clean_up2 so the request is released exactly once. Issue found using a prototype static analysis tool and confirmed by code 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: udf: Mark LVID buffer as uptodate before marking it dirty When an I/O error occurs while wCVE-2026-93140 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67

  In the Linux kernel, the following vulnerability has been resolved: udf: Mark LVID buffer as uptodate before marking it dirty When an I/O error occurs while writing the Logical Volume Integrity Descriptor (LVID) buffer to the block device, the block layer's completion handler (`end_buffer_write_sync()`) clears the `BH_Uptodate` flag on the buffer. However, the buffer still contains valid LVID data in memory. If the filesystem is subsequently remounted read-write or synced, `udf_open_lvid()` or `udf_sync_fs()` will modify the LVID buffer and call `mark_buffer_dirty()`. This triggers a spurious `WARN_ON_ONCE(!buffer_uptodate(bh))` warning in `mark_buffer_dirty()` because the buffer is not marked uptodate, even though its in-memory contents are valid and are about to be overwritten. To prevent this spurious warning, unconditionally set the `BH_Uptodate` flag before calling `mark_buffer_dirty()` in `udf_open_lvid()` and `udf_sync_fs()`. This acknowledges that the in-memory buffer is valid and matches the workaround previously applied to `udf_close_lvid()` in commit 853a0c25baf9 ("udf: Mark LVID buffer as uptodate before marking it dirty"). Extending this workaround ensures consisten

  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/amdgpu/mes: Fix hung_queue_db_array loop limit for multi-XCC The loop iterated only AMCVE-2026-93139 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67

  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.

  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: Fix vmlinux BTF prep race in bpf_get_btf_vmlinux bpf_get_btf_vmlinux() lazily parses CVE-2026-93138 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67High 7.8

  In the Linux kernel, the following vulnerability has been resolved: bpf: Fix vmlinux BTF prep race in bpf_get_btf_vmlinux bpf_get_btf_vmlinux() lazily parses the vmlinux BTF under the bpf_verifier_lock, but publishes the result through a plain store and re-checks it through a plain lockless load. Nothing orders the stores initializing the struct btf inside btf_parse_vmlinux() against the store publishing the pointer: On a weakly ordered arch, a concurrent first-time caller taking the lockless fast path could in principle observe the pointer before the parsed contents are visible. The mutex_unlock() does not help such a reader given it only synchronizes with a later acquisition of the same lock. Thus, publish the pointer with smp_store_release() and read it on the fast path with smp_load_acquire(). Acquire semantics are needed rather than a dependency-ordered READ_ONCE(): btf_parse_vmlinux() also populates globals outside the returned object (e.g. bpf_ctx_convert.t). An address dependency would only order accesses performed through the pointer and not cover other globals.

  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: Fix use-after-free on mm_struct in bpf_find_vma() bpf_find_vma() reads task->mm and cCVE-2026-93137 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67High 7.8

  In the Linux kernel, the following vulnerability has been resolved: bpf: Fix use-after-free on mm_struct in bpf_find_vma() bpf_find_vma() reads task->mm and calls mmap_read_trylock(mm) without holding a reference on the mm. On a foreign task, a concurrent exit_mm() can free the mm_struct between the lockless read and the trylock, resulting in a use-after-free. mm_struct is not SLAB_TYPESAFE_BY_RCU. For the current task, task->mm is stable. For a foreign task, pin the mm under task->alloc_lock and release it with mmput_async(), mirroring commit d8e27d2d22b6 ("bpf: fix mm lifecycle in open-coded task_vma iterator"). Use spin_trylock() instead of get_task_mm() so BPF context does not block on alloc_lock. Reject irqs-disabled contexts and !CONFIG_MMU on the foreign-task path because dropping the mm reference is not safe there. Race: CPU0 (BPF program) CPU1 (exiting task) ============================ ========================== bpf_find_vma(foreign_task): mm = task->mm exit_mm(): task->mm = NULL mmput(mm) -> frees mm_struct mmap_

  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: bus: mhi: ep: Fix device refcount leak in the error path of MHI device creation mhi_ep_creCVE-2026-93136 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67

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

  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: Reject programs with inlined helpers if JIT is not available When an architecture (suCVE-2026-93135 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67

  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.

  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: printk: Fix possible console use-after-free When emitting a record via legacy printing, itCVE-2026-93134 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67

  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.

  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: ACPI: RISC-V: Check acpi_get_handle() status in riscv_acpi_add_prt_dep() In riscv_acpi_addCVE-2026-93133 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67

  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.

  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.