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
Created e2fsprogs tracking bugs for this issue: Affects: fedora-all [bug 1790049]
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.
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.
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
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