IBM Cloud Pak for Data System 11.3.1.2 Interim Fix 001 through - 11.3.1.2 Interim Fix 002 could allow a user with administrative privileges to read and write arbitrary files on the system due to incorrect permission assignments.

Last updated 14 September 2026

A flaw was found in rsync. An authenticated daemon peer can exploit an integer overflow vulnerability in the compressed-token decoder. By carefully manipulating the compressed-token, a malicious sender can trigger an overflow, leading to remote memory disclosure. This allows an attacker to leak sensitive process memory contents, including environment variables, passwords, and memory pointers, which significantly weakens Address Space Layout Randomization (ASLR) and can facilitate further exploitation.

A flaw was found in rsync. An rsync daemon configured with "use chroot = no" is exposed to a time-of-check / time-of-use race on parent path components. A local attacker with write access to a module can replace a parent directory component with a symlink between the receiver's check and its open(), redirecting reads (basis-file disclosure) and writes (file overwrite) outside the module. Under elevated daemon privilege this allows privilege escalation. Default "use chroot = yes" is not exposed.

GNU coreutils uniq is vulnerable to an out‑of‑bounds read due to incorrect handling of multibyte input when the -w (--check-chars) option is used. The findfield() function miscalculates the byte length of characters by repeatedly processing a fixed pointer instead of advancing through the input, resulting in an inflated length value. This incorrect length is later used in a memcmp operation, causing reads beyond the allocated buffer when processing crafted multibyte input.

A use after free can have a range of potential consequences such as the corruption of valid data, crashes or execution of arbitrary code. However, only applications that directly call the SSLfreebuffers function are affected by this issue. Applications that do not call this function are not vulnerable. Our investigations indicate that this function is rarely used by applications.

The SSLfreebuffers function is used to free the internal OpenSSL buffer used when processing an incoming record from the network. The call is only expected to succeed if the buffer is not currently in use. However, two scenarios have been identified where the buffer is freed even when still in use.

The first scenario occurs where a record header has been received from the network and processed by OpenSSL, but the full record body has not yet arrived. In this case calling SSLfreebuffers will succeed even though a record has only been partially processed and the buffer is still in use.

The second scenario occurs where a full record containing application data has been received and processed by OpenSSL but the application has only read part of this data. Again a call to SSLfreebuffers will succeed even though the buffer is still in use.

While these scenarios could occur accidentally during normal operation a malicious attacker could attempt to engineer a stituation where this occurs. We are not aware of this issue being actively exploited.

The FIPS modules in 3.3, 3.2, 3.1 and 3.0 are not affected by this issue.

OpenSSL 1.0.2 is also not affected by this issue.

OpenSSL 3.3, 3.2, 3.1, 3.0 and 1.1.1 are vulnerable to this issue.

OpenSSL 3.3 users should upgrade to OpenSSL 3.3.1 once it is released.

OpenSSL 3.2 users should upgrade to OpenSSL 3.2.2 once it is released.

OpenSSL 3.1 users should upgrade to OpenSSL 3.1.6 once it is released.

OpenSSL 3.0 users should upgrade to OpenSSL 3.0.14 once it is released.

OpenSSL 1.1.1 users should upgrade to OpenSSL 1.1.1y once it is released (premium support customers only).

Due to the low severity of this issue we are not issuing new releases of OpenSSL at this time. The fix will be included in the next releases when they become available. The fix is also available in commit e5093133c3 (for 3.3), commit c88c3de510 (for 3.2), commit 704f725b96 (for 3.1) and commit b3f0eb0a29 (for 3.0) in the OpenSSL git repository. It is available to premium support customers in commit f7a045f314 (for 1.1.1).

This issue was reported on 10th April 2024 by William Ahern (Akamai). The fix was developed by Matt Caswell and Watson Ladd (Akamai).

Issue summary: When an OpenSSL QUIC server (Listener SSL object) processes valid QUIC Initial packets for unknown destination connection IDs, it can allocate and queue new incoming channels without enforcing any limit.

A flaw was found in GLib. An off-by-one error can occur in the gvstupleisnormal function in the glib/gvariant-serialiser.c file when doing an alignment padding check because the bounds check uses instead of =, causing an out-of-bounds read of only 1 byte. This issue can cause a minor information disclosure of 1 byte and a denial of service when the out-of-bounds read crosses a page boundary.

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

rtnetlink: add missing netlinknscapable() check for peer netns

rtnlnewlink() lacks a CAPNETADMIN capability check on the peer network namespace when creating paired devices (veth, vxcan, netkit). This allows an unprivileged user with a user namespace to create interfaces in arbitrary network namespaces, including initnet.

Add a netlinknscapable() check for CAPNETADMIN in the peer namespace before allowing device creation to proceed.

A flaw was found in GLib. A buffer over-read can occur in giochannelreadlinebackend() in the giochannel.c file when a custom line terminator with a length greater than one is set, causing memcmp to read past the GString buffer. This vulnerability can cause a minor information disclosure of 7 bytes or a denial of service when the buffer over-read crosses a page boundary.

dm log: fix out-of-bounds write due to regioncount overflow

A flaw was found in the interactive shell of the xmllint command-line tool, used for parsing XML files. When a user inputs an overly long command, the program does not check the input size properly, which can cause it to crash. This issue might allow attackers to run harmful code in rare configurations without modern protections.

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

xen/privcmd: fix double free via VMA splitting

privcmdvmops defines .close (privcmdclose), but neither .maysplit nor .open. When userspace does a partial munmap() on a privcmd mapping, the kernel splits the VMA via splitvma(). Since maysplit is NULL, the split is allowed. vmareadup() copies vmprivatedata (a pages array allocated in allocemptypages()) into the new VMA without any fixup, because there is no .open callback.

Both VMAs now point to the same pages array. When the unmapped portion is closed, privcmdclose() calls: - xenunmapdomaingfnrange() - xenfreeunpopulatedpages() - kvfree(pages)

The surviving VMA still holds the dangling pointer. When it is later destroyed, the same sequence runs again, which leads to a double free.

Fix this issue by adding a .maysplit callback denying the VMA split.

This is XSA-487 / CVE-2026-31787

AMD-SN-7061: Safe RET Interrupt Vulnerability

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

net: bridge: use a stable FDB dst snapshot in RCU readers

Local FDB entries can be rewritten in place by fdbdeletelocal(), which updates f->dst to another port or to NULL while keeping the entry alive. Several bridge RCU readers inspect f->dst, including brfdbfillbuf() through the brforwardread() sysfs path.

These readers currently load f->dst multiple times and can therefore observe inconsistent values across the check and later dereference. In brfdbfillbuf(), this means a concurrent local-FDB update can change f->dst after the NULL check and before the portno dereference, leading to a NULL-ptr-deref.

Fix this by taking a single READONCE() snapshot of f->dst in each affected RCU reader and using that snapshot for the rest of the access sequence. Also publish the in-place f->dst updates in fdbdeletelocal() with WRITEONCE() so the readers and writer use matching access patterns.

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

RDMA/vmwpvrdma: Fix double free on pvrdmaallocucontext() error path

Sashiko points out that pvrdmauarfree() is already called within pvrdmadeallocucontext(), so calling it before triggers a double free.

A flaw was found in GLib. The D-Bus client-side implementation of the DBUSCOOKIESHA1 SASL authentication mechanism does not validate the cookiecontext parameter received from the server. A malicious D-Bus server can supply a cookiecontext containing path traversal sequences, causing the client to read an arbitrary file and exfiltrate sensitive data by verifying guessed file contents against a generated hash.

A flaw was found in GLib. An out-of-bounds read of only 2 bytes can occur in the gdatetimegetymd function in the glib/gdatetime.c file when an invalid GDateTime object produced by the gdatetimeaddfull function is processed. This flaw can corrupt the date output and potentially cause logic errors that may lead to a denial of service.

A flaw was found in GLib. An off-by-one error can occur in the gkeyfilegetlocalestringlist function in the gkeyfile.c file when loading a key file with an empty value. This flaw can cause an out-of-bounds access of 1 byte or a denial of service when the out-of-bounds access crosses a page boundary.

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

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

netfilter: nfnetlinkcthelper: fix OOB read in nfnlcthelperdumptable()

nfnlcthelperdumptable() has a 'goto restart' that jumps to a label inside the for loop body. When the "last" helper saved in cb->args[1] is deleted between dump rounds, every entry fails the (cur != last) check, so cb->args[1] is never cleared. The for loop finishes with cb->args[0] == nfcthelperhsize, and the 'goto restart' jumps back into the loop body bypassing the bounds check, causing an 8-byte out-of-bounds read on nfcthelperhash[nfcthelperhsize].

The 'goto restart' block was meant to re-traverse the current bucket when "last" is no longer found, but it was placed after the for loop instead of inside it. Move the block into the for loop body so that the restart only occurs while cb->args[0] is still within bounds.

BUG: KASAN: slab-out-of-bounds in nfnlcthelperdumptable+0x9f/0x1b0 Read of size 8 at addr ffff888104ca3000 by task poccthelper/131 Call Trace: nfnlcthelperdumptable+0x9f/0x1b0 netlinkdump+0x333/0x880 netlinkrecvmsg+0x3e2/0x4b0 sockrecvmsg+0xde/0xf0 sysrecvfrom+0x150/0x200 x64sysrecvfrom+0x76/0x90 dosyscall64+0xc3/0x6e0

Allocated by task 1: kvmallocnodenoprof+0x21b/0x700 nfctallochashtable+0x65/0xd0 nfconntrackhelperinit+0x21/0x60 nfconntrackinitstart+0x18d/0x300 nfconntrackstandaloneinit+0x12/0xc0

A flaw was found in libsolv. This heap buffer overflow occurs during the decompression of attacker-controlled compressed data within .solv files due to insufficient input validation. An attacker can provide a specially crafted .solv file, which, when processed by a vulnerable application, can lead to out-of-bounds memory access. This could result in information disclosure, alteration of program execution, or a denial of service.

A flaw was found in GLib. A buffer over-read can occur in the gregexreplace function when used with the GREGEXRAW compile flag and case-change replacement escapes because the stringappend function processes matched substrings using UTF-8 functions that assume valid UTF-8 input, even when the string is treated as raw bytes. This vulnerability can cause a minor information disclosure of 1-5 bytes and a denial of service when the buffer over-read crosses a page boundary.

A flaw was found in GLib. A state confusion issue exists in gdbusnodeinfonewforxml() in the gio/gdbusintrospection.c file when processing malformed D-Bus introspection XML, specifically with a node element nested within other elements like method, signal, property or arg. This issue can cause an unsigned integer overflow and lead to an out-of-bounds read, resulting in a denial of service.

Summary

A man-in-the-middle attacker can cause Net::IMAP#starttls to return "successfully", without starting TLS.

Details

When using Net::IMAP#starttls to upgrade a plaintext connection to use TLS, a man-in-the-middle attacker can inject a tagged OK response with an easily predictable tag. By sending the response before the client finishes sending the command, the command completes "successfully" before the response handler is registered. This allows #starttls to return without error, but the response handler is never invoked, the TLS connection is never established, and the socket remains unencrypted.

This allows man-in-the-middle attackers to perform a STARTTLS stripping attack, unless the client code explicitly checks Net::IMAP#tlsverified?.

Impact

TLS bypass, leading to cleartext transmission of sensitive information.

Mitigation

Upgrade to a patched version of net-imap that raises an exception whenever #starttls does not establish TLS. Connect to an implicit TLS port, rather than use STARTTLS with a cleartext port. This is strongly recommended anyway: RFC 8314: Cleartext Considered Obsolete: Use of Transport Layer Security (TLS) for Email Submission and Access NO STARTTLS: Why TLS is better without STARTTLS, A Security Analysis of STARTTLS in the Email Context Explicitly verify Net::IMAP#tlsverified? is true, before using the connection after #starttls.

Summary

Symbol arguments to commands are vulnerable to a CRLF Injection / IMAP Command injection via Symbol arguments passed to IMAP commands.

Details

Symbol arguments represent IMAP "system flags", which are formatted as "atoms" (with no quoting) with a "\" prefix. Vulnerable versions of Net::IMAP sends the symbol name directly to the socket, with no validation.

Because the Symbol input is unvalidated, it could contain invalid flag characters, including SP and CRLF, which could be used to finish the current command and inject new commands.

Although IMAP flag arguments are only valid input for a few IMAP commands, most Net::IMAP commands use generic argument handling, and will allow Symbol (flag) inputs.

Note also that the list of valid symbol inputs should be restricted to an enumerated set of standard RFC defined flag types, which have each been given specific defined semantics. Any user-provided values outside of that list of standard "system flags" needs to use the IMAP keyword syntax, which are sent as atoms, i.e: string inputs. Under no circumstances should #tosym ever be called on unvetted user-provided input: that will always be a bug in the calling code for the simple reason that userinputatom is as \userinputatom.

For forward compatibility with future IMAP extentions, Net::IMAP, does not restrict flag inputs to an enumerated list. That is the responsibility of the calling application code, which knows which flag semantics are valid for its context.

Impact

If a developer passes user-controlled input as a Symbol to most Net::IMAP commands, an attacker can append CRLF sequence followed by a new IMAP command (like DELETE mailbox).

Mitigation Upgrade to a version of Net::IMAP that validates Symbols are valid as an IMAP flag. User-provided input should never be able to control calling #tosym on string arguments.

For example, do not unsafely serialize and deserialize command arguments (e.g. with YAML or Marshal) in a way that could create unvetted Symbol arguments. For the few IMAP commands which do allow flag arguments, it may be appropriate to hard-code Symbol arguments or restrict them to an enumerated list which is valid for the calling application.

A path traversal flaw was found in SSSD's AD GPO provider. The adgpoextractsmbcomponents() function does not sanitize .. sequences in the gPCFileSysPath LDAP attribute, allowing an attacker with AD GPO management access to write files outside the GPO cache directory as root. On default RHEL configurations with SELinux enforcing, this can be used to inject Kerberos configuration leading to authentication bypass.

A flaw was found in SSSD's LDAP sudo provider. When the ldapsudosearchbase option is not explicitly configured, SSSD searches the entire LDAP directory tree for sudoRole objects. An authenticated attacker with write access to any subtree can inject a sudoRole object granting root-level sudo privileges on all SSSD-enrolled hosts.

Internationalized Domain Names in Applications (IDNA) for Python provides support for Internationalized Domain Names in Applications (IDNA) and Unicode IDNA Compatibility Processing. In versions prior to 3.15, payloads such as "\u0660" N or "\u30fb" N + "\u6f22" utilize the validcontexto function prior to length rejection, and for high values of N will take a long time to process. This is the same issue as CVE-2024-3651, however the original remediation in 2024 was not a complete fix. A specially crafted argument to the idna.encode() function could consume significant resources. This may lead to a denial-of-service. Starting in version 3.14, the function rejects long inputs as soon as practicable prior to any further processing to minimize resource consumption. In version 3.15, this approach was extended to lesser used alternate functions (i.e. per-label conversions and codec support). A workaround is available. Domain names cannot exceed 253 characters in length. If this length limit is enforced prior to passing the domain to the idna.encode() function, it should no longer consume significant resources. This is triggered by arbitrarily large inputs that would not occur in normal usage, but may be passed to the library assuming there is no preliminary input validation by the higher-level application.

A GDBus authentication denial-of-service / resource exhaustion flaw has been reported. The vulnerability involves a lack of line length limitations when gdbusauth reads input from a client. This can be exploited by an unauthenticated remote or local attacker to cause excessive memory and CPU consumption.