CVE-2026-31739

What it actually does

This vulnerability is in the Linux kernel Tegra crypto driver. The driver registers asynchronous crypto algorithms without marking them with the CRYPTO_ALG_ASYNC flag, allowing the kernel crypto API to select those algorithms for callers that requested only synchronous crypto behavior. When a synchronous caller receives an asynchronous implementation unexpectedly, the mismatch can cause kernel crashes and service disruption. Depending on the calling path and kernel configuration, the impact may extend beyond denial of service, but the directly described failure mode is kernel instability or crash when affected crypto operations are exercised.

Why it matters to the business

Systems running affected Linux kernels on NVIDIA Tegra-based platforms can become unstable or crash when vulnerable crypto paths are triggered, causing outages for appliances, embedded systems, edge devices, robotics, IoT gateways, or other services built on Tegra hardware. Although EPSS is currently low and there is no known KEV listing or public exploit maturity, the CVSS severity is high because a kernel-level failure can interrupt critical workloads and may require reboot or manual recovery. Organizations with fleets of Tegra-based Linux devices should prioritize normal kernel patching and ensure exposed services cannot be abused to repeatedly trigger crypto operations.

How an attack unfolds

An attacker first needs a way to cause the target system to perform kernel crypto operations that request synchronous algorithms. This may be through a local account, a container or restricted workload with access to crypto-using kernel interfaces, or a network-facing service that processes attacker-supplied input and relies on affected kernel crypto functionality. Because the Tegra driver incorrectly exposes asynchronous implementations as if they were suitable for synchronous callers, the kernel crypto API can select an incompatible algorithm implementation. When the caller invokes the operation and expects synchronous completion semantics, the mismatch can lead to a kernel fault, crash, or system instability. Repeating the trigger can produce sustained denial of service until the kernel is patched, the vulnerable driver is disabled, or the reachable crypto path is otherwise blocked.

How to fix it

Upgrade to a Linux kernel or vendor-provided kernel package that includes the Tegra crypto driver fix adding CRYPTO_ALG_ASYNC to the affected asynchronous algorithms. No exact fixed package versions were provided in the input, so use the relevant distribution, device vendor, BSP, or long-term kernel advisory to identify the patched build for each platform. Where immediate patching is not possible, reduce exposure by disabling or blacklisting the affected Tegra crypto driver if operationally safe, disabling hardware crypto acceleration for affected algorithms where supported, limiting untrusted access to services that heavily exercise kernel crypto, isolating untrusted workloads, and applying standard kernel hardening and reboot-on-panic controls appropriate for availability requirements.

How to confirm the fix worked

Confirm that systems are running a vendor kernel containing the Tegra crypto driver correction. Review kernel package changelogs or source patches for the addition of CRYPTO_ALG_ASYNC to Tegra asynchronous crypto algorithm registrations. On running systems, verify the loaded kernel version and vendor build against the patched advisory. Confirm whether Tegra crypto modules are loaded or built in, and whether the platform actually uses Tegra hardware crypto acceleration. After patching, perform controlled regression testing of crypto-dependent workloads and confirm there are no kernel oops, panic, or crypto API errors under load. Vulnerability scanners should treat unpatched affected Linux kernel builds on Tegra platforms as exposed.

Typical attack path

1. Identify a Linux system running an affected kernel on Tegra hardware with the vulnerable crypto driver available.
2. Find a local interface, container boundary, application feature, VPN/TLS/IPsec/storage encryption path, or other service that causes the kernel to perform crypto operations.
3. Submit crafted or repeated requests that exercise synchronous crypto API callers likely to select the affected Tegra implementation.
4. Trigger the async-versus-sync mismatch in the kernel crypto path.
5. Cause a kernel oops, panic, service interruption, reboot, or repeated instability.
6. Repeat the trigger to maintain denial of service if the vulnerable path remains reachable.

How to detect it

To determine whether this was already exploited or triggered, review kernel logs, persistent journal entries, crash dumps, and device management telemetry for unexplained reboots, kernel oopses, panics, or crypto subsystem faults on Tegra-based systems. Useful sources include /var/log/kern.log, /var/log/messages, /var/log/syslog, journalctl -k output, pstore/ramoops records, kdump/vmcore artifacts, watchdog reset logs, and application logs from crypto-heavy services immediately preceding a crash. Look for temporal correlation between crashes and repeated client requests to VPN, TLS, IPsec, encrypted storage, authentication, or other crypto-using services. Because no public exploit or unique payload is described, detection should focus on kernel crash signatures involving the Tegra crypto driver, the Linux crypto API, and repeated availability failures rather than on a definitive network IOC. Distinguish malicious triggering from normal driver bugs by looking for repeated crashes following similar request patterns, activity from the same remote source, or crashes occurring shortly after untrusted workloads invoke crypto functionality.

• tegra crypto
• tegra.*crypto
• CRYPTO_ALG_ASYNC
• crypto: tegra
• kernel: Oops
• kernel: panic
• Kernel panic - not syncing
• BUG: kernel NULL pointer dereference
• Unable to handle kernel NULL pointer dereference
• Internal error: Oops
• Call trace:.*tegra
• Call Trace:.*tegra
• Call trace:.*crypto
• Call Trace:.*crypto
• /sys/fs/pstore
• /proc/vmcore
• /var/crash
• /var/log/kern.log
• /var/log/messages
• /var/log/syslog

What your security team should do

• Inventory Linux systems using NVIDIA Tegra hardware or vendor kernels that include the Tegra crypto driver.
• Map affected kernel versions to vendor advisories and schedule upgrades to patched kernel builds during the next appropriate maintenance window, sooner for internet-facing or safety-critical devices.
• Prioritize devices that run untrusted workloads, containers, VPNs, TLS termination, encrypted storage, IPsec, or other crypto-heavy services.
• If patching is delayed, evaluate disabling the affected Tegra crypto acceleration path or restricting access to services that can trigger kernel crypto operations.
• Monitor kernel logs for oops, panic, crash, crypto API, or Tegra crypto messages, especially following malformed or high-volume requests.
• Validate post-upgrade stability with workload-specific crypto stress tests and confirm the vulnerable driver registration behavior is no longer present.
• Because there is no KEV listing, no known ransomware association, low EPSS, and no public exploit maturity reported, prioritize based on asset criticality rather than emergency internet-wide exploitation risk.