Stack buffer overflow in toybox readelf `scan_elf`

[eglonnnn]

Description

A stack buffer overflow vulnerability in toybox 0.8.12. When readelf_main() processes a crafted ELF file, scan_elf() writes beyond the stack buffer via printf(), causing a stack-buffer-overflow.

Impact

• Denial-of-service via process crash
• Any user processing untrusted ELF files with toybox readelf is affected

Reproduction

All materials are available in my research repository:
https://github.com/eglonnnn/opensource-fuzz-vulnerability-research/tree/main/Stack%20buffer%20overflow%20in%20toybox%20readelf%20scan_elf

[landley]

On 7/5/26 05:57, eglonnnn wrote: eglonnnn created an issue (landley/toybox#607) ### Description A stack buffer overflow vulnerability in toybox 0.8.12.

Looks like the sh_flags[] buffer wasn't expanded enough when extra machine-specific flags went in. Nobody noticed because even if you fed it a christmas tree packet, the compiler inserts padding before the next argument for alignment. (Even if your architecture supports dereferencing unaligned pointers, no optimizer would leave that.) The result is the printf could theoretically spit a little garbage (the padding isn't zeroed so %s would continue until it found a NUL), it's ASAN that turns that into a crash. I expanded the char buffer to the size the compiler was aligning it to anyway, and ASAN shut up.

`scan_elf()` writes beyond the stack buffer via `printf()`, causing a stack-buffer-overflow.

printf doesn't write to its arguments. ASAN noticed it _reading_ something it shouldn't.

### Impact - Denial-of-service via process crash

Now it prints 99,174 lines of "program header X's offset > file size 120" if you consider that an improvement... I pushed commit a29e6d2 to https://codeberg.org/landley/toybox (see https://github.com/landley/toybox/blob/0.8.14/www/news.html#L62 ). Rob

[enh-google]

Now it prints 99,174 lines of "program header X's offset > file size
120" if you consider that an improvement...

yeah, that's my fault. there might be a conflict between "what normal people want" and my need/desire for a tool that never lies (even small lies like gnu readelf's elision of the empty entry that's usually at the end of the dynamic section) and never gives up (on deliberately obfuscated elf files, say) because i'm probably debugging something that's generating or parsing elf files (or trying to examine an elf file that's been deliberately fucked with to try to make that hard). there are probably a lot of places where a "we've already output this exact message, don't repeat yourself" would help though.