In the Linux kernel, the following vulnerability has been resolved:

net/sched: Always pass notifications when child class becomes empty

Certain classful qdiscs may invoke their classes' dequeue handler on an enqueue operation. This may unexpectedly empty the child qdisc and thus make an in-flight class passive via qlennotify(). Most qdiscs do not expect such behaviour at this point in time and may re-activate the class eventually anyways which will lead to a use-after-free.

The referenced fix commit attempted to fix this behavior for the HFSC case by moving the backlog accounting around, though this turned out to be incomplete since the parent's parent may run into the issue too. The following reproducer demonstrates this use-after-free:

tc qdisc add dev lo root handle 1: drr tc filter add dev lo parent 1: basic classid 1:1 tc class add dev lo parent 1: classid 1:1 drr tc qdisc add dev lo parent 1:1 handle 2: hfsc def 1 tc class add dev lo parent 2: classid 2:1 hfsc rt m1 8 d 1 m2 0 tc qdisc add dev lo parent 2:1 handle 3: netem tc qdisc add dev lo parent 3:1 handle 4: blackhole

echo 1 | socat -u STDIN UDP4-DATAGRAM:127.0.0.1:8888 tc class delete dev lo classid 1:1 echo 1 | socat -u STDIN UDP4-DATAGRAM:127.0.0.1:8888

Since backlog accounting issues leading to a use-after-frees on stale class pointers is a recurring pattern at this point, this patch takes a different approach. Instead of trying to fix the accounting, the patch ensures that qdisctreereducebacklog always calls qlennotify when the child qdisc is empty. This solves the problem because deletion of qdiscs always involves a call to qdiscreset() and / or qdiscpurgequeue() which ultimately resets its qlen to 0 thus causing the following qdisctreereducebacklog() to report to the parent. Note that this may call qlennotify on passive classes multiple times. This is not a problem after the recent patch series that made all the classful qdiscs qlennotify() handlers idempotent.

A heap-based buffer overflow was found in Corosync's Totem Process Group (totempg) message reassembly. When processing fragmented multicast messages, the buffer used to reassemble fragments lacks a runtime bounds check in release builds. A network-adjacent attacker able to send crafted multicast protocol messages to the cluster could cause a heap buffer overflow with attacker-controlled data. This can crash the Corosync daemon, causing a denial of service to the entire cluster, and may potentially allow further exploitation given sufficient heap-corruption control.

openvt -u is intended to identify the owner of the current VT and then execute login as that user from a privileged context. In the documented kbrequest/init usage, the ownership test in authenticateuser() relies on stat("/proc/<pid>/fd/0"). stat() on /proc/<pid>/fd/0 follows the symlink to the underlying TTY device node. As a result, buf.stuid reflects the owner of the TTY node rather than the owner of the process holding the file descriptor. If the TTY owner returns to root or the getty owner after logout while an unprivileged process still has fd 0 attached to that TTY, the check can incorrectly treat that process as belonging to the privileged console owner. Once that check succeeds, the -u path executes a passwordless login as the selected user. In the documented kbrequest/init deployment using openvt -us, this can result in passwordless login -f root on the spawned VT. This report establishes that privilege escalation path for that documented deployment; it does not claim equivalent reachability for deployments that do not use openvt -u from a privileged kbrequest/init path.

It was found that polkit could be tricked into bypassing the credential checks for D-Bus requests, elevating the privileges of the requestor to the root user. This flaw could be used by an unprivileged local attacker to, for example, create a new local administrator. The highest threat from this vulnerability is to data confidentiality and integrity as well as system availability.

A Local Privilege Escalation vulnerability (from any user to root) was found in polkit's pkexec, a SUID-root program that is installed by default on every major Linux distribution.

Critical: kernel security update

OpenShift Container Platform 4.22.21 security and extras update

OpenShift Container Platform 4.20.45 security and extras update

Important: bind9.18 security, bug fix, and enhancement update

Important: bind9.16 security, bug fix, and enhancement update

zero trust workload identity manager for Red Hat OpenShift 1.1.3

AIONLYREPORT package: libkcapi-1.5.0-3.el10 ------ Summary: Memory Corruption via Uncanceled AIO Requests on Error: libkcapi's one-shot AIO path can return an error before all submitted IOCBs are drained, allowing later kernel writes into caller-owned output buffers. Requirements to exploit: A consumer must use the one-shot AIO interfaces with KCAPIINITAIO so the real AIO backend is active, hit an error after one or more IOCBs have been submitted or completed, and then free or reuse the referenced outiov buffers before all kernel completions finish. Component affected: libkcapi-1.5.0-3.el10, lib/kcapi-kernel-if.c, kcapiaioreadall(), kcapiaioreadiov(), kcapiciphercryptaio() in the one-shot AIO path Version affected: libkcapi-1.5.0-3.el10 when the handle is initialized with KCAPIINITAIO and libkcapi enables its real kernel AIO backend Patch available: no released package fix established; proposed patch included below Version fixed: unknown Upstream coordination: Unknown. CVSS: CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:H - 6.8 (MEDIUM) AV:L - exploitation is local to the process using libkcapi. AC:L - once the real AIO path is active, the unsafe behavior is reached directly through documented error paths after request submission. PR:N - no elevated privileges are required beyond the ability to exercise the affected API in the local process. UI:N - no separate user interaction is required. S:U - the impact stays within the security scope of the calling process. C:L - late writes into reused buffers can expose limited process data. I:L - late kernel writes can alter caller memory after the library has reported failure. A:H - heap corruption or process termination is a realistic outcome. Impact: Moderate. This flaw can cause real process memory corruption, but it depends on an opt-in AIO configuration, kernel AIO availability, and an error path after submission rather than a default or easily reachable execution path. Under Red Hat's severity guidance, that is more consistent with Moderate impact than Important or Critical. Embargo: no Reason: the issue is local and configuration-dependent, requires explicit AIO use plus an error-path trigger, and does not present a straightforward remote compromise scenario. Acknowledgement: Aisle Research Vulnerability Details: In the affected one-shot AIO path, libkcapi can return failure before all submitted kernel requests are drained. kcapiaioreadall() returns immediately on the first negative completion result, and kcapiaioreadiov() returns immediately on a short iosubmit() result even if some IOCBs were already submitted. kcapiciphercryptaio() then propagates that error directly to the caller. If the caller treats the operation as failed and promptly frees or reuses outiov[].iovbase, later kernel completions may still write into those buffers. c if (events[i].res < 0) { handle->aio.iocbret[events[i].data] = events[i].res; return (int)events[i].res; } ... ret = iosubmit(handle->aio.aioctx, (long)iovlen, handle->aio.ciopp); if ((uint32t)ret != iovlen) { if (ret < 0) { ret = -errno; kcapidolog(KCAPILOGERR, "ioread Error: %d\n", ret); return ret; } else { kcapidolog(KCAPILOGERR, "Could not sumbit AIO read\n"); return -EIO; } } c ret = kcapiaioreadiov(handle, outiov, process); if (ret < 0) return ret; The issue is not established for the default synchronous path. Reachability depends on the caller enabling KCAPIINITAIO so libkcapi uses the real kernel AIO backend. Steps to reproduce: 1. Build an ASAN-enabled harness that calls kcapicipherencryptaio() or kcapiaeaddecryptaio() with multiple output iovec entries. 2. Initialize the handle with KCAPIINITAIO so the real AIO path is active. 3. Force a deterministic short-submit path with an LDPRELOAD wrapper around syscall(NRiosubmit, ...) that returns 0 < ret < iovlen after forwarding only the first N IOCBs. 4. Optionally fault-inject iogetevents() so one returned event has res < 0 before all completions are consumed. 5. When the API returns an error, immediately free or reallocate the outiov[].iovbase buffers. 6. Observe delayed writes into freed or reused memory, for example as an ASAN use-after-free, heap corruption, or a canary mismatch. Mitigation: Until a fix is available, avoid initializing affected handles with KCAPIINITAIO and prefer the synchronous interfaces. If the real AIO path must remain enabled, applications should not immediately free or reuse outiov buffers after an error return. Proposed Fix: Drain all submitted requests before returning an error. A minimal approach is to record the first completion error, continue draining outstanding completions, and drain any successfully submitted subset after a short iosubmit() result. diff diff --git a/lib/kcapi-kernel-if.c b/lib/kcapi-kernel-if.c — a/lib/kcapi-kernel-if.c +++ b/lib/kcapi-kernel-if.c @@ -420,6 +420,7 @@ int kcapiaioreadall(struct kcapihandle handle, sizet toread, struct timespec timeout) { + int firsterr = 0; if (toread > KCAPIAIOCONCURRENT) return -EINVAL; @@ -440,8 +441,10 @@ int kcapiaioreadall(struct kcapihandle handle, sizet toread, if (events[i].res < 0) { handle->aio.iocbret[events[i].data] = events[i].res; - return (int)events[i].res; + if (!firsterr) + firsterr = (int)events[i].res; + continue; } @@ -467,7 +470,7 @@ int kcapiaioreadall(struct kcapihandle handle, sizet toread, toread -= (uint32t)rc; } - return 0; + return firsterr; } @@ -534,15 +537,20 @@ int kcapiaioreadiov(struct kcapihandle handle, ret = iosubmit(handle->aio.aioctx, (long)iovlen, handle->aio.ciopp); if ((uint32t)ret != iovlen) { + sizet submitted = (ret > 0) ? (sizet)ret : 0; + int submiterr = (ret < 0) ? -errno : -EIO; if (ret < 0) { - ret = -errno; kcapidolog(KCAPILOGERR, "ioread Error: %d\n", ret); - return ret; } else { kcapidolog(KCAPILOGERR, "Could not sumbit AIO read\n"); - return -EIO; } + if (submitted) { + int drain = kcapiaioreadall(handle, submitted, NULL); + if (submiterr == 0 && drain < 0) + submiterr = drain; + } + return submiterr; } (Equivalent fix using iocancel + confirmed drain is also acceptable.) ------ This report was generated using AI technology. Always review AI-generated content prior to use

A flaw was found in dracut. A remote attacker on the adjacent network can exploit this vulnerability by providing specially crafted DHCP options, such as a malicious root-path, next-server, or bootfile name, to a system using dracut's NetworkManager-based initrd network module. These options are improperly handled and written into a temporary shell script without proper escaping, leading to command injection. This allows the attacker to achieve root code execution within the initramfs during system boot.

Important: bind security, bug fix, and enhancement update

Red Hat Hardened Images RPMs bug fix and enhancement update

Critical: kernel security, bug fix, and enhancement update

Red Hat Ansible Automation Platform 2.7 Container Release Update

Important: Red Hat Build of Apache Camel 4.18 for Quarkus 3.33 update is now available

Important: Red Hat Ansible Automation Platform 2.6 Product Security and Bug Fix Update

Important: Red Hat Ansible Automation Platform 2.5 Product Security and Bug Fix Update

Red Hat Web Terminal Operator 1.15.3 release.

A flaw was found in openshift/oc's local tar-extraction code used by oc image extract. The createTarFile() function in pkg/cli/image/archive/archive.go (oc's private fork of Docker/Moby's pkg/archive) validates that a symlink or hardlink target stays inside the extraction directory by computing targetPath := filepath.Join(filepath.Dir(path), hdr.Linkname) and testing strings.HasPrefix(targetPath, extractDir), but then creates the symlink using the raw, unvalidated hdr.Linkname via os.Symlink(hdr.Linkname, path). The check fails in two independent ways: for an absolute Linkname (e.g. /etc/passwd), Go's filepath.Join does not re-root, so the computed path folds under the extraction directory and passes, while the created symlink points to the attacker-specified absolute path; and for a relative Linkname sharing the destination's basename as a text prefix (e.g. ../safe-x/marker against a safe destination), strings.HasPrefix matches across the path boundary and the target resolves into a sibling directory outside the destination. The hardlink (TypeLink) branch is affected by the sibling-prefix variant. oc image extract reaches this code by calling archive.ApplyLayer() directly with a reader sourced from the remote image's layer blob, so the processed tar stream is attacker-controlled. The dangling-symlink primitive further chains into an arbitrary-content write outside the destination: a second tar entry whose name traverses the just-planted symlink is written with OpenFile(path, OCREATE|OWRONLY, …), which follows symlinks, because the per-entry name check inspects only the textual dest+Name join and never Lstats intermediate components. The general entry-name containment check in the same file is correct (it uses filepath.Rel); only the symlink/hardlink target check was left in the older, insufficient form.

A flaw was found in Wildfly. A remote attacker can bypass authentication on IIOP EJB invocations as the CSIv2 security interceptor accepts ITTPrincipalName identity assertions in the service context without verifying transport-level authentication, allowing a pre-auth attacker on the port 3528 to impersonate any principal on every IIOP-exposed @Remote EJB.

Red Hat Web Terminal Operator 1.14.2 release.

Red Hat Web Terminal Operator 1.17.2 release.

Red Hat Web Terminal Operator 1.11.3 release.

Red Hat Web Terminal Operator 1.16.3 release.

Red Hat Web Terminal Operator 1.13.2 release.

Red Hat Hardened Images RPMs bug fix and enhancement update

when EAP runs with -secmgr, the openjdk-orb's JDKBridge honours attacker-supplied CDR codebase URLs during object unmarshalling on :3528, allowing an unauthenticated attacker to load and instantiate arbitrary classes from a remote URL in the server JVM before EJB security interceptors run.