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 <[email protected]> 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 >
