Bug 1790048 (CVE-2019-5188) - CVE-2019-5188 e2fsprogs: Out-of-bounds write in e2fsck/rehash.c
Summary: CVE-2019-5188 e2fsprogs: Out-of-bounds write in e2fsck/rehash.c
Keywords:
Status: CLOSED ERRATA
Alias: CVE-2019-5188
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
URL:
Whiteboard:
Depends On: 1783777 1790049 1792193 1797731 1797732
Blocks: 1790051
TreeView+ depends on / blocked
 
Reported: 2020-01-11 14:47 UTC by Pedro Sampaio
Modified: 2021-04-20 05:50 UTC (History)
7 users (show)

Fixed In Version: e2fsprogs 1.45.5
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-09-29 21:59:30 UTC


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2020:4011 0 None None None 2020-09-29 20:34:12 UTC

Description Pedro Sampaio 2020-01-11 14:47:02 UTC
A code execution vulnerability exists in the directory rehashing functionality of E2fsprogs e2fsck 1.45.4. A specially crafted ext4 directory can cause an out-of-bounds write on the stack, resulting in code execution. An attacker can corrupt a partition to trigger this vulnerability.

References:

https://talosintelligence.com/vulnerability_reports/TALOS-2019-0973

Upstream patches:

https://github.com/tytso/e2fsprogs/commit/8dd73c149f418238f19791f9d666089ef9734dff
https://github.com/tytso/e2fsprogs/commit/71ba13755337e19c9a826dfc874562a36e1b24d3

Comment 1 Pedro Sampaio 2020-01-11 14:47:20 UTC
Created e2fsprogs tracking bugs for this issue:

Affects: fedora-all [bug 1790049]

Comment 3 Marco Benatto 2020-02-03 21:43:10 UTC
There's an issue with fsck application contained on e2fsck package. The fsck application runs the filesystem checking and repair for ext3 and ext4 filesystems. During the Pass 3 it tries to hash all filenames contained into a given directory as one step, if a rash collision is detected is temporarily renames the file to solve the collision. During this step it relies on direntry metainformation to read from disk the file's name lenght, however due to lack of validation if the metadata is still corrupted it eventually may read the length as zero from disk. As this value is further used in mutate_name() as a part of a calculation to generate an index for a in-memory buffer, the invalid value may trigger an out-of-bounds read which may lead to data corruption and eventually code execution.

Comment 4 Marco Benatto 2020-02-03 21:45:55 UTC
It's important to notice that at Pass, 3a where the issue happens, all directory entries should already had any entry related corruption already. However this a chance the user declined to fix a given entry which may end up leaving the crafted corrupted entry available to trigger the attack.

Comment 5 errata-xmlrpc 2020-09-29 20:34:10 UTC
This issue has been addressed in the following products:

  Red Hat Enterprise Linux 7

Via RHSA-2020:4011 https://access.redhat.com/errata/RHSA-2020:4011

Comment 6 Product Security DevOps Team 2020-09-29 21:59:30 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-2019-5188


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