CVE-2017-14340: xfs: unprivileged user kernel oops

Hi folks,

I just pushed this XFS vulnerability disclosure to [email protected], so it's out in public now though I don't know how long it will take to get out through that list.

TL;DR:

Every XFS user needs to check if their kernel is compiled with CONFIG_XFS_RT=y and if they are you should plan to update your kernels as soon as updated kernels filter through the upstream/distro channels.

-Dave.
(Standing in for Darrick, who timed his holiday extremely well)

Summary
-------

XFS mishandles a user settable inode flag in kernels prior to 4.14-rc1 which can cause a local denial of service via a kernel oops.

Description
-----------

Richard Wareing recently discovered that if the XFS kernel code is compiled with CONFIG_XFS_RT=y, the code mishandles FS_XFLAG_RTINHERIT and FS_XFLAG_REALTIME flags when the filesystem does not have a realtime device configured. When an fsync/fdatasync operation is run on an inode configured this way, we attempt to flush the cache of the non-existent realtime device and the kernel will oops.

While a user cannot set the FS_XFLAG_REALTIME directly on such a filesystem, we fail to prevent them from setting the FS_XFLAG_RTINHERIT on directories. Hence files can inherit the problematic FS_XFLAG_REALTIME flag from their parent directory at create time. Setting the FS_XFLAG_RTINHERIT flag does not require special privileges, so any user with permission to write to a directory can set it.

Details of the oops signature and the trivial reproducer can be found in the commit message for the fix below.

Scope of vulnerable filesystems
-------------------------------

This vulnerability was introduced in late 2005 by commit f538d4da8d52 ("[XFS] write barrier support"). Hence XFS filesystems on all kernels since 2.6.16 are vulnerable except for:

* Kernels that are compiled with CONFIG_XFS_RT=n are not vulnerable.

* XFS filesystems with actual realtime devices are not not vulnerable.

How to recognise a vulnerable system
------------------------------------

1. Search the boot log for the XFS initialisation message. If this message contains the world "realtime" then the kernel is vulnerable to the issue:

CONFIG_XFS_RT=y (vulnerable):

# dmesg |grep "XFS with"
[    1.625711] SGI XFS with ACLs, security attributes, realtime, debug enabled

CONFIG_XFS_RT=n (not vulnerable):

# dmesg |grep "XFS with"
[    1.625711] SGI XFS with ACLs, security attributes, debug enabled

2. If you have a vulnerable kernel, check each XFS filesystems to see if they use a realtime device.

This filesystem is not vulnerable as it has a realtime device configured:

# xfs_info /mnt |grep ^realtime
realtime =/dev/ram0              extsz=4096   blocks=2048000, rtextents=2048000

This filesystem is vulnerable if the kernel is vulnerable as it does not have a realtime device:

# xfs_info /mnt |grep ^realtime
realtime =none                   extsz=4096   blocks=0, rtextents=0

Mitigation
----------

Fixed upstream in 4.14-rc1, commit below.

Backports to supported stable upstream kernels is already underway, so fixes will roll out with the next stable kernel releases.

Recompile the kernel with CONFIG_XFS_RT=n. This is recommended for users who cannot wait for upstream or distro kernel updates, cannot backport the fix themselves and do not use realtime devices.

Upstream commit
---------------

commit b31ff3cdf540110da4572e3e29bd172087af65cc

Author: Richard Wareing <[email protected]>
Date:   Wed Sep 13 09:09:35 2017 +1000

xfs: XFS_IS_REALTIME_INODE() should be false if no rt device present

If using a kernel with CONFIG_XFS_RT=y and we set the RHINHERIT flag on a directory in a filesystem that does not have a realtime device and create a new file in that directory, it gets marked as a real time file. When data is written and a fsync is issued, the filesystem attempts to flush a non-existent rt device during the fsync process.

This results in a crash dereferencing a null buftarg pointer in xfs_blkdev_issue_flush():

BUG: unable to handle kernel NULL pointer dereference at 0000000000000008
IP: xfs_blkdev_issue_flush+0xd/0x20
.....
Call Trace:
xfs_file_fsync+0x188/0x1c0
vfs_fsync_range+0x3b/0xa0
do_fsync+0x3d/0x70
SyS_fsync+0x10/0x20
do_syscall_64+0x4d/0xb0 entry_SYSCALL64_slow_path+0x25/0x25

Setting RT inode flags does not require special privileges so any unprivileged user can cause this oops to occur. To reproduce, confirm kernel is compiled with CONFIG_XFS_RT=y and run:

# mkfs.xfs -f /dev/pmem0
# mount /dev/pmem0 /mnt/test
# mkdir /mnt/test/foo
# xfs_io -c 'chattr +t' /mnt/test/foo
# xfs_io -f -c 'pwrite 0 5m' -c fsync /mnt/test/foo/bar

Or just run xfstests with MKFS_OPTIONS="-d rtinherit=1" and wait.

Kernels built with CONFIG_XFS_RT=n are not exposed to this bug.

Timeline:

2017.09.04 - Discussion on [email protected] (public list) hinted
at crash bug in realtime device support
2017.09.09 - Bug found and reported to XFS maintainers 2017.09.12 - Bug reported to [email protected] 2017.09.13 - Fix committed to kernel
2017.09.13 - Announcement to oss-security

Dave Chinner
[email protected]