Hide Forgot
The Linux kernel is vulnerable to an out-of-bound access bug in the fs/posix_acl.c:get_acl() function. An attacker could trick a legitimate user or a privileged attacker could exploit this to cause a system crash or other unspecified impact with a crafted ext4 image. Due to the nature of the flaw, privilege escalation cannot be fully ruled out, although we believe it is unlikely. References: https://bugzilla.kernel.org/show_bug.cgi?id=199185 http://seclists.org/oss-sec/2018/q1/284 An upstream patch: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=54dd0e0a1b255
Acknowledgments: Name: Wen Xu
Created kernel tracking bugs for this issue: Affects: fedora-all [bug 1560794]
Notes: While the reproducer works when run as a privileged user (the "root"), this requires a mount of a certain filesystem image. An unprivileged attacker cannot do this even from a user+mount namespace: $ unshare -U -r -m # mount -t ext4 fs.img mnt/ mount: mnt/: mount failed: Operation not permitted. The article https://lwn.net/Articles/652468/ (thanks, Jonathan!) discusses unprivileged user mounts and hostile filesystem images: > ... for the most part, the mount() system call is denied to processes running > within user namespaces, even if they are privileged in their namespaces. It also states that unprivileged filesystem mounts are not allowed as of now in the Linux kernel and probably won't be allowed in a future. Until that such flaws are considered as not exploitable: > There were no proposals for solutions to the hostile-filesystem problem. > But, in the absence of some sort of assurance that they can be made safe, > unprivileged filesystem mounts are unlikely to gain acceptance; even if the > feature gets into the kernel, distributions would be likely to disable it. On the other hand, there is a potential possibility that still an attacker can trick a regular user to mount a malicious filesystem image, like trick him to insert an usb-flash-drive with a forged filesystem to a desktop system which will auto-mount it. In case this results only in a system crash (a DoS due to, for example, a NULL pointer dereference) the flaw impact is low but it still exists. Another example is that if an attacker wants to hack into his coworker's notebook. While a coworker is away (on a coffee break) an attacker may insert an usb-flash-drive into the target notebook. In case of a flaw which results in a privilege escalation the flaw's impact is high. In case of a system crashes the impact is lower, but still a harm is done by crashing the system mid-work and losing a work done so far. So the Red Hat would still consider bugs which require mounting a filesystem image to exploit as security flaws.
Hi Vladis, I think the description of this bug may need modification. Considering the information in https://bugzilla.kernel.org/show_bug.cgi?id=199185: 1) the crash is at 0xffffffffc0c0c0c0, which is not NULL pointer. 2) the patch (https://bugzilla.kernel.org/attachment.cgi?id=275005&action=diff) fix the range of a signed int32 value, since it will be converted to a large unsigned int64 value which leads to out-of-bound access. Thanks!
(In reply to Wen Xu from comment #7) > I think the description of this bug may need modification. hello, Wen, indeed, this is an out-of-bound access. i'm changing descriptions accordingly.
This is fixed for Fedora with 4.16.4 stable updates.
This issue has been addressed in the following products: Red Hat Enterprise Linux 7 Via RHSA-2018:2948 https://access.redhat.com/errata/RHSA-2018:2948