Red Hat Linux Security Advisories &amp; CVEs

Aug 17, 2026

High8.1Red Hat

High [CVE-2026-19693] Arbitrary file write via symlink in archive

extract-zip through 2.0.1 containment-checks only the parent directory of each archive entry and never the entry's own final path component, so an archive containing two entries with identical names - a symlink whose target is outside the destination, followed by a regular file - writes through the planted symlink and yields an arbitrary file write outside the destination directory. By crafting a malicious zip archive containing a symbolic link (symlink) and a regular file with the same name, the attacker can bypass security checks. The extract-zip utility incorrectly validates only the parent directory, enabling the attacker to write files to arbitrary locations on the system. The flaw arises from insufficient validation of archive entries, allowing a remote attacker to write files to arbitrary locations on the system by providing a specially crafted zip archive. This requires user interaction to extract the malicious archive, but successful exploitation could lead to significant system integrity and availability compromise. Red Hat severity: Important — CVSS 8.1 (CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:H). Weakness: CWE-59. Affected products named by the advisory: Node HealthCheck Operator; OpenShift Pipelines; Red Hat Build of Podman Desktop; Red Hat Ceph Storage 4; and 6 more.

CVE-2026-19693

High7.9Vendor: MediumRed Hat

Aug 17, 2026

High [CVE-2026-15218] maas-api and maas-controller ServiceAccounts with excessive permissions lead to privilege escalation

A flaw was found in the maas-api and maas-controller ServiceAccounts within Red Hat OpenShift AI. These ServiceAccounts are granted cluster-wide permissions that exceed their operational requirements. An attacker who compromises the identity of these ServiceAccounts, either through a remote code execution vulnerability or by creating a malicious pod in the same namespace, could exploit these excessive permissions. This could lead to full cluster administrator privileges through the creation of new ClusterRoleBindings or the disclosure of sensitive information by accessing all secrets across the cluster. Although exploitation necessitates a prior compromise of a pod or the ability to create pods in the respective namespaces, a successful attack could result in privilege escalation to cluster-admin or the unauthorized exfiltration of cluster-wide secrets. Red Hat severity: Moderate — CVSS 7.9 (CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:C/C:H/I:H/A:L). Weakness: CWE-266. Affected Red Hat products: Red Hat OpenShift AI 3.4; Red Hat OpenShift AI (RHOAI). Red Hat fixing advisory: RHSA-2026:60520.

High [CVE-2026-73194] DBI for Perl: Heap out-of-bounds write via unvalidated numeric placeholder

DBI versions before 1.652 for Perl allow a heap out-of-bounds write via an unvalidated numeric placeholder that sets the binder counter in preparse. preparse reserves seven output bytes per input byte, the width of the longest ':p99999' expansion. The ':N' branch parses the number with `atoi(src)` and assigns it to the binder counter with no range check, so a statement containing ':2147483648' leaves the counter negative (-2147483648 with glibc, where atoi wraps). Each following '?' then expands through `sprintf(start, ":p%d", idx++)` to ':p-2147483648', 14 bytes with the terminating NUL where the buffer budgets 7. The placeholder limit added in 1.650 tests the counter against 99,999, which a negative counter passes. Any caller that preparses an untrusted statement into ':pN' style placeholders gets a heap out-of-bounds write that grows with the number of '?' marks following the poisoned placeholder. The '?' and '%s' return styles compare the parsed number against the expected sequence and error out, and are unaffected. When processing an untrusted statement, a specially crafted numeric placeholder can cause the binder counter to become negative. This results in subsequent placeholders expanding beyond their allocated buffer, leading to memory corruption. An attacker could exploit this to potentially achieve arbitrary code execution or cause a denial of service.

CVE-2026-73194

High7.8Red Hat

High [CVE-2026-73193] Arbitrary Code Execution on 32-bit Perl via Integer Wraparound

DBI versions before 1.652 for Perl allow a heap out-of-bounds write on 32-bit perl via an integer wraparound in the output buffer size computed by preparse. preparse reserves its output buffer with `newSV(strlen(statement) * 7 + 16)`, budgeting seven output bytes per input byte for the longest ':p99999' expansion. The product is computed in STRLEN, which is 32 bits wide on a 32-bit perl build, so a statement of 613,566,757 bytes multiplies to 4,294,967,299, wraps modulo 2^32 to 3, and reserves 19 bytes. The parser then copies the statement out through a raw pointer with no capacity check, writing the whole 585 MB input past the end of the allocation. The 99,999 placeholder limit does not bound this path, which is reached by ordinary non-placeholder content. Any caller that passes an untrusted statement of that length to preparse on a 32-bit perl gets a heap out-of-bounds write of attacker controlled bytes. Builds with a 64-bit STRLEN are not affected, since the wrap there needs a statement of about 2.3 exabytes. A flaw was found in DBI. A remote attacker can exploit this by providing a specially crafted, excessively large statement. This can lead to a heap out-of-bounds write, potentially allowing the attacker to execute arbitrary code or cause a denial of service. Red Hat severity: Important — CVSS 7.8 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H). Weakness: CWE-787.

CVE-2026-73193

High7.5Red Hat

High [CVE-2026-73635] Denial of Service via unbounded localized-text caches

Allocation of resources without limits or throttling vulnerability in Apache Struts. When no fixed locale is configured, the locale used for localized-text lookups is taken from the incoming request, allowing an unauthenticated remote client to cause the framework's internal localized-text caches to grow without bound and exhaust the Java heap, denying service to other users. Applications that configure a fixed locale are not affected. Users are recommended to upgrade to version 6.11.0 or 7.3.0, which fixes the issue. This can lead to the exhaustion of Java heap memory, resulting in a Denial of Service (DoS) for other users. An uncontrolled resource consumption flaw exists in the Apache Struts localized-text lookup caching mechanism. An unauthenticated remote attacker can exploit this by streaming requests with arbitrary, unique locale parameters, exhausting JVM heap space and causing a denial of service. The impact is limited to process availability. Red Hat severity: Important — CVSS 7.5 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H). Weakness: CWE-770. Red Hat lists Red Hat Enterprise Linux 10; Red Hat Enterprise Linux 8; Red Hat Enterprise Linux 9; Red Hat Fuse 7 as not affected.

CVE-2026-73635

Unclassified

High [CVE-2026-72310] fix overflow in passthrough ioctl bounds check

In the Linux kernel, the following vulnerability has been resolved: smb: client: fix overflow in passthrough ioctl bounds check smb2_ioctl_query_info() validates the PASSTHRU_FSCTL response payload before copying it to userspace. The payload offset and length both come from 32-bit fields. The bounds check currently adds OutputOffset and qi.input_buffer_length directly, so the addition can wrap in 32-bit arithmetic before the result is compared against the response buffer length. A malicious server can use a large OutputOffset and a small OutputCount to make the wrapped sum pass the bounds check. The later copy_to_user() then reads from io_rsp + OutputOffset, outside the response buffer. Use size_add() for the offset plus length check so overflow is treated as out of bounds. By sending a specially crafted response with a large offset, the server can cause the client to read data beyond the allocated buffer. This out-of-bounds read could lead to information disclosure from the kernel memory. Red Hat severity: Moderate — CVSS 7 (CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H). Weakness: CWE-125. 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.

High [CVE-2026-72042] Fix user refcount underflow in event delivery

In the Linux kernel, the following vulnerability has been resolved: ipmi: Fix user refcount underflow in event delivery ipmi_alloc_recv_msg(user) takes the temporary user reference owned by the receive message, and ipmi_free_recv_msg() drops it again. If event delivery fails after allocating receive messages for earlier users, handle_read_event_rsp() rolls those messages back with ipmi_free_recv_msg(). That rollback path still drops user->refcount explicitly after freeing each message. The extra put can free a user that remains linked on intf->users, so later event delivery may dereference a freed user or trip refcount_t's addition-on-zero warning when ipmi_alloc_recv_msg() tries to acquire another reference. Remove the stale explicit put and the now-dead user assignment. Keep the list_del() and ipmi_free_recv_msg() calls; they are the required rollback operations. A flaw was found in the Linux kernel's Intelligent Platform Management Interface (IPMI) subsystem. An issue in the event delivery mechanism, specifically a reference count underflow, can lead to a use-after-free vulnerability. This occurs when a user's reference count is prematurely decremented during event delivery rollback, allowing for the potential dereferencing of freed memory. This could result in system instability or a denial of service.

CVE-2026-72042

Unclassified

High [CVE-2026-72069] Fix the incorrect RCU protection in rt_spin_unlock

In the Linux kernel, the following vulnerability has been resolved: locking/rt: Fix the incorrect RCU protection in rt_spin_unlock() rt_spin_unlock() releases the RCU protection before unlocking the lock. That opens the door for the following UAF scenario: T1T2 spin_lock(&p->lock);rcu_read_lock(); invalidate(p);p = rcu_dereference(ptr); rcu_assign_pointer(ptr, NULL);if (!p) return; spin_unlock(&p->lock);spin_lock(&p->lock) lock(&lock->lock); rcu_read_lock(); kfree_rcu(p);rcu_read_unlock();.... spin_unlock(&p->lock) rcu_read_unlock(); // Ends grace period rcu_do_batch() kfree(p); UAF -> rt_mutex_cmpxchg_release(&lock->lock...) Regular spinlocks keep preemption disabled accross the unlock operation, which provides full RCU protection, but the RT substitution fails to resemble that. Same applies for the rwlock substitution. Move the rcu_read_unlock() invocation past the unlock operations to match the non-RT semantics. This makes it asymmetric vs. rt_xxx_lock(), but that's harmless as the caller needs to hold RCU read lock across the lock operation. The migrate_enable() call stays before the unlock operation because there is no per CPU operation in the unlock path which would require migration to be kept disabled. Affected products named by the advisory: Red Hat Enterprise Linux 10; Red Hat Enterprise Linux 9; Red Hat package: kernel-rt.

High [CVE-2026-72220] harden rq_procinfo lifecycle to prevent double-free

In the Linux kernel, the following vulnerability has been resolved: sunrpc: harden rq_procinfo lifecycle to prevent double-free The svc_release_rqst() function executes the callback inside rqstp->rq_procinfo->pc_release. However, if a worker thread begins processing a new request and encounters an early error path (e.g., unsupported protocol, short frame, or bad auth) before a valid rq_procinfo is installed, a stale release hook can be re-triggered against reused state from the previous RPC, resulting in a double-free or use-after-free vulnerability. Ensuring svc_release_rqst() always clears rq_procinfo after the optional pc_release() call, regardless of whether the hook exists. 2. Explicitly clearing rq_procinfo at request entry in svc_process() before any early decode or drop paths. 3. Ensuring svc_process_bc() does the same at backchannel entry. This guarantees that error flows will not encounter a non-NULL stale rq_procinfo pointer when there is nothing to release. This can lead to a double-free or use-after-free vulnerability, potentially allowing an attacker to cause a denial of service or execute arbitrary code. Red Hat severity: Important — CVSS 7 (CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H). Weakness: CWE-1341. Affected Red Hat products: Red Hat Enterprise Linux 10. Red Hat does not currently list a fixing RHSA for this CVE.

CVE-2026-72220

Linux Kernel

High [CVE-2026-72287] Move vTPR vs. TPR Threshold consistency check into "normal" checks

In the Linux kernel, the following vulnerability has been resolved: KVM: nVMX: Move vTPR vs. TPR Threshold consistency check into "normal" checks Move the off-by-default consistency check for vmcs12.tpr_threshold vs. the virtual APIC vTPR into the "normal" controls checks, as waiting until KVM has loaded some amount of state is unnecessary and actively dangerous. Specifically, failure to unwind vmcs01.GUEST_CR3 to KVM's value when EPT is disabled results in KVM running L1 with an L1-controlled CR3, not with KVM's CR3! Alternatively, KVM could simply reset the MMU to force a reload of vmcs01.GUEST_CR3, but the _only_ reason the check was shoved into a "late" flow was to wait until the vmcs12 pages were retrieved. Rather than build up more crusty code, simply access vTPR using a regular guest memory access (performance isn't a concern). To circumvent the restrictions that led to KVM deferring nested_get_vmcs12_pages(), (a) use a VM-scoped API to read guest memory so that it always hits non-SMM memslots (for RSM), and (b) skip the check (since its off-by-default anyways) when the vCPU doesn't want to run, i.e. when userspace is restoring/stuffing state. If reading guest memory fails, simply skip the consistency check, as KVM's de facto ABI is that VMX instruction accesses to non-existent memory get PCI Bus Error semantics, where reads return 0xFFs.

High [CVE-2026-72248] support IPIP tunnel with direct xmit

In the Linux kernel, the following vulnerability has been resolved: netfilter: flowtable: support IPIP tunnel with direct xmit The combination of IPIP tunnel with direct xmit, eg. bridge device, breaks because no dst_entry is provided to check the skb headroom and to set the iph->frag_off field. This leads to invalid dst usage and can trigger a crash in the tunnel transmit path. Fix this by moving dst_cache and dst_cookie out of the runtime union so that they can be shared by neighbour, xfrm, and direct tunnel flows. For FLOW_OFFLOAD_XMIT_DIRECT tuples carrying tunnel metadata, preserve route state in these shared fields and release it through the common dst release path. Since dst_entry is now available to the three supported xmit modes and dst_release() already deals with NULL dst, remove the xmit type check in nft_flow_dst_release(). Moreover, skip the check if the dst entry is NULL in nf_flow_dst_check() which is now the case for the direct xmit case. Based on patch from Rein Wei. When an Internet Protocol over Internet Protocol (IPIP) tunnel is used with direct transmit (xmit), such as with a bridge device, the system fails to properly handle network packet destination entries. This improper handling can lead to a system crash in the tunnel transmit path, resulting in a Denial of Service (DoS).

CVE-2026-72248

Linux Kernel