Bug 1571627 (CVE-2018-10323) - CVE-2018-10323 kernel: Invalid pointer dereference in xfs_bmapi_write() when mounting and operating on crafted xfs image allows denial of service
Summary: CVE-2018-10323 kernel: Invalid pointer dereference in xfs_bmapi_write() when ...
Keywords:
Status: CLOSED NOTABUG
Alias: CVE-2018-10323
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
low
low
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
URL:
Whiteboard:
Depends On: 1571630 1571631
Blocks: 1571633
TreeView+ depends on / blocked
 
Reported: 2018-04-25 08:51 UTC by Adam Mariš
Modified: 2021-06-10 15:58 UTC (History)
43 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
The xfs_bmap_extents_to_btree function in fs/xfs/libxfs/xfs_bmap.c in the Linux kernel can cause a NULL pointer dereference in xfs_bmapi_write function. An attacker could trick a legitimate user or a privileged attacker could exploit this by mounting a crafted xfs filesystem image to cause a kernel panic and thus a denial of service.
Clone Of:
Environment:
Last Closed: 2019-06-10 10:20:35 UTC
Embargoed:


Attachments (Terms of Use)

Description Adam Mariš 2018-04-25 08:51:33 UTC
The xfs_bmap_extents_to_btree function in fs/xfs/libxfs/xfs_bmap.c in the Linux kernel can cause a NULL pointer dereference in xfs_bmapi_write function. An attacker could trick a legitimate user or a privileged attacker could exploit this by mounting a crafted xfs filesystem image to cause a kernel panic and thus a denial of service.

References:

https://www.spinics.net/lists/linux-xfs/msg17254.html

https://bugzilla.kernel.org/show_bug.cgi?id=199423

An upstream patch:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=2c4306f719b0

Comment 1 Adam Mariš 2018-04-25 08:53:05 UTC
Created kernel tracking bugs for this issue:

Affects: fedora-all [bug 1571630]

Comment 5 Vladis Dronov 2018-05-04 12:42:59 UTC
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 xfs xfs.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.

So the Red Hat would still consider bugs which require mounting a filesystem image to exploit as security flaws.


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