Red Hat Linux Security Advisories & CVEs
12467 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
Medium [CVE-2026-72321] Fix potential memory leaks in igmp_mod_timer and igmp_stop_timer
In the Linux kernel, the following vulnerability has been resolved: ipv4: igmp: Fix potential memory leaks in igmp_mod_timer() and igmp_stop_timer() When a timer is deleted and not re-armed in igmp_mod_timer(), or stopped in igmp_stop_timer(), the code currently decrements the reference counter of the multicast list entry @im using refcount_dec(&im->refcnt). However, both functions can be called from the RCU reader path: - igmp_mod_timer() via igmp_heard_query() -> for_each_pmc_rcu() - igmp_stop_timer() via igmp_rcv() -> igmp_heard_report() If the group im was concurrently removed from the list by ip_mc_dec_group(), its reference count might have already been decremented to 1. In this case, timer_delete() succeeds, and refcount_dec() decrements the refcount from 1 to 0. Since refcount_dec() does not free the object when it hits 0 (unlike ip_ma_put()), the im structure is leaked. Fix this by using ip_ma_put(im) instead of refcount_dec(&im->refcnt), and deferring the put until after the spinlock is released. A flaw was found in the Linux kernel's IPv4 Internet Group Management Protocol (IGMP) component. Incorrect handling of reference counts in the `igmp_mod_timer()` and `igmp_stop_timer()` functions can occur when a multicast list entry is concurrently removed. This can lead to a memory leak of the `im` structure, potentially impacting system stability.
Medium [CVE-2026-72295] Validate irqchip index in irqfd routing
In the Linux kernel, the following vulnerability has been resolved: LoongArch: KVM: Validate irqchip index in irqfd routing Sashiko reported that the irqchip index is not validated for LoongArch. Add validation and reject out-of-range irqchip indexes to avoid indexing past the routing table's chip array. A flaw was found in the Linux kernel's Kernel-based Virtual Machine (KVM) for LoongArch architecture. An unvalidated interrupt controller (irqchip) index in the irqfd routing mechanism could allow a local attacker to perform an out-of-bounds memory access. This could lead to a denial of service or potentially privilege escalation within the 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-823. 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-72331] Fix VMA access race
In the Linux kernel, the following vulnerability has been resolved: accel/amdxdna: Fix VMA access race aie2_populate_range() and amdxdna_umap_release() access a saved VMA pointer that may have already been freed, leading to a potential use-after-free. Remove the VMA accesses from these functions to avoid the race. This race condition can lead to a use-after-free vulnerability, which could result in system instability or potentially allow a local attacker to escalate privileges. A local user with access to an affected device could potentially trigger this use-after-free, causing system instability or a kernel crash. Red Hat assessed this flaw as having moderate impact (CVSS 5.5, AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H), limited to availability, whereas the upstream CVE record assigns a higher score (7.8) that assumes full confidentiality, integrity, and availability impact. The vulnerable code is not present in the Red Hat Enterprise Linux and Red Hat In-Vehicle OS kernels shipped by Red Hat, so all Red Hat products are currently marked as not affected. Weakness: CWE-825.
Medium [CVE-2026-72395] (pmbus) Fix passing events to regulator core
In the Linux kernel, the following vulnerability has been resolved: hwmon: (pmbus) Fix passing events to regulator core Sashiko reports: Commit 754bd2b4a084 ("hwmon: (pmbus/core) Protect regulator operations with mutex") introduced a worker to batch regulator events over time using atomic_or(). The delayed worker then passes the combined bitmask unmodified to regulator_notifier_call_chain(). The core regulator subsystem's regulator_handle_critical() function evaluates the event parameter using a strict switch statement. If multiple distinct faults occur before the worker runs (e.g., REGULATOR_EVENT_UNDER_VOLTAGE | REGULATOR_EVENT_OVER_CURRENT), the combined bitmask fails to match any case. This leaves the reason as NULL and completely bypasses the critical hw_protection_trigger(). Fix the problem by passing events bit by bit to the regulator event handler. A worker designed to batch regulator events can combine multiple distinct hardware fault events into a single bitmask. This combined bitmask is then incorrectly processed by the critical hardware protection function, `regulator_handle_critical()`, causing it to bypass essential safety mechanisms. This could prevent the system from properly responding to critical hardware faults, potentially leading to system instability or damage. A moderate-impact flaw was found in the Linux kernel hwmon (pmbus) subsystem.
Medium [CVE-2026-72334] fix malformed ISO_END/CONT handling
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: ISO: fix malformed ISO_END/CONT handling Core specification (Part C vol 4 sec 5.4.5) does not exclude empty ISO_CONT, ISO_END packets. We currently reject them if they are last. If controller sends malformed sequence ISO_START -> rx_len = 4, ISO_CONT skb->len 4, ISO_START that ends payload in ISO_CONT, we leak conn->rx_skb. If controller sends too long ISO_END, we panic on skb_put. Fix by marking unfinished ISO_START via conn->rx_skb!= NULL. Check skb->len properly before skb_put. Combine the ISO_CONT/END code paths as they require the same initial checks. Reject too short ISO_END packets. A remote attacker, by sending specially crafted malformed Bluetooth ISO packets, could trigger a kernel panic, leading to a denial of service. Additionally, this vulnerability could result in a memory leak within the kernel. This issue arises from improper handling of ISO_END and ISO_CONT packets, particularly when they are malformed or unexpected. 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 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-72230] free unfragmentable packet
In the Linux kernel, the following vulnerability has been resolved: batman-adv: frag: free unfragmentable packet The caller of batadv_frag_send_packet() assume that the skb provided to the function are always consumed. But the pre-check for an empty payload or the zero fragment size returned an error without any further actions. A failed pre-check must use the same error handling code as the rest of the function. A flaw was found in the `batman-adv` (Better Approach To Mobile Ad-hoc Networking - Advanced) fragmentation module of the Linux kernel. The `batadv_frag_send_packet()` function, responsible for sending fragmented packets, does not properly free allocated memory when a packet is deemed unfragmentable due to an empty payload or zero fragment size. This oversight can lead to a memory leak, potentially affecting system stability and performance. When batadv_frag_send_packet() rejected a packet as unfragmentable because of an empty payload or a zero fragment size, it returned an error without freeing the associated socket buffer (skb), even though callers of the function assume the skb is always consumed. Red Hat rated this flaw Moderate (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H), affecting only availability, because exploiting it requires the ability to locally originate the malformed batman-adv traffic that reaches the flawed error path.
Medium [CVE-2026-72360] Don't attempt to process FAST_REQ or EVENT relays
In the Linux kernel, the following vulnerability has been resolved: drm/xe/pf: Don't attempt to process FAST_REQ or EVENT relays Currently defined VF/PF relay actions use regular REQUEST messages only and the PF shouldn't attempt to handle FAST_REQUEST nor EVENT messages as this would result in breaking the VFPF ABI protocol and also might trigger an assert on the PF side. (cherry picked from commit 1714d360fc5ae2e0886a69e979095d9c7ff3568a) The Physical Function (PF) incorrectly attempts to process `FAST_REQUEST` or `EVENT` messages, which are not part of the defined Virtual Function to Physical Function (VFPF) Application Binary Interface (ABI) protocol. This misprocessing can lead to a violation of the VFPF ABI protocol and may trigger an assert on the PF side, potentially resulting in a denial of service. A denial-of-service flaw rated moderate by Red Hat was found in the Linux kernel's drm/xe SR-IOV GuC relay handling for Intel Xe graphics. No impact on confidentiality or integrity has been identified. The Red Hat Enterprise Linux 9 and 10 kernel and kernel-rt components and the Red Hat In-Vehicle OS 2 kernels are affected; because the impact is limited to denial of service by an attacker who already controls a VF on an affected host, the fix has been deferred to a future update, leaving that residual risk in the meantime.
Medium [CVE-2026-72149] Fix burst size calculation
In the Linux kernel, the following vulnerability has been resolved: dmaengine: tegra: Fix burst size calculation Currently, the Tegra GPC DMA hardware requires the transfer length to be a multiple of the max burst size configured for the channel. When a client requests a transfer where the length is not evenly divisible by the configured max burst size, the DMA hangs with partial burst at the end. Fix this by reducing the burst size to the largest power-of-2 value that evenly divides the transfer length. For example, a 40-byte transfer with a 16-byte max burst will now use an 8-byte burst (40 / 8 = 5 complete bursts) instead of causing a hang. This issue was observed with the PL011 UART driver where TX DMA transfers of arbitrary lengths were stuck. 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-131. 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-72294] Check irq validity in kvm_vcpu_ioctl_interrupt
In the Linux kernel, the following vulnerability has been resolved: LoongArch: KVM: Check irq validity in kvm_vcpu_ioctl_interrupt() Function kvm_vcpu_ioctl_interrupt() can be called from userspace, here add irq validility cheking in kvm_vcpu_ioctl_interrupt(). A flaw was found in the Linux kernel's Kernel-based Virtual Machine (KVM) component, specifically within the LoongArch architecture. The `kvm_vcpu_ioctl_interrupt()` function, which can be invoked from userspace, lacks proper validation of interrupt requests. This missing validity check could allow a local attacker to trigger an invalid interrupt, potentially leading to a denial of service. Red Hat rated this flaw Moderate (CVSS 3.1 score 5.5, CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H) because the impact is limited to availability, with no confidentiality or integrity impact; this differs from the upstream CVEORG rating of Important (8.8), which assumes a changed scope with high confidentiality and integrity impact. Red Hat Enterprise Linux and Red Hat In-Vehicle OS are not affected by this flaw because the vulnerable LoongArch KVM code is not present in the kernels shipped for these products. Weakness: CWE-1287.
Medium [CVE-2026-72159] reject non-inline dinodes with i_size and zero i_clusters
In the Linux kernel, the following vulnerability has been resolved: ocfs2: reject non-inline dinodes with i_size and zero i_clusters On a volume mounted without OCFS2_FEATURE_INCOMPAT_SPARSE_ALLOC, a non-inline regular file with non-zero i_size and zero i_clusters is structurally malformed: the extent map declares no allocated clusters yet the size header claims content exists. Keep rejecting that shape, but express it through a shared predicate so the same invariant is available to normal inode reads and online filecheck. The same zero-cluster shape is also malformed for non-inline directories. ocfs2 directory growth allocates backing storage before advancing i_size, and ocfs2_dir_foreach_blk_el() later walks until ctx->pos reaches i_size_read(inode). A forged directory dinode with a huge i_size and no clusters would repeatedly fail on holes while advancing through the claimed size. Sparse regular files remain exempt: on sparse-alloc volumes, truncate can legitimately grow i_size without allocating clusters. System inodes and inline-data dinodes also retain their separate storage rules. Mirror the check in ocfs2_filecheck_validate_inode_block() as well. filecheck reports through its own error namespace, so malformed size/cluster state is logged as a filecheck invalid-inode result rather than via ocfs2_error(), but it must not proceed into ocfs2_populate_inode().
Medium [CVE-2026-72265] fix potential memory leak in nvidiafb_probe
In the Linux kernel, the following vulnerability has been resolved: fbdev: nvidia: fix potential memory leak in nvidiafb_probe() In nvidiafb_probe(), the memory allocated for modelist in nvidia_set_fbinfo() is not freed in the subsequent error paths. Fix that by calling fb_destroy_modelist(). A flaw was found in the Linux kernel's NVIDIA framebuffer driver. During the initialization process within the `nvidiafb_probe()` function, if certain error conditions occur, memory allocated for internal data structures is not properly released. This can lead to a memory leak, potentially affecting system stability and performance over extended periods. When nvidiafb_probe() fails on an error path after nvidia_set_fbinfo() has allocated the framebuffer mode list, that memory is not released, resulting in a small kernel memory leak per failed probe attempt. Triggering the flaw requires local access with privileges sufficient to influence driver loading, device binding, or PCI framebuffer probe conditions, and the consequence is limited to memory exhaustion (denial of service) after repeated failed probes; confidentiality and integrity are not affected. Affected products named by the advisory: Red Hat Enterprise Linux 8; Red Hat package: kernel-rt.
Medium [CVE-2026-72471] prevent potential lcn remains uninitialized
In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: prevent potential lcn remains uninitialized The target VCN being sought was not found within runs[0], causing run_lookup() to return false. This causes run_lookup_entry() to return false, which in turn results in a len value of 0, and the new parameter passed to attr_data_get_block() is NULL. Collectively, these factors ultimately cause attr_data_get_block_locked() to exit prematurely without initializing lcn, thereby triggering [1]. To prevent [1], the clen check within ni_seek_data_or_hole() has been moved to occur before the lcn check. [1] BUG: KMSAN: uninit-value in ni_seek_data_or_hole+0x24f/0x5f0 fs/ntfs3/frecord.c:2862 ni_seek_data_or_hole+0x24f/0x5f0 fs/ntfs3/frecord.c:2862 ntfs_llseek+0x22a/0x4a0 fs/ntfs3/file.c:1530 vfs_llseek fs/read_write.c:391 [inline] An uninitialized value vulnerability exists when processing NTFS3 filesystem operations. This can lead to a kernel crash, resulting in a denial of service (DoS) for the affected system. A local attacker could potentially exploit this by interacting with a specially crafted NTFS3 filesystem. A moderate impact uninitialized-value flaw was found in the NTFS3 filesystem driver in the Linux kernel.
Medium [CVE-2026-72424] fix NULL deref in shared IRQ handler at probe
In the Linux kernel, the following vulnerability has been resolved: rtc: msc313: fix NULL deref in shared IRQ handler at probe msc313_rtc_probe() calls devm_request_irq() with IRQF_SHARED and &pdev->dev as the cookie, but platform_set_drvdata() is only called later after the clock setup. With a shared IRQ line, another device on the same line can trigger the handler in that window. The handler does dev_get_drvdata() on the cookie, gets NULL, and dereferences priv->rtc_base in interrupt context. Pass priv as the cookie directly so the handler reads it from dev_id without the lookup, removing the dependency on probe order. During the probe phase, a shared Interrupt Request (IRQ) handler could be triggered by another device before the necessary driver data was fully initialized. This could lead to a null pointer dereference, where the system attempts to access an invalid memory location. A local attacker could potentially exploit this to cause a system crash, leading to a denial of service. A low impact flaw was found in the Linux kernel MStar MSC313 RTC driver. Red Hat rates the impact of this flaw as low because triggering it requires a narrow probe-time race on hardware where this RTC device shares its interrupt line with another device, even though the Red Hat CVSS 3.1 base score is 5.5.
Medium [CVE-2026-72215] Ensure 32-bit stack location for o32 prom_printf
In the Linux kernel, the following vulnerability has been resolved: MIPS: DEC: Ensure 32-bit stack location for o32 prom_printf() In 64-bit configurations calling any firmware entry points from a kernel thread other than the initial one will result in a situation where the stack has been placed in the XKPHYS 64-bit memory segment. Consequently the stack pointer is no longer a 32-bit value and when the 32-bit firmware code called uses 32-bit ALU operations to manipulate the stack pointer, the calculated result is incorrect (in fact in the 64-bit MIPS ISA almost all 32-bit ALU operations will produce an unpredictable result when executed on 64-bit data) and control goes astray. This may happen when no final console driver has been enabled in the configuration and consequently the initial console continues being used late into bootstrap, or with an upcoming change that will switch the zs driver to use a platform device, which in turn will make the console handover happen only after other kernel threads have already been started, and the kernel will hang at: pid_max: default: 32768 minimum: 301 or somewhat later, but always before: cblist_init_generic: Setting adjustable number of callback queues. has been printed. It seems that only the prom_printf() entry point is affected.
Medium [CVE-2026-72307] fix refcount leak in mlxsw_sp_vrs_lpm_tree_replace
In the Linux kernel, the following vulnerability has been resolved: mlxsw: fix refcount leak in mlxsw_sp_vrs_lpm_tree_replace() When mlxsw_sp_vrs_lpm_tree_replace() fails after replacing some VRs, the error rollback loop does not correctly revert the preceding replacements. The loop decrements the index but fails to update the vr pointer, which still points to the VR that caused the failure. As a result, the condition and the rollback call always operate on the same VR, potentially calling mlxsw_sp_vr_lpm_tree_replace() multiple times on it while never rolling back the earlier VRs. Those VRs continue to hold a reference to new_tree acquired via mlxsw_sp_lpm_tree_hold(), leaking the reference count of new_tree. Fix by reinitializing vr inside the error loop with the updated index: vr = &mlxsw_sp->router->vrs[i]; so that the loop correctly iterates over all VRs that were actually replaced. When the `mlxsw_sp_vrs_lpm_tree_replace()` function encounters an error during Virtual Router (VR) replacement operations, its rollback mechanism fails to correctly release resources. This leads to a reference count leak, where system resources are not properly deallocated. Over time, this resource exhaustion could potentially result in a denial of service (DoS) condition, 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).
Medium [CVE-2026-72172] fix uninitialized struct pages for ZONE_DEVICE
In the Linux kernel, the following vulnerability has been resolved: mm/mm_init: fix uninitialized struct pages for ZONE_DEVICE If DAX memory is hotplugged into an unoccupied subsection of an early section, section_activate() reuses the unoptimized boot memmap. However, compound_nr_pages() still assumes that vmemmap optimization is in effect and initializes only the reduced number of struct pages. As a result, the remaining tail struct pages are left uninitialized, which can later lead to unexpected behavior or crashes. Fix this by treating early sections as unoptimized when calculating how many struct pages to initialize. When Direct Access (DAX) memory is hotplugged, certain internal memory structures (`struct pages`) may not be fully initialized. This uninitialized state can lead to unexpected system behavior or crashes, potentially resulting in 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-908. Affected Red Hat products: Red Hat Enterprise Linux 10; Red Hat Enterprise Linux 6; 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-72177] fix dir put orders in access_pattern_add_dirs
In the Linux kernel, the following vulnerability has been resolved: mm/damon/sysfs-schemes: fix dir put orders in access_pattern_add_dirs() Patch series "mm/damon/sysfs-schemes: fix wrong directories put orders in error paths". Error paths of damon_sysfs_access_pattern_add_dirs() and damon_sysfs_scheme_add_dirs() functions put references to directories in wrong orders. As a result, uninitialized memory dereference and/or memory leak can happen. Fix those. This patch (of 2): In access_pattern_add_dirs(), error handling path puts references starting from setup failed directories. If the failure happpened from the initial allication in the setup functions, uninitialized memory dereference happen. The allocation failures will not commonly happen, but the consequence is quite bad. The issue was discovered [1] by Sashiko. A flaw was found in the Linux kernel's memory management subsystem (DAMON). This vulnerability could potentially cause system instability or unauthorized 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-824. 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-72166] fix infinite loop in p9_client_rpc on fatal signal
In the Linux kernel, the following vulnerability has been resolved: net/9p: fix infinite loop in p9_client_rpc on fatal signal When p9_client_rpc() is called with type P9_TFLUSH and the transport has no peer (e.g. fd transport backed by pipes with no 9p server), a fatal signal causes an infinite loop: again: err = io_wait_event_killable(req->wq,...) /* SIGKILL wakes the task, returns -ERESTARTSYS */ if (err == -ERESTARTSYS && c->status == Connected && type == P9_TFLUSH) { sigpending = 1; clear_thread_flag(TIF_SIGPENDING); goto again; } clear_thread_flag() clears TIF_SIGPENDING before jumping back to io_wait_event_killable(). signal_pending_state() checks TIF_SIGPENDING, finds it zero, and the task goes to sleep again. The task can only wake on the next signal delivery that calls signal_wake_up() and sets TIF_SIGPENDING again. When that happens the loop repeats, clears TIF_SIGPENDING, and sleeps again indefinitely. This is triggered in practice by coredump_wait(): when a thread in a multi-threaded process causes a coredump (e.g. via SIGSYS from Syscall User Dispatch), coredump_wait() sends SIGKILL to all other threads and waits for them to call mm_release(). Affected products named by the advisory: Red Hat Enterprise Linux 6; Red Hat package: kernel.
Medium [CVE-2026-72170] skip nlink update in cacheless mode to fix WARN_ON
In the Linux kernel, the following vulnerability has been resolved: 9p: skip nlink update in cacheless mode to fix WARN_ON v9fs_dec_count() unconditionally calls drop_nlink() on regular files, even when the inode's nlink is already zero. In cacheless mode the client refetches inode metadata from the server (the source of truth) on every operation, so by the time v9fs_remove() returns, the locally cached nlink may already reflect the post-unlink value: 1. Client initiates unlink, server processes it and sets nlink to 0 2. Client's v9fs_remove() completes successfully 4. Client calls v9fs_dec_count() which calls drop_nlink() on nlink=0 This race is easily triggered under heavy unlink workloads, such as stress-ng's unlink stressor, producing the following warning: WARNING: fs/inode.c:417 at drop_nlink+0x4c/0xc8 Call trace: drop_nlink+0x4c/0xc8 v9fs_remove+0x1e0/0x250 [9p] v9fs_vfs_unlink+0x20/0x38 [9p] vfs_unlink+0x13c/0x258... In cacheless mode the server is authoritative and the inode is on its way out, so locally adjusting nlink buys nothing. Skip v9fs_dec_count() entirely when neither CACHE_META nor CACHE_LOOSE is set, which both avoids the warning and removes a class of nlink races (two concurrent unlinkers observing nlink > 0 and both calling drop_nlink()) that an nlink == 0 guard alone would only narrow rather than close.
Medium [CVE-2026-72258] Release reserved memory on cleanup
In the Linux kernel, the following vulnerability has been resolved: ASoC: mediatek: mt8183: Release reserved memory on cleanup The MT8183 AFE probe can assign reserved memory with of_reserved_mem_device_init(), but the assignment is never released on driver removal or later probe failures. Register a devm cleanup action so the reserved memory assignment is released consistently, matching newer Mediatek AFE drivers. A flaw was found in the Linux kernel's Advanced Linux Sound Architecture System on Chip (ASoC) Mediatek MT8183 audio driver. The Audio Front End (AFE) probe assigns reserved memory but does not release it when the driver is removed or if probe failures occur. This oversight can lead to a memory leak, potentially causing 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 10. Red Hat does not currently list a fixing RHSA for this CVE. Affected products named by the advisory: Red Hat package: kernel.