Bug 1637556 (CVE-2018-17983)

Summary: CVE-2018-17983 mercurial: Out-of-bounds read in cext/manifest.c
Product: [Other] Security Response Reporter: Andrej Nemec <anemec>
Component: vulnerabilityAssignee: Red Hat Product Security <security-response-team>
Status: CLOSED NOTABUG QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: unspecifiedCC: abhgupta, dbaker, jlaska, jokerman, katzj, mads, mplch, ndbecker2, pcahyna, pstodulk, sebastian.kisela, sthangav, trankin
Target Milestone: ---Keywords: Security
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: mercurial 4.7.2 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-04-21 10:31:48 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 1637557, 1637559    
Bug Blocks: 1637560    

Description Andrej Nemec 2018-10-09 13:32:52 UTC 
cext/manifest.c in Mercurial before 4.7.2 has an out-of-bounds read during parsing of a malformed manifest entry.

Upstream changelog:

https://www.mercurial-scm.org/wiki/WhatsNew#Mercurial_4.7.2_.282018-10-01.29

Upstream patch:

https://www.mercurial-scm.org/repo/hg/rev/5405cb1a7901
Comment 1 Andrej Nemec 2018-10-09 13:33:40 UTC 
Created mercurial tracking bugs for this issue:

Affects: fedora-all [bug 1637557]
Comment 3 Scott Gayou 2018-10-15 19:21:43 UTC 
First off, this code is in a subsystem that does not appear to be in RHEL's 2.6.2. I did find a similar pattern and investigated it for applicability though:

Presumably, the AFL issue is triggered by generating a "correct" manifest file (hashes and potentially pyobject internals would need to match I believe) with a hash that is less than 40 characters, thus potentially triggering a read past the true bounds of the buffer:

```c
hash = unhexlify(s + llen + 1, 40);
```

That code is not present in the RHEL 7 version. RHEL7 has a slightly similar pattern in the above mentioned line (inside parse_manifest):

```c
node = unhexlify(zero + 1, nlen > 40 ? 40 : (int)nlen);
```

This does not appear to be vulnerable as the correct length of the manifest hash length is calculated, passed to unhexlify, and not assumed to be 40. Thus, it appears that RHEL* is not affected.
Comment 4 Product Security DevOps Team 2020-04-21 10:31:48 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-17983