CVE-2026-53051

What it actually does

This flaw is a denial-of-service condition in the Linux kernel PCIe endpoint controller path for NVIDIA Tegra194-based systems. During a repeated PCIe PERST# reset sequence, the driver can access DesignWare DBI registers, including offset 0x8bc / PCIE_MISC_CONTROL_1_OFF, before the PCIe controller core has been powered on with reset_control_deassert(). Because the hardware block is not yet operational, the access can trigger a Control Backbone timeout and destabilize the PCIe endpoint controller or the affected system.

Why it matters to the business

Systems using the affected Tegra194 PCIe endpoint functionality may experience device instability, PCIe endpoint failure, kernel errors, or service interruption when exposed to specific reset sequencing. The risk is primarily availability-related and appears specialized to systems where an attacker, attached host, test harness, or faulty hardware can cause repeated PCIe reset events. Public exploitation is not currently indicated, EPSS is low, and this issue is not listed in CISA KEV, but operational impact can be significant for embedded, edge, automotive, industrial, or appliance platforms that depend on reliable PCIe endpoint operation.

How an attack unfolds

An attacker would need a position that allows them to influence PCIe reset behavior for a Tegra194 device operating in endpoint mode, such as control of the upstream PCIe host, physical access to the PCIe link, or access to a management/test path that can repeatedly assert and deassert PERST#. By causing PERST# to be deasserted, asserted, and deasserted again at the wrong point in the endpoint controller lifecycle, the vulnerable kernel code executes cleanup/deinitialization routines before the PCIe controller core has been powered on. Those routines attempt to access DBI registers, including PCIE_MISC_CONTROL_1_OFF at offset 0x8bc, while the controller is unavailable. The invalid early register access can produce a CBB timeout, leading to PCIe endpoint malfunction or broader system instability. There is no indication from the provided data that this enables code execution or privilege escalation.

How to fix it

Apply a Linux kernel update that includes the fix for the Tegra194 PCIe endpoint reset ordering issue. The corrected behavior moves pci_epc_deinit_notify() and dw_pcie_ep_cleanup() until after reset_control_deassert(pcie->core_rst), ensuring DBI registers are accessed only after the controller core is powered on. If fixed package versions are not yet identified for a distribution or vendor kernel, track the relevant kernel vendor advisory and backport status. As interim mitigations, restrict physical and administrative access to PCIe host/reset controls, avoid untrusted systems acting as upstream PCIe hosts, disable unused PCIe endpoint functionality where feasible, and reduce automated reset cycling in test or production workflows until patched.

How to confirm the fix worked

Confirm that the running kernel includes the patch changing the Tegra194 PCIe endpoint reset-deassert ordering so that controller core reset deassertion occurs before endpoint deinit/cleanup paths that touch DBI registers. Validate using vendor package metadata, kernel changelogs, source inspection, or a controlled regression test that repeats PERST# assert/deassert sequences while monitoring for CBB timeout messages. Successful remediation should show no CBB timeout at DBI offset 0x8bc and no PCIe endpoint controller failure during repeated reset sequencing.

Typical attack path

1. Identify or gain access to a system using the Linux kernel Tegra194 PCIe endpoint controller path.
2. Obtain the ability to influence the upstream PCIe reset signal or otherwise trigger repeated endpoint reset handling.
3. Cause a PERST# sequence such as assert, deassert, assert, deassert.
4. Trigger the vulnerable reset-deassert handling path where endpoint cleanup/deinitialization occurs before the controller core is powered on.
5. Force an early DBI register access, particularly around PCIE_MISC_CONTROL_1_OFF / offset 0x8bc.
6. Cause a CBB timeout and resulting PCIe endpoint failure, kernel error, or service disruption.

How to detect it

Review kernel logs, persistent journald records, serial console output, crash dumps, and hardware error telemetry for signs of CBB timeouts or PCIe endpoint failures following repeated PERST# reset events. Focus on systems using Tegra194 PCIe endpoint mode. Look for messages referencing CBB timeout, DBI access, PCIE_MISC_CONTROL_1_OFF, offset 0x8bc, tegra194 PCIe, DesignWare PCIe endpoint cleanup, or call traces involving pci_epc_deinit_notify(), dw_pcie_ep_cleanup(), dw_pcie_ep_clear_bar(), __dw_pcie_ep_reset_bar(), and dw_pcie_dbi_ro_wr_en(). Correlate suspicious events with physical maintenance, upstream host resets, lab automation jobs, hot reset activity, device enumeration failures, or unexpected endpoint disconnects. Because this is a denial-of-service condition rather than a typical intrusion primitive, absence of a unique attacker artifact is expected; repeated reset-triggered hardware timeouts are the most useful evidence.

• CBB timeout
• DBI register offset 0x8bc
• PCIE_MISC_CONTROL_1_OFF
• dw_pcie_dbi_ro_wr_en
• __dw_pcie_ep_reset_bar
• dw_pcie_ep_clear_bar
• pci_epc_clear_bar
• pci_epf_test_clear_bar
• pci_epf_test_epc_deinit
• pci_epc_deinit_notify
• dw_pcie_ep_cleanup
• pex_ep_event_pex_rst_deassert
• reset_control_deassert
• pcie->core_rst
• tegra194
• PERST#

What your security team should do

• Prioritize patching systems that use NVIDIA Tegra194 PCIe endpoint mode, especially embedded or appliance deployments where PCIe availability is operationally critical.
• Inventory kernels and downstream vendor images that include the Tegra194 PCIe endpoint controller driver and determine whether the reset-ordering fix has been backported.
• Restrict access to PCIe host interfaces, lab automation, hardware management interfaces, and physical paths capable of toggling PERST#.
• Monitor kernel logs for CBB timeout, DBI register access, and Tegra PCIe endpoint reset errors until all exposed systems are updated.
• For high-availability products, run a controlled PERST# reset-cycle validation test after patching to confirm that endpoint operation remains stable.
• Because EPSS is low and the issue is not in CISA KEV, treat this as a targeted availability risk rather than an internet-scale emergency unless affected devices are exposed to untrusted PCIe hosts.