CVE-2026-53310

What it actually does

This flaw is a Linux kernel denial-of-service issue in the NVIDIA Tegra CBB interconnect error-handling path. When a Tegra fabric receives an error interrupt for an error that actually occurred on a different fabric, the kernel used the wrong register base address while looking up target-timeout information. That incorrect address calculation can cause an invalid kernel memory access and a kernel page fault, potentially leading to an oops, panic, or system crash on affected Tegra-based systems.

Why it matters to the business

Affected embedded, edge, automotive, robotics, or appliance platforms using vulnerable Linux kernels on Tegra hardware may experience unexpected crashes or reboots when the vulnerable error path is triggered. The practical risk is service interruption rather than data theft. Current public exploitation indicators are low: EPSS is very low, it is not listed in CISA KEV, no ransomware association is reported, and no public exploit maturity is identified.

How an attack unfolds

An attacker would need a way to trigger or induce a Tegra CBB fabric error condition that causes the kernel interrupt handler to process an error associated with a different fabric. When the interrupt handler runs, the vulnerable code uses offsets from one fabric's target map against another fabric's base register address. That incorrect lookup can dereference an invalid kernel virtual address during timeout-slave resolution, producing a kernel paging fault in the Tegra CBB error handler. Depending on kernel configuration and panic-on-oops behavior, the result may be a kernel oops, service degradation, or a full system crash/reboot. There is no indication from the provided intelligence that this is remotely exploitable in a product-wide default configuration, and exploitation is expected to be highly platform- and access-dependent.

How to fix it

Update the Linux kernel to a version or vendor-maintained kernel package that includes the upstream fix for the Tegra CBB cross-fabric target-timeout lookup. Because no exact affected products or fixed package versions were provided, use the relevant Linux distribution, BSP, SoC vendor, or device-vendor advisory to identify the corrected kernel build. Where immediate patching is not possible, reduce exposure by limiting untrusted local access to affected Tegra systems, restricting access to device interfaces that can generate fabric errors, disabling unnecessary peripherals, and monitoring for repeated Tegra CBB faults or kernel oops events. Consider configuring high-availability or watchdog recovery for systems where a crash would cause operational disruption.

How to confirm the fix worked

Confirm remediation by verifying that the running kernel includes the patch that adds correct fabric lookup for Tegra234 CBB target-timeout handling, including use of the correct fabric device base address when accessing timeout registers. Validate the installed kernel package against the vendor advisory or source commit history. On a test device, review boot and runtime kernel logs to ensure Tegra CBB error handling no longer produces page faults in tegra234_cbb_get_tmo_slv, print_err_notifier, or tegra234_cbb_isr. Confirm that the system remains stable during normal peripheral and interconnect stress testing. For fleet validation, inventory Tegra-based Linux devices and compare their kernel builds against vendor-fixed releases.

Typical attack path

1. Identify a Linux-based system running on affected NVIDIA Tegra hardware with the vulnerable Tegra CBB driver code.
2. Obtain a means to trigger CBB/interconnect fabric error interrupts, such as through local device interaction, driver-accessible hardware paths, or workload conditions that can produce target timeouts.
3. Trigger an error where the reporting fabric and the fabric associated with the target-timeout lookup differ.
4. Cause the vulnerable interrupt handler to use the wrong fabric base address for timeout-register access.
5. Induce a kernel page fault in the Tegra CBB error handling path, causing an oops, panic, reboot, or denial of service.

How to detect it

Look for evidence of kernel crashes or oops events involving the Tegra CBB error-handling path. Relevant log sources include kernel ring buffer output, persistent journald logs, syslog, crash dump storage, kdump/vmcore repositories, device watchdog logs, BMC or out-of-band reboot records, and platform health telemetry. Search for kernel paging requests, call traces, and function names associated with the vulnerable path, especially tegra234_cbb_get_tmo_slv, print_err_notifier, and tegra234_cbb_isr. Correlate any such events with unexpected reboots, watchdog resets, peripheral activity, stress workloads, or local user/device interactions shortly before the crash. Because no public exploit artifacts or actor-specific indicators are provided, detection should focus on behavioral evidence of exploitation or accidental triggering rather than known malicious payloads.

• Unable to handle kernel paging request at virtual address
• tegra234_cbb_get_tmo_slv
• print_err_notifier
• tegra234_cbb_isr
• soc/tegra: cbb
• kernel paging request
• Call trace:
• Kernel panic - not syncing
• Oops:
• watchdog: watchdog0: watchdog did not stop

What your security team should do

• Prioritize patching Tegra-based production systems where unexpected reboot or service interruption would create safety, availability, or operational risk.
• Use vendor kernel/BSP advisories to identify the fixed kernel release because exact fixed versions were not provided in the input intelligence.
• Inventory Linux systems running on NVIDIA Tegra/Tegra234-class platforms and flag those using vulnerable or unverified kernels.
• Restrict untrusted local shell, container, peripheral, debug, and device-node access on affected embedded systems until patched.
• Add monitoring for kernel oops, panic, and Tegra CBB error-handler stack traces to detect attempted or accidental triggering.
• Treat this as an availability-focused vulnerability; escalate urgency if devices are internet-managed, physically exposed, safety-critical, or difficult to reboot manually.
• Because the vulnerability is not currently KEV-listed and has very low EPSS, prioritize based on operational criticality rather than broad internet exploitation risk.