CVE-2024-36914

What it actually does

Uninitialized memory access in AMD display driver leads to slab-out-of-bounds read/write when writeback connectors are present because certain features are not initialized for that connector type.

Why it matters to the business

Kernel memory corruption or crashes on Linux systems with AMD GPUs can cause system instability, denial of service, or potential escalation if the out-of-bounds access is leveraged, affecting servers, desktops, and embedded devices using the affected kernel versions.

How an attack unfolds

An attacker with local access or the ability to influence display configuration triggers the AMD display code path that encounters a writeback connector; the missing initialization check allows KASAN-detected out-of-bounds access which, under certain conditions, could be turned into memory corruption for privilege escalation or denial of service, as noted in campaigns by espionage and financially motivated actors targeting Linux kernel flaws.

How to fix it

Update the Linux kernel to a version containing commit 87de0a741ef6d93fcb99983138a0d89a546a043c which adds the connector type check to skip writeback connectors when the feature is not applicable; apply the fix across all stable branches and rebuild custom kernels as needed.

How to confirm the fix worked

Verify the running kernel contains commit 87de0a741ef6d93fcb99983138a0d89a546a043c or later equivalent; inspect dmesg or kernel logs after loading the amdgpu module for absence of KASAN slab-out-of-bounds reports on writeback connectors; confirm connector type handling in drm/amd/display code.

Typical attack path

1. Obtain local code execution or user-level access on a Linux system with AMD display hardware
2. Configure or trigger a display mode that activates a writeback connector
3. Invoke the drm/amd/display code path that skips initialization for writeback connectors
4. Trigger the uninitialized memory access leading to slab-out-of-bounds condition
5. Leverage resulting memory corruption for further exploitation or cause kernel panic

How to detect it

Search kernel logs and KASAN output for slab-out-of-bounds messages referencing drm/amd/display or writeback connectors; review audit logs for unusual display mode changes or amdgpu module activity around the time of any crashes; correlate with threat actor patterns involving Linux kernel memory issues.

What your security team should do

• Prioritize kernel updates containing the referenced commit within the next patch cycle due to potential memory corruption impact
• Monitor for KASAN reports or kernel oops involving amdgpu and writeback connectors
• Restrict unprivileged access to display configuration interfaces where possible until patched
• Review downstream dependent packages and rebuild any custom kernels or modules after applying the fix