libkcapi CVE-2026-71227

Exploitation requires a local attacker who can influence the execution flow of an application that explicitly uses libkcapi's AIO interface - not applications using the synchronous libkcapi API or direct AF_ALG sockets. Two specific preconditions must be met: first, a prior AIO operation on the target handle must have returned a completion error; second, the attacker must be able to cause or observe this error state and then induce the application to reuse that same handle without reinitializing it. The high attack complexity (AC:H) reflects that both conditions must align, likely requiring timing control, ability to inject I/O errors, or deep knowledge of the target application's state machine. Limiting factors: only applications explicitly calling _kcapi_aio_read_all() with reused handles are vulnerable; applications using the synchronous API are unaffected; the attack is strictly local (no network exposure); and no privilege escalation is possible - impact is limited to hanging the affected thread or process. Environments where untrusted users cannot execute local code or interact with AIO-using crypto processes face no realistic risk.

The CVSS 3.1 score of 5.1 (AV:L/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H) is internally consistent with the described attack: local access is required (AV:L), exploitation is highly complex (AC:H) because the attacker must induce a specific AIO completion error and then influence handle reuse, and impact is availability-only with no confidentiality or integrity consequences. No EPSS score was provided in the input data, so exploitation probability cannot be quantified. The vulnerability is not listed in CISA KEV and no public exploit code is known, making this a low-urgency finding by all available signals. The AC:H rating is meaningful here - the attacker must control or race application behavior around AIO error handling, which is non-trivial without source code knowledge or specific application instrumentation. In multi-tenant RHEL or OpenShift environments where untrusted users can execute local code adjacent to crypto-using services, the risk is moderate; in tightly controlled single-tenant deployments, realistic risk is low. The PR:N rating warrants scrutiny: while no elevated OS privileges are required, practical exploitation likely demands the ability to influence a target process, which may imply application-level access not fully captured in the CVSS vector.

A local user on a shared RHEL or OpenShift node identifies a long-running service (such as a crypto daemon or key management process) that uses libkcapi with AIO-enabled operations. The attacker triggers a resource contention or I/O error to cause a prior AIO completion error on the target handle, then induces the application - through crafted input, signal injection, or timing - to reuse the same errored handle, causing _kcapi_aio_read_all() to spin indefinitely and the affected service thread to become permanently unresponsive. No public exploit code is known; this scenario requires application-specific knowledge of AIO handle management.