On 27/04/23 04:28, Yang Jihong wrote:Yes, it may be an error, or it may be that the build-id was specified when the elf file was created.
In elf_read_build_id(), if gnu build_id is found, should return the size of
the actually copied data. If descsz is greater thanBuild_ID_SIZE,
write_buildid data access may occur.
Fixes: be96ea8ffa78 ("perf symbols: Fix issue with binaries using 16-bytes buildids (v2)")
Reported-by: Will Ochowicz <Will.Ochowicz@xxxxxxxxxxxx>
Link: https://lore.kernel.org/lkml/CWLP265MB49702F7BA3D6D8F13E4B1A719C649@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/T/
Tested-by: Will Ochowicz <Will.Ochowicz@xxxxxxxxxxxx>
Signed-off-by: Yang Jihong <yangjihong1@xxxxxxxxxx>
As an aside, note that the build ID on the ELF file triggering the bug was
62363266373430613439613534633666326432323334653665623530396566343938656130663039
which is 80 ASCII characters, which would have been a 20 byte binary number i.e.
$ echo -en "0000: 62363266373430613439613534633666\n0010: 32643232333465366562353039656634\n0020: 3938656130663039" | xxd -r | od -c -A d
0000000 b 6 2 f 7 4 0 a 4 9 a 5 4 c 6 f
0000016 2 d 2 2 3 4 e 6 e b 5 0 9 e f 4
0000032 9 8 e a 0 f 0 9
0000040
So perhaps a mistake in the creation of the build ID on that ELF file.
In any case, for the fix:Thanks for the acked-by.
Acked-by: Adrian Hunter <adrian.hunter@xxxxxxxxx>