CVE-2024-38592: drm/mediatek: Init `ddp_comp` with devm_kcalloc()
In the Linux kernel, the following vulnerability has been resolved:
drm/mediatek: Init `ddp_comp` with devm_kcalloc()
In the case where `conn_routes` is true we allocate an extra slot in
the `ddp_comp` array but mtk_drm_crtc_create() never seemed to
initialize it in the test case I ran. For me, this caused a later
crash when we looped through the array in mtk_drm_crtc_mode_valid().
This showed up for me when I booted with `slub_debug=FZPUA` which
poisons the memory initially. Without `slub_debug` I couldn't
reproduce, presumably because the later code handles the value being
NULL and in most cases (not guaranteed in all cases) the memory the
allocator returned started out as 0.
It really doesn't hurt to initialize the array with devm_kcalloc()
since the array is small and the overhead of initting a handful of
elements to 0 is small. In general initting memory to zero is a safer
practice and usually it's suggested to only use the non-initting alloc
functions if you really need to.
Let's switch the function to use an allocation function that zeros the
memory. For me, this avoids the crash.
Security readout for executives and security teams
Plain-English summary
CVE-2024-38592 is a Linux kernel MediaTek display-driver bug that can crash the system in a specific driver path. The issue is uninitialized memory in a small array. The public record does not provide a CVSS score, CWE, or evidence of active exploitation.
Executive priority
Treat this as a targeted kernel reliability issue, not a confirmed widespread exploitation event. Prioritize patching where MediaTek-based Linux devices are business-critical or exposed through managed appliance fleets.
Technical view
When `conn_routes` is true, the MediaTek DRM code allocates an extra `ddp_comp` array slot that may remain uninitialized. Later iteration in `mtk_drm_crtc_mode_valid()` can treat poisoned or nonzero garbage as meaningful and crash. The kernel fix changes allocation to `devm_kcalloc()` so entries start as zero.
Likely exposure
Exposure appears limited to Linux systems using affected kernel versions and the MediaTek DRM display driver path. General Linux servers without this driver path are less likely to be exposed, but the source data does not provide deployment prevalence.
Exploitation context
No provided source claims exploitation in the wild, and the CVE is not marked KEV. The reporter reproduced a crash with `slub_debug=FZPUA`; without that setting, they could not reproduce it in their test case.
Researcher notes
The public description supports an availability-oriented kernel crash condition caused by uninitialized allocation. Evidence is incomplete for exploitability, privilege requirements, and real-world reach. Avoid assuming memory corruption impact beyond the reported crash without further kernel analysis.
Mitigation direction
Update affected Linux kernels to a version containing the referenced stable fixes.
Check your Linux distribution or device vendor for backported kernel packages.
Prioritize systems using MediaTek DRM/display hardware paths.
If no patched build is available, request vendor guidance before accepting production risk.
Validation and detection
Inventory Linux kernel versions across MediaTek-based systems and appliances.
Confirm whether the MediaTek DRM display driver is present or enabled.
Verify the relevant stable fix commit is included in your running kernel tree.
Review crash logs for MediaTek DRM display-mode validation failures.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cve · low confidence lookup
CVE-2024-38592 mapping review
Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.