CVE-2025-39787

What it actually does

Out-of-bounds read in the Qualcomm MDT loader when iterating ELF program and section headers without validating the firmware buffer size or e_phentsize/e_shentsize fields.

Why it matters to the business

Local denial-of-service on Linux systems using Qualcomm remoteproc or MDT firmware loading, with potential for broader kernel instability in high-prevalence embedded and server deployments; urgency is moderate given the 411-day window since publication and low EPSS.

How an attack unfolds

An attacker supplies a malformed or truncated MDT/ELF firmware image to a client that does not pre-sanitize the header; the loader then walks past the end of the supplied buffer while reading e_phentsize or e_shentsize, triggering a kernel read of unmapped memory and a subsequent crash or information leak.

How to fix it

Upgrade to Linux kernel commit 1096eb63ecfc8df90b70cd068e6de0c2ff204dfd or later; apply the same fix to any downstream trees that carry the qcom/mdt_loader.c code.

How to confirm the fix worked

Confirm the presence of the size checks on the firmware buffer and on e_phentsize/e_shentsize in mdt_loader.c; run kernel selftests or fuzzers that supply undersized ELF headers to the MDT path and verify no out-of-bounds accesses occur.

Typical attack path

1. Identify a user-space or kernel interface that loads MDT firmware without prior ELF-header sanitization
2. Craft a firmware blob whose size is smaller than required for the full ELF header plus program/section tables
3. Trigger the load path (remoteproc, etc.) with the malformed blob
4. Observe kernel oops or panic caused by the out-of-bounds read

How to detect it

Review kernel logs for oops/panic messages originating from mdt_loader.c or remoteproc when loading firmware; correlate with processes that invoke the affected firmware load path; no public exploit artifacts are known.

What your security team should do

• Prioritize patching production kernels that use Qualcomm remoteproc within the next sprint
• Add the fixed commit to any internal kernel build pipelines and rebuild images
• Monitor EPSS trend and re-evaluate if new exploit code appears