* Re: dtc: 5 memory-safety defect(s) — reports, PoCs and patches attached
2026-10-13 10:15 dtc: 5 memory-safety defect(s) — reports, PoCs and patches attached 胡景浩
@ 2026-10-14 5:21 ` David Gibson
0 siblings, 0 replies; 2+ messages in thread
From: David Gibson @ 2026-10-14 5:21 UTC (permalink / raw)
To: 胡景浩; +Cc: devicetree-compiler
[-- Attachment #1: Type: text/plain, Size: 5691 bytes --]
On Tue, Oct 13, 2026 at 06:15:55PM +0800, 胡景浩 wrote:
> Hello,
>
>
> I found 5 defect(s) in dtc.
Well, your LLM did. Which is fine, but *you* are responsible for
checking that the output is not nonsense. From my initial examination
these look like real defects, but their severity is wildly overstated
to the point that describing them as "vulnerabilities" at all is
dubious.
Maintaining dtc is entirely done in my volunteered, uncompensated
spare time, so I don't much appreciate spending longer on analysing
the impact of these defects than it looks like you spent validating
LLM output before sending them.
You may be interested in:
https://stuart-thomas.com/research/calculator-discipline/
Another security researcher's reflection on the caution required when
reporting LLM discovered defects.
> Each has a minimal PoC, a reproduction command and a proposed patch.
Thank you for providing this detail, although. The proposed patches
would be much more useful accompanied with DCO Signed-off-by
assertions. As it is, they're small enough (at least arguably below a
copyrightable threshold) that I can use it, but I do have to make that
assessment for each one.
The biggest reason all of these defects are only dubiously
vulnerabilities is that dtc is just a local userspace program. It has
no special privilege it can escalate to. Now, there are real
scenarios where this could be a vulnerability, such as when dtc is run
in an automated pipeline with untrusted input. However a CVSS
calculation doesn't make sense without *describing* the specific
attack scenario that's in mind.
> 1. Negative size passed to memcpy while reading a flattened device tree property
> CWE-787 / CWE-190 — Medium | CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H (7.8 High)
This CVSS score is wildly inflated. AV:L, AC:L, UI:R and S:U are
accurate, or at least close enough. The remainder is not.
PR:N is at minimum misleading
You at least need to be able to run dtc, so AFAICT that's at least
PR:L (indeed it's not clear to me what AV:L/PR:N would even mean).
More importantly dtc does not run as a daemon or network service, so
while, yes, you can run it with no particular system privilege, it
doesn't gain any privileges you didn't already have.
C:H
I:H are just plain incorrect
Again, dtc - buggy or not - has no privileges that the user didn't
have to start with. Even if it did, the bug in question is causing a
crash, so it's not how where a confidentiality or integrity problem
appears. It's possible this crash might be chained into an arbitrary
code execution, but that involves a bunch more steps and is no longer
AC:L.
A:H is certainly misleading and IMO also incorrect
It's true that dtc crashes, but dtc is not a daemon or long-running
process. Only a single instance loses availability.
> A negative length (derived from the property header) bypasses the bounds check and is passed to memcpy, producing a huge copy.
>
>
> 2. strchr over-read on a non-terminated property value (alias path checking)
> CWE-125 — Low | CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N (5.5
> Medium)
This CVSS is again greatly inflated. How this comes up as C:H but I:N
and A:N I have no idea.
> A property value that is not NUL-terminated is passed to strchr() while checking alias paths, reading past the property buffer.
The remaining three bugs affect fdtdump which is a quick and dirty
debug tool making no pretensions to particular robustness or security.
> 3. fdtdump reads the memory-reserve map at an unvalidated offset
> CWE-125 — heap-buffer-overflow read -> crash | CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N (5.5 Medium)
> fdtdump computes the reserve-map pointer straight from the header field off_mem_rsvmap and then walks it without ever comparing against totalsize.
>
>
> 4. fdtdump passes an unvalidated nameoff to printf("%s")
> CWE-125 — heap-buffer-overflow read via printf %s -> information leak and crash | CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N (5.5 Medium)
> The property-name offset nameoff from the structure block is added to the string-block pointer without any validation against size_dt_strings or totalsize, and the result is handed to printf("%s").
>
>
> 5. fdtdump walks the structure block without a totalsize bound
> CWE-125 — heap-buffer-overflow read | CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N (5.5 Medium)
> dump_blob() starts at p_struct and follows tags without bounding the cursor by totalsize / size_dt_struct; strlen() on a node name is likewise unbounded.
>
>
> PoC files, harness sources and patches are in the attached archive, one directory per item.
>
>
> On the CVE side: no CNA covers these projects upstream, so the ID
> would come from MITRE (CNA of last resort). MITRE's preferred route
> is for the upstream project to submit the request; if you would
> rather do that I can hand you the completed request fields ready to
> paste. Otherwise I will file with MITRE myself once we agree the
> defects are real. No CVE ID has been assigned yet.
The entire CVE process is wild overkill for these defects. Not to
mention that interacting with it as a single-person project is pretty
impractical.
I will fix these when I get the chance. You could expedite this by
supplying patches with actual commit messages and Signed-off-by from a
human.
--
David Gibson (he or they) | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you, not the other way
| around.
http://www.ozlabs.org/~dgibson
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 2+ messages in thread