Re: [PATCH] staging: sm750fb: do not program the PLL from an uninitialized value

On Mon, Aug 17, 2026 at 4:59 AM Dan Carpenter <[email protected]> wrote:
>
> On Mon, Aug 17, 2026 at 05:13:53PM +0800, Junrui Luo via B4 Relay wrote:
> > From: Junrui Luo <[email protected]>
> >
> > sm750_calc_pll_value() writes pll->M, N, OD and POD only when its search
> > loop finds a divider combination with 0 < M < 256, and returns 0 when
> > there is none. ddk750_set_mode_timing() discards that return value and
> > calls program_mode_registers() regardless, so sm750_format_pll_reg()
> > reads the four members uninitialized and pokes them into PANEL_PLL_CTRL
> > or CRT_PLL_CTRL. Nothing bounds var->pixclock on the way in, so a mode
> > set can ask for a clock the loop cannot represent.
> >
> > Consume the return value and reject the mode; hw_sm750_crtc_set_mode()
> > already propagates a non-zero return. Initialize the structure as well:
> > sm750_calc_pll_value() returns early for SM750LE without writing the
> > members, and returns non-zero on that path.
> >
> > Fixes: 81dee67e215b ("staging: sm750fb: add sm750 to staging")
> > Reported-by: Yuhao Jiang <[email protected]>
> > Assisted-by: Claude:claude-opus-5
> > Cc: [email protected]
> > Signed-off-by: Junrui Luo <[email protected]>
> > ---
>
> Greg is not taking AI patches unless they can be tested.
> https://lore.kernel.org/all/2026080354-skater-urgent-31b2@gregkh/
>
> I kind of hate AI commit messages...  They are so verbose, confident
> and reasonable sounding.  But they don't answer any of the real
> questions I want to know.  How did Yuhao Jiang find this bug?  What

We're working on an LLM-assisted system for vulnerability discovery,
and this bug was found by the system and checked by me.

We proactively wrote this patch to push for a faster fix. This patch was
also assisted by AI but we manually reviewed it before submitting.

> did the symptoms look like to a user?  Are there ways we could
> improve our QC process to prevent this sort of bug in the future?
>
> Probably the answer is that the bug was detected with AI and we
> have no idea what the symptoms look like.  Everyone sane automatically
> initializes variables to zero so probably there are no symptoms.
>
> So the problem is that the user inputs invalid var->pixclock, and
> it leads to an uninitialized variable usage.  This patch addresses
> it by initializing he variable to zero and checking if
> sm750_calc_pll_value() returns an error code.  Either approach on
> its own would would fix the problem, hopefully right?  So it's a belt
> and suspenders approach.  But isn't the real solution to reject
> invalid pixclocks in lynxfb_ops_check_var()?

Yes.

>
> We're not going to apply this patch because it hasn't been tested.
> Probably we should invent a new tag so we can create a TODO list
> of rejected AI patches.

Since the bug is valid, and we lack the hardware to test it, leaving it
on the KTODO list is fine.

>
> KTODO: investigate unintialized variables in sm750fb found by AI
>
> regards,
> dan carpenter
>


--
Yuhao Jiang