]> git.ipfire.org Git - thirdparty/binutils-gdb.git/commit
aarch64 core: use of uninitialised value
authorAlan Modra <amodra@gmail.com>
Tue, 26 May 2026 07:40:34 +0000 (17:10 +0930)
committerAlan Modra <amodra@gmail.com>
Tue, 26 May 2026 07:40:34 +0000 (17:10 +0930)
commit3ec37a1948196800af10018b8b11b9da4abc886d
tree3d445ac00adcf021c6c2448f01a02d676c286f8d
parentadbfdef7131011d1ec85060128a2467c4f18fe0a
aarch64 core: use of uninitialised value

Commit d0ff5ca959df adding PT_AARCH64_MEMTAG_MTE support, creates
a section that stores "p_memsz" from the program header in "rawsize"
and "p_filesz" in "size".  p_memsz is the memory range, usually 32
times p_filesz.  This can be a problem when bfd reads the section, for
example to display it with objdump -s, as the usual (linker) meaning
for input section "rawsize" is the original size on disk.  Memory is
allocated to read the larger of "size" and "rawsize".  So 32 times the
memory is allocated than what is really needed.

With fuzzed input "rawsize" can be smaller than "size" since the
header values are not sanity checked.  This results in section
contents with only the first "rawsize" bytes read from disk, the rest
being uninitialised.  Of course fuzzed input can also have very large
"rawsize" which might result in OOM.

One way of fixing this is to move the p_memsz value somewhere else
(output_offset would work, I think).  Another might be to qualify use
of rawsize by is_linker_input, but I haven't checked over all the bfd
code using rawsize.  And then there is this approach:

* bfd.c (bfd_get_section_limit_octets),
(bfd_get_section_alloc_size): Ignore rawsize in bfd_core.
* bfd-in32.h: Regenerate.
bfd/bfd-in2.h
bfd/bfd.c