Bug 1664708 (CVE-2018-20657) - CVE-2018-20657 libiberty: Memory leak in demangle_template function resulting in a denial of service
Summary: CVE-2018-20657 libiberty: Memory leak in demangle_template function resulting...
Keywords:
Status: CLOSED ERRATA
Alias: CVE-2018-20657
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
low
low
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
URL:
Whiteboard:
Depends On: 1664713 1664714 1664715 1668428 1668429 1668430 1668431 1668432 1668635 1668636 1668637 1668638 1668639 1668640 1668642 1668643
Blocks: 1664716
TreeView+ depends on / blocked
 
Reported: 2019-01-09 13:42 UTC by Andrej Nemec
Modified: 2019-11-06 00:51 UTC (History)
24 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-11-06 00:51:37 UTC
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2019:3352 0 None None None 2019-11-05 20:39:59 UTC

Description Andrej Nemec 2019-01-09 13:42:26 UTC 
A memory leak was found in the demangle_template function in GNU libiberty, as distributed in GNU Binutils. A crafted filed could cause the application to crash.

Upstream issue:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88539
Comment 1 Andrej Nemec 2019-01-09 13:48:02 UTC 
Created binutils tracking bugs for this issue:

Affects: fedora-all [bug 1664713]


Created mingw-binutils tracking bugs for this issue:

Affects: epel-all [bug 1664715]
Affects: fedora-all [bug 1664714]
Comment 2 Riccardo Schirone 2019-01-22 17:24:37 UTC 
`work->tmpl_argvec` is allocated but never freed in demangle_template() function.
Comment 7 Christophe de Dinechin 2019-01-29 13:59:18 UTC 
10 bytes hard-to-reach memory leak which only possibly impacts short-lived programs.

I believe that a reproducer would be even harder to do with binutils, because you need to run for example nm with the --demangle option and have the symbols in the input file actually match the POC.

Given that the simplest of the two provided POCs contains several control characters and actually looks like this:

00000000: 2e5a 4333 4a33 4c53 5f64 315f 5f5f 5f31  .ZC3J3LS_d1____1
00000010: 455f 2064 537f 7d5f 5f53 655f 0002 0000  E_ dS.}__Se_....
00000020: 2c64 4d36 6236 806f 6a65 4e72 4e6d 5348  ,dM6b6.ojeNrNmSH
00000030: 314d 7458 4953 875f 4d70 3239 36e9 546d  1MtXIS._Mp296.Tm
00000040: 8dd1 455f 4780 002e 454f 5749 536b 5f35  ..E_G...EOWISk_5
00000050: 745f 5832 8034 b84c 5849 445f 5f4d 7434  t_X2.4.LXID__Mt4
00000060: 64ce 007c 1f48 9f1f 5f5f 5f4d 7434 64ce  d..|.H..___Mt4d.
00000070: 007c 1f48 9f1f 5f5f 5f48 3164 315f 5f62  .|.H..___H1d1__b
00000080: 5f31 4548 3164 3180 535f 4d74 5849 3e6e  _1EH1d1.S_MtXI>n
00000090: 0a                                       .

I find it unlikely any actual symbol would look like this. I am closing as WONTFIX, following the decision of the original library maintainers https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88539.
Comment 12 errata-xmlrpc 2019-11-05 20:39:57 UTC 
This issue has been addressed in the following products:

  Red Hat Enterprise Linux 8

Via RHSA-2019:3352 https://access.redhat.com/errata/RHSA-2019:3352
Comment 13 Product Security DevOps Team 2019-11-06 00:51:37 UTC 
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-2018-20657
Note You need to log in before you can comment on or make changes to this bug.