Skip to content
VulniPulse

Red Hat Linux Security Advisories & CVEs

12447 advisories tracked · Red Hat Security Data API · direct feeds checked every minute; rate-limited backstops use a safe source cadence

Android app · Google Play

Monitor Red Hat CVEs from your phone.

Choose a whole vendor or a precise platform, then receive matching security advisories by phone notification, email, or both. Coverage follows 34 official vendor sources and 160+ reviewed platform categories.

Security advisories for your Red Hat release

Pick your distribution release to see every advisory issued for it and its severity mix. Fixes ship as errata — keep the system patched. This is the release's advisory history, not a per-package scan.

Official source

Red Hat Security Data API

Red Hat Enterprise Linux errata (RHSA) via the official Red Hat Security Data API — CVE severity, CVSS and affected packages. A credential-free official source.

Latest Red Hat advisories

Medium5.5Red Hat

Medium [CVE-2026-72244] bail out of try_harder when alignment cannot be honoured

In the Linux kernel, the following vulnerability has been resolved: gpu/buddy: bail out of try_harder when alignment cannot be honoured The try_harder contiguous fallback could return a range whose start offset did not match the caller's min_block_size. When a candidate's start is misaligned, realign it: free the misaligned run and reallocate exactly @size at the next lower min_block_size boundary. This keeps the returned size unchanged with no surplus to trim, and rejects the request only when no aligned candidate fits. v2: align misaligned candidates down to min_block_size instead of bailing out, for both the RHS and LHS paths (Matthew). The `try_harder` memory allocation fallback mechanism could return a memory range whose starting offset did not match the required minimum block size. This incorrect memory alignment could lead to improper memory handling within the kernel, potentially causing system instability or unexpected behavior. A moderate severity flaw was found in the Linux kernel's gpu/buddy GPU memory allocator. A local user able to reach the GPU memory allocation path could cause the GPU driver or hardware to operate on misaligned memory, which may lead to allocation failures, GPU faults or resets, and degraded graphics or compute availability.

CVE-2026-72244
Unclassified
Aug 15, 2026
Medium5.5Red Hat

Medium [CVE-2026-72185] fix WARN_ON for resident attribute in ntfs_map_runlist_nolock

In the Linux kernel, the following vulnerability has been resolved: ntfs: fix WARN_ON for resident attribute in ntfs_map_runlist_nolock() When ntfs_map_runlist_nolock() needs to look up the attribute extent containing a target VCN (ctx_needs_reset == true), it calls ntfs_attr_lookup() and then expects the result to be a non-resident attribute, since only non-resident attributes have a mapping pairs array to decompress. A crafted NTFS image can place a resident attribute where a non-resident one is expected, causing ntfs_attr_lookup() to succeed but return a resident attribute record. Previously this was caught only by a WARN_ON(), which does not stop execution. The code then falls through to read a->data.non_resident.highest_vcn from what is actually a resident attribute, accessing the wrong union member and corrupting the VCN range check. The caller path triggering this warning during mount is: ntfs_map_runlist_nolock ntfs_empty_logfile load_system_files ntfs_fill_super In this path ctx is NULL, so ntfs_map_runlist_nolock() allocates a temporary search context internally and sets ctx_needs_reset = true. The existing resident-attribute guard in the ctx!= NULL branch already returns -EIO silently for the same condition; make the ctx_needs_reset path consistent by replacing the WARN_ON() with the same -EIO error return.

CVE-2026-72185
Unclassified
Aug 15, 2026
Medium5.5Vendor: LowRed Hat

Medium [CVE-2026-72376] Fix misplaced inc of net->cells_outstanding

In the Linux kernel, the following vulnerability has been resolved: afs: Fix misplaced inc of net->cells_outstanding Fix net->cells_outstanding being incremented before the check for failure of idr_alloc_cyclic(), leaving the count incremented on error. A flaw was found in the Andrew File System (AFS) component of the Linux kernel. This can lead to the counter being incorrectly incremented even when an error occurs, potentially causing a resource leak and impacting system stability or availability. When an AFS cell is created, the net->cells_outstanding counter is incremented before the result of idr_alloc_cyclic() is checked, so if that allocation fails the counter remains incorrectly incremented, causing a resource leak that can impact system availability. Confidentiality and integrity are not affected. Although AFS is a network filesystem, this flaw is in the local AFS cell setup path: Red Hat rates it with a local attack vector and low privileges required (CVSS 3.1 AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H, score 5.5). Given the low impact and the fact that exploitation requires reaching the AFS cell allocation failure path, the fix for the affected Red Hat Enterprise Linux 9, 10, and Red Hat In-Vehicle OS 2 streams has been deferred; the residual risk is limited to a local, availability-only impact. Weakness: CWE-772.

CVE-2026-72376
Linux Kernel
Aug 15, 2026
Medium5.5Vendor: LowRed Hat

Medium [CVE-2026-72173] do not warn on seeing non-migration pmd entry

In the Linux kernel, the following vulnerability has been resolved: fs/proc/task_mmu: do not warn on seeing non-migration pmd entry Patch series "mm/hmm: A fix and a selftest", v3. Patch 1 fixes a stale warning present from the time when only migration softleaf entries were supported at the PMD level. Patch 2 adds some code into hmm-tests.c which exercises the pagemap path for PMD device-private entries. This became false once device-private entries at the PMD level were added. Therefore, remove the stale migration-only assertion. A flaw was found in the Linux kernel's memory management unit (MMU). The `pagemap_pmd_range_thp()` function incorrectly issued a warning when encountering certain non-present Page Middle Directory (PMD) entries. This issue arose because an assertion related to migration-only softleaf entries became outdated after the introduction of device-private PMD entries. While not directly exploitable for arbitrary code execution or privilege escalation, this flaw could lead to misleading diagnostic information within the kernel. 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-617. Affected Red Hat products: Red Hat Enterprise Linux 6. Will not fix / out of support: Red Hat Enterprise Linux 6. Red Hat does not currently list a fixing RHSA for this CVE.

CVE-2026-72173
Linux Kernel
Aug 15, 2026
Medium5.5Red Hat

Medium [CVE-2026-72169] make sure scratch size is always aligned by CMA_MIN_ALIGNMENT_BYTES

In the Linux kernel, the following vulnerability has been resolved: kho: make sure scratch size is always aligned by CMA_MIN_ALIGNMENT_BYTES When using scratch_scale, the scratch sizes are rounded up to CMA_MIN_ALIGNMENT_BYTES since they will be released as MIGRATE_CMA. This is not done when using fixed scratch sizes via command line. This can result in user specifying a size which is not aligned, and thus kernel releasing a pageblock that is only partially scratch. Do the rounding up for both cases in scratch_size_update(). A flaw was found in the Linux kernel's 'kho' component, responsible for memory management. This can result in the kernel releasing a pageblock that is only partially used for scratch, potentially leading to memory corruption or system instability. A flaw of Moderate security impact was found in the Linux kernel's kexec handover (kho) subsystem. Triggering the flaw requires local access with the ability to set the kernel command-line parameters that define the kho scratch size. The vulnerable kho code is not present in the Red Hat Enterprise Linux and Red Hat In-Vehicle OS kernels shipped in currently maintained streams, so all tracked Red Hat kernel, kernel-rt, kernel-ivos-qualcomm, and related components are marked not affected for this flaw. 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-131.

CVE-2026-72169
Unclassified
Aug 15, 2026
Medium5.5Red Hat

Medium [CVE-2026-72268] fix potential memory leak in tdfxfb_probe

In the Linux kernel, the following vulnerability has been resolved: fbdev: tdfxfb: fix potential memory leak in tdfxfb_probe() In tdfxfb_probe(), the memory allocated for modelist using fb_videomode_to_modelist() when CONFIG_FB_3DFX_I2C is defined, is not freed in the subsequent error paths. Fix that by calling fb_destroy_modelist(). Specifically, the `tdfxfb_probe()` function, when the `CONFIG_FB_3DFX_I2C` option is enabled, does not properly free memory allocated for the modelist in certain error handling paths. This oversight can lead to a memory leak, which a local attacker could potentially exploit to cause a Denial of Service (DoS) by exhausting system memory. A Moderate-impact memory leak flaw was found in the Linux kernel's tdfxfb framebuffer driver. When the kernel is built with the CONFIG_FB_3DFX_I2C option enabled, tdfxfb_probe() allocates memory for the video mode list via fb_videomode_to_modelist(), but this memory is not freed when the function later takes an error path. A local attacker able to trigger repeated probe failures of this driver could use this flaw to exhaust kernel memory and cause a denial of service. Red Hat rated this flaw with a CVSS 3.1 base score of 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H).

CVE-2026-72268
Unclassified
Aug 15, 2026
Medium5.5Red Hat

Medium [CVE-2026-72387] Fix potential invalid pointer deref in group_process_tiler_oom

In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Fix potential invalid pointer deref in group_process_tiler_oom() If heaps is an ERR_PTR(), panthor_heap_pool_put() will deref an invalid pointer. Make sure we set it to NULL in that case. This vulnerability, located in the `group_process_tiler_oom()` function, occurs when error pointers are improperly handled, leading to an invalid memory dereference. A local attacker could potentially exploit this flaw to cause a system crash, resulting in a denial of service. A moderate impact flaw was found in the drm/panthor driver in the Linux kernel. In the group_process_tiler_oom() function, when the heaps variable holds an ERR_PTR() value, it can be passed to panthor_heap_pool_put(), which then dereferences the invalid pointer. Red Hat rated this flaw a CVSS 3.1 base score of 5.5 (AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H), a Moderate impact. All currently assessed Red Hat Enterprise Linux and Red Hat In-Vehicle OS kernel, kernel-rt, and kernel-ivos-qualcomm update streams are not affected because the vulnerable code is not present in the shipped kernel builds. Weakness: CWE-476.

CVE-2026-72387
Unclassified
Aug 15, 2026
Medium5.5Red Hat

Medium [CVE-2026-72281] account pKVM reclaim against the VM mm

In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: account pKVM reclaim against the VM mm Protected guest faults charge long term pins to the VM's mm. Teardown can run later from file release, where current->mm may be unrelated. A flaw was found in the Linux kernel's Kernel-based Virtual Machine (KVM) for arm64 architectures. This vulnerability involves an issue with memory accounting for protected guest faults. During the teardown process, the system may incorrectly manage long-term memory pins, potentially leading to resource management inconsistencies within the virtual machine's memory. This could affect system stability or resource availability. When handling protected guest memory faults, the host charges long-term pins of guest pages against the virtual machine's mm (memory descriptor). Exploitation requires local access with privileges and impacts availability only (Red Hat CVSS 3.1 score 5.5, vector CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H). The vulnerable pKVM code is not present in the shipped Red Hat kernels, so all Red Hat Enterprise Linux and Red Hat In-Vehicle OS kernel components are currently marked NOT AFFECTED for this flaw. 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-911.

CVE-2026-72281
Unclassified
Aug 15, 2026
Medium5.5Red Hat

Medium [CVE-2026-72231] avoid request storms during pending request

In the Linux kernel, the following vulnerability has been resolved: batman-adv: tt: avoid request storms during pending request batadv_send_tt_request() allocates a tt_req_node when none exists for the destination originator node. This should prevent that a multiple TT requests are send at the same time to an originator. But if allocation of the send buffer failed, this request must be cleaned up again. But indicator for such a failure is "ret == false". But the actual implementation is checking for "ret == true". The check must be inverted to not loose the information about the TT request directly after it was attempted to be sent out. A flaw was found in the batman-adv (Better Approach To Mobile Ad-hoc Networking) module of the Linux kernel. An incorrect check during the handling of TT (Topology Table) requests can prevent the proper cleanup of request nodes when send buffer allocation fails. This can lead to a remote attacker causing request storms, potentially resulting in a Denial of Service (DoS) condition. A remote attacker able to participate in a batman-adv mesh network could exploit this to trigger TT request storms, resulting in a denial of service. Red Hat Product Security rates this flaw Moderate (CVSS 3.1 score 5.5), while the upstream CVE record assigns a higher severity of Important (CVSS 3.1 score 7.5, using a network attack vector).

CVE-2026-72231
Unclassified
Aug 15, 2026
Medium5.5Red Hat

Medium [CVE-2026-72402] Mask pseudo pointer values in verifier logs

In the Linux kernel, the following vulnerability has been resolved: bpf: Mask pseudo pointer values in verifier logs print_bpf_insn() masks ldimm64 immediates for pointer-bearing pseudo sources when pointer leaks are not allowed, but the mask only covers BPF_PSEUDO_MAP_FD and BPF_PSEUDO_MAP_VALUE. BPF_PSEUDO_MAP_IDX, BPF_PSEUDO_MAP_IDX_VALUE, and BPF_PSEUDO_BTF_ID can also be resolved to kernel pointer values before the verifier log prints the instruction. Include them in the existing pointer classification so the log prints 0x0 instead of the rewritten address. A flaw was found in the Linux kernel's BPF (Berkeley Packet Filter) verifier logging mechanism. The `print_bpf_insn()` function, responsible for masking sensitive pointer values in verifier logs, did not correctly mask all pseudo-pointer types. This oversight could lead to kernel memory addresses being exposed in the verifier logs, potentially allowing an attacker to gain sensitive information about the kernel's memory layout. A local user able to load a BPF program and read the verifier log could use this to obtain sensitive information about the kernel's memory layout, weakening KASLR-based protections and potentially assisting the exploitation of other kernel vulnerabilities.

CVE-2026-72402
Linux Kernel
Aug 15, 2026
Medium5.5Red Hat

Medium [CVE-2026-72236] Add missing array_index_nospec to __hw_perf_event_init

In the Linux kernel, the following vulnerability has been resolved: s390/perf_cpum_cf: Add missing array_index_nospec() to __hw_perf_event_init() ev variable is userspace controlled via event->attr.config and used as an array index after bounds checking, but without speculation barriers. Add the missing array_index_nospec() call to prevent speculative execution. A flaw was found in the Linux kernel's s390 performance monitoring component (`s390/perf_cpum_cf`). This could allow a local attacker to potentially exploit speculative execution, leading to information disclosure. 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-125. 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. 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.

CVE-2026-72236
Linux Kernel
Aug 15, 2026
Medium5.5Red Hat

Medium [CVE-2026-72356] Fix missing credit release on failure in cifs_issue_read

In the Linux kernel, the following vulnerability has been resolved: cifs: Fix missing credit release on failure in cifs_issue_read() Fix missing release of credits in the failure path in cifs_issue_read() lest retrying the subreq just overwrites the credits value. A flaw was found in the CIFS (Common Internet File System) component of the Linux kernel. A missing credit release on failure in the `cifs_issue_read()` function can lead to a situation where retrying a sub-request overwrites existing credit values. This resource management issue could potentially lead to system instability or a denial of service. When a read subrequest issued through cifs_issue_read() fails, the SMB credits acquired for that read are not released before the failed subrequest is terminated; retrying the read then simply overwrites the stored credits value, leaking the previously acquired credits. Repeated read failures and retries on a mounted CIFS share can progressively exhaust the credit accounting for the SMB session, stalling further reads or other I/O against the share and causing a denial of service. Only availability is impacted; there is no impact on confidentiality or integrity. Exploitation requires an existing CIFS mount and read activity that exercises the failure and retry path, for example read failures induced by a misbehaving or compromised remote SMB server.

CVE-2026-72356
Linux Kernel
Aug 15, 2026
Medium5.5Vendor: LowRed Hat

Medium [CVE-2026-72142] fix locked bus on SMBus block-read of 0 (atomic)

In the Linux kernel, the following vulnerability has been resolved: i2c: imx: fix locked bus on SMBus block-read of 0 (atomic) SMBus 3.1 6.5.7 allows a Block Read byte count of 0, but the atomic (polling) path rejects it as -EPROTO. Worse, it returns without a NACK+STOP: the next receive cycle has already started, so the target keeps holding SDA and the bus stays stuck until a power cycle for this i2c controller. Reading I2DR to obtain the count likewise arms the next byte on the count > I2C_SMBUS_BLOCK_MAX path, which also returned -EPROTO directly and left the bus held. Handle both: NACK the in-flight dummy byte (TXAK) and extend msgs->len so the existing last-byte handling emits STOP; the dummy byte is discarded. A count of 0 is a valid empty block read; a count above I2C_SMBUS_BLOCK_MAX is still reported as -EPROTO, but only after the bus has been released. The interrupt-driven path has the same flaw from a later commit and is fixed separately, as it carries a different Fixes: tag and stable range. When an I2C slave device performs an SMBus block-read operation with a byte count of zero, the atomic (polling) path in the driver fails to properly release the I2C bus. This can cause the bus to become stuck, requiring a power cycle of the I2C controller to restore functionality. This issue leads to a denial of service for the affected system.

CVE-2026-72142
Linux Kernel
Aug 15, 2026
Medium5.5Red Hat

Medium [CVE-2026-72433] fix NFT_META_BRI_IIFPVID stack leak

In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_meta_bridge: fix NFT_META_BRI_IIFPVID stack leak This needs to test for nonzero retval. A flaw was found in the Linux kernel's netfilter component, specifically within the `nft_meta_bridge` module. This vulnerability, a stack leak, occurs due to improper handling of return values, which fails to test for nonzero results. An attacker could potentially exploit this issue to gain access to sensitive information from the kernel's memory. 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-562. 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.

CVE-2026-72433
Linux Kernel
Aug 15, 2026
Medium5.5Red Hat

Medium [CVE-2026-72379] refuse O_TMPFILE creation with an unmapped fsuid or fsgid

In the Linux kernel, the following vulnerability has been resolved: fs: refuse O_TMPFILE creation with an unmapped fsuid or fsgid vfs_tmpfile() never checked that the caller's fsuid and fsgid map into the filesystem. On an idmapped mount whose idmapping does not cover the caller's fs{u,g}id, the ->tmpfile() instance initializes the new inode through inode_init_owner(), where mapped_fsuid()/mapped_fsgid() return INVALID_UID/INVALID_GID, and the tmpfile ends up owned by (uid_t)-1. Every other creation path already refuses this: may_o_create() (O_CREAT) and may_create_dentry() (mkdir, mknod, symlink, link) bail out with -EOVERFLOW via fsuidgid_has_mapping() precisely so that an object cannot be created with an owner the filesystem cannot represent. An O_TMPFILE is no exception: it is created I_LINKABLE and linkat(2) can splice it into the namespace afterwards, so the same guarantee must hold. Add the missing fsuidgid_has_mapping() check to vfs_tmpfile(). On a non-idmapped mount the caller's fs{u,g}id always map in the superblock's user namespace, so this is a no-op there and only takes effect on an idmapped mount that does not map the caller. It applies to every filesystem that sets FS_ALLOW_IDMAP and implements ->tmpfile() (tmpfs, ext4, btrfs, xfs, f2fs,...), and to overlayfs, whose upper-layer tmpfile creation funnels through vfs_tmpfile() via backing_tmpfile_open().

CVE-2026-72379
Linux Kernel
Aug 15, 2026
Medium5.5Red Hat

Medium [CVE-2026-72438] fix writes_pending and barrier reference leaks on discard failures

In the Linux kernel, the following vulnerability has been resolved: md/raid10: fix writes_pending and barrier reference leaks on discard failures raid10_make_request() acquires a writes_pending reference with md_write_start() before calling raid10_handle_discard(). Several failure paths in raid10_handle_discard() complete the bio and return without releasing the corresponding reference, causing md_write_end() to be skipped. Call md_write_end() before returning from these failure paths to keep writes_pending accounting balanced. Additionally, discard split allocation failures can occur after wait_barrier() succeeds. Those paths return without calling allow_barrier(), leaking the associated barrier reference. Release the barrier before returning from those paths. A flaw was found in the Linux kernel's multiple device (MD) driver, specifically in the RAID10 implementation. An attacker could potentially exploit this by triggering discard failures, leading to resource exhaustion and a Denial of Service (DoS) on the affected system. 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-772. 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.

CVE-2026-72438
Linux Kernel
Aug 15, 2026
Medium5.5Red Hat

Medium [CVE-2026-72418] prevent connlimit drops for early confirmed ct

In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_conncount: prevent connlimit drops for early confirmed ct Commit 69894e5b4c5e ("netfilter: nft_connlimit: update the count if add was skipped") introduced a regression where packets for valid connections are dropped when using connlimit for soft-limiting scenarios. The issue occurs when a new connection reuses a socket currently in the TIME_WAIT state. In this scenario, the connection tracking entry is evaluated as already confirmed. Previously, __nf_conncount_add() assumed that if a connection was confirmed and did not originate from the loopback interface, it should skip the addition and return -EEXIST. Skipping the addition triggers a garbage collection run that cleans up the TIME_WAIT connection. Consequently, the active connection count drops to 0, which xt_connlimit mishandles, leading to the false rejection of the perfectly valid new connection. Fix this by replacing the interface check with protocol-agnostic state checks. We now skip the tree insertion and preserve the lockless garbage collection optimization only if the connection is IPS_ASSURED. This allows early-confirmed setup packets (such as reused TIME_WAIT sockets or locally generated SYN-ACKs) to be properly evaluated and counted without falsely dropping.

CVE-2026-72418
Linux Kernel
Aug 15, 2026
Medium5.5Red Hat

Medium [CVE-2026-72211] grow index root value before reparent header update

In the Linux kernel, the following vulnerability has been resolved: ntfs: grow index root value before reparent header update ntfs_ir_reparent() moves the resident index root entries into an index block and leaves a small root stub containing the child VCN. For example, an empty root with value_length 48 has an index area of 32 bytes, while the large-index root stub needs index_length and allocated_size of 40 bytes. The current code publishes the larger index.index_length and index.allocated_size before resizing the resident value. If the resize returns -ENOSPC, the recovery path can call ntfs_inode_add_attrlist(), which looks attributes up again while the root header says allocated_size 40 but the resident value still only provides 32 bytes of index area. Lookup-time $INDEX_ROOT validation then correctly rejects that transient layout as corrupt. This reproduces as a generic/013 failure under qemu. In the failing run, the transient root had value_len=48, index_size=32, index_length=40, and allocated_size=40, and ntfsprogs-plus ntfsck reported "Corrupt index root in MFT record 1177". If the resize fails, the old root remains valid for recovery lookups. Keep the existing header-before-resize ordering for shrink or same-size cases so the resident value never temporarily exposes an allocated_size beyond its bounds.

CVE-2026-72211
Unclassified
Aug 15, 2026
Medium5.5Red Hat

Medium [CVE-2026-72167] fix probe resource allocation

In the Linux kernel, the following vulnerability has been resolved: mtd: rawnand: pl353: fix probe resource allocation During probe(), the devm_ioremap() is called with the parent device instead of the current one. So when the module is unloaded, the register area isn't released. A local attacker could potentially exploit this to cause a resource leak, leading to a denial of service (DoS) over time. A moderate-severity flaw was found in the Linux kernel pl353 raw NAND controller driver (drivers/mtd/nand/raw/pl35x-nand-controller.c). All currently tracked Red Hat Enterprise Linux (kernel and kernel-rt) and Red Hat In-Vehicle OS (kernel and kernel-ivos-qualcomm) streams are marked not affected because the vulnerable code is not present in the shipped kernels. 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-772.

CVE-2026-72167
Unclassified
Aug 15, 2026
Medium5.5Red Hat

Medium [CVE-2026-72385] Fix NULL pointer dereference in fprobe_fgraph_entry

In the Linux kernel, the following vulnerability has been resolved: tracing/fprobe: Fix NULL pointer dereference in fprobe_fgraph_entry() fprobe_fgraph_entry() sizes a shadow-stack reservation in one walk of the per-ip fprobe list and fills it in a second walk, both under rcu_read_lock() only. A fprobe registered on an already-live ip can become visible between the two walks, so the fill walk processes an exit_handler the sizing walk did not count and used runs past reserved_words. If the sizing walk counted nothing, fgraph_data is NULL and the first write_fprobe_header() faults: Oops: general protection fault, probably for non-canonical address... KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] RIP: 0010:fprobe_fgraph_entry+0xa38/0xf10 kernel/trace/fprobe.c:167 Call Trace: function_graph_enter_regs+0x44c/0xa10 kernel/trace/fgraph.c:677 ftrace_graph_func+0xc5/0x140 arch/x86/kernel/ftrace.c:671 __kernel_text_address+0x9/0x40 kernel/extable.c:78 arch_stack_walk+0x117/0x170 arch/x86/kernel/stacktrace.c:26 kmem_cache_free+0x188/0x580 mm/slub.c:6378 tcp_data_queue+0x18d/0x6550 net/ipv4/tcp_input.c:5590 [...] The list cannot be frozen across the two walks, so skip a node that does not fit the reservation and count it as missed. A race condition can occur in the `fprobe_fgraph_entry()` function during shadow-stack reservation.

CVE-2026-72385
Unclassified
Aug 15, 2026

← All vendors