On Mon, Jun 08, 2026 at 11:10:22AM +0200, Lorenz Kofler wrote: > Hello! > > Gentle ping :) Any feedback on this patch? > > On 6/2/26 9:43 AM, Lorenz Kofler wrote: > > CVE-2021-27138 was fixed by rejecting any FIT node whose name contains '@'. > > That stops libfdt's unit-address matching from resolving a reference such > > as "kernel" to a node named "kernel@1". > > > > Rejecting '@' outright, however, is a regression. We have a customer with > > signed FIT images deployed in the field that use '@' in node names, and > > with signature verification enabled those images are now rejected and fail > > to boot. > > > > Such names are admittedly not ideal. The devicetree specification only > > allows a unit address when the node has a matching 'reg' property, and > > newer dtc versions warn about violations. New FIT images should therefore > > avoid such names, but existing deployed images still need to keep working. > > > > This series fixes CVE-2021-27138 without that regression. The root cause is > > not the '@' character itself, but accepting a non-exact node-name match > > when resolving a FIT reference. Patch 1 hardens the lookups so the > > requested name and the resolved node name must match exactly: an inserted > > "kernel@1" can no longer stand in for the "kernel" node. Patches 2 and 3 > > then drop the now-redundant blanket '@' rejection. > > > > Review is welcome, especially on whether I missed any place that looks up a > > FIT node by name.
I think it's good to have made this public, for anyone else that's in a similar situation, but that the migration path for deployed systems here should include a step migration away from deprecated images. We're a bit more than 5 years past the original fix and so while I would have been open to this change in 2021, or maybe even early 2022, it's just too late at this point. -- Tom
signature.asc
Description: PGP signature
