CVE-2024-53152

What it actually does

Controller cleanup functions (dw_pcie_ep_cleanup and pci_epc_deinit_notify) execute during pex_ep_event_pex_rst_assert when refclk is disabled, causing hardware register accesses on Tegra194 endpoints that lack independent clock and resulting in SoC crash.

Why it matters to the business

Endpoint systems experience crashes during routine host reset sequences, producing instability, downtime, and operational disruption in PCIe-dependent embedded and server deployments.

How an attack unfolds

An attacker controlling the host side asserts PERST# to invoke the flawed cleanup path while refclk is absent, triggering register accesses that crash the endpoint SoC.

How to fix it

Apply the upstream fix that relocates cleanups to the start of pex_ep_event_pex_rst_deassert after resources are enabled; upgrade affected kernel packages to the listed fixed versions such as php5 5.5.9+dfsg-1ubuntu4.16 and php7.0 7.0.4-7ubuntu2.1.

How to confirm the fix worked

Confirm kernel source contains the moved cleanup calls inside pex_ep_event_pex_rst_deassert and verify no register access occurs in the assert path; test PERST# toggle sequences on target hardware.

Typical attack path

1. Host asserts PERST# signal
2. Endpoint invokes pex_ep_event_pex_rst_assert handler
3. Cleanup functions attempt hardware register access without refclk
4. Endpoint SoC crashes due to unclocked register operations

How to detect it

Review kernel logs for PCIe endpoint crashes or register access faults during PERST# events; inspect dmesg and system logs for tegra194 and dw_pcie_ep messages around reset timestamps.

What your security team should do

• Prioritize kernel updates on all Tegra194 endpoint systems before the CISA deadline
• Monitor EPSS trend and threat actor activity for increased exploitation likelihood
• Validate fixed versions in build and deployment pipelines
• Test reset sequences in staging environments matching production hardware