CVE-2026-71227: 
NixOS vulnerability analysis and mitigation

CVE-2026-71227 is an infinite loop denial-of-service vulnerability in libkcapi, a Linux kernel cryptography API userspace library. A local attacker who can influence an application using libkcapi's Asynchronous Input/Output (AIO) interface can trigger a non-terminating wait loop in the _kcapi_aio_read_all() function by reusing an AIO-enabled handle after a prior completion error, causing the affected application or thread to hang indefinitely. Affected versions span libkcapi 0.12.0 through 1.5.0 (fixed in 1.5.1), and Red Hat Enterprise Linux 8.0, 9.0, and 10.0 as well as Red Hat OpenShift Container Platform 4.x are also listed as affected. The vulnerability was disclosed on August 5, 2026, and carries a CVSS v3.1 base score of 5.1 (Medium) (Red Hat Advisory, Github Advisory).

The root cause is classified as CWE-835 (Loop with Unreachable Exit Condition / Infinite Loop). In lib/kcapi-kernel-if.c, the _kcapi_aio_read_all() function loops waiting for toread completions from io_getevents(), but does not handle a timeout return value of 0 — when io_getevents() times out, toread is never decremented and the loop makes no progress. The companion function _kcapi_aio_read_iov() can drive this condition by calling _kcapi_aio_read_all(handle, iovlen, &timeout) with a iovlen greater than the number of completions still outstanding after a prior AIO error drained some but not all slots. Exploitation requires: (1) a handle initialized with KCAPI_INIT_AIO, (2) at least one prior AIO completion error, and (3) reuse of the same handle for a subsequent AIO operation — making the attack vector local with high complexity (Red Hat Bugzilla, Red Hat Advisory).

Successful exploitation results in a persistent denial of service: the affected application thread enters a non-terminating wait loop and becomes permanently unresponsive without crashing or generating an error. There is no confidentiality or integrity impact — the vulnerability is purely an availability issue scoped to the vulnerable process. Applications relying on libkcapi for cryptographic operations (e.g., encryption, decryption via the kernel crypto API) could be rendered non-functional, potentially disrupting security-sensitive workflows on affected Red Hat Enterprise Linux and OpenShift systems (Red Hat Advisory, Red Hat Bugzilla).

A proof-of-concept with detailed, reproducible steps is publicly available in the Red Hat Bugzilla report, including specific API calls and observable behavior confirming the infinite loop (Red Hat Bugzilla). There is no evidence of in-the-wild exploitation at this time, and the NVD SSVC assessment confirms exploitation status as "none." The EPSS score is approximately 0.107–0.112%, placing it in the 2nd percentile for exploitation likelihood. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. Exploitation is constrained by high attack complexity — requiring a specific sequence of AIO initialization, error triggering, and handle reuse.

1. Identify a target application: Locate a local application that uses libkcapi (versions 0.12.0–1.5.0) and initializes handles with the KCAPI_INIT_AIO flag, enabling the AIO code path.
2. Initialize an AIO-enabled handle: Ensure the target application (or a crafted test program) calls the libkcapi initialization with KCAPI_INIT_AIO to enable asynchronous I/O support.
3. Trigger an AIO completion error: Call an AIO API such as kcapi_aead_decrypt_aio() or kcapi_cipher_*_aio() with multiple IOVs and force at least one completion error — for example, by supplying an invalid AEAD authentication tag for one request, causing _kcapi_aio_read_all() to return before all IOCB slots are drained.
4. Reuse the handle with excess iovlen: Without destroying and reinitializing the handle, issue another AIO call on the same handle where iovlen is greater than the number of still-completable prior events.
5. Observe the infinite loop: Watch _kcapi_aio_read_iov() enter the while (cb->aio_fildes) loop and repeatedly call _kcapi_aio_read_all(handle, iovlen, &timeout). Confirm that io_getevents() returns 0 (timeout) repeatedly while toread is never decremented, leaving the thread permanently stuck (Red Hat Bugzilla).

• Process Behavior: Application threads using libkcapi AIO functions become permanently unresponsive; strace or perf output shows repeated io_getevents() syscalls returning 0 with no forward progress.
• System Monitoring: High CPU or sustained syscall activity from a process invoking io_getevents in a tight loop without completing; process appears hung but does not exit or crash.
• Logs: Application-level logs showing a cryptographic AIO operation that never completes or returns; absence of expected completion callbacks or return values from libkcapi AIO calls.
• Kernel/System: ps or top showing a process in uninterruptible or looping state associated with kernel crypto AIO operations; /proc/<pid>/syscall showing repeated io_getevents calls (Red Hat Bugzilla).

Upgrade libkcapi to version 1.5.1 or later, which addresses the infinite loop by treating zero-completion timeout returns as errors and correcting IOCB slot state management (Red Hat Advisory). Red Hat has issued security updates for Red Hat Enterprise Linux 8.0, 9.0, and 10.0 — apply available errata packages. As a configuration-based workaround, avoid initializing libkcapi handles with KCAPI_INIT_AIO if AIO functionality is not strictly required. If AIO must be used, applications should destroy and reinitialize libkcapi handles after any AIO completion error rather than reusing them for subsequent operations (Red Hat Bugzilla).

The vulnerability was discovered by AISLE Research in partnership with Red Hat, and reported through Red Hat's coordinated disclosure process (Red Hat Advisory). No significant public researcher commentary, social media discussion, or notable media coverage has been identified beyond standard CVE aggregator entries and the Red Hat Bugzilla report.