CVE-2023-52816

What it actually does

The flaw permits an excessively large shift exponent (255) on a 64-bit unsigned long in svm_range_split_by_granularity, triggering UBSAN shift-out-of-bounds handling during GPU memory range operations in the amdgpu driver.

Why it matters to the business

Systems using AMD GPUs may experience kernel warnings, instability, or crashes during memory migration or page-fault handling, leading to operational downtime and potential loss of GPU-accelerated workloads.

How an attack unfolds

An attacker triggers memory operations that invoke svm_migrate_to_ram and subsequently svm_range_split_by_granularity with crafted granularity values, causing the oversized shift; the supplied threat actor reference does not align with public exploitation data for this issue.

How to fix it

Update to a kernel containing the referenced fix; for the listed foosel/octoprint (GIT) packages apply commit 506648c152681bf4b1416cf2b5aaf97d526ee752 or later.

How to confirm the fix worked

Confirm the fix by verifying the absence of the UBSAN shift-out-of-bounds report in dmesg when exercising svm_range_split_by_granularity paths; check installed kernel or package versions against the supplied fixed commits.

Typical attack path

1. Identify a target system running a vulnerable Linux kernel with amdgpu loaded
2. Perform GPU memory allocation or migration operations that reach svm_range_split_by_granularity
3. Supply a granularity value producing shift exponent 255
4. Trigger page fault handling path to execute the invalid shift

How to detect it

Search kernel logs for the exact message 'shift exponent 255 is too large for 64-bit type' and stack frames containing svm_range_split_by_granularity or send_exception_work_handler; correlate with page-fault activity on AMD GPUs.

• shift exponent 255 is too large for 64-bit type 'long unsigned int'
• svm_range_split_by_granularity.cold
• send_exception_work_handler [amdgpu]

What your security team should do

• Apply the listed fixed versions or kernel patches immediately given the public stack trace
• Monitor EPSS trend (stable at ~0.0024) and re-evaluate if new exploit code appears
• Restrict untrusted GPU workloads until patches are deployed