CVE-2025-38080

What it actually does

Buffer overflow in hwss_build_fast_sequence overflows the fixed-size block_sequence array when more than 50 steps are generated (possible on 6-pipe ASICs with all pipes in one MPC chain), corrupting adjacent block_sequence_steps memory and triggering a kernel crash.

Why it matters to the business

Unplanned system crashes and reboots on affected Linux systems with multi-pipe AMD display hardware, causing downtime, loss of work, and degraded user experience; low exploitability keeps widespread impact limited but still requires prompt patching on graphics workstations and servers.

How an attack unfolds

An attacker with local access configures a display setup that triggers generation of more than 50 steps inside hwss_build_fast_sequence (for example by attaching a 6-pipe ASIC with all pipes chained), causing the overflow that corrupts kernel memory and forces a crash; listed threat actors have been observed targeting similar Linux kernel display and privilege-escalation issues but no public weaponization of this specific flaw is known.

How to fix it

Update the Linux kernel to a version containing commit de67e80ab48f1f23663831007a2fa3c1471a7757 or later; for Mageia 5 systems also apply gajim 0.16.5-1.mga5 and python-nbxmpp 0.5.3-1.mga5 packages. Reboot after kernel update and verify the fix is active by checking the running kernel version.

How to confirm the fix worked

Confirm the running kernel contains commit de67e80ab48f1f23663831007a2fa3c1471a7757, then exercise display mode-setting with a 6-pipe configuration while monitoring for crashes; review kernel logs for absence of block_sequence-related panics.

Typical attack path

1. Obtain local user access on a Linux system with vulnerable AMD display driver
2. Configure or attach a multi-pipe ASIC display topology that forces hwss_build_fast_sequence to exceed 50 steps
3. Trigger the display initialization or mode-setting path that calls the vulnerable function
4. Induce kernel memory corruption leading to panic or crash

How to detect it

Search kernel logs (dmesg, /var/log/kern.log, journalctl) for panic messages referencing block_sequence or hwss_build_fast_sequence around display initialization events; correlate with AMD GPU driver load events on multi-pipe hardware.

What your security team should do

• Prioritize kernel updates on all systems with AMD display hardware within the next patch cycle
• Monitor EPSS and KEV feeds for any future rise in exploit maturity
• Restrict local user access on multi-GPU or multi-pipe display workstations until patches are applied
• Include the fixed commit hash in automated kernel version checks and SBOM scans