Complete feed
Recently updated
Advisories the vendor has revised
Android app · Google Play
Take your CVE monitoring with you.
Choose a whole vendor or a precise platform, then receive matching security advisories by phone notification, email, or both. Coverage follows 32 official vendor sources and 160+ reviewed platform categories.
Medium [CVE-2026-52977] Prevent lockup in requeue-PI during signal/ timeout wakeup
In the Linux kernel, the following vulnerability has been resolved: futex: Prevent lockup in requeue-PI during signal/ timeout wakeup During wait-requeue-pi (task A) and requeue-PI (task B) the following race can happen: Task A Task B futex_wait_requeue_pi() futex_setup_timer() futex_do_wait() futex_requeue() CLASS(hb, hb1)(&key1); CLASS(hb, hb2)(&key2); *timeout* futex_requeue_pi_wakeup_sync() requeue_state = Q_REQUEUE_PI_IGNORE *blocks on hb->lock* futex_proxy_trylock_atomic() futex_requeue_pi_prepare() Q_REQUEUE_PI_IGNORE => -EAGAIN double_unlock_hb(hb1, hb2) *retry* Task B acquires both hb locks and attempts to acquire the PI-lock of the top most waiter (task B). Task A is leaving early due to a signal/ timeout and started removing itself from the queue. It updates its requeue_state but can not remove it from the list because this requires the hb lock which is owned by task B. Usually task A is able to swoop the lock after task B unlocked it. However if task B is of higher priority then task A may not be able to wake up in time and acquire the lock before task B gets it again. Especially on a UP system where A is never scheduled. As a result task A blocks on the lock and task B busy loops, trying to make progress but live locks the system instead. Tragic. This can be fixed by removing the top most waiter from the list in this case.
Medium [CVE-2026-53088] fix off-by-one in bcmgenet_put_txcb
In the Linux kernel, the following vulnerability has been resolved: net: bcmgenet: fix off-by-one in bcmgenet_put_txcb The write_ptr points to the next open tx_cb. We want to return the tx_cb that gets rewinded, so we must rewind the pointer first then return the tx_cb that it points to. That way the txcb can be correctly cleaned up. A flaw was found in the Linux kernel's bcmgenet network driver. An off-by-one error in the `bcmgenet_put_txcb` function, related to the `write_ptr` handling for transmit control blocks (tx_cb), could lead to incorrect cleanup of these blocks. This issue may result in system instability or unexpected behavior. Red Hat severity: Low — CVSS 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H). Weakness: CWE-193. Affected Red Hat products: Red Hat Enterprise Linux 10; Red Hat Enterprise Linux 9. Red Hat does not currently list a fixing RHSA for this CVE. Affected products named by the advisory: Red Hat package: kernel-rt.
Medium [CVE-2026-53103] fix potential deadlock in mt7925_roc_abort_sync
In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7925: fix potential deadlock in mt7925_roc_abort_sync roc_abort_sync() can deadlock with roc_work(). roc_work() holds dev->mt76.mutex, while cancel_work_sync() waits for roc_work() to finish. If the caller already owns the same mutex, both sides block and no progress is possible. This deadlock can occur during station removal when mt76_sta_state() -> mt76_sta_remove() -> mt7925_mac_sta_remove_link() -> mt7925_mac_link_sta_remove() -> mt7925_roc_abort_sync() invokes cancel_work_sync() while roc_work() is still running and holding dev->mt76.mutex. This avoids the mutex deadlock and preserves exactly-once work ownership. A flaw was found in the Linux kernel's Wi-Fi subsystem, specifically within the `mt7925_roc_abort_sync` function. This vulnerability can lead to a deadlock condition when `roc_abort_sync()` attempts to cancel a work item (`roc_work()`) while `roc_work()` is already holding a mutex. This situation can occur during Wi-Fi station removal, causing the system to become unresponsive, resulting in a Denial of Service (DoS). Red Hat severity: Moderate — CVSS 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H). Weakness: CWE-833. Affected Red Hat products: Red Hat Enterprise Linux 10; Red Hat Enterprise Linux 9. Red Hat does not currently list a fixing RHSA for this CVE.
Medium [CVE-2026-53127] fix zones_cond memory leak on zone revalidation error paths
In the Linux kernel, the following vulnerability has been resolved: block: fix zones_cond memory leak on zone revalidation error paths When blk_revalidate_disk_zones() fails after disk_revalidate_zone_resources() has allocated args.zones_cond, the memory is leaked because no error path frees it. This can lead to resource exhaustion, potentially resulting in a Denial of Service (DoS) for the system. Red Hat severity: Low — CVSS 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H). Weakness: CWE-772. Affected Red Hat products: Red Hat Enterprise Linux 10. Red Hat does not currently list a fixing RHSA for this CVE. Affected products named by the advisory: Red Hat package: kernel.
Medium [CVE-2026-53035] bpf, sockmap: Fix af_unix iter deadlock
In the Linux kernel, the following vulnerability has been resolved: bpf, sockmap: Fix af_unix iter deadlock bpf_iter_unix_seq_show() may deadlock when lock_sock_fast() takes the fast path and the iter prog attempts to update a sockmap. Affected products named by the advisory: Red Hat Enterprise Linux 10; Red Hat Enterprise Linux 6; Red Hat Enterprise Linux 9; Red Hat package: kernel-rt.
Medium [CVE-2026-52949] Fix ttm_bo_shrink infinite LRU walk on backup failure
In the Linux kernel, the following vulnerability has been resolved: drm/ttm: Fix ttm_bo_shrink() infinite LRU walk on backup failure Apply the same fix as b2ed01e7ad ("drm/ttm: Fix ttm_bo_swapout() infinite LRU walk on swapout failure") to the ttm_bo_shrink() path. Move del_bulk_move from before the backup to after success only, using ttm_resource_del_bulk_move_unevictable() since the resource is now unevictable once fully backed up. A flaw was found in the Linux kernel's Direct Rendering Manager (DRM) subsystem. Specifically, within the `ttm_bo_shrink()` function, a backup failure could lead to an infinite Least Recently Used (LRU) walk. This issue may allow a local attacker to trigger a Denial of Service (DoS), making the system unresponsive. Red Hat severity: Low — CVSS 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H). Weakness: CWE-835. Affected Red Hat products: Red Hat Enterprise Linux 10; Red Hat Enterprise Linux 9. Red Hat does not currently list a fixing RHSA for this CVE. Affected products named by the advisory: Red Hat package: kernel-rt.
Medium [CVE-2026-53092] Fix linked reg delta tracking when src_reg == dst_reg
In the Linux kernel, the following vulnerability has been resolved: bpf: Fix linked reg delta tracking when src_reg == dst_reg Consider the case of rX += rX where src_reg and dst_reg are pointers to the same bpf_reg_state in adjust_reg_min_max_vals(). The latter first modifies the dst_reg in-place, and later in the delta tracking, the subsequent is_reg_const(src_reg)/reg_const_value(src_reg) reads the post-{add,sub} value instead of the original source. This is problematic since it sets an incorrect delta, which sync_linked_regs() then propagates to linked registers, thus creating a verifier-vs-runtime mismatch. Fix it by just skipping this corner case. A flaw was found in the Linux kernel's Berkeley Packet Filter (BPF) subsystem. This vulnerability occurs due to incorrect delta tracking when source and destination registers are the same during register value adjustments. This can lead to a mismatch between the BPF verifier's analysis and the actual runtime behavior of BPF programs, potentially allowing a malicious BPF program to bypass security checks. This CVE has been rated as Moderate because eBPF (and XDP) is restricted to root-only on Red Hat Enterprise Linux. Red Hat severity: Moderate — CVSS 6.4 (CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:U/C:H/I:H/A:H). Weakness: CWE-393. Affected Red Hat products: Red Hat Enterprise Linux 10; Red Hat Enterprise Linux 9.
Medium [CVE-2026-53096] Use RCU-safe iteration in dev_map_redirect_multi SKB path
In the Linux kernel, the following vulnerability has been resolved: bpf: Use RCU-safe iteration in dev_map_redirect_multi() SKB path The DEVMAP_HASH branch in dev_map_redirect_multi() uses hlist_for_each_entry_safe() to iterate hash buckets, but this function runs under RCU protection (called from xdp_do_generic_redirect_map() in softirq context). Concurrent writers (__dev_map_hash_update_elem, dev_map_hash_delete_elem) modify the list using RCU primitives (hlist_add_head_rcu, hlist_del_rcu). hlist_for_each_entry_safe() performs plain pointer dereferences without rcu_dereference(), missing the acquire barrier needed to pair with writers' rcu_assign_pointer(). On weakly-ordered architectures (ARM64, POWER), a reader can observe a partially-constructed node. It also defeats CONFIG_PROVE_RCU lockdep validation and KCSAN data-race detection. Replace with hlist_for_each_entry_rcu() using rcu_read_lock_bh_held() as the lockdep condition, consistent with the rcu_dereference_check() used in the DEVMAP (non-hash) branch of the same functions. Also fix the same incorrect lockdep_is_held(&dtab->index_lock) condition in dev_map_enqueue_multi(), where the lock is not held either. A flaw was found in the Linux kernel's BPF (Berkeley Packet Filter) component, specifically within the `dev_map_redirect_multi()` function.
Medium [CVE-2026-53028] Fix error pointer dereference
In the Linux kernel, the following vulnerability has been resolved: usb: typec: Fix error pointer dereference The variable tps->partner is checked for an error pointer and then if it is, it sends an error message but does not return and then immediately dereferenced a few lines below: tps->partner = typec_register_partner(tps->port, &desc); if (IS_ERR(tps->partner)) dev_warn(tps->dev, "%s: failed to register partnet\n", __func__); if (desc.identity) { typec_partner_set_identity(tps->partner); cd321x->cur_partner_identity = st.partner_identity; } Add early return and fix spelling mistake in error message. Detected by Smatch: drivers/usb/typec/tipd/core.c:827 cd321x_update_work() error: 'tps->partner' dereferencing possible ERR_PTR() A flaw was found in the Linux kernel's USB Type-C subsystem. This unhandled error can cause a system crash, resulting in a Denial of Service (DoS) for the affected system. Red Hat severity: Low — CVSS 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H). Weakness: CWE-390. Affected Red Hat products: Red Hat Enterprise Linux 10; Red Hat Enterprise Linux 9. Red Hat does not currently list a fixing RHSA for this CVE. Affected products named by the advisory: Red Hat package: kernel-rt.
Medium [CVE-2026-53063] dm cache: fix write hang in passthrough mode
In the Linux kernel, the following vulnerability has been resolved: dm cache: fix write hang in passthrough mode The invalidate_remove() function has incomplete logic for handling write hit bios after cache invalidation. It sets up the remapping for the overwrite_bio but then drops it immediately without submission, causing write operations to hang. Fix by adding a new invalidate_committed() continuation that submits the remapped writes to the cache origin after metadata commit completes, while using the overwrite_endio hook to ensure proper completion sequencing. This maintains existing coherency. Also improve error handling in invalidate_complete() to preserve the original error status instead of using bio_io_error() unconditionally. A flaw was found in the Linux kernel's device-mapper (dm) cache component. This occurs because the function sets up remapping for write operations but fails to submit them, causing write operations to indefinitely wait for completion. This vulnerability could allow a local attacker to cause a Denial of Service (DoS) by triggering a write hang. Red Hat severity: Low — CVSS 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H). Weakness: CWE-826. Affected Red Hat products: Red Hat Enterprise Linux 10; Red Hat Enterprise Linux 6; Red Hat Enterprise Linux 7; Red Hat Enterprise Linux 8; Red Hat Enterprise Linux 9.
Medium [CVE-2026-53124] reset per-IO canceled flag on each fetch
In the Linux kernel, the following vulnerability has been resolved: ublk: reset per-IO canceled flag on each fetch If a ublk server starts recovering devices but dies before issuing fetch commands for all IOs, cancellation of the fetch commands that were successfully issued may never complete. This is because the per-IO canceled flag can remain set even after the fetch for that IO has been submitted - the per-IO canceled flags for all IOs in a queue are reset together only once all IOs for that queue have been fetched. So if a nonempty proper subset of the IOs for a queue are fetched when the ublk server dies, the IOs in that subset will never successfully be canceled, as their canceled flags remain set, and this prevents ublk_cancel_cmd from actually calling io_uring_cmd_done on the commands, despite the fact that they are outstanding. Fix this by resetting the per-IO cancel flags immediately when each IO is fetched instead of waiting for all IOs for the queue (which may never happen). When a ublk server fails to complete all I/O (input/output) operations, a per-I/O cancellation flag may remain set. This prevents the successful cancellation of outstanding I/O commands, potentially leading to resource exhaustion or a denial of service (DoS) condition where system resources are tied up indefinitely.
Medium [CVE-2026-53052] check widget type before accessing data
In the Linux kernel, the following vulnerability has been resolved: ASoC: qcom: qdsp6: topology: check widget type before accessing data Check widget type before accessing the private data, as this could a virtual widget which is no associated with a dsp graph, container and module. Accessing witout check could lead to incorrect memory access. The Advanced Linux Sound Architecture on Chip (ASoC) subsystem, specifically within the Qualcomm qdsp6 topology component, fails to verify the type of a virtual widget before accessing its private data. This oversight could allow an attacker to cause incorrect memory access, potentially leading to a denial of service (DoS) condition. Red Hat severity: Moderate — CVSS 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H). Weakness: CWE-843. Red Hat lists Red Hat Enterprise Linux 10; Red Hat Enterprise Linux 6; Red Hat Enterprise Linux 7; Red Hat Enterprise Linux 8; Red Hat Enterprise Linux 9 as not affected.
Medium [CVE-2026-52961] fix BUG_ON in __ceph_build_xattrs_blob due to stale blob size
In the Linux kernel, the following vulnerability has been resolved: ceph: fix BUG_ON in __ceph_build_xattrs_blob() due to stale blob size The generic/642 test-case can reproduce the kernel crash: [40243.605254] ------------[ cut here ]------------ [40243.605956] kernel BUG at fs/ceph/xattr.c:918! [40243.607142] Oops: invalid opcode: 0000 [#1] SMP PTI [40243.608067] CPU: 7 UID: 0 PID: 498762 Comm: kworker/7:1 Not tainted 7.0.0-rc7+ #3 PREEMPT(full) [40243.609700] Hardware name: QEMU Ubuntu 25.10 PC v2 (i440FX + PIIX, + 10.1 machine, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [40243.611820] Workqueue: ceph-msgr ceph_con_workfn [40243.612715] RIP: 0010:__ceph_build_xattrs_blob+0x1b8/0x1e0 [40243.613731] Code: 0f 84 82 fe ff ff e9 cf 8e 56 ff 48 8d 65 e8 31 c0 5b 41 5c 41 5d 5d 31 d2 31 c9 31 f6 31 ff 45 31 c0 45 31 c9 c3 cc cc cc cc 0b 4c 8b 62 08 41 8b 85 24 07 00 00 49 83 c4 04 41 89 44 24 fc [40243.616888] RSP: 0018:ffffcc80c4d4b688 EFLAGS: 00010287 [40243.617773] RAX: 0000000000010026 RBX: 0000000000000001 RCX: 0000000000000000 [40243.618928] RDX: ffff8a773798dee0 RSI: 0000000000000000 RDI: 0000000000000000 [40243.620158] RBP: ffffcc80c4d4b6a0 R08: 0000000000000000 R09: 0000000000000000 [40243.621573] R10: 0000000000000000 R11: 0000000000000000 R12: ffff8a75f3b58000 [40243.622907] R13: ffff8a75f3b58000 R14: 0000000000000080 R15: 000000000000bffd [40243.624054] FS…
Medium [CVE-2026-53093] Fix error pointer dereference
In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: Fix error pointer dereference The function brcmf_chip_add_core() can return an error pointer and is not checked. Add checks for error pointer. Detected by Smatch: drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c:1010 brcmf_chip_recognition() error: 'core' dereferencing possible ERR_PTR() drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c:1013 brcmf_chip_recognition() error: 'core' dereferencing possible ERR_PTR() drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c:1016 brcmf_chip_recognition() error: 'core' dereferencing possible ERR_PTR() drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c:1019 brcmf_chip_recognition() error: 'core' dereferencing possible ERR_PTR() drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c:1022 brcmf_chip_recognition() error: 'core' dereferencing possible ERR_PTR() [add missing wifi: prefix] A flaw was found in the Linux kernel's Broadcom FullMAC wireless driver (brcmfmac). This vulnerability could allow a local attacker to cause a system crash, resulting in a Denial of Service (DoS). Red Hat severity: Low — CVSS 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H). Weakness: CWE-476. Affected Red Hat products: Red Hat Enterprise Linux 10; Red Hat Enterprise Linux 8; Red Hat Enterprise Linux 9.
Medium [CVE-2026-53129] cancel shrink work before destroying the cache
In the Linux kernel, the following vulnerability has been resolved: fs/mbcache: cancel shrink work before destroying the cache mb_cache_destroy() calls shrinker_free() and then frees all cache entries and the cache itself, but it does not cancel the pending c_shrink_work work item first. If mb_cache_entry_create() schedules c_shrink_work via schedule_work() and the work item is still pending or running when mb_cache_destroy() runs, mb_cache_shrink_worker() will access the cache after its memory has been freed, causing a use-after-free. This is only reachable by a privileged user (root or CAP_SYS_ADMIN) who can trigger the last put of a mounted ext2/ext4/ocfs2 filesystem. Cancel the work item with cancel_work_sync() before calling shrinker_free(), ensuring the worker has finished and will not be rescheduled before the cache is torn down. Red Hat severity: Moderate — CVSS 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H). Affected Red Hat products: Red Hat Enterprise Linux 10; Red Hat Enterprise Linux 6; Red Hat Enterprise Linux 8; Red Hat Enterprise Linux 9. Will not fix / out of support: Red Hat Enterprise Linux 6. Red Hat does not currently list a fixing RHSA for this CVE. Affected products named by the advisory: Red Hat package: kernel-rt.
Medium [CVE-2026-53086] fix racing timeout handler
In the Linux kernel, the following vulnerability has been resolved: net: bcmgenet: fix racing timeout handler The bcmgenet_timeout handler tries to take down all tx queues when a single queue times out. This is over zealous and causes many race conditions with queues that are still chugging along. Instead lets only restart the timed out queue. A flaw was found in the Linux kernel's `bcmgenet` network driver. This vulnerability arises from an overly aggressive timeout handler that attempts to reset all network transmission queues when only one experiences an issue. This behavior can create race conditions, potentially leading to system instability or a denial of service, where network services become unavailable. Red Hat severity: Moderate — CVSS 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H). Weakness: CWE-366. Affected Red Hat products: Red Hat Enterprise Linux 10; Red Hat Enterprise Linux 9. Red Hat does not currently list a fixing RHSA for this CVE. Affected products named by the advisory: Red Hat package: kernel-rt.
Medium [CVE-2026-53104] Fix memory leak destroying device
In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: Fix memory leak destroying device All MT76 rx queues have an associated page_pool even if the queue is not associated to a NAPI (e.g. WED RRO queues with WED enabled). Destroy the page_pool running mt76_dma_cleanup routine during module unload. This vulnerability, a memory leak, occurs when the device is destroyed during module unload. Specifically, the `mt76_dma_cleanup` routine fails to properly destroy the `page_pool` associated with all MT76 receive queues, leading to unreleased memory. Over time, this can lead to system instability or a denial of service (DoS) due to resource exhaustion. Red Hat severity: Low — CVSS 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H). Weakness: CWE-772. Affected Red Hat products: Red Hat Enterprise Linux 10; Red Hat Enterprise Linux 9. Red Hat does not currently list a fixing RHSA for this CVE. Affected products named by the advisory: Red Hat package: kernel-rt.
Medium [CVE-2026-53069] net, bpf: fix null-ptr-deref in xdp_master_redirect for down master
In the Linux kernel, the following vulnerability has been resolved: net, bpf: fix null-ptr-deref in xdp_master_redirect() for down master syzkaller reported a kernel panic in bond_rr_gen_slave_id() reached via xdp_master_redirect(). Full decoded trace: bond_rr_gen_slave_id() dereferences bond->rr_tx_counter, a per-CPU counter that bonding only allocates in bond_open() when the mode is round-robin. If the bond device was never brought up, rr_tx_counter stays NULL. The XDP redirect path can still reach that code on a bond that was never opened: bpf_master_redirect_enabled_key is a global static key, so as soon as any bond device has native XDP attached, the XDP_TX -> xdp_master_redirect() interception is enabled for every slave system-wide. The path xdp_master_redirect() -> bond_xdp_get_xmit_slave() -> bond_xdp_xmit_roundrobin_slave_get() -> bond_rr_gen_slave_id() then runs against a bond that has no rr_tx_counter and crashes. Fix this in the generic xdp_master_redirect() by refusing to call into the master's ->ndo_xdp_get_xmit_slave() when the master device is not up. IFF_UP is only set after ->ndo_open() has successfully returned, so this reliably excludes masters whose XDP state has not been fully initialized. Drop the frame with XDP_ABORTED so the exception is visible via trace_xdp_exception() rather than silently falling through.
Medium [CVE-2026-53038] Correctly create securityfs files for unsupported hash algos
In the Linux kernel, the following vulnerability has been resolved: ima_fs: Correctly create securityfs files for unsupported hash algos ima_tpm_chip->allocated_banks[i].crypto_id is initialized to HASH_ALGO__LAST if the TPM algorithm is not supported. However there are places relying on the algorithm to be valid because it is accessed by hash_algo_name[]. Affected products named by the advisory: Red Hat Enterprise Linux 10; Red Hat package: kernel.
Medium [CVE-2026-52997] drain both C-queue and L-queue in dualpi2_change
In the Linux kernel, the following vulnerability has been resolved: net/sched: sch_dualpi2: drain both C-queue and L-queue in dualpi2_change() Fix dualpi2_change() to correctly enforce updated limit and memlimit values after a configuration change of the dualpi2 qdisc. Before this patch, dualpi2_change() always attempted to dequeue packets via the root qdisc (C-queue) when reducing backlog or memory usage, and unconditionally assumed that a valid skb will be returned. When traffic classification results in packets being queued in the L-queue while the C-queue is empty, this leads to a NULL skb dereference during limit or memlimit enforcement. This is fixed by first dequeuing from the C-queue path if it is non-empty. Once the C-queue is empty, packets are dequeued directly from the L-queue. Return values from qdisc_dequeue_internal() are checked for both queues. When dequeuing from the L-queue, the parent qdisc qlen and backlog counters are updated explicitly to keep overall qdisc statistics consistent. A flaw was found in the Linux kernel's `sch_dualpi2` qdisc (queueing discipline) component. This can lead to a NULL skb (socket buffer) dereference, potentially causing a system crash or a Denial of Service (DoS). Red Hat severity: Moderate. Weakness: CWE-476.