CVE-2026-80704: drm/amd/display: use proper context for logging
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: use proper context for logging
The same as the rest of the code, getssinfofromatombios() uses calcpllcs->ctx->logger for logging. But calcpllcs->ctx is initialized only later in calcpllmaxvcoconstruct(). Therefore, any output using DCLOGSYNC() leads to a NULL pointer deference in getssinfofromatombios().
According to Sashiko, the very same problem exists in dce112getpixclkdividers() and dcn3getpixclkdividers() too.
To avoid accessing the NULL context, use clksrc->base.ctx->logger everywhere. That context in base is initialized earlier in dce110clksrcconstruct() and dce112clksrcconstruct(). Before getssinfofromatombios() or Sashiko's getpixclkdividers functions above are actually called. This is done by redefining DCLOGGER to CTX->logger.
Before: dce110clksrcconstruct() did: -> sets clksrc->base.ctx = ctx; -> ssinfofromatombioscreate() -> getssinfofromatombios() <- uses calcpllcs->ctx # BOOM -> calcpllmaxvcoconstruct() <- sets calcpllcs->ctx
After: dce110clksrcconstruct() does: -> sets clksrc->base.ctx = ctx; -> ssinfofromatombioscreate() -> getssinfofromatombios() <- uses clksrc->base.ctx
(cherry picked from commit 6f16fcbb0c46a87e3d9685407e906573d60104b0)
Affected Software
Event History
Frequently Asked Questions
When can this NULL pointer dereference occur?
It can occur during AMD display clock-source construction, when get_ss_info_from_atombios() emits logging through DC_LOG_SYNC() before calc_pll_cs->ctx has been initialized. The same initialization-order issue is identified in dce112_get_pix_clk_dividers() and dcn3_get_pix_clk_dividers().
What configuration or hardware path is implicated?
The affected code is in the Linux kernel AMD display driver clock-source paths, including construction paths initialized by dce110_clk_src_construct() and dce112_clk_src_construct(). The issue is triggered by logging from the affected functions during that construction sequence.
What does the fix change?
The fix makes logging use clk_src->base.ctx->logger rather than calc_pll_cs->ctx->logger. The base context is initialized earlier, before the affected firmware-information and pixel-clock-divider functions are called.