Multiple vulnerabilities in the U-Boot FIT image signature verification logic

[Anton Ivanov]

All the patches have now been sent:
[PATCH] fdt: Check return value and len of fdt_get_name() calls –
fixes BRLY-2026-037 and BRLY-2026-038
[PATCH] image-fit-sig: Check that the strings region is within bounds –
fixes BRLY-2026-039
[PATCH] fdt_region: Check the return value of fdt_get_property_by_offset()
calls – fixes BRLY-2026-040
[PATCH] image-fit: Check that external data is in bounds –
fixes BRLY-2026-041
[PATCH] image-fit: Check nesting depth in fdt_check_no_at() –
fixes BRLY-2026-042

Thank you,
Anton


On Wed, May 20, 2026 at 5:09 PM Tom Rini <trini at konsulko.com> wrote:

> On Wed, May 20, 2026 at 05:02:19PM +0100, Anton Ivanov wrote:
>
> > Hi Tom, nice to meet you.
> >
> > While we understand your concerns about AI-assisted vulnerability
> research
> > and AI-generated security reports, we're not sure why you think these
> > advisories don't require attention.
>
> I'm not saying they don't require attention. But I am saying I'm not,
> and I don't think anyone else should either, without the reporting human
> doing, well, what's outlined in the various links I've sent, pay
> attention. The hard part has rarely been finding a bug, it's been
> dealing with fixing it and verifying it's a problem.
>
> > We have recently started using AI tools for vulnerability research
> > projects. We use it responsibly, conducting several rounds of human
> review.
> > We have confirmed that all the security issues described in these reports
> > are valid. Furthermore, each advisory contains a PoC section that
> > demonstrates how the vulnerable code can be triggered to lead to DoS or
> > arbitrary code execution, as in the case of BRLY-2026-038. We used either
> > sandbox_defconfig or qemu_arm_defconfig builds to confirm this.
> >
> > As for the content of the reports, we strongly believe that they contain
> > the minimum amount of information required to understand the
> vulnerability,
> > including the PoC and suggestions for fixes, as well as the other common
> > information, such as the CVSS score and disclosure timeline. We
> understand
> > that this format may feel unusual to you, but this is how we typically
> > report vulnerabilities. You can find more examples in
> > https://github.com/binarly-io/Vulnerability-REsearch. Please note that
> most
> > of the advisories were created before the AI era.
>
> That's good to know. Unfortunately the bar for entry in the security
> research world is now zero and so as a volunteer and community project,
> we don't have time to investigate if every reporter represents someone
> with a long standing history or someone new that unleashed an LLM agent
> on things without a general understanding. That means the bar for
> reporting from long time researchers is much higher than it used to be.
>
> > As an alternative, to save everyone time, we can provide the necessary
> > patches to resolve these issues. Does this sound good to you?
>
> So yes, following the general project guidelines for submitting patches
> as I sent before, and also if applicable
>
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/coding-assistants.rst
> a patch to fix the problem, and updating our test suites if possible to
> catch regressions, would be appreciated. Thanks.
>
> --
> Tom
>