Re: [PATCH] drm/amd/display: Validate max_fclk_mhz in DML2 policy builder

[listdansp]

On 07/06/2026 00:50, sashiko-...@kernel.org wrote:
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) 
to consider:
Pre-existing issues:
- [High] Missing bounds check in `insert_entry_into_table_sorted` allows array 
out-of-bounds write.
--

commit 803110810943a93ffdbd8a40adba9348d5b58b1b
Author: Danila Chernetsov <listda...@mail.ru>

drm/amd/display: Validate max_fclk_mhz in DML2 policy builder

This commit adds a validation check for max_fclk_mhz to prevent an integer
underflow and out-of-bounds array access when all FCLK entries are zero.

diff --git a/drivers/gpu/drm/amd/display/dc/dml2_0/dml2_policy.c 
b/drivers/gpu/drm/amd/display/dc/dml2_0/dml2_policy.c
index ab2964811c5bc..938faa6272c2c 100644
--- a/drivers/gpu/drm/amd/display/dc/dml2_0/dml2_policy.c
+++ b/drivers/gpu/drm/amd/display/dc/dml2_0/dml2_policy.c
@@ -157,7 +157,8 @@ int dml2_policy_build_synthetic_soc_states(struct 
dml2_policy_build_synthetic_so
                        num_uclk_dpms++;
        }
  
-	if (!max_dcfclk_mhz || !max_dispclk_mhz || !max_dppclk_mhz || !max_phyclk_mhz || !max_dtbclk_mhz)
+       if (!max_dcfclk_mhz || !max_dispclk_mhz || !max_dppclk_mhz || 
!max_phyclk_mhz ||
+               !max_dtbclk_mhz || !max_fclk_mhz)
                return -1;
  
  	p->out_states->num_states = 0;

[Severity: High]
This isn't a bug introduced by this patch, but can the subsequent state
insertions overflow the out_states array?

Looking at dml2_policy_build_synthetic_soc_states(), it calls
insert_entry_into_table_sorted() multiple times:

     // Insert all the DCFCLK STAs first
     for (i = 0; i < p->num_dcfclk_stas; i++) {
         ...
         insert_entry_into_table_sorted(p->in_bbox, p->out_states, &s->entry);
     }

     // Insert the UCLK DPMS
     for (i = 0; i < num_uclk_dpms; i++) {
         ...
         insert_entry_into_table_sorted(p->in_bbox, p->out_states, &s->entry);
     }

     // Insert FCLK DPMs (if present)
     if (num_fclk_dpms > 2) {
         for (i = 0; i < num_fclk_dpms; i++) {
             ...
             insert_entry_into_table_sorted(p->in_bbox, p->out_states, 
&s->entry);
         }
     }

If num_uclk_dpms and num_fclk_dpms can each be derived from the 30-element
input array, the combined insertions could exceed __DML_MAX_STATE_ARRAY_SIZE__.

Inside insert_entry_into_table_sorted(), elements are shifted without a bounds
check:

     for (i = table->num_states; i > index; i--) {
         table->state_array[i] = table->state_array[i - 1];
     }
     ...
     table->num_states++;

Could this write past the end of table->state_array if the total number of
inserted states across these loops exceeds 30?


Thanks for the review. Both reported issues are pre-existing in the codebase and are completely unrelated to my changes. 
This patch does not introduce, touch, or modify this logic. I request the maintainers to review my patch as is.

Best regards,
Danila Chernetsov