Skip to content
VulniPulse

Red Hat Linux Security Advisories & CVEs

5837 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-74570] harden runlist realloc size calculations

In the Linux kernel, the following vulnerability has been resolved: ntfs: harden runlist realloc size calculations Add a shared helper to safely convert runlist element counts to byte sizes using overflow checks, and use it in both ntfs_rl_realloc() and ntfs_rl_realloc_nofail(). A flaw was found in the Linux kernel's NTFS file system driver. This vulnerability arises from insufficient size calculations during runlist memory reallocation, which could lead to an integer overflow. An attacker could potentially exploit this to cause memory corruption, leading to system instability or 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-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.

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

Medium [CVE-2026-74470] Fix REPORT ZONES alloc_len underflow OOB write

In the Linux kernel, the following vulnerability has been resolved: scsi: scsi_debug: Fix REPORT ZONES alloc_len underflow OOB write resp_report_zones() sizes the reply buffer from the CDB allocation length. The v3 fix rounds alloc_len up with ALIGN() before deriving the descriptor count: rep_max_zones = (ALIGN((u64)alloc_len, RZONES_DESC_HD) - RZONES_DESC_HD) >> ilog2(RZONES_DESC_HD); arr_len = (u64)RZONES_DESC_HD * (rep_max_zones + 1); For alloc_len in 0xFFFFFFC1..0xFFFFFFFF, ALIGN() rounds up to 0x100000000, so arr_len is 4 GB. On 32-bit, kzalloc()'s size_t is 32-bit and truncates 0x100000000 to 0; kzalloc(0) returns ZERO_SIZE_PTR, which passes the!arr check, and desc = arr + 64 is then dereferenced in the loop -> out-of-bounds write / panic. Clamp rep_max_zones to devip->nr_zones. The loop already stops at sdebug_capacity (after nr_zones zones), so a report can never hold more than nr_zones descriptors; the clamp does not change the report, it only bounds arr_len to (nr_zones + 1) * RZONES_DESC_HD, a real device property that can never reach 0x100000000. This vulnerability occurs in the `resp_report_zones()` function when handling specific allocation lengths, leading to an integer underflow. On 32-bit systems, this can cause an out-of-bounds write, which results in a kernel panic. A local attacker could exploit this to cause a denial of service (DoS).

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

Medium [CVE-2026-74529] hold conn in hci_connect_pa_sync callback

In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_sync: hold conn in hci_connect_pa_sync() callback There is theoretical UAF if the conn is freed while the hci_sync task is running. Hold refcount to avoid that. A flaw was found in the Linux kernel's Bluetooth Host Controller Interface (HCI) synchronization component. This vulnerability, a Use-After-Free (UAF), occurs when a connection object is prematurely released while the `hci_sync` task is still active. A local attacker could potentially exploit this to cause a system crash or other undefined behavior, leading to a denial of service or possibly arbitrary code execution. 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-825. 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-74529
Linux Kernel
Aug 15, 2026
Medium5.5Red Hat

Medium [CVE-2026-74508] reject frames without a transaction header

In the Linux kernel, the following vulnerability has been resolved: Bluetooth: HIDP: reject frames without a transaction header hidp_recv_ctrl_frame() and hidp_recv_intr_frame() read skb->data[0] before checking that the L2CAP SDU contains a transaction header. A connected HIDP peer can send an empty basic-mode SDU and make both paths use an uninitialized byte from skb tailroom. KMSAN reports the use in hidp_session_run(), with the uninitialized value originating in __alloc_skb() through vhci_write(). The control path produces two reports and the interrupt path produces one. The byte can also be controlled by a malformed lower-layer packet. If an HCI ACL packet contains an L2CAP PDU with a declared zero-length payload followed by an extra 0x15 byte, l2cap_recv_acldata() reduces skb->len to the declared PDU length before dispatch. The current HIDP path nevertheless consumes the extra byte as HIDP_TRANS_HID_CONTROL | HIDP_CTRL_VIRTUAL_CABLE_UNPLUG and terminates the HIDP session. With this change, the same packet is discarded and a subsequent feature report request succeeds. Pull the transaction header with skb_pull_data() and discard frames that do not contain it. A flaw was found in the Linux kernel's Bluetooth Human Interface Device Protocol (HIDP) implementation.

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

Medium [CVE-2026-74555] Fix HA resume deadlock and hisi_sas disk-wake race

In the Linux kernel, the following vulnerability has been resolved: scsi: libsas: Fix HA resume deadlock and hisi_sas disk-wake race Commit fbefe22811c3 ("scsi: libsas: Don't always drain event workqueue for HA resume") introduced sas_resume_ha_no_sync() to avoid a deadlock: the PHYE_RESUME_TIMEOUT handler, running on the HA event workqueue, calls sas_deform_port() -> sas_destruct_devices(), which removes SCSI devices and waits for the host to become runtime-active. But the host cannot resume until sas_resume_ha() -> sas_drain_work() returns, and the drain is blocked on that very handler. However skipping the drain reintroduces a race: hisi_sas returns from resume before all PHY UP work and libsas discovery work finish. The controller may then autosuspend while disks are still waking up. The disks issue IO to a suspended controller, the IO fails, and the disks get disabled. Fix the deadlock at its source by moving the PHYE_RESUME_TIMEOUT notification to after sas_drain_work(). By then the host resume is about to complete, so device removal through device_link no longer blocks on the resume and the cycle is broken. With the deadlock gone, restore sas_resume_ha() (the draining variant) in hisi_sas and remove sas_resume_ha_no_sync(). The reorder is safe for the other libsas consumers (isci, pm8001, aic94xx, mvsas).

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

Medium [CVE-2026-72160] reject dinodes with non-canonical i_mode type

In the Linux kernel, the following vulnerability has been resolved: ocfs2: reject dinodes with non-canonical i_mode type Patch series "ocfs2: harden inode validators against forged metadata", v2. This series adds three structural checks to OCFS2 dinode validation so malformed on-disk fields are rejected before ocfs2_populate_inode() copies them into the in-core inode. The checks cover: - i_mode values whose type bits do not name a canonical POSIX file type; - non-device dinodes whose id1.dev1.i_rdev field is non-zero; and - non-inline dinodes that claim non-zero i_size while i_clusters is zero, covering directories unconditionally and regular files on non-sparse volumes. The normal read path reports these through ocfs2_error(), matching the existing suballoc-slot, inline-data, chain-list, and refcount checks. The online filecheck path uses the same structural predicates but keeps its own reporting contract, returning OCFS2_FILECHECK_ERR_INVALIDINO instead of calling ocfs2_error(). This patch (of 3): ocfs2_validate_inode_block() currently accepts any non-zero i_mode value. ocfs2_populate_inode() then copies that mode verbatim into inode->i_mode and dispatches on i_mode & S_IFMT to the file/dir/symlink/special_file iops; an unrecognised type falls through to ocfs2_special_file_iops and init_special_inode().

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

Medium [CVE-2026-72198] reject non-resident records for resident-only attributes

In the Linux kernel, the following vulnerability has been resolved: ntfs: reject non-resident records for resident-only attributes The shared lookup-time attribute validator rejects non-resident $FILE_NAME and $VOLUME_NAME records because their formats require resident values and callers handle returned records as resident attributes. Other resident-only attribute types still pass through the generic non-resident mapping-pairs checks. That leaves real resident/non-resident union confusion paths. Inode load looks up $STANDARD_INFORMATION and then reads data.resident.value_offset without checking a->non_resident. ntfs_inode_sync_standard_information() does the same when updating the standard information value. ntfs_write_volume_flags() also looks up $VOLUME_INFORMATION and reads data.resident.value_offset directly. $INDEX_ROOT callers in dir.c and index.c depend on the same lookup contract before consuming the resident index root value. Keep the existing $FILE_NAME and $VOLUME_NAME behavior, but factor it through a helper and extend it to $STANDARD_INFORMATION, $OBJECT_ID, $VOLUME_INFORMATION, $INDEX_ROOT, and $EA_INFORMATION. For $OBJECT_ID and $EA_INFORMATION this is contract hardening for resident-only formats; this patch only rejects the non-resident form and does not add new resident value validation for those types.

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

Medium [CVE-2026-72290] Fix GISC refcount leak on AIF enable failure

In the Linux kernel, the following vulnerability has been resolved: KVM: s390: pci: Fix GISC refcount leak on AIF enable failure kvm_s390_gisc_register() registers the guest ISC before pinning the guest interrupt forwarding pages and allocating the AISB bit. If any of the later setup steps fails, the function unwinds the pinned pages and other local state, but does not unregister the GISC reference. Add the missing kvm_s390_gisc_unregister() to the error unwind path. A flaw was found in the Linux kernel's Kernel-based Virtual Machine (KVM) for s390 PCI. During the setup of guest interrupt forwarding, a reference count (refcount) to the Guest Interrupt Service Call (GISC) may not be properly released if subsequent setup steps fail. This resource leak can lead to resource exhaustion, potentially allowing a local attacker to cause a Denial of Service (DoS) to the virtualized environment. 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-911. Affected Red Hat products: Red Hat Enterprise Linux 10; Red Hat Enterprise Linux 8; 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-72290
Linux Kernel
Aug 15, 2026
Medium5.5Red Hat

Medium [CVE-2026-72182] fix refcount leak in is_full_charged

In the Linux kernel, the following vulnerability has been resolved: power: supply: charger-manager: fix refcount leak in is_full_charged() In is_full_charged(), power_supply_get_by_name() is called to obtain a reference to the fuel_gauge power supply. If the voltage check (uV >= desc->fullbatt_uV) succeeds, the function returns true directly without releasing the reference, leaking the refcount. Fix this by setting a flag and jumping to the out label where power_supply_put() properly drops the reference. A reference count (refcount) leak occurs within the `is_full_charged()` function. This happens when a reference to the fuel gauge power supply is obtained but not properly released if a specific voltage check succeeds. This resource leak could potentially lead to system instability or a denial of service. 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. 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.

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

Medium [CVE-2026-72278] Re-translate VNCR before injecting abort

In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: nv: Re-translate VNCR before injecting abort KVM faults in the VNCR page with FOLL_WRITE whenever the guest aborts for a write, similar to how a regular stage-2 mapping is handled. It is entirely possible that the guest reads from the VNCR before writing to it, in which case the PFN could only be read-only. Invalidate the VNCR TLB and re-fetch the translation upon taking a VNCR abort, allowing the host mapping to be faulted in for write the second time around. Interestingly enough, this also satisfies the ordering requirements of FEAT_ETS2/3 between descriptor updates and MMU faults. A flaw was found in the Linux kernel's Kernel-based Virtual Machine (KVM) for arm64 systems. This vulnerability occurs when a guest operating system attempts to access the Virtualization Nested Control Register (VNCR) page. If the guest reads from VNCR before writing to it, KVM may incorrectly handle the memory access, potentially leading to unexpected behavior or instability within the virtualized environment. 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-280. 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.

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

Medium [CVE-2026-72300] validate vendor array size before parsing

In the Linux kernel, the following vulnerability has been resolved: ASoC: SOF: topology: validate vendor array size before parsing sof_parse_token_sets() reads array->size while iterating over topology private data. The loop condition only checks that some data remains, so a malformed topology with a truncated trailing vendor array can make the parser read the size field before a full vendor-array header is available. Validate that the remaining private data contains a complete snd_soc_tplg_vendor_array header before reading array->size. The declared array size check also needs to remain signed. asize is an int, but sizeof(*array) has type size_t, so comparing them directly promotes negative asize values to unsigned and lets them pass the check, as reported in the stable review thread reference below. This rejects negative, zero and otherwise too-small sizes before the parser dispatches to the tuple-specific code. A flaw was found in the Linux kernel's Advanced Linux Sound Architecture (ASoC) Sound Open Firmware (SOF) topology component. A local attacker could exploit this by providing malformed topology data, leading to an out-of-bounds read. This could result in system instability or a denial of service. 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.

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

Medium [CVE-2026-72199] validate resident index root values on lookup

In the Linux kernel, the following vulnerability has been resolved: ntfs: validate resident index root values on lookup Resident $INDEX_ROOT values carry index header fields that callers consume after lookup. Some callers already validate parts of the layout before walking entries, but those checks are scattered and do not cover all root header invariants, such as entries_offset alignment and lower bound, index_length, and allocated_size consistency. The resident root resize paths now keep these header fields consistent while the value size changes: ntfs_ir_truncate() lowers index.allocated_size before shrinking the resident value, and ntfs_ir_reparent() grows the resident value before publishing a larger root header. Lookup-time validation can therefore cover these invariants without tripping over the driver's own resize paths. Add $INDEX_ROOT to the minimum resident value size table and validate the resident index header fields before returning the attribute from lookup. Require 8-byte aligned index header fields, a sane entries_offset, an index_length within allocated_size, allocated_size within the resident value, and enough entry space for at least an index entry header. The shared validator already rejects non-resident records for resident-only attribute types, including $INDEX_ROOT. A flaw was found in the NTFS filesystem driver of the Linux kernel.

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

Medium [CVE-2026-72370] release pages on atomic dio size mismatch

In the Linux kernel, the following vulnerability has been resolved: iomap: release pages on atomic dio size mismatch If bio_iov_iter_get_pages() or the bounce helper succeeds but builds a short bio, the REQ_ATOMIC size check rejects it before submission. The old error path only dropped the bio reference, leaving any pages already attached to the bio unreleased. Release or unbounce the pages before falling through to out_put_bio on this error path. This bug was reported by sashiko: When handling atomic direct I/O (DIO) operations, if a bio (a data structure representing I/O requests) is built with a size mismatch and subsequently rejected, the kernel's error handling path fails to release the associated memory pages. This oversight can lead to a resource leak, potentially causing memory exhaustion and a Denial of Service (DoS) condition on 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-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.

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

Medium [CVE-2026-72377] Remove setting of AS_RELEASE_ALWAYS for symlinks and mountpoints

In the Linux kernel, the following vulnerability has been resolved: afs: Remove setting of AS_RELEASE_ALWAYS for symlinks and mountpoints Regular AFS files correctly use afs_file_aops which have release_folio set as netfs_release_folio, so AS_RELEASE_ALWAYS is valid for them when fscache is enabled (set via afs_vnode_set_cache()). However, afs_apply_status() unconditionally calls mapping_set_release_always() for these. In such case when memory management code attempts to release folios, filemap_release_folio() checks folio_needs_release() which returns true due to AS_RELEASE_ALWAYS being set. Since there is no release_folio callback, it falls through to try_to_free_buffers(), which at present expects buffer_heads to be not null. For symlinks and mountpoints without buffer_heads, this causes pointer dereference. [dh: Added more bits that were missed] A flaw was found in the Linux kernel's Andrew File System (AFS) module. When fscache is enabled, AFS symlinks and mountpoints are incorrectly handled during memory management operations. This can lead to a pointer dereference, which a local attacker could potentially exploit to cause a system crash, 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-476. Affected Red Hat products: Red Hat Enterprise Linux 10.

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

Medium [CVE-2026-72280] Drop bogus WARN for write to ZCR_EL2

In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: nv: Drop bogus WARN for write to ZCR_EL2 It is entirely possible for a guest to write to the ZCR_EL2 sysreg alias while in a nested context, as it is expected if FEAT_NV2 is advertised to the L1 hypervisor. Get rid of the bogus WARN which, since the hyp vectors were installed at this point, has the effect of a hyp_panic... A flaw was found in the Linux kernel's KVM (Kernel-based Virtual Machine) for ARM64 architectures. A guest operating system, when operating in a nested virtualization environment, could trigger a hypervisor panic (hyp_panic) by writing to the ZCR_EL2 system register alias. This issue leads to a denial of service for the virtual machine, potentially affecting the stability of the host 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-617. 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-72280
Linux Kernel
Aug 15, 2026
Medium5.5Red Hat

Medium [CVE-2026-72423] Guard conntrack opts error writes

In the Linux kernel, the following vulnerability has been resolved: bpf: Guard conntrack opts error writes The conntrack lookup and allocation kfuncs take an opts pointer together with an opts__sz argument. The verifier checks only the memory range described by opts__sz, but the wrappers unconditionally write opts->error whenever the internal lookup or allocation helper returns an error. For an invalid size smaller than the end of opts->error, that write can land outside the verifier-checked range. Keep returning NULL for invalid arguments, but only report the error through opts->error when the supplied size includes the field. This preserves error reporting for the supported 12-byte and 16-byte layouts, and for other invalid sizes that still include opts->error. The BPF (Berkeley Packet Filter) subsystem's conntrack (connection tracking) functionality contains an out-of-bounds write vulnerability. This occurs because the system does not properly validate the size of an options structure when reporting errors in conntrack lookup and allocation kernel functions (kfuncs). An attacker could potentially exploit this by providing an invalid size, leading to memory corruption. 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-787. Affected Red Hat products: Red Hat Enterprise Linux 9.

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

Medium [CVE-2026-72171] remove failed entries from the device list

In the Linux kernel, the following vulnerability has been resolved: mtd: slram: remove failed entries from the device list register_device() links a new slram_mtdlist entry before allocating all of the state needed by the entry. If a later allocation, memremap(), or mtd_device_register() fails, the partially initialized entry remains on the global list. A later cleanup can then dereference or free invalid state from that failed entry. Unwind the partially initialized entry and clear the list tail on each failure path after the entry has been linked. A flaw was found in the Linux kernel's Memory Technology Device (MTD) subsystem, specifically within the `slram` module. A subsequent cleanup operation may then attempt to dereference or free invalid memory, potentially leading to memory corruption or a system crash (Denial of Service). 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-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.

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

Medium [CVE-2026-72269] fix potential memory leak in uvesafb_probe

In the Linux kernel, the following vulnerability has been resolved: fbdev: uvesafb: fix potential memory leak in uvesafb_probe() Due to an incorrect goto label, memory allocated for modedb and modelist in uvesafb_vbe_init() is not freed in some error paths. A flaw was found in the Linux kernel's framebuffer device (fbdev) component, specifically within the `uvesafb` driver. This vulnerability occurs because memory allocated for display modes is not properly released during certain error handling paths. This oversight can lead to a memory leak, which might exhaust system resources and cause 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-772. 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.

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

Medium [CVE-2026-72263] fix memory leak in snd_sof_load_topology

In the Linux kernel, the following vulnerability has been resolved: ASoC: SOF: topology: fix memory leak in snd_sof_load_topology When the topology filename contains "dummy" and tplg_cnt is 0, the function returns -EINVAL directly without freeing the tplg_files allocated by kcalloc() at line 2497. This leaks memory on every such topology load attempt. Fix this by setting ret = -EINVAL and jumping to the out: label, which already handles the kfree(tplg_files) cleanup. A flaw was found in the Linux kernel's ASoC (Audio System on Chip) Sound Open Firmware (SOF) topology component. When a topology filename contains "dummy" and a specific counter is zero, the `snd_sof_load_topology` function fails to deallocate previously assigned memory. This oversight results in a memory leak with each failed topology load attempt, potentially leading to resource exhaustion and 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 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-72263
Linux Kernel
Aug 15, 2026
Medium5.5Red Hat

Medium [CVE-2026-72138] fix error handling in ioctl

In the Linux kernel, the following vulnerability has been resolved: xen/gntdev: fix error handling in ioctl When gntdev_ioctl_map_grant_ref() fails to copy the operation result back to userspace after successfully adding the mapping to the list, the error path returns -EFAULT without releasing the reference acquired by gntdev_alloc_map(). The mapping remains in priv->maps with a refcount of 1, causing a memory leak and a dangling list entry. Additionally, gntdev_add_map() may modify map->index to avoid overlap with existing mappings. Therefore, the index returned to userspace must be obtained after gntdev_add_map() completes. Fix this by holding the mutex across gntdev_add_map(), retrieving the correct index, and copy_to_user(). If copy_to_user() fails, remove the mapping from the list and release the reference while still holding the lock. Fix these issues by properly handling all error cases. When the `gntdev_ioctl_map_grant_ref()` function fails to copy operation results back to userspace, it does not properly release a memory reference. This oversight can lead to a memory leak and a corrupted list entry. A local attacker could exploit this to cause a denial of service by exhausting system 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-772.

CVE-2026-72138
Unclassified
Aug 15, 2026

← All vendors