From URL: 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 <rwareing () fb com> 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. Fixes: f538d4da8d52 ("[XFS] write barrier support") Cc: <stable () vger kernel org> Signed-off-by: Richard Wareing <rwareing () fb com> Signed-off-by: Dave Chinner <david () fromorbit com> Signed-off-by: Linus Torvalds <torvalds () linux-foundation org> Timeline: 2017.09.04 - Discussion on xfs () vger kernel org (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 security () kernel org 2017.09.13 - Fix committed to kernel 2017.09.13 - Announcement to oss-security -Dave. -- Dave Chinner david () fromorbit com
Fix in 4.9.50, 4.14
