Red Hat Linux Security Advisories & CVEs
6006 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-64155] fix error path leaks in some WMI WOW calls
In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: fix error path leaks in some WMI WOW calls Fix two instances where we used to directly return the result of ath11k_wmi_cmd_send(...). Because we did not check the return value, we also did not free the skb in the error path. This vulnerability is caused by improper error handling in certain Wireless Management Interface (WMI) Wake-on-Wireless (WOW) calls. Specifically, the ath11k_wmi_cmd_send function did not properly free socket buffers (skb) in error paths, leading to a resource leak. This resource leak could potentially lead to system instability or a denial of service. Red Hat severity: Low — CVSS 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H). Weakness: CWE-772. Affected Red Hat products: Red Hat Enterprise Linux 10; Red Hat Enterprise Linux 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.
Medium [CVE-2026-64133] Fix potential OOB array access at reading cache
In the Linux kernel, the following vulnerability has been resolved: ALSA: asihpi: Fix potential OOB array access at reading cache find_control() to retrieve a cached info accesses the array with the given index blindly, which may lead to an OOB array access. Add a sanity check for avoiding it. A flaw was found in the Linux kernel, specifically within the Advanced Linux Sound Architecture (ALSA) asihpi component. This vulnerability occurs because a function designed to retrieve cached information does not properly check the boundaries of an array it is accessing. This oversight could allow a local attacker to access memory outside of its intended limits, potentially leading to system instability (denial of service) or, in some cases, unauthorized privilege escalation. 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 7; 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.
Medium [CVE-2026-64106] Reject restored DTE with out-of-range num_eventid_bits
In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: vgic-its: Reject restored DTE with out-of-range num_eventid_bits Userspace can restore an ITS Device Table Entry whose Size field encodes more EventID bits than the virtual ITS supports. The live MAPD path rejects that state, but vgic_its_restore_dte() accepts it and stores the out-of-range value in dev->num_eventid_bits. Reject restored DTEs with num_eventid_bits > VITS_TYPER_IDBITS before allocating the device. This mirrors the MAPD check and prevents the restored state from reaching vgic_its_restore_itt(), where the unchecked value can be converted into an oversized scan_its_table() range. A flaw was found in the Linux kernel's Kernel-based Virtual Machine (KVM) for arm64 architecture, specifically within the virtual Generic Interrupt Controller (vgic-its) module. This unchecked value can lead to an oversized scan of the ITS table, potentially causing 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-805. 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.
Medium [CVE-2026-64062] Fix potential deadlock in write-through mode
In the Linux kernel, the following vulnerability has been resolved: netfs: Fix potential deadlock in write-through mode Fix netfs_advance_writethrough() to always unlock the supplied folio and to mark it dirty if it isn't yet written to the end. Unfortunately, it can't be marked for writeback until the folio is done with as that may cause a deadlock against mmapped reads and writes. Even though it has been marked dirty, premature writeback can't occur as the caller is holding both inode->i_rwsem (which will prevent concurrent truncation, fallocation, DIO and other writes) and ictx->wb_lock (which will cause flushing to wait and writeback to skip or wait). Note that this may be easier to deal with once the queuing of folios is split from the generation of subrequests. A flaw was found in the Linux kernel's network filesystem (netfs) component. Specifically, a vulnerability in the netfs_advance_writethrough() function, when operating in write-through mode, can lead to a system deadlock. This occurs because the function may not consistently unlock memory pages (folios) or mark them as modified, preventing proper writeback operations. Consequently, concurrent memory-mapped (mmapped) read and write operations can cause the system to become 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.
Medium [CVE-2026-64170] fix error pointer deref after DMA setup failure
In the Linux kernel, the following vulnerability has been resolved: spi: qup: fix error pointer deref after DMA setup failure The driver falls back to PIO mode if DMA setup fails during probe. Make sure to the clear the DMA channel pointers on setup failure to avoid dereferencing an error pointer (or attempting to release a channel a second time) on later probe errors or driver unbind. This issue was flagged by Sashiko when reviewing a devres allocation conversion patch. A flaw was found in the Linux kernel's Serial Peripheral Interface (SPI) Qualcomm Universal Peripheral (QUP) driver. When the Direct Memory Access (DMA) setup fails during the driver's initialization, the driver attempts to fall back to Programmed Input/Output (PIO) mode. However, it fails to properly clear the DMA channel pointers, which could lead to dereferencing an invalid memory address. This could result in system instability or a denial of service, making the system unresponsive to legitimate requests. 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 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.
Medium [CVE-2026-64097] Validate GPIO pin LUT table size before iterating
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Validate GPIO pin LUT table size before iterating [Why&How] The GPIO pin table parsers in get_gpio_i2c_info() and bios_parser_get_gpio_pin_info() derive an element count from the VBIOS table_header.structuresize field, then iterate over gpio_pin[] entries. However, GET_IMAGE() only validates that the table header itself fits within the BIOS image. If the VBIOS reports a structuresize larger than the actual mapped data, the loop reads past the end of the BIOS image, causing an out-of-bounds read. Fix this by calling bios_get_image() to validate that the full claimed structuresize is accessible within the BIOS image before entering the loop in both functions. (cherry picked from commit ba5e95b43b773ae1bf1f66ee6b31eb774e65afe3) This vulnerability is caused by improper validation of the GPIO (General Purpose Input/Output) pin table size. An attacker could exploit this by providing a malformed Video BIOS (VBIOS) that leads to reading data beyond its intended memory boundary, potentially causing information disclosure or system instability. 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.
Medium [CVE-2026-64070] fix preempt count leak in sysfs show paths
In the Linux kernel, the following vulnerability has been resolved: powerpc/hv-gpci: fix preempt count leak in sysfs show paths Four sysfs show() callbacks in hv-gpci take get_cpu_var(hv_gpci_reqb) (which calls preempt_disable()) but only call the matching put_cpu_var() on the error path under the 'out:' label. Every successful read leaks one preempt_disable(): processor_bus_topology_show() processor_config_show() affinity_domain_via_virtual_processor_show() affinity_domain_via_domain_show() (affinity_domain_via_partition_show() was already correct.) On a CONFIG_PREEMPT=y kernel, repeated reads raise preempt_count and eventually return to userspace with preemption still disabled. The next user-mode page fault then hits faulthandler_disabled() == 1, gets forced to SIGSEGV, and the resulting coredump trips 'BUG: scheduling while atomic' in call_usermodehelper_exec -> wait_for_completion_state -> schedule: BUG: scheduling while atomic: //0x00000004... __schedule_bug+0x6c/0x90 __schedule+0x58c/0x13a0 schedule+0x48/0x1a0 schedule_timeout+0x104/0x170 wait_for_completion_state+0x16c/0x330 call_usermodehelper_exec+0x254/0x2d0 vfs_coredump+0x1050/0x2590 get_signal+0xb9c/0xc80 do_notify_resume+0xf8/0x470 Add an out_success label that calls put_cpu_var() before returning the byte count, mirroring affinity_domain_via_partition_show().
Medium [CVE-2026-64094] avoid NULL-ptr deref for claim via dropped interface
In the Linux kernel, the following vulnerability has been resolved: batman-adv: bla: avoid NULL-ptr deref for claim via dropped interface Without rtnl_lock held, a hardif might be retrieved as primary interface of a meshif, but then (while operating on this interface) getting decoupled from the mesh interface. In this case, the meshif still exists but the pointer from the primary hardif to the meshif is set to NULL. The mesh_iface must be checked first to be non-NULL before continuing to send an ARP request using meshif. A flaw was found in the Linux kernel's batman-adv (Better Approach To Mobile Ad-hoc Networking - Advanced) component, specifically within its Bridge Loop Avoidance (BLA) feature. This vulnerability occurs when a network interface is unexpectedly removed while the system attempts to send an Address Resolution Protocol (ARP) request. This can lead to a null-pointer dereference, which may cause the system to crash, resulting in a denial of service. 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. 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-64156] netfs, afs: Fix write skipping in dir/link writepages
In the Linux kernel, the following vulnerability has been resolved: netfs, afs: Fix write skipping in dir/link writepages Fix netfs_write_single() and afs_single_writepages() to better handle a write that would be skipped due to lock contention and WB_SYNC_NONE by returning 1 from netfs_write_single() if it skipped and making afs_single_writepages() skip also. If a skip occurs, the inode must be re-marked as the VFS may have cleared the mark. This is really only theoretical for directories in netfs_write_single() as the only path to that is through afs_single_writepages() that takes the ->validate_lock around it, thereby serialising it. A flaw was found in the Linux kernel's network file system (netfs) and AFS (Andrew File System) components. When a write operation is skipped due to lock contention and a specific writeback control flag (WB_SYNC_NONE), the system may fail to correctly re-mark the inode, which is a data structure that stores information about a file or directory. While currently considered theoretical for directories, this could potentially lead to data inconsistency or other unexpected behavior within the file 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-367. Affected Red Hat products: Red Hat Enterprise Linux 10. Red Hat does not currently list a fixing RHSA for this CVE.
Medium [CVE-2026-64116] add NULL check for idev in ipv6_hop_ioam
In the Linux kernel, the following vulnerability has been resolved: ipv6: ioam: add NULL check for idev in ipv6_hop_ioam() Reported by Sashiko: The function ipv6_hop_ioam() accesses __in6_dev_get(skb->dev)->cnf.ioam6_enabled without validating the returned idev pointer. Because addrconf_ifdown() can concurrently clear dev->ip6_ptr via RCU, __in6_dev_get() can return NULL during interface teardown, which could cause a NULL pointer dereference when processing an IOAM Hop-by-Hop option. Let's add a check and use SKB_DROP_REASON_IPV6DISABLED accordingly. A flaw was found in the Linux kernel's IPv6 In-situ Operations, Administration, and Maintenance (IOAM) module. This vulnerability allows a remote attacker to cause a system crash, leading to a Denial of Service (DoS). The flaw occurs because the `ipv6_hop_ioam()` function does not properly validate a pointer during IPv6 interface teardown, which can result in a NULL pointer dereference when processing an IOAM Hop-by-Hop option. 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; 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. Affected products named by the advisory: Red Hat package: kernel.
Medium [CVE-2026-64127] send packed pdu, not stack pointer
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: ecred_reconfigure: send packed pdu, not stack pointer Commit 1c08108f3014 ("Bluetooth: L2CAP: Avoid -Wflex-array-member-not-at-end warnings") converted the on-stack request PDU in l2cap_ecred_reconfigure() from an explicit packed struct to DEFINE_RAW_FLEX(), but did not adjust the size and source-pointer arguments to l2cap_send_cmd(): - struct { - struct l2cap_ecred_reconf_req req; - __le16 scid; - } pdu; + DEFINE_RAW_FLEX(struct l2cap_ecred_reconf_req, pdu, scid, 1);... l2cap_send_cmd(conn, chan->ident, L2CAP_ECRED_RECONF_REQ, sizeof(pdu), &pdu); After the conversion, DEFINE_RAW_FLEX() expands to declare an anonymous union pdu_u plus a local pointer "pdu" pointing at it. Therefore: - sizeof(pdu) is now sizeof(struct l2cap_ecred_reconf_req *) = 8 on 64-bit (4 on 32-bit), not the 6 bytes of (mtu, mps, scid[1]). - &pdu is the address of the local pointer's stack storage, not the address of the request payload. l2cap_send_cmd() forwards (data, count) to l2cap_build_cmd(), which calls skb_put_data(skb, data, count). The L2CAP_ECRED_RECONFIGURE_REQ packet body therefore contains 8 bytes copied from the kernel stack starting at &pdu -- the 8 bytes overlap the pdu pointer's value, leaking a kernel stack address to the paired Bluetooth peer.
Medium [CVE-2026-64183] Allocate runtime workqueue before ACPI init
In the Linux kernel, the following vulnerability has been resolved: efi: Allocate runtime workqueue before ACPI init Since commit 5894cf571e14 ("acpi/prmt: Use EFI runtime sandbox to invoke PRM handlers") ACPI PRM calls are delegated to a workqueue which runs in a kernel thread, making it easier to detect and mitigate faulting memory accesses performed by the firmware. Rafael reports that such PRM accesses may occur before efisubsys_init() executes, which is where the workqueue is allocated, leading to NULL pointer dereferences. Since acpi_init() [which triggers the early PRM accesses] executes as a subsys_initcall() as well, and has its own dependencies that may be sensitive to initcall ordering, deferring acpi_init() is not an option. So instead, split off the workqueue allocation into its own postcore initcall, as this is the only missing piece to allow EFI runtime calls to be made. This ensures that EFI runtime call (including PRM calls) are accessible to all code running at subsys_initcall() level. This vulnerability occurs due to a NULL pointer dereference when ACPI (Advanced Configuration and Power Interface) PRM (Platform Runtime Mechanism) calls are made before the necessary workqueue is allocated. This can lead to system instability or crashes, resulting in a denial of service. 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-64077] move to two-stage removal scheme
In the Linux kernel, the following vulnerability has been resolved: netfilter: ebtables: move to two-stage removal scheme Like previous patches for x_tables, follow same pattern in ebtables. We can't reuse xt helpers: ebt_table struct layout is incompatible. table->ops assignment is now done while still holding the ebt mutex to make sure we never expose partially-filled table struct. A concurrency issue exists during the two-stage removal scheme where the `table->ops` assignment could expose a partially-filled table structure if the `ebt` mutex is not held. This could lead to unpredictable system behavior. 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-413. Affected Red Hat products: Red Hat Enterprise Linux 10; 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. Affected products named by the advisory: Red Hat package: kernel.
Medium [CVE-2026-64072] fix bio leak on mapping failure
In the Linux kernel, the following vulnerability has been resolved: nvme: fix bio leak on mapping failure The local bio is always NULL, so we'd leak the bio if the integrity mapping failed. Just get it directly from the request. A flaw was found in the Linux kernel's Non-Volatile Memory Express (NVMe) subsystem. This vulnerability occurs when an integrity mapping fails, leading to a 'bio' (block I/O) leak. This resource leak can potentially lead to a denial of service (DoS) due to resource exhaustion. Red Hat severity: Low — CVSS 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H). Weakness: CWE-772. Affected Red Hat products: Red Hat Enterprise Linux 10. Red Hat does not currently list a fixing RHSA for this CVE. Affected products named by the advisory: Red Hat package: kernel.
Medium [CVE-2026-53370] Improve validation and configuration of ACR masks
In the Linux kernel, the following vulnerability has been resolved: perf/x86/intel: Improve validation and configuration of ACR masks Currently there are several issues on the user space ACR mask validation and configuration. - The validation for user space ACR mask (attr.config2) is incomplete, e.g., the ACR mask could include the index which belongs to another ACR events group, but it's not validated. - An early return on an invalid ACR mask caused all subsequent ACR groups to be skipped. - The stale hardware ACR mask (hw.config1) is not cleared before setting new hardware ACR mask. The following changes address all of the above issues. - Figure out the event index group of an ACR group. Any bits in the user-space mask not present in the index group are now dropped. - Instead of an early return on invalid bits, drop only the invalid portions and continue iterating through all ACR events to ensure full configuration. - Explicitly clear the stale hardware ACR mask for each event prior to writing the new configuration. Besides, a non-leader event member of ACR group could be disabled in theory. This could cause bit-shifting errors in the acr_mask of remaining group members. But since ACR sampling requires all events to be active, this should not be a big concern in real use case. Add a "FIXME" comment to notice this risk.
Medium [CVE-2026-53367] fix avdcache auditing
In the Linux kernel, the following vulnerability has been resolved: selinux: fix avdcache auditing The per-task avdcache was incorrectly saving and reusing the audited vector computed by avc_audit_required() rather than recomputing based on the currently requested permissions and distinguishing the denied versus allowed cases. As a result, some permission checks were not being audited, e.g. directory write checks after a previously cached directory search check. [PM: line wrap tweaks] This prevented some critical security permission checks, such as directory write operations, from being properly audited. As a result, an attacker could potentially perform actions without them being recorded in the system's audit logs, leading to a security bypass of auditing mechanisms. 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-778. 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. Affected products named by the advisory: Red Hat package: kernel.
Medium [CVE-2026-53372] Block PASID attachment to nested domain with dirty tracking
In the Linux kernel, the following vulnerability has been resolved: iommu/vt-d: Block PASID attachment to nested domain with dirty tracking Kernel lacks dirty tracking support on nested domain attached to PASID, fails the attachment early if nesting parent domain is dirty tracking configured, otherwise dirty pages would be lost. A flaw was found in the Linux kernel's Input/Output Memory Management Unit (IOMMU) subsystem. This vulnerability arises in virtualized environments when a nested domain attempts to attach to a Process Address Space ID (PASID), a mechanism for devices to access memory, while its parent domain is configured for dirty page tracking. The kernel lacks proper dirty tracking support for the nested domain in this scenario, leading to a failure in attachment and the potential loss of dirty pages. This can result in data integrity issues or system instability within the virtualized environment. 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-820. 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-53369] reject descriptors with oversized CRC length
In the Linux kernel, the following vulnerability has been resolved: udf: reject descriptors with oversized CRC length udf_read_tagged() skips CRC verification when descCRCLength + sizeof(struct tag) exceeds the block size. A crafted UDF image can set descCRCLength to an oversized value to bypass CRC validation entirely; the descriptor is then accepted based solely on the 8-bit tag checksum, which is trivially recomputable. Reject such descriptors instead of silently accepting them. A legitimate single-block descriptor should never have a CRC length that exceeds the block. A flaw was found in the Linux kernel's Universal Disk Format (UDF) filesystem. A remote attacker could craft a malicious UDF image with an oversized Cyclic Redundancy Check (CRC) length. This could allow the attacker to bypass the integrity validation of UDF descriptors, leading to the acceptance of potentially corrupted or malicious data based on a weak checksum. 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-354. 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.
Medium [CVE-2026-53371] bound node_desc sysfs read with %.64s
In the Linux kernel, the following vulnerability has been resolved: RDMA/ionic: bound node_desc sysfs read with %.64s node_desc[64] in struct ib_device is not guaranteed to be NUL- terminated. The core IB sysfs handler uses "%.64s" for exactly this reason (drivers/infiniband/core/sysfs.c:1307), since node_desc_store() performs a raw memcpy of up to IB_DEVICE_NODE_DESC_MAX bytes with no NUL termination: memcpy(desc.node_desc, buf, min_t(int, count, IB_DEVICE_NODE_DESC_MAX)); If exactly 64 bytes are written via the node_desc sysfs file, the array contains no NUL byte. The ionic hca_type_show() handler uses unbounded "%s" and will read past the end of node_desc into adjacent fields of struct ib_device until it encounters a NUL. ionic supports IB_DEVICE_MODIFY_NODE_DESC, so this is triggerable by userspace. Match the core handler and bound the format specifier. A flaw was found in the Linux kernel's ionic Remote Direct Memory Access (RDMA) driver. A local user can exploit this vulnerability due to an unbounded read operation when displaying the `node_desc` sysfs file. If the `node_desc` field is not null-terminated, the system will read beyond its allocated buffer, potentially exposing sensitive information from adjacent memory regions within the `ib_device` structure. 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.
Medium [CVE-2026-53373] do not try to unmap a VMA if mmap_prepare invoked from mmap
In the Linux kernel, the following vulnerability has been resolved: mm/vma: do not try to unmap a VMA if mmap_prepare() invoked from mmap() The mmap_prepare hook functionality includes the ability to invoke mmap_prepare() from the mmap() hook of existing 'stacked' drivers, that is ones which are capable of calling the mmap hooks of other drivers/file systems (e.g. overlayfs, shm). As part of the mmap_prepare action functionality, we deal with errors by unmapping the VMA should one arise. This works in the usual mmap_prepare case, as we invoke this action at the last moment, when the VMA is established in the maple tree. However, the mmap() hook passes a not-fully-established VMA pointer to the caller (which is the motivation behind the mmap_prepare() work), which is detached. So attempting to unmap a VMA in this state will be problematic, with the most obvious symptom being a warning in vma_mark_detached(), because the VMA is already detached. It's also unncessary - the mmap() handler will clean up the VMA on error. So to fix this issue, this patch propagates whether or not an mmap action is being completed via the compatibility layer or directly. If the former, then we do not attempt VMA cleanup, if the latter, then we do. This patch also updates the userland VMA tests to reflect the change. A flaw was found in the Linux kernel's memory management (mm/vma) component.