CVE-2026-43492

What it actually does

This is a local Linux kernel denial-of-service vulnerability in the MPI crypto helper mpi_read_raw_from_sgl(). A low-privileged local user can trigger an unsigned integer underflow by invoking KEYCTL_PKEY_ENCRYPT with an input buffer consisting of zero bytes and an output length larger than the input length. Under the affected call path, the kernel can count more leading zero bytes than the expected nbytes value, underflow the length calculation, and enter an effectively infinite loop. The observable result is a CPU-consuming kernel spin with soft lockup warnings, degrading or halting system availability. The vulnerability does not provide confidentiality or integrity impact by itself and is not remote exploitable under the provided CVSS vector.

Why it matters to the business

Successful exploitation can make affected Linux systems unresponsive, interrupt workloads, cause service outages, and require operational intervention such as rebooting or failover. Because exploitation requires local low-privileged access, the primary risk is from compromised user accounts, multi-user systems, container or workload escape-adjacent scenarios where the keyctl syscall is exposed, and shared hosting or build environments. This is not currently listed in CISA KEV, is not reported as ransomware-used, and has a low EPSS score, so prioritization should focus on internet-facing or business-critical Linux hosts with local user or untrusted workload execution rather than emergency fleet-wide response.

How an attack unfolds

An attacker first obtains the ability to execute code as a low-privileged local user on an affected Linux system. They then reach the kernel asymmetric key encryption path by using the keyctl pkey encryption interface with parameters that cause the kernel to prepare a scatterlist where the data is all zeroes and the requested output length is larger than the input length. This flows through 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(), and finally mpi_read_raw_from_sgl(). In vulnerable kernels, mpi_read_raw_from_sgl() subtracts the number of leading zero bytes from an unsigned length value without adequately preventing the zero count from exceeding the expected byte count. The subtraction underflows, causing the kernel to spin indefinitely. The attacker’s practical outcome is denial of service: affected CPUs may lock up, kernel watchdog messages appear, and the system or hosted services may become unavailable until recovered.

How to fix it

Apply the vendor-provided Linux kernel update that includes the fix for mpi_read_raw_from_sgl(), then reboot into the fixed kernel or apply an equivalent live patch where supported. Because no fixed package versions were provided in the input, use the applicable distribution or kernel vendor advisory to identify the corrected kernel build for each supported release stream. As interim mitigations, reduce local attack surface: restrict untrusted shell access, avoid running untrusted workloads on shared kernels, use seccomp/AppArmor/SELinux policies to block or constrain the keyctl syscall where applications do not require it, and monitor or disable unnecessary asymmetric key operations. Containers should not be considered a complete mitigation if they share the vulnerable host kernel and can invoke keyctl; enforce runtime syscall filtering for untrusted containers.

How to confirm the fix worked

Confirm remediation by verifying that systems booted into a kernel build containing the mpi_read_raw_from_sgl() underflow fix, not merely that the package was installed. Check kernel version and vendor changelog/advisory references for the backported patch. Validate that live patch status, if used, shows the patch applied and active. Where safe and approved, use a non-production test host to confirm that previously triggering KEYCTL_PKEY_ENCRYPT edge-case behavior returns normally or fails safely instead of producing soft lockups. For exposure validation, inventory Linux hosts, identify those with affected kernel versions, determine whether local users or untrusted workloads can execute arbitrary code, and verify whether seccomp or mandatory access control policies block keyctl usage where not needed.

Typical attack path

1. Gain local code execution as an unprivileged user on an affected Linux host.
2. Identify that the kernel exposes the keyctl syscall and asymmetric key pkey operation path.
3. Prepare an all-zero input buffer for the public-key encryption operation.
4. Invoke KEYCTL_PKEY_ENCRYPT with an output length larger than the input length.
5. Trigger the vulnerable MPI scatterlist parsing path in mpi_read_raw_from_sgl().
6. Cause an unsigned integer underflow and kernel spin, leading to soft lockups and service disruption.
7. Force administrators or automation to recover the host through reboot, failover, or workload rescheduling.

How to detect it

To determine whether exploitation may have occurred, review kernel logs, system journal, audit logs, endpoint telemetry, and crash or watchdog records for soft lockups or CPU stalls temporally associated with keyctl public-key encryption operations. Relevant log sources include /var/log/kern.log, /var/log/messages, /var/log/syslog, journalctl -k output, auditd logs for keyctl syscall execution, eBPF/syscall telemetry, EDR process telemetry, and crash dump/kdump data if collected. Look for watchdog reports, hung task messages, RCU stalls, unexplained reboots, or service outages with stack traces referencing mpi_read_raw_from_sgl(), rsa_enc(), crypto_akcipher_encrypt(), crypto_akcipher_sync_prep(), or keyctl_pkey_e_d_s(). If auditd syscall logging is enabled, investigate bursts or unusual invocations of keyctl, especially by non-administrative users, containerized workloads, test binaries, or processes that normally do not use the kernel keyring or asymmetric key APIs. Absence of these artifacts does not prove non-exploitation because kernel lockups can prevent complete log flushing.

• mpi_read_raw_from_sgl
• rsa_enc
• crypto_akcipher_encrypt
• crypto_akcipher_sync_prep
• crypto_akcipher_sync_encrypt
• software_key_eds_op
• asymmetric_key_eds_op
• keyctl_pkey_e_d_s
• sys_keyctl
• KEYCTL_PKEY_ENCRYPT
• watchdog: BUG: soft lockup
• BUG: soft lockup
• soft lockup - CPU#
• INFO: rcu_sched detected stalls
• INFO: rcu_preempt detected stalls
• kernel: watchdog: BUG: soft lockup
• audit: SYSCALL arch=.* syscall=.* keyctl
• type=SYSCALL msg=.* comm="keyctl"
• /var/log/kern.log
• /var/log/messages
• /var/log/syslog

What your security team should do

• Prioritize patching business-critical Linux systems, shared multi-user servers, virtualization/container hosts, CI/CD runners, and systems that run untrusted workloads.
• Verify that patched systems have been rebooted into the fixed kernel or have an active live patch; do not rely only on package installation state.
• Deploy or tighten seccomp profiles to deny the keyctl syscall for containers and services that do not require kernel keyring functionality.
• Review audit and kernel logs for recent keyctl pkey activity followed by soft lockup, hung task, watchdog, or unexpected reboot events.
• Add monitoring for kernel soft lockup messages containing mpi_read_raw_from_sgl, rsa_enc, crypto_akcipher_encrypt, or keyctl_pkey_e_d_s stack frames.
• Limit local interactive access and arbitrary code execution paths on affected systems until patches are applied.
• Include this issue in Linux kernel vulnerability management tracking, but prioritize according to local-execution exposure given the low EPSS score and absence from CISA KEV at this time.