CVE-2026-63805

What it actually does

This is a local Linux kernel memory-corruption flaw in the NX crypto driver cleanup path. The vulnerable code passes an NX crypto context pointer to a function that incorrectly treats it as a different kernel crypto object type, causing invalid memory access during crypto transform teardown. The observed failure path is reachable when AF_ALG sockets using hash or cipher crypto operations are released, producing a kernel oops in functions such as nx_crypto_ctx_shash_exit or nx_crypto_ctx_skcipher_exit. Because the bug occurs in kernel space, the worst-case technical impact is local privilege escalation, kernel memory disclosure or corruption, and system crash; the CVSS vector indicates a local, low-complexity attack requiring a low-privileged local user and no user interaction.

Why it matters to the business

Systems running affected Linux kernels may be vulnerable to local attacks that can crash workloads or potentially allow a low-privileged user or compromised application account to gain elevated control of the host. This is most relevant to multi-user Linux systems, shared compute platforms, container hosts, CI/CD runners, high-performance computing environments, and servers where untrusted users or workloads can execute local code. It is not listed in CISA KEV, is not currently associated with ransomware use, has no known mature public exploit in the supplied data, and has a low EPSS score, so internet-scale exploitation is unlikely; however, kernel privilege-escalation bugs should still be prioritized where local code execution by untrusted users is possible.

How an attack unfolds

An attacker first needs the ability to run code locally on a vulnerable Linux system, for example through a normal shell account, a compromised service account, or code execution inside a workload that can access the relevant kernel crypto interfaces. The attacker then causes the kernel to allocate and later destroy affected crypto transform state through the AF_ALG interface or another path that exercises the NX crypto shash or skcipher teardown routines. During cleanup, the kernel passes the wrong type of context into the NX crypto cleanup function, leading to invalid pointer interpretation and memory access in kernel mode. In observed cases this produces a kernel oops and denial of service. If an attacker can shape the surrounding kernel heap state and object lifecycle reliably, the same class of memory-corruption condition may be explored for privilege escalation or kernel memory compromise, although no public mature exploit is indicated by the provided intelligence.

How to fix it

Apply the vendor-supplied Linux kernel update that includes the fix for the NX crypto context cleanup type mismatch. Because no exact fixed package versions were supplied, use the security advisory and package metadata from the relevant Linux distribution, appliance vendor, cloud image provider, or kernel maintainer to identify the corrected kernel build. Reboot systems into the patched kernel after installation; simply installing the package is not sufficient if the host continues running the old kernel. Where immediate patching is not possible, reduce exposure by preventing untrusted local users or workloads from running on affected hosts, disabling or restricting access to AF_ALG where feasible, unloading or disabling the affected NX crypto driver if it is not required and the platform supports doing so safely, and applying container/namespace/seccomp policies that block creation of AF_ALG sockets for untrusted workloads. Validate all mitigations carefully because crypto subsystem changes can affect applications that rely on kernel cryptographic acceleration.

How to confirm the fix worked

Confirm the running kernel, not only the installed kernel package, contains the fix. On Linux systems, compare `uname -a` and distribution package information against the vendor advisory for this vulnerability. Verify the system has been rebooted into the corrected kernel after patching. Check whether the affected NX crypto module or driver is present or loaded using standard module and kernel configuration inspection tools such as `lsmod`, `/proc/modules`, `/boot/config-*`, and `/proc/crypto`. Review whether untrusted workloads can create AF_ALG sockets; where seccomp or container policies are used as mitigation, test that AF_ALG socket creation is denied for untrusted execution contexts. Review kernel logs for absence of recurring oops traces involving `nx_crypto_ctx_shash_exit`, `nx_crypto_ctx_skcipher_exit`, `crypto_destroy_tfm`, `af_alg_release`, or `alg_sock_destruct` after the update.

Typical attack path

1. Gain local code execution on a vulnerable Linux host as a low-privileged user or workload.
2. Confirm the system uses an affected kernel build and has the NX crypto driver and AF_ALG crypto interface available.
3. Create or use kernel crypto transform objects through AF_ALG or another crypto API path that reaches the NX shash or skcipher implementation.
4. Trigger release/destruction of the crypto object, such as by closing the associated socket or process resources.
5. Cause the vulnerable cleanup routine to mis-handle the crypto context pointer, resulting in kernel memory corruption or a kernel oops.
6. Leverage the condition for denial of service, or attempt further exploitation to gain elevated kernel privileges.

How to detect it

Look for evidence of prior exploitation or triggering in kernel logs, crash dumps, audit telemetry, and endpoint process history. Primary sources include `dmesg`, journald kernel logs, `/var/log/kern.log`, `/var/log/messages`, `/var/log/syslog`, kdump/vmcore artifacts, ABRT/apport crash records, auditd logs, and EDR telemetry showing local processes creating AF_ALG sockets shortly before a kernel oops or reboot. Search for oops traces that include `nx_crypto_ctx_shash_exit`, `nx_crypto_ctx_skcipher_exit`, `crypto_shash_exit_tfm`, `crypto_destroy_tfm`, `crypto_exit_ahash_using_shash`, `hash_release`, `alg_sock_destruct`, `af_alg_release`, or `sock_close` in the same stack. Correlate timestamps with local user sessions, recently started containers, CI jobs, cryptographic test tools, suspicious binaries, or repeated process crashes. Unexpected reboots, kernel panics, or repeated oops messages on systems running vulnerable kernels should be investigated, especially if they occur after activity by untrusted users or workloads. No specific public exploit tool, filename, command line, IP address, or malware indicator is derivable from the supplied information.

• BUG: Unable to handle kernel data access
• Oops: Kernel access of bad area
• nx_crypto_ctx_shash_exit
• nx_crypto_ctx_skcipher_exit
• crypto_shash_exit_tfm
• crypto_destroy_tfm
• crypto_exit_ahash_using_shash
• hash_release
• alg_sock_destruct
• af_alg_release
• __sk_destruct
• AF_ALG
• Faulting instruction address: 0xc000000000396cb4
• Kernel access of bad area, sig: 11

What your security team should do

• Inventory Linux systems that run kernels with the NX crypto driver, especially PowerPC or IBM platforms where NX crypto acceleration is commonly present.
• Prioritize patching shared, multi-tenant, developer-accessible, CI/CD, container-host, HPC, and bastion systems where low-privileged local users or untrusted workloads can execute code.
• Apply the appropriate vendor kernel update and reboot into the patched kernel; track remediation by running kernel version, not package installation status alone.
• If patching is delayed, restrict untrusted local code execution and consider seccomp or workload policies that block AF_ALG socket creation for untrusted containers and services.
• Monitor kernel logs and crash reports for oops traces containing NX crypto teardown functions and AF_ALG release paths.
• Treat any unexplained kernel oops on affected systems as a potential security event until correlated with patch status, local user activity, and workload behavior.
• Because this is not currently KEV-listed, has low EPSS, and has no supplied mature exploit status, prioritize based on local-execution exposure rather than broad internet exposure.