Vendored core/eos is behind eos security fixes: DTB parser reads out of bounds, secure boot never loads its key, OTA trusts the update's own hash #182

What is wrong

core/eos/ is pinned to eos 5544c98 (2026-08-28) in core/UPSTREAM.yaml. eos has since merged security fixes that never reached the vendored copy, and some files counted as "drift" are older than the pin, not ebuild changes.

1. drivers/devicetree/devicetree.c trusts every offset and length in the blob. eos fixed this in d41fa55 (fix(ebuild): key package download cache by package, not URL basename #50, "bounds-check untrusted DTB input"). Running eos's own tests/test_devicetree.c against ebuild's copy with ASan/UBSan aborts (exit 134):

   • heap-buffer-overflow … in be32: the parser reads past the end of the blob;
   • eos_dt_get_irq(node, -1): index 4294967292 out of bounds for type 'const uint8_t[256]';
   • signed integer overflow: 1073741824 * 4 in the same function.

   The same test passes 37/37 against eos's current parser.

2. services/security/src/security.c is missing the public-key load. The pinned eos already opens pubkey_path and fails the boot if the key is missing or empty. ebuild's copy predates that: it never opens the key, so secure boot verifies against no key material. eos has since also fixed a NULL-path crash in the same function (f648600).

3. The OTA service has no authenticity check. eos 2a37b3d (Validate toolchain extra_cflags/extra_ldflags as string lists #75) stops treating the update's own SHA-256 as proof of origin, and 7f6ad00 (master does not parse — orphan else: in dispatch.py breaks every ebuild command #87) rejects oversized chunks without wrapping the length.

4. hal/src/hal_rtos.c and tests/test_ota.c are counted as drift but are stale. They are older versions of the pinned files, not ebuild changes.

Expected

The vendored eos carries eos's fixes, the pin points at the revision it actually mirrors, and baseline_drift drops by the stale files that are reconciled.