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-53280] Fix NULL group->domain dereference in pci_dev_reset_iommu_done
In the Linux kernel, the following vulnerability has been resolved: iommu: Fix NULL group->domain dereference in pci_dev_reset_iommu_done() Local sashiko review pointed it out that group->domain could be NULL when a default domain fails to allocate during the first probe, which can crash at domain->ops->attach_dev dereference in __iommu_attach_device() invoked by pci_dev_reset_iommu_done(). pci_dev_reset_iommu_prepare() is fine as an old_domain pointer can be NULL. Skip the re-attach in pci_dev_reset_iommu_done() to fix the bug. A flaw was found in the Linux kernel's Input-Output Memory Management Unit (IOMMU) component. This can 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 does not currently list a fixing RHSA for this CVE. Affected products named by the advisory: Red Hat package: kernel.
Medium [CVE-2026-53279] fix hang on init failure
In the Linux kernel, the following vulnerability has been resolved: drm/gma500/oaktrail_lvds: fix hang on init failure The LVDS init code looks up an I2C adapter using i2c_get_adapter() and tries to read the EDID before falling back to allocating and registering its own adapter. The error handling does not separate these cases so on a late init failure it will try to deregister and free also an adapter that had previously been registered. Since i2c_get_adapter() takes another reference to the adapter, deregistration hangs indefinitely while waiting for the reference to be released. Fix this by only destroying adapters allocated during LVDS init on errors. This issue occurs during the initialization of the Low-Voltage Differential Signaling (LVDS) display interface. Due to improper error handling, the system may attempt to deregister an I2C adapter that is still in use, causing the system to hang indefinitely. This can lead to 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-833. Affected Red Hat products: Red Hat Enterprise Linux 10; Red Hat Enterprise Linux 8. Red Hat does not currently list a fixing RHSA for this CVE. Affected products named by the advisory: Red Hat package: kernel-rt.
Low [CVE-2026-48935] Unauthorized file metadata modification
A flaw in Node.js Permission API can cause a file metadata to be modified even on a path that was set as read-only with e.g. This vulnerability affects all supported release lines: **Node.js 22**, **Node.js 24**, and **Node.js 26**. The Permission API allows a local user to modify file metadata on paths that have been explicitly set as read-only. This can lead to unauthorized changes in file properties, impacting the integrity of the file system. Red Hat severity: Low — CVSS 3.3 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N). Weakness: CWE-279. Affected Red Hat products: Red Hat Enterprise Linux 10; Red Hat Enterprise Linux 8; Red Hat Enterprise Linux 9; Red Hat Hardened Images. Red Hat fixing advisory: RHSA-2026:35841, RHSA-2026:35842, RHSA-2026:39868, RHSA-2026:41947, RHSA-2026:35891, RHSA-2026:35892, RHSA-2026:33866, RHSA-2026:34478, RHSA-2026:35272, RHSA-2026:7378, RHSA-2026:9455. Affected products named by the advisory: Red Hat package: nodejs24; Red Hat package: nodejs22.
Low [CVE-2026-48936] Local server can be started without network permission via Permission API flaw
A flaw in Node.js Permission API can cause a local server to be started (via a Unix domain socket), even without the `--allow-net` permission. This vulnerability affects one supported release line: **Node.js 26**. A flaw was found in Node.js. This bypasses intended security restrictions, potentially leading to unintended local network exposure or integrity impact. Red Hat severity: Low — CVSS 3.3 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N). Weakness: CWE-648. Affected Red Hat products: Red Hat Hardened Images; Red Hat Enterprise Linux 10; Red Hat Enterprise Linux 8; Red Hat Enterprise Linux 9. Red Hat fixing advisory: RHSA-2026:33866, RHSA-2026:34478, RHSA-2026:35272, RHSA-2026:7378, RHSA-2026:9455. Affected products named by the advisory: Red Hat package: nodejs22; Red Hat package: nodejs24.
Advisory [CVE-2026-53299] Move ndesc initialization at end of airoha_qdma_init_tx
In the Linux kernel, the following vulnerability has been resolved: net: airoha: Move ndesc initialization at end of airoha_qdma_init_tx() If queue entry list allocation fails in airoha_qdma_init_tx_queue routine, airoha_qdma_cleanup_tx_queue() will trigger a NULL pointer dereference accessing the queue entry array. A flaw was found in the Linux kernel, specifically within the airoha network driver. This vulnerability arises from an issue where a variable (ndesc) is initialized too early in the airoha_qdma_init_tx_queue routine. This results in a Denial of Service (DoS), making the system unavailable. Red Hat severity: not rated. Weakness: CWE-824. 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.
Advisory [CVE-2026-53301] Fix null reset ops
In the Linux kernel, the following vulnerability has been resolved: reset: amlogic: t7: Fix null reset ops Fix missing reset ops causing kernel null pointer dereference. This SOC's reset is currently not used yet. Missing reset operations can lead to a null pointer dereference, which may cause system instability or a denial of service (DoS). This vulnerability occurs when the system attempts to use uninitialized reset operations, resulting in an unexpected system state. Red Hat severity: not rated. Weakness: CWE-824. 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.
Advisory [CVE-2026-53288] Reserve an extra page for early kernel mapping
In the Linux kernel, the following vulnerability has been resolved: arm64: Reserve an extra page for early kernel mapping The final part of [data, end) segment may overflow into the next page of init_pg_end[1] which is the gap page before early_init_stack[2]: [1] crash_arm64_v9.0.1> vtop ffffffed00601000 VIRTUAL PHYSICAL ffffffed00601000 83401000 PAGE DIRECTORY: ffffffecffd62000 PGD: ffffffecffd62da0 => 10000000833fb003 PMD: ffffff80033fb018 => 10000000833fe003 PTE: ffffff80033fe008 => 68000083401f03 PAGE: 83401000 PTE PHYSICAL FLAGS 68000083401f03 83401000 (VALID|SHARED|AF|NG|PXN|UXN) PAGE PHYSICAL MAPPING INDEX CNT FLAGS fffffffec00d0040 83401000 0 0 1 4000 reserved [2] ffffffed002c8000 (r) __pi__data ffffffed0054e000 (d) __pi___bss_start ffffffed005f5000 (b) __pi_init_pg_dir ffffffed005fe000 (b) __pi_init_pg_end ffffffed005ff000 (B) early_init_stack ffffffed00608000 (b) __pi__end For 4K pages, the early kernel mapping may use 2MB block entries but the kernel segments are only 64KB aligned. Segment boundaries that fall within a 2MB block therefore require a PTE table so that different attributes can be applied on either side of the boundary. KERNEL_SEGMENT_COUNT still correctly counts the five permanent kernel VMAs registered by declare_kernel_vmas().
Advisory [CVE-2026-53312] Remove overflows on the invalidation path
In the Linux kernel, the following vulnerability has been resolved: iommu/riscv: Remove overflows on the invalidation path Since RISC-V supports a sign extended page table it should support a gather->end of ULONG_MAX, but if this happens it will infinite loop because of the overflow. Also avoid overflow computing the length by moving the +1 to the other side of the < A flaw was found in the Linux kernel's IOMMU (Input/Output Memory Management Unit) component for RISC-V architectures. This vulnerability could allow a local attacker to cause a Denial of Service (DoS) by triggering the overflow condition. Red Hat severity: not rated. Weakness: CWE-190. 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.
Advisory [CVE-2026-53298] Move ndesc initialization at end of airoha_qdma_init_rx_queue
In the Linux kernel, the following vulnerability has been resolved: net: airoha: Move ndesc initialization at end of airoha_qdma_init_rx_queue() If queue entry or DMA descriptor list allocation fails in airoha_qdma_init_rx_queue routine, airoha_qdma_cleanup() will trigger a NULL pointer dereference running netif_napi_del() for RX queue NAPIs since netif_napi_add() has never been executed to this particular RX NAPI. The issue is due to the early ndesc initialization in airoha_qdma_init_rx_queue() since airoha_qdma_cleanup() relies on ndesc value to check if the queue is properly initialized. Move page_pool allocation after descriptor list allocation in order to avoid memory leaks if desc allocation fails. A flaw was found in the Linux kernel's airoha network driver. An issue with early initialization of the ndesc variable in the airoha_qdma_init_rx_queue() routine can lead to a NULL pointer dereference during cleanup. This can result in a Denial of Service (DoS) condition. Additionally, improper ordering of page pool allocation could lead to memory leaks. Red Hat severity: not rated. Weakness: CWE-476. 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.
Advisory [CVE-2026-53302] eip93 - fix hmac setkey algo selection
In the Linux kernel, the following vulnerability has been resolved: crypto: eip93 - fix hmac setkey algo selection eip93_hmac_setkey() allocates a temporary ahash transform for computing HMAC ipad/opad key material. The allocation uses the driver-specific cra_driver_name (e.g. "sha256-eip93") but passes CRYPTO_ALG_ASYNC as the mask, which excludes async algorithms. Since the EIP93 hash algorithms are the only ones registered under those driver names and they are inherently async, the lookup is self-contradictory and always fails with -ENOENT. When called from the AEAD setkey path, this failure leaves the SA record partially initialized with zeroed digest fields.
Advisory [CVE-2026-53308] Free allocated workqueue and fix removal order
In the Linux kernel, the following vulnerability has been resolved: power: supply: max77705: Free allocated workqueue and fix removal order Use devm interface for allocating workqueue to fix two bugs at the same time: 1. Driver leaks the memory on remove(), because the workqueue is not destroyed. 2. Driver allocates workqueue and then registers interrupt handlers with devm interface. The interrupt handler schedules work on this exact workqueue, thus if interrupt is hit in this short time window - after destroying workqueue, but before devm() frees the interrupt - the schedulled work will lead to use of freed memory. Change is not equivalent in the workqueue itself: use non-legacy API which does not set (__WQ_LEGACY | WQ_MEM_RECLAIM). The workqueue is used to update power supply (power_supply_changed()) status, thus there is no point to run it for memory reclaim. Note that dev_name() is not directly used in second argument to prevent possible unlikely parsing any "%" character in device name as format. Incorrect management of workqueues and interrupt handlers during device removal can lead to a use-after-free vulnerability. This allows for the potential use of freed memory, which could result in system instability or, in certain scenarios, arbitrary code execution. Red Hat severity: not rated. Weakness: CWE-364.
Advisory [CVE-2026-53300] fix NTMP DMA use-after-free issue
In the Linux kernel, the following vulnerability has been resolved: net: enetc: fix NTMP DMA use-after-free issue The AI-generated review reported a potential DMA use-after-free issue [1]. If netc_xmit_ntmp_cmd() times out and returns an error, the pending command is not explicitly aborted, while ntmp_free_data_mem() unconditionally frees the DMA buffer. If the buffer has already been reallocated elsewhere, this may lead to silent memory corruption. Because the hardware eventually processes the pending command and perform a DMA write of the response to the physical address of the freed buffer. To resolve this issue, this patch does the following modifications: 1. Convert cbdr->ring_lock from a spinlock to a mutex The lock was originally a spinlock in case NTMP operations might be invoked from atomic context. After downstream support for all NTMP tables, no such usage has materialized. A mutex lock is now required because the driver now needs to reclaim used BDs and release associated DMA memory within the lock's context, while dma_free_coherent() might sleep. 2. Introduce software command BD (struct netc_swcbd) The hardware write-back overwrites the addr and len fields of the BD, so the driver cannot rely on the hardware BD to free the associated DMA memory. The driver now maintains a software shadow BD storing the DMA buffer pointer, DMA address, and size.
Advisory [CVE-2026-53320] reject zero bd_oblocknr in nilfs_ioctl_mark_blocks_dirty
In the Linux kernel, the following vulnerability has been resolved: nilfs2: reject zero bd_oblocknr in nilfs_ioctl_mark_blocks_dirty() nilfs_ioctl_mark_blocks_dirty() uses bd_oblocknr to detect dead blocks by comparing it with the current block number bd_blocknr. If they differ, the block is considered dead and skipped. However, bd_oblocknr should never be 0 since block 0 typically stores the primary superblock and is never a valid GC target block. A corrupted ioctl request with bd_oblocknr set to 0 causes the comparison to incorrectly match when the lookup returns -ENOENT and sets bd_blocknr to 0, bypassing the dead block check and calling nilfs_bmap_mark() on a non-existent block. This causes nilfs_btree_do_lookup() to return -ENOENT, triggering the WARN_ON(ret == -ENOENT). Fix this by rejecting ioctl requests with bd_oblocknr set to 0 at the beginning of each iteration. [ryusuke: slightly modified the commit message and comments for accuracy] A local attacker could exploit this vulnerability by sending a specially crafted input/output control (ioctl) request to the `nilfs_ioctl_mark_blocks_dirty()` function. By providing a zero block number, the attacker can bypass a critical dead block check, causing the system to attempt operations on a non-existent block. This ultimately leads to a system crash, resulting in a Denial of Service (DoS). Red Hat severity: not rated.
Advisory [CVE-2026-53307] Fully validate 'pinmux' property
In the Linux kernel, the following vulnerability has been resolved: pinctrl: pinconf-generic: Fully validate 'pinmux' property The pinconf_generic_parse_dt_pinmux() assumes that the 'pinmux' property is not empty when present. This might be not true. With that, the allocator will give a special value in return and not NULL which lead to the crash when trying to access that (invalid) memory. Fix that by fully validating 'pinmux' value, including its length. An attacker could provide an empty 'pinmux' property, which would cause the system to crash due to invalid memory access. This could lead to a denial of service. Red Hat severity: not rated. Weakness: CWE-824. 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.
Advisory [CVE-2026-53303] protect extension_list reading with sb_lock in f2fs_sbi_show
In the Linux kernel, the following vulnerability has been resolved: f2fs: protect extension_list reading with sb_lock in f2fs_sbi_show() In f2fs_sbi_show(), the extension_list, extension_count and hot_ext_count are read without holding sbi->sb_lock. If a concurrent sysfs store modifies the extension list via f2fs_update_extension_list(), the show path may read inconsistent count and array contents, potentially leading to out-of-bounds access or displaying stale data. Fix this by holding sb_lock around the entire extension list read and format operation. It occurs because the `extension_list` and related counts are read without proper synchronization, enabling a concurrent system file system (sysfs) store operation to modify the list while it is being accessed. This inconsistency can lead to system instability or incorrect information being presented. Red Hat severity: not rated. Weakness: CWE-366. 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.
Advisory [CVE-2026-53319] remove WARN_ON_ONCE from wbt_init_enable_default
In the Linux kernel, the following vulnerability has been resolved: blk-wbt: remove WARN_ON_ONCE from wbt_init_enable_default() wbt_init_enable_default() uses WARN_ON_ONCE to check for failures from wbt_alloc() and wbt_init(). However, both are expected failure paths: - wbt_alloc() can return NULL under memory pressure (-ENOMEM) - wbt_init() can fail with -EBUSY if wbt is already registered syzbot triggers this by injecting memory allocation failures during MTD partition creation via ioctl(BLKPG), causing a spurious warning. wbt_init_enable_default() is a best-effort initialization called from blk_register_queue() with a void return type. Failure simply means the disk operates without writeback throttling, which is harmless. Replace WARN_ON_ONCE with plain if-checks, consistent with how wbt_set_lat() in the same file already handles these failures. Add a pr_warn() for the wbt_init() failure to retain diagnostic information without triggering a full stack trace. A flaw was found in the Linux kernel's block writeback throttling (blk-wbt) component. The `wbt_init_enable_default()` function used a warning mechanism (WARN_ON_ONCE) for expected failure paths during memory allocation or if writeback throttling was already registered. Red Hat severity: not rated. Weakness: CWE-544.
Critical [CVE-2026-13283] Use after free in AdFilter
Use after free in AdFilter in Google Chrome on Android prior to 149.0.7827.201 allowed a remote attacker who convinced a user to engage in specific UI gestures to execute arbitrary code via a crafted HTML page. (Chromium security severity: High) An use after free flaw was found in the AdFilter component of the Chromium browser. Upstream bug(s): Red Hat Product Security rates the severity of this flaw as determined by the Google Chrome Security Advisory. Red Hat severity: Important — CVSS 9.6 (CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H). Weakness: CWE-825.
High [CVE-2026-40941] Package Import Signature Validation Bypass Allows Self-Signed Packages
Cacti is an open source performance and fault management framework. Versions 1.2.30 and prior have a package import signature validation bypass allows which allows self-signed packages. This issue has been fixed in version 1.2.31. By exploiting this flaw, an attacker can import self-signed packages, potentially leading to the execution of unauthorized code or compromise of system integrity. This could lead to the execution of arbitrary code with the privileges of the Cacti application, potentially compromising the integrity and availability of the system. Exploitation requires an attacker to have privileges to import packages. Red Hat severity: Important — CVSS 8.8 (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H). Weakness: CWE-347.
High [CVE-2026-13281] Integer overflow in Mojo
Integer overflow in Mojo in Google Chrome prior to 149.0.7827.201 allowed a remote attacker who had compromised the renderer process to potentially perform a sandbox escape via a malicious file. (Chromium security severity: High) Upstream bug(s): Red Hat Product Security rates the severity of this flaw as determined by the Google Chrome Security Advisory. Red Hat severity: Important — CVSS 8.7 (CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:H/I:H/A:N). Weakness: CWE-190.
High [CVE-2026-48702] Denial of Service due to unbounded gzip decompression in Alpine APK parsing
Rekor is a software supply chain transparency log. Starting in version 0.3.0 and prior to version 1.5.2, the `Package. Unmarshal()` function in `pkg/types/alpine/apk.go` decompresses the signature and control gzip members of an APK file into in-memory buffers without bounding the total decompressed size. The existing `max_apk_metadata_size` check (default 1MB) is only applied to individual tar entry header sizes after decompression completes, so it does not prevent a decompression bomb from consuming unbounded heap memory. An attacker can craft a gzip stream that compresses at a ~1000:1 ratio (e.g., 2MB compressed zeros → 2GB decompressed). When submitted as spec.package.content in an Alpine `ProposedEntry`, the server decompresses the full payload into memory during request processing, triggering a fatal Go runtime out-of-memory error or OS OOM-kill that cannot be caught by the server's recover() middleware. This is reachable via two unauthenticated endpoints, `POST /api/v1/log/entries (createLogEntry)` and `POST /api/v1/log/entries/retrieve (searchLogQuery)`. Both invoke `V001Entry. Canonicalize()` → `fetchExternalEntities()` → `apk. Unmarshal(packageData)`, which performs the unbounded decompression. Version 1.5.2 patches the issue. There is no effective workaround.