Re: [cip-dev] Request for review for 4.19-st20, 4.19-cip136

[Ulrich Hecht <uli@fpond.eu>]

> On 09/03/2026 1:59 PM CEST Pavel Machek via lists.cip-project.org <pavel=nabladev.com@lists.cip-project.org> wrote:
> I have some comments here. I'll try to continue review soon.

Thanks, this is very helpful!

> a > 27bcd94232ddc ipv6: mcast: Fix potential UAF in MLD delayed work
> !! should return -EINVAL > d03436150e4a9 drm/edid: fix OOB read in drm_parse_tiled_block()

The argument that the LLM brings forward is that returning -EINVAL would abort parsing of the DisplayID extension and thus any valid blocks that may exist down the line will be ignored. I'm not an expert on DRM, but I think the fact that in upstream drm_parse_tiled_block() doesn't even have a return value anymore supports that view.

> !! it fails to return error > 6fe1ea5d01613 hwmon: (adt7470) Fix PWM auto temp state array and bounds check

I would not consider that wrong. The 4.19 code does not check for or propagate any errors here, and adding that is beyond the scope of a minimum viable fix.

> !! should VMXNET3_RCD_HDR_INNER_SHIFT be 13? > e05a9dca311e3 vmxnet3: fix BUG_ON in vmxnet3_get_hdr_len() for Geneve packets

It should. Looking into it I found that because the LLM only had access to one branch (4.19), when it had to find out what that value is and couldn't, it made an educated guess. One tiny complete tool rewrite later, and with access to both branches, that mistake is gone. (Fixed it in the tree, too.)

I have also added instructions to the prompt to separate established facts (things determined by looking at actual code) from assumptions made by the LLM, which should help identify fails like this one.

CU
Uli