CVE-2026-43336

What it actually does

This flaw leaves a ChaCha cipher intermediate value, `permuted_state`, on the Linux kernel stack after use. Because the ChaCha permutation is invertible, that leftover stack data may be sufficient to reconstruct the original cryptographic state, including key material, if an attacker can later read the affected kernel stack memory through another information-disclosure path. The vulnerability is primarily a confidentiality issue: it does not directly provide code execution, privilege escalation, or denial of service, but it can weaken kernel cryptographic protections by allowing sensitive material to remain recoverable from memory longer than necessary.

Why it matters to the business

Systems running affected Linux kernels may expose sensitive cryptographic material if an attacker can obtain kernel memory, increasing the risk of credential, session, or encryption-key compromise. The practical risk depends heavily on whether an attacker has a way to read kernel memory, but because Linux kernels are widely deployed across servers, appliances, cloud workloads, containers, and embedded systems, unpatched exposure can have broad operational impact. This issue is not listed in CISA KEV, is not known to be used in ransomware campaigns, and currently has low EPSS probability, so it should be prioritized as a defense-in-depth confidentiality fix rather than treated as an actively exploited emergency.

How an attack unfolds

An attacker first needs access to a system or service path that can cause the kernel to execute the affected ChaCha code path, such as cryptographic operations involving kernel RNG or ChaCha-based primitives. The vulnerable code leaves the invertible `permuted_state` value in stack memory after the operation completes. By itself, that does not expose the key externally; the attacker must also have or trigger a separate kernel memory disclosure primitive, such as an uninitialized stack leak, out-of-bounds read, debug interface exposure, crash dump leakage, or another vulnerability that reveals kernel stack contents. If the stale stack bytes are recovered before they are overwritten, the attacker can use the invertibility of the ChaCha permutation to reconstruct the original internal state and potentially recover sensitive key material. That recovered material could then be used to undermine confidentiality of data or security mechanisms relying on the affected cryptographic state.

How to fix it

Upgrade the Linux kernel to a vendor-provided fixed release that includes the change to explicitly zeroize `permuted_state` before it leaves scope in the ChaCha implementation. Because no universal fixed version is provided for all distributions, use the applicable Linux distribution, appliance, cloud image, or kernel vendor advisory to identify the corrected package version. Where immediate patching is not possible, reduce exposure to kernel memory disclosure by disabling unnecessary debug interfaces, restricting access to crash dumps and kernel logs, enforcing kernel hardening options, limiting unprivileged access to attack surfaces that may trigger kernel memory leaks, and applying available mitigations for related information-disclosure vulnerabilities. Reboot systems after installing the fixed kernel so the patched code is actually running.

How to confirm the fix worked

Confirm remediation by verifying that the running kernel, not only the installed package, matches a vendor release that contains the fix. Check `uname -r` and compare it with the distribution advisory or package changelog for the backported patch. Where source validation is possible, confirm the kernel tree includes an explicit zeroization of `permuted_state` in the ChaCha implementation under `lib/crypto`. For fleets, inventory all Linux kernel versions, including container hosts, hypervisors, appliances, and custom kernels, and ensure each maps to a patched vendor build. After patching, reboot and re-check the active kernel version; live patching should be validated through the live patch vendor’s status tooling and advisory documentation.

Typical attack path

1. Identify a target running an affected Linux kernel version.
2. Reach or trigger code paths that use the kernel ChaCha implementation, potentially through networking, cryptographic, or random-number-generation activity.
3. Use a separate memory-disclosure capability to read kernel stack contents after the ChaCha operation has completed.
4. Search the leaked memory for residual ChaCha `permuted_state` data.
5. Invert the ChaCha permutation offline to reconstruct the original state and recover sensitive cryptographic material.
6. Use recovered secrets to decrypt protected data, impersonate trusted activity, or support further compromise.

How to detect it

There are no reliable standalone exploitation indicators for this flaw because it leaves sensitive data in kernel stack memory and normally requires a second memory-disclosure mechanism to extract it. Detection should focus on evidence of kernel memory leakage, abnormal access to crash dumps, debugging interfaces, kernel logs, and suspicious collection of diagnostic artifacts. Review audit logs, EDR telemetry, shell history, process execution records, and file access logs for access to `/proc/kcore`, `/dev/mem`, `/dev/kmem`, crash dump directories, `kdump` output, `debugfs`, tracing interfaces, and kernel log buffers. Investigate kernel warnings, oopses, panics, or repeated crashes around the time of suspicious activity, especially if followed by archive, compression, or exfiltration of dump files. Also review exploitation attempts or alerts for other kernel information-disclosure vulnerabilities on the same hosts, because those could provide the read primitive needed to extract the residual ChaCha state. Named threat actor activity and ransomware use have not been reported for this CVE based on the provided data.

What your security team should do

• Inventory all Linux systems and identify kernels from vendors or builds affected by the ChaCha stack zeroization issue.
• Prioritize patching internet-facing, multi-tenant, high-sensitivity, cryptography-heavy, and untrusted-workload hosts first.
• Apply vendor kernel updates and reboot into the fixed kernel; do not rely solely on package installation status.
• Review and reduce kernel memory disclosure risks by disabling unnecessary debugfs, kdump exposure, kernel pointer leaks, and overly permissive access to kernel logs or crash artifacts.
• Correlate this issue with any known or recently patched kernel information-disclosure vulnerabilities, because exploitation is most realistic when paired with another memory leak.
• For custom kernels, backport the upstream fix that zeroizes `permuted_state` before scope exit and rebuild all derived images.
• Monitor vendor advisories for distribution-specific fixed versions because this issue may be backported without changing the upstream kernel version string.
• Treat recovered kernel memory dumps, crash dumps, and diagnostic bundles as sensitive because they may contain residual cryptographic material from affected systems.