An out-of-bounds read/write vulnerability was found in e2fsprogs which can lead to a segmentation fault and possibly arbitrary code execution via a specially crafted filesystem. The issue occurs in ext2fs_extent_delete() in lib/ext2fs/extent.c when path->left is equal to -1, resulting in a call to memmove() with invalid arguments. Reference: https://bugzilla.redhat.com/show_bug.cgi?id=2068113
Created e2fsprogs tracking bugs for this issue: Affects: fedora-all [bug 2069727]
(In reply to Borja Tarraso from comment #0) > A vulnerability was found in e2fsck. During the processing of the attached > disk image via e2fsck -p -f /testcase an out-of-bounds write is triggered > and causes a segmentation fault (SIGSEGV). Hello, thanks for the report, however there are couple of things missing. I don't see a Fedora version for which this bug is supposed to be and I don't see the version of e2fsprogs which this problem applies to. Also there is no disk image attached. Please provide the missing information and the mentioned disk image. > > This bug allows an attacker to perform a denial of service and possibly > opens up other attack vectors. how does it allow to perform a DoS? What other attack vectors does it open? Thanks! -Lukas
In reply to comment #2: > Hello, > > thanks for the report, however there are couple of things missing. I don't > see a Fedora version for which this bug is supposed to be and I don't see > the version of e2fsprogs which this problem applies to. Also there is no > disk image attached. Please provide the missing information and the > mentioned disk image. Hi Lukas, You can find the original bug report with more information here: https://bugzilla.redhat.com/show_bug.cgi?id=2068113 > how does it allow to perform a DoS? What other attack vectors does it open? We are still investigating this issue and that's not clear yet. Thanks.
Indeed this is a bug and should be fixed. But as always when fuzzer images pop up, I don't consider it a security issue as it requires a physical access and an elaborate, non standard and not very smart setup to automatically run fsck on inserted USB.
Marking services-* and OSD affected/low/delegated for presence of affected code. Couple items of note: [0] Exploitation is highly unlikely. [1] "Unfortunately, we were not able to reproduce the issue on RHEL UBI since it appears that `e2fsprogs` is not part of the standard repository." Yet another argument for Red Hat to stop using non-UBI images in our managed services… --- services-ansible-automation-hub/automation-hub/automation-hub-ansible-test:latest/e2fsprogs-1.44.1-1ubuntu1.3 https://quay.io/cloudservices/automation-hub-ansible-test:latest services-managed-kafka/cos-fleet-manager/cos-fleet-catalog-camel:latest/e2fsprogs-1.44.5-1+deb10u3 https://quay.io/rhoas/cos-fleet-catalog-camel:latest services-managed-kafka/strimzi/prometheus-kafka-consumer-group-exporter:latest/e2fsprogs-1.44.5-1+deb10u3 https://quay.io/app-sre/prometheus-kafka-consumer-group-exporter:latest services-openshift-cluster-manager/ocm/golangci-lint:latest/e2fsprogs-1.46.2-2 https://quay.io/app-sre/golangci-lint:latest services-openshift-cluster-manager/ocm/selenium-standalone-chrome-debug:latest/e2fsprogs-1.45.5-2ubuntu1 https://quay.io/app-sre/selenium-standalone-chrome-debug:latest services-openshift-cluster-manager/ocm/selenium-standalone-firefox-debug:latest/e2fsprogs-1.45.5-2ubuntu1 https://quay.io/app-sre/selenium-standalone-firefox-debug:latest
In reply to comment #5: > Indeed this is a bug and should be fixed. But as always when fuzzer images > pop up, I don't consider it a security issue as it requires a physical > access and an elaborate, non standard and not very smart setup to > automatically run fsck on inserted USB. Hi Lukas, thank you for your input on this. Although that is an attack scenario, that is not the only one. An attacker can corrupt a filesystem or prepare, distribute and force an user to run e2fsck on a crafted filesystem image. Given the conditions to trigger this vulnerability, it has at most a moderate severity. Thanks.
This issue has been addressed in the following products: Red Hat Enterprise Linux 8 Via RHSA-2022:7720 https://access.redhat.com/errata/RHSA-2022:7720
This issue has been addressed in the following products: Red Hat Enterprise Linux 9 Via RHSA-2022:8361 https://access.redhat.com/errata/RHSA-2022:8361
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-2022-1304