CVE-2024-47667

What it actually does

Inbound PCIe TLPs spanning more than two internal AXI 128-byte bursts can corrupt packet payload on affected AM65x SR 1.0 silicon, potentially hanging applications or the processor.

Why it matters to the business

Systems using the affected hardware may experience unexpected hangs or data corruption during PCIe transfers, leading to downtime and reduced reliability in embedded or industrial deployments; the low EPSS and absence from KEV indicate limited active exploitation risk but the 733 days since publication underscore the need to apply the fix promptly in affected environments.

How an attack unfolds

An attacker with the ability to send crafted inbound PCIe TLPs on affected AM65x/DRA80xM hardware triggers the errata by exceeding two AXI bursts, causing payload corruption that may lead to application or system hangs; threat actor references to espionage and financial campaigns highlight potential interest in Linux kernel environments though no specific actor exploitation of this errata is confirmed.

How to fix it

Update the Linux kernel to the fixed commit cfb006e185f64edbbdf7869eac352442bc76b8f6 which adds the workaround limiting maximum read request size and maximum payload size to 128 bytes; the errata is hardware-specific to AM65x SR 1.0 and later silicon revisions are unaffected.

How to confirm the fix worked

Verify the kernel commit cfb006e185f64edbbdf7869eac352442bc76b8f6 is present and confirm via PCIe configuration registers that MRRS and MPS are limited to 128 bytes on AM65x SR 1.0 hardware.

Typical attack path

1. Identify systems running AM65x SR 1.0 silicon with PCIe inbound traffic enabled.
2. Craft and transmit PCIe TLPs larger than two 128-byte AXI bursts.
3. Trigger payload corruption leading to application or processor hang.

How to detect it

Review kernel logs for PCIe-related hangs or corruption messages on AM65x hardware; check git history for absence of the workaround commit; threat actor references to Linux kernel issues can guide broader log searches but no specific IOCs apply here.

What your security team should do

• Prioritize patching affected AM65x SR 1.0 systems to the fixed commit to enforce the 128-byte size limits.
• Inventory hardware using the vulnerable silicon revision and schedule upgrades for later revisions where possible.
• Monitor EPSS trend (stable at 0.0021) and threat actor mentions for any change in exploitation likelihood.