CVE-2026-63805 fixes a Linux kernel crash in the
The National Vulnerability Database published the record on July 19, 2026, with the underlying fix attributed to kernel.org. The NVD has not assigned CVSS v3 or v4 severity data, a CWE classification, or an exploitation assessment. That leaves administrators with a clear stability fix to deploy, but no evidence so far that this issue is being used for privilege escalation or remote compromise.
The practical priority is narrow: Linux administrators running IBM Power Systems with the
The vulnerable code sits in
According to the kernel.org fix description reproduced by NVD, the problem is in
Those are not interchangeable objects. The original cleanup routine then attempted an additional context conversion through
The upstream correction is deliberately small: make
That distinction matters. The CVE title may read like a cryptography vulnerability, but the evidence currently points to a kernel reliability defect during context cleanup, not a demonstrated break in encryption or hashing algorithms.
The supplied call trace travels through
That is a useful operational clue for Power Linux estates. A workload does not need to be explicitly written around the NX driver to encounter the issue. If the system has compatible hardware, the NX acceleration driver is selected and loaded, and an application or library chooses an AF_ALG-backed crypto path, a seemingly routine close operation can expose the bad cleanup logic.
The report also notes a parallel issue in
For incident responders, the signature is a kernel oops rather than an application-level error. The disclosed trace includes an “Unable to handle kernel data access” event and a failure in
Distribution packaging remains the decisive detail. Red Hat Enterprise Linux, SUSE Linux Enterprise, Ubuntu, Debian, IBM Linux distributions, appliance vendors, and managed hosting providers may carry the fix under their own kernel package versions rather than the upstream numbers above. Administrators should consult their vendor’s advisory and package changelog rather than assuming a release number alone maps directly to an installed enterprise kernel.
A quick exposure review on Power Linux should establish three facts: the machine architecture, whether the NX crypto driver is enabled, and whether the vendor kernel has incorporated the backport.
A Windows endpoint running WSL 2 is not made vulnerable merely because WSL runs a Linux kernel. Standard WSL 2 deployments run on x86-64 hardware and do not use the PowerPC-specific NX acceleration driver at the center of CVE-2026-63805. Installing a Linux distribution from the Microsoft Store, using Docker Desktop with WSL integration, or running ordinary Linux command-line tooling on a Windows workstation does not create this exposure.
The caveat is for organizations that manage heterogeneous infrastructure from Windows consoles. A Windows admin workstation using Windows Terminal, OpenSSH, PowerShell remoting, or a browser-based management plane may be responsible for IBM Power Linux guests or physical Power Systems elsewhere in the estate. In that case, the CVE belongs on the Linux patch-management queue, not the Windows endpoint queue.
This is also a reminder that “Linux kernel CVE” is too broad a label for prioritization. Architecture, selected kernel configuration, loaded drivers, and real workload paths determine exposure. The
The immediate milestone is vendor availability of kernels incorporating the 6.18.38 or 7.1.3 stable backports, or later equivalent packages. For IBM Power Linux systems using NX acceleration, schedule that update; for Windows and mainstream x86-64 Linux estates, document the architectural non-exposure and keep patching attention focused where this driver actually runs.
nx-crypto driver used for IBM PowerPC Nest (NX) cryptographic acceleration, but it does not affect ordinary Windows PCs, Windows Server on x86-64, or typical WSL 2 installations. The flaw is a type-handling error during destruction of certain cryptographic contexts that can lead to a kernel oops when an affected PowerPC system closes an AF_ALG crypto socket.The National Vulnerability Database published the record on July 19, 2026, with the underlying fix attributed to kernel.org. The NVD has not assigned CVSS v3 or v4 severity data, a CWE classification, or an exploitation assessment. That leaves administrators with a clear stability fix to deploy, but no evidence so far that this issue is being used for privilege escalation or remote compromise.
The practical priority is narrow: Linux administrators running IBM Power Systems with the
nx_crypto driver enabled should take the next distribution kernel update that contains the upstream backport. Everyone else should resist treating a newly numbered Linux kernel CVE as a universal emergency.
A Bad Pointer on the Way Out
The vulnerable code sits in drivers/crypto/nx/nx.c and drivers/crypto/nx/nx.h, part of Linux’s support for IBM PowerPC Nest hardware cryptographic acceleration. That hardware offload path can accelerate AES and SHA2 operations on compatible Power systems, particularly in pSeries environments.According to the kernel.org fix description reproduced by NVD, the problem is in
nx_crypto_ctx_shash_exit. The function passes the result of crypto_shash_ctx(...) into nx_crypto_ctx_exit, but the former supplies an nx_crypto_ctx * while the latter had been defined to expect a crypto_tfm *.Those are not interchangeable objects. The original cleanup routine then attempted an additional context conversion through
crypto_tfm_ctx, effectively interpreting memory through the wrong type. When the crypto transform was torn down, the invalid conversion could push the kernel into an access to a bad address and produce an oops.The upstream correction is deliberately small: make
nx_crypto_ctx_exit accept the context type it is actually given, then remove the invalid crypto_tfm_ctx conversion. This is not a redesign of Linux cryptography or AF_ALG; it is a targeted repair to teardown handling in a hardware-specific driver.That distinction matters. The CVE title may read like a cryptography vulnerability, but the evidence currently points to a kernel reliability defect during context cleanup, not a demonstrated break in encryption or hashing algorithms.
AF_ALG Makes the Crash Reachable
The fault was observed through Linux’s AF_ALG interface, which exposes kernel cryptographic algorithms through sockets. NVD’s record says the crash surfaced whenhardlink(1) opportunistically used AF_ALG, then closed the relevant socket path.The supplied call trace travels through
nx_crypto_ctx_shash_exit, crypto_destroy_tfm, alg_sock_destruct, af_alg_release, sock_close, and finally the file-descriptor close path. In short, the visible trigger was ordinary process cleanup after a utility accessed the kernel crypto API.That is a useful operational clue for Power Linux estates. A workload does not need to be explicitly written around the NX driver to encounter the issue. If the system has compatible hardware, the NX acceleration driver is selected and loaded, and an application or library chooses an AF_ALG-backed crypto path, a seemingly routine close operation can expose the bad cleanup logic.
The report also notes a parallel issue in
nx_crypto_ctx_skcipher_exit, which likewise received a context it did not expect. The upstream description says that branch apparently went untriggered for years. The patch therefore addresses both hashing and symmetric-cipher cleanup paths before the second variant becomes a field failure.For incident responders, the signature is a kernel oops rather than an application-level error. The disclosed trace includes an “Unable to handle kernel data access” event and a failure in
nx_crypto_ctx_shash_exit. Systems showing comparable PowerPC kernel logs around AF_ALG socket destruction deserve prompt patching and a check of whether nx_crypto is loaded.Fixed Kernel Lines Are Already Identified
NVD’s affected-version data identifies Linux kernel 5.5 and later as affected until the relevant stable fixes, while earlier versions are marked unaffected. The listed corrected release lines are:- Linux kernel 6.18.38 includes the fix for the 6.18 stable series.
- Linux kernel 7.1.3 includes the fix for the 7.1 stable series.
- Linux kernel 7.2-rc1 includes the original upstream correction for the development line.
Distribution packaging remains the decisive detail. Red Hat Enterprise Linux, SUSE Linux Enterprise, Ubuntu, Debian, IBM Linux distributions, appliance vendors, and managed hosting providers may carry the fix under their own kernel package versions rather than the upstream numbers above. Administrators should consult their vendor’s advisory and package changelog rather than assuming a release number alone maps directly to an installed enterprise kernel.
A quick exposure review on Power Linux should establish three facts: the machine architecture, whether the NX crypto driver is enabled, and whether the vendor kernel has incorporated the backport.
uname -m, the running kernel release, loaded-module information, and the build configuration for CONFIG_CRYPTO_DEV_NX are more useful here than a generic vulnerability scanner result.Windows Administrators Can Treat This as a Platform Boundary
For the WindowsForum audience, the key point is architectural.nx-crypto is a Linux kernel driver for IBM PowerPC NX acceleration; it is not part of Windows 11, Windows Server, Hyper-V, BitLocker, CNG, or Microsoft’s x86-64 WSL 2 kernel environment.A Windows endpoint running WSL 2 is not made vulnerable merely because WSL runs a Linux kernel. Standard WSL 2 deployments run on x86-64 hardware and do not use the PowerPC-specific NX acceleration driver at the center of CVE-2026-63805. Installing a Linux distribution from the Microsoft Store, using Docker Desktop with WSL integration, or running ordinary Linux command-line tooling on a Windows workstation does not create this exposure.
The caveat is for organizations that manage heterogeneous infrastructure from Windows consoles. A Windows admin workstation using Windows Terminal, OpenSSH, PowerShell remoting, or a browser-based management plane may be responsible for IBM Power Linux guests or physical Power Systems elsewhere in the estate. In that case, the CVE belongs on the Linux patch-management queue, not the Windows endpoint queue.
This is also a reminder that “Linux kernel CVE” is too broad a label for prioritization. Architecture, selected kernel configuration, loaded drivers, and real workload paths determine exposure. The
CONFIG_CRYPTO_DEV_NX feature is tied to PowerPC hardware support, not to generic Linux cryptography on Intel or AMD servers.Patch the Affected Power Hosts, Then Move On
CVE-2026-63805 is worth fixing because a kernel oops can interrupt workloads and because cryptographic offload drivers can be exercised indirectly by applications. But the present record does not justify claims of a broad Linux compromise, a Windows vulnerability, or an urgent fleet-wide response across unrelated architectures.The immediate milestone is vendor availability of kernels incorporating the 6.18.38 or 7.1.3 stable backports, or later equivalent packages. For IBM Power Linux systems using NX acceleration, schedule that update; for Windows and mainstream x86-64 Linux estates, document the architectural non-exposure and keep patching attention focused where this driver actually runs.
References
- Primary source: NVD / Linux Kernel
Published: 2026-07-20T01:01:30-07:00
NVD - CVE-2026-63805
nvd.nist.gov
- Security advisory: MSRC
Published: 2026-07-20T01:01:30-07:00
Original feed URL
Security Update Guide - Microsoft Security Response Center
msrc.microsoft.com
