CVE-2026-43492: Linux Kernel MPI Integer Underflow DoS

CVE-2026-43492 Overview

CVE-2026-43492 is an integer underflow vulnerability in the Linux kernel's Multi-Precision Integer (MPI) cryptographic helper mpi_read_raw_from_sgl() located in lib/crypto/mpi. The flaw occurs when the function subtracts a leading-zero counter (lzeros) from the unsigned nbytes parameter while iterating over a scatterlist. When the scatterlist contains more zero bytes than nbytes, the subtraction wraps around, producing a massive unsigned value that drives the kernel into an effectively infinite loop. Reachable from userland through the KEYCTL_PKEY_ENCRYPT keyctl operation, the bug allows an unprivileged local user to trigger a denial of service through soft lockups.

Critical Impact

An unprivileged local user can invoke keyctl(KEYCTL_PKEY_ENCRYPT) with crafted parameters to spin the kernel indefinitely, producing soft lockup splats and a system-wide denial of service.

Affected Products

• Linux kernel versions containing commit 2d4d1eea540b ("lib/mpi: Add mpi sgl helpers") that also include commit 63ba4d67594a ("KEYS: asymmetric: Use new crypto interface without scatterlists")
• Linux distributions shipping vulnerable stable and longterm kernel branches prior to the upstream fix
• Systems with the asymmetric keys subsystem and RSA support enabled in the kernel configuration

Discovery Timeline

• 2026-05-19 - CVE-2026-43492 published to the National Vulnerability Database (NVD)
• 2026-05-19 - Last updated in NVD database

Technical Details for CVE-2026-43492

Vulnerability Analysis

The defect lives in mpi_read_raw_from_sgl(), a helper in lib/crypto/mpi that converts a scatter-gather list into a multi-precision integer. The function walks the scatterlist counting leading zero bytes (lzeros) and then subtracts that count from the caller-supplied nbytes length. The subtraction is performed on an unsigned type.

When the scatterlist holds more bytes than nbytes and the first nbytes + 1 bytes are all zero, the loop counts more zeroes than nbytes. The subtraction nbytes - lzeros then underflows to a value near SIZE_MAX. Subsequent allocation and copy logic uses this huge value, and the kernel becomes stuck processing the bogus length, producing soft lockup warnings.

Root Cause

The root cause is missing bounds enforcement between the scatterlist length and the nbytes argument. The original commit 2d4d1eea540b ("lib/mpi: Add mpi sgl helpers") assumed all callers would pass a scatterlist whose length matched nbytes. Commit 63ba4d67594a ("KEYS: asymmetric: Use new crypto interface without scatterlists") broke that assumption by routing requests through crypto_akcipher_sync_prep(), which constructs an oversized all-zero scatterlist when out_len > in_len. This is a classic integer underflow [CWE-191] caused by trusting an externally influenced count in unsigned arithmetic.

Attack Vector

A local unprivileged process invokes the keyctl(KEYCTL_PKEY_ENCRYPT) system call against an asymmetric key, supplying an out_len larger than in_len and filling the input buffer with zero bytes. The call chain sys_keyctl() → keyctl_pkey_e_d_s() → asymmetric_key_eds_op() → software_key_eds_op() → crypto_akcipher_sync_encrypt() → crypto_akcipher_sync_prep() → crypto_akcipher_encrypt() → rsa_enc() → mpi_read_raw_from_sgl() reaches the vulnerable subtraction. The kernel then loops on the underflowed length, hanging the CPU and emitting soft lockup splats. No special privileges or capabilities are required beyond access to the keyctl interface.

No verified public proof-of-concept code is available. The reproduction recipe is documented in the upstream commit message and consists of issuing a KEYCTL_PKEY_ENCRYPT request against any RSA key with a zeroed oversized input buffer.

Detection Methods for CVE-2026-43492

Indicators of Compromise

• Repeated kernel soft lockup or watchdog: BUG: soft lockup - CPU#N stuck messages in dmesg or /var/log/messages with stack traces referencing mpi_read_raw_from_sgl, rsa_enc, or crypto_akcipher_sync_prep.
• Unresponsive CPU cores with one or more kernel threads pinned at 100% utilization while servicing a keyctl syscall from an unprivileged process.
• Unexpected invocations of keyctl(KEYCTL_PKEY_ENCRYPT) from non-administrative users or workloads that do not normally exercise asymmetric key operations.

Detection Strategies

• Audit keyctl syscalls using auditd rules on syscall=keyctl and alert when operation number 29 (KEYCTL_PKEY_ENCRYPT) is issued by unexpected UIDs.
• Correlate kernel ring buffer soft lockup events with the calling process via perf or eBPF tracing on crypto_akcipher_encrypt and mpi_read_raw_from_sgl.
• Track kernel build versions across the fleet and flag hosts running kernels that contain 63ba4d67594a but lack the fix commits.

Monitoring Recommendations

• Forward dmesg and /var/log/kern.log to a centralized log pipeline and create alerts for soft lockup and RCU stall patterns referencing crypto symbols.
• Monitor per-CPU utilization and run queue length for sustained saturation by kernel threads, a common symptom of this denial of service.
• Track Linux kernel package versions through configuration management and verify that vulnerable builds are replaced with patched stable releases.

How to Mitigate CVE-2026-43492

Immediate Actions Required

• Apply the upstream Linux kernel fixes referenced in commits 26d3a97, 2aa77a18, 30e513e7, 8637dfb4, and 8c2f1288 from kernel.org as soon as your distribution ships them.
• Update to the latest stable kernel point release from your Linux distribution vendor and reboot affected hosts.
• Inventory hosts that expose the keyctl asymmetric key interface to untrusted local users, including multi-tenant servers, container hosts, and shared developer systems.

Patch Information

The fix adds a bounds check so that lzeros cannot exceed nbytes, preventing the underflow. The patch is distributed across the following kernel.org stable commits: Kernel Git Commit 26d3a97, Kernel Git Commit 2aa77a18, Kernel Git Commit 30e513e7, Kernel Git Commit 8637dfb4, and Kernel Git Commit 8c2f1288. Consult your distribution's security advisories for the corresponding packaged kernel releases.

Workarounds

• Restrict access to the keyctl asymmetric key operations using seccomp filters that block SYS_keyctl for untrusted workloads and containers.
• Apply SELinux or AppArmor policies that deny the keyctl capability to non-administrative service accounts where asymmetric key usage is not required.
• Where feasible, disable kernel configuration options CONFIG_ASYMMETRIC_KEY_TYPE and CONFIG_ASYMMETRIC_PUBLIC_KEY_SUBTYPE on systems that do not require user-facing asymmetric key operations.

# Verify the running kernel version and check for the fix
uname -r

# Example: block keyctl syscall in a seccomp-protected container (Docker)
docker run --security-opt seccomp=/etc/docker/seccomp-no-keyctl.json myimage

# Example auditd rule to log KEYCTL_PKEY_ENCRYPT invocations
echo '-a always,exit -F arch=b64 -S keyctl -F a0=29 -k keyctl_pkey_encrypt' \
  | sudo tee -a /etc/audit/rules.d/keyctl.rules
sudo augenrules --load