Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.
Bug 1637556 - (CVE-2018-17983) CVE-2018-17983 mercurial: Out-of-bounds read in cext/manifest.c
CVE-2018-17983 mercurial: Out-of-bounds read in cext/manifest.c
Status: NEW
Product: Security Response
Classification: Other
Component: vulnerability (Show other bugs)
unspecified
All Linux
medium Severity medium
: ---
: ---
Assigned To: Red Hat Product Security
impact=moderate,public=20181001,repor...
: Security
Depends On: 1637557 1637559
Blocks: 1637560
  Show dependency treegraph
 
Reported: 2018-10-09 09:32 EDT by Andrej Nemec
Modified: 2018-10-25 18:31 EDT (History)
15 users (show)

See Also:
Fixed In Version: mercurial 4.7.2
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed:
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Andrej Nemec 2018-10-09 09:32:52 EDT
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 09:33:40 EDT
Created mercurial tracking bugs for this issue:

Affects: fedora-all [bug 1637557]
Comment 3 Scott Gayou 2018-10-15 15:21:43 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.