Bug 1610084 (CVE-2018-14611)
|Summary:||CVE-2018-14611 kernel: Use-after-free in try_merge_free_space() when mounting crafted btrfs image|
|Product:||[Other] Security Response||Reporter:||Sam Fowler <sfowler>|
|Component:||vulnerability||Assignee:||Red Hat Product Security <security-response-team>|
|Status:||CLOSED NOTABUG||QA Contact:|
|Version:||unspecified||CC:||abhgupta, airlied, aquini, bhu, blc, bskeggs, dbaker, dhoward, esammons, ewk, fhrbata, hdegoede, hkrzesin, hwkernel-mgr, iboverma, ichavero, itamar, jarodwilson, jforbes, jglisse, jkacur, john.j5live, jokerman, jonathan, josef, jross, jwboyer, kernel-maint, kernel-mgr, labbott, lgoncalv, linville, lwang, matt, mchehab, mcressma, mguzik, mjg59, mlangsdo, nmurray, plougher, rt-maint, rvrbovsk, skozina, slawomir, steved, sthangav, trankin, vdronov, williams|
|Fixed In Version:||Doc Type:||If docs needed, set a value|
An issue was discovered in the btrfs filesystem code in the Linux kernel. A use-after-free is possible in try_merge_free_space() when mounting a crafted btrfs image due to a lack of chunk type flag checks in btrfs_check_chunk_valid() in the fs/btrfs/volumes.c function. This could lead to a denial of service or other unspecified impact.
|Last Closed:||2018-08-05 16:01:42 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Cloudforms Team:||---||Target Upstream Version:|
|Bug Depends On:||1610085, 1610086|
Description Sam Fowler 2018-07-31 01:31:36 UTC
An issue was discovered in the btrfs filesystem code in the Linux kernel. A use-after-free is possible in try_merge_free_space() when mounting a crafted btrfs image, because of a lack of chunk type flag checks in btrfs_check_chunk_valid() in fs/btrfs/volumes.c, leading to a denial of service or other unspecified impact. References: https://bugzilla.kernel.org/show_bug.cgi?id=199839 A suggested upstream patch: https://patchwork.kernel.org/patch/10503099/
Comment 1 Sam Fowler 2018-07-31 01:32:19 UTC
Created kernel tracking bugs for this issue: Affects: fedora-all [bug 1610085]
Comment 5 Vladis Dronov 2018-08-05 16:01:42 UTC
Notes: While the flaw 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 btrfs fs.img mnt/ mount: mnt/: mount failed: Operation not permitted. The article https://lwn.net/Articles/652468/ 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. In case of a flaw which results in a privilege escalation the flaw's impact is higher. So the Red Hat would still consider bugs which require mounting a filesystem image to exploit as security flaws, though with Low severity.
Comment 6 Justin M. Forbes 2018-09-11 20:39:44 UTC
This is fixed for Fedora with the 4.18 rebases.