In elfutils 0.175, a heap-based buffer over-read was discovered in the function elf32_xlatetom in elf32_xlatetom.c in libelf. A crafted ELF input can cause a segmentation fault leading to denial of service (program crash) because ebl_core_note does not reject malformed core file notes. References: https://sourceware.org/bugzilla/show_bug.cgi?id=24089 https://sourceware.org/ml/elfutils-devel/2019-q1/msg00049.html
Created elfutils tracking bugs for this issue: Affects: fedora-all [bug 1677539]
Note that the description of this CVE is somewhat misleading. This can only be triggered running eu-readelf -n on a core file. And the core file needs to have a NT_PLATFORM note with a non-zero terminated string. eu-readelf might then try to process too much data in the note, possibly eventually calling elf_xlatetom on that data. But the bug is not in that library function, it is simply eu-readelf not handling one specific core file note with a non-zero terminated string.
I cannot understand why the CVSS3 score includes "AV:H". There is no service whose availability is impacted. This is an ordinary program crashing on corrupt input.
I meant A:H (thanks mjw)
In reply to comment #5: > I meant A:H (thanks mjw) As per my understanding I assigned A:H because it causing SEGV resulting in dos, which may lead to complete disruption of service instead of reduced performance or any other interruption.
(In reply to Dhananjay Arunesh from comment #6) > In reply to comment #5: > > I meant A:H (thanks mjw) > As per my understanding I assigned A:H because it causing SEGV resulting in > dos, which may lead to complete disruption of service instead of reduced > performance or any other interruption. What is the 'service'? This really is just a local user running eu-readelf -n on a local core file. Also does it really SEGV in normal situations? Running the (second) reproducer under valgrind I can see it accesses an uninitialized (but addressable) byte. When recompiled with the gcc address sanitizer this access turns into a SEGV. But I haven't been able to use any of the reproducers to produce a crash without extra debugging techniques. I am not denying it isn't a bug (I did fix it upstream already). But it would be good to know why such a bug gets such a high CVE score.
In reply to comment #7: > (In reply to Dhananjay Arunesh from comment #6) > > In reply to comment #5: > > > I meant A:H (thanks mjw) > > As per my understanding I assigned A:H because it causing SEGV resulting in > > dos, which may lead to complete disruption of service instead of reduced > > performance or any other interruption. > > What is the 'service'? > This really is just a local user running eu-readelf -n on a local core file. > > Also does it really SEGV in normal situations? Running the (second) > reproducer under valgrind I can see it accesses an uninitialized (but > addressable) byte. > When recompiled with the gcc address sanitizer this access turns into a > SEGV. But I haven't been able to use any of the reproducers to produce a > crash without extra debugging techniques. > > I am not denying it isn't a bug (I did fix it upstream already). > But it would be good to know why such a bug gets such a high CVE score. Hi Mark, Thanks for the information provided by you, according to the analysis provided by I'd assign A:L. updated "A:L" and Impact to Low
This issue has been addressed in the following products: Red Hat Enterprise Linux 7 Via RHSA-2019:2197 https://access.redhat.com/errata/RHSA-2019:2197
This bug is now closed. Further updates for individual products will be reflected on the CVE page(s): https://access.redhat.com/security/cve/cve-2019-7665
This issue has been addressed in the following products: Red Hat Enterprise Linux 8 Via RHSA-2019:3575 https://access.redhat.com/errata/RHSA-2019:3575