CVE-2026-46068

What it actually does

This Linux kernel flaw is a memory-management bug in the NX 842 crypto/compression path. The driver allocates multi-page bounce buffers with an order-2 allocation but frees them as single pages, leaving part of each allocation unreleased. A local user who can cause repeated creation and destruction of affected NX 842 crypto contexts may consume kernel memory over time, potentially causing memory pressure, process termination by the OOM killer, system instability, or denial of service. Because the bug is in kernel memory handling, successful abuse can affect the whole host, not just the invoking process.

Why it matters to the business

Exploitation can make affected Linux systems unstable or unavailable, which may interrupt workloads, degrade performance, or force emergency reboots. The risk is most relevant on systems using the affected NX 842 crypto/compression support, particularly platforms where that hardware acceleration path is enabled. This issue is not currently listed in CISA KEV, is not known to be used in ransomware campaigns, has no known public exploit maturity, and has a low EPSS score, so broad internet-scale exploitation is unlikely; however, local attackers or malicious workloads on shared systems can still use it to create operational impact.

How an attack unfolds

An attacker first obtains local code execution with low privileges, such as a shell, a compromised service account, or the ability to run a workload on an affected Linux host. The attacker then identifies whether the system exposes or uses the affected NX 842 crypto/compression functionality. If available, they repeatedly trigger allocation and teardown of NX 842 crypto contexts. Each cycle allocates bounce buffers and then frees them incorrectly, leaving some pages leaked. By looping this operation, the attacker steadily consumes kernel memory. As memory pressure rises, the host may log allocation failures, kill processes through the OOM killer, degrade in performance, or become unstable enough to require administrative intervention or reboot. There is no indication from the provided data that public exploit code or active exploitation is currently widespread.

How to fix it

Upgrade the Linux kernel to a vendor-supported version that includes the fix for the NX 842 bounce-buffer free logic, where order-2 allocations are released with free_pages() using the matching order instead of free_page(). No specific fixed package versions were provided, so use the relevant Linux distribution or appliance vendor advisory as the source of truth. If immediate patching is not possible, reduce exposure by disabling, unloading, or blacklisting the affected NX 842 crypto/compression module where it is not required; limiting local interactive access; restricting untrusted workloads; and ensuring memory pressure/OOM monitoring is active. Rebooting may be required after kernel update or as a temporary recovery action if memory has already been leaked.

How to confirm the fix worked

Confirm that the running kernel version is the vendor-fixed build, not only that an updated package is installed on disk. Where source or vendor patches are available, verify that the NX 842 crypto context cleanup path frees bounce buffers with the correct allocation order. Check whether NX 842-related modules or hardware-accelerated compression paths are loaded or enabled. For functional validation, run a controlled repeated allocation/free workload for the affected crypto/compression path on a test system and confirm that available memory does not steadily decline and no kernel allocation failure or OOM messages appear. Also validate that mitigation controls, such as module blacklisting, remain effective after reboot.

Typical attack path

1. Gain local low-privileged execution on an affected Linux system.
2. Determine whether the affected NX 842 crypto/compression driver or module is present and usable.
3. Invoke an interface or workload path that repeatedly creates NX 842 crypto contexts.
4. Force repeated teardown of those contexts so the vulnerable free path is exercised.
5. Accumulate leaked kernel pages over time.
6. Cause memory pressure, OOM events, service disruption, host instability, or denial of service.

How to detect it

Detection is challenging because exploitation does not necessarily create unique files, network traffic, or authentication artifacts. Focus on host telemetry and kernel logs. Review syslog, journald, dmesg, audit logs, EDR process telemetry, and resource monitoring for repeated memory pressure, kernel page allocation failures, OOM killer activity, or crashes following activity by local users or workloads. Correlate unexplained memory depletion with processes that repeatedly use compression, crypto, or hardware-accelerated NX 842 functionality. On shared systems, investigate users, containers, jobs, or services that rapidly create and destroy compression/crypto contexts or show tight looping behavior before OOM events. If threat hunting across a fleet, start with systems running affected kernels where NX 842 modules are loaded and look for abnormal memory exhaustion without corresponding user-space memory growth.

• nx842
• nx-842
• crypto: nx
• page allocation failure
• Out of memory
• oom-killer
• Killed process
• Memory allocation failure
• allocation failed
• invoked oom-killer
• kernel: Out of memory
• dmesg: page allocation failure

What your security team should do

• Prioritize patching affected Linux systems where untrusted local users, containers, build jobs, HPC jobs, or multi-tenant workloads can execute code.
• Confirm whether NX 842 crypto/compression support is enabled or loaded; systems without this path exposed are lower risk.
• Apply the vendor-fixed kernel and reboot into it during the next maintenance window, or sooner for shared systems with untrusted local execution.
• If patching is delayed, disable or blacklist the affected NX 842 functionality where operationally safe.
• Monitor for unexplained memory pressure, repeated OOM kills, kernel page allocation failures, or service instability on potentially affected hosts.
• Treat suspected exploitation primarily as local denial-of-service activity unless other evidence indicates broader compromise.
• Because this is not KEV-listed, not ransomware-associated, and has low EPSS at the time of assessment, prioritize based on exposure to local untrusted code rather than internet exposure alone.