Forked from
drm / msm
200155 commits behind the upstream repository.
-
Darrick J. Wong authored
According to the glibc compat header for Irix 4, these ioctls originated in April 1991 as a (somewhat clunky) way to preallocate space at the end of a file on an EFS filesystem. XFS, which was released in Irix 5.3 in December 1993, picked up these ioctls to maintain compatibility and they were ported to Linux in the early 2000s. Recently it was pointed out to me they still lurk in the kernel, even though the Linux fallocate syscall supplanted the functionality a long time ago. fstests doesn't seem to include any real functional or stress tests for these ioctls, which means that the code quality is ... very questionable. Most notably, it was a stale disk block exposure vector for 21 years and nobody noticed or complained. As mature programmers say, "If you're not testing it, it's broken." Given all that, let's withdraw these ioctls from the XFS userspace API. Normally we'd set a long deprecation process, but I estimate that there aren't any real users, so let's trigger a warning in dmesg and return -ENOTTY. See: CVE-2021-4155 Augments: 983d8e60 ("xfs: map unwritten blocks in XFS_IOC_{ALLOC,FREE}SP just like fallocate") Signed-off-by:
Darrick J. Wong <djwong@kernel.org> Reviewed-by:
Eric Sandeen <sandeen@redhat.com> Reviewed-by:
Dave Chinner <dchinner@redhat.com>
Darrick J. Wong authoredAccording to the glibc compat header for Irix 4, these ioctls originated in April 1991 as a (somewhat clunky) way to preallocate space at the end of a file on an EFS filesystem. XFS, which was released in Irix 5.3 in December 1993, picked up these ioctls to maintain compatibility and they were ported to Linux in the early 2000s. Recently it was pointed out to me they still lurk in the kernel, even though the Linux fallocate syscall supplanted the functionality a long time ago. fstests doesn't seem to include any real functional or stress tests for these ioctls, which means that the code quality is ... very questionable. Most notably, it was a stale disk block exposure vector for 21 years and nobody noticed or complained. As mature programmers say, "If you're not testing it, it's broken." Given all that, let's withdraw these ioctls from the XFS userspace API. Normally we'd set a long deprecation process, but I estimate that there aren't any real users, so let's trigger a warning in dmesg and return -ENOTTY. See: CVE-2021-4155 Augments: 983d8e60 ("xfs: map unwritten blocks in XFS_IOC_{ALLOC,FREE}SP just like fallocate") Signed-off-by:
xfs_ioctl.h 1.47 KiB
// SPDX-License-Identifier: GPL-2.0
/*
* Copyright (c) 2008 Silicon Graphics, Inc.
* All Rights Reserved.
*/
#ifndef __XFS_IOCTL_H__
#define __XFS_IOCTL_H__
struct xfs_bstat;
struct xfs_ibulk;
struct xfs_inogrp;
int
xfs_ioc_swapext(
xfs_swapext_t *sxp);
extern int
xfs_find_handle(
unsigned int cmd,
xfs_fsop_handlereq_t *hreq);
extern int
xfs_open_by_handle(
struct file *parfilp,
xfs_fsop_handlereq_t *hreq);
extern int
xfs_readlink_by_handle(
struct file *parfilp,
xfs_fsop_handlereq_t *hreq);
int xfs_ioc_attrmulti_one(struct file *parfilp, struct inode *inode,
uint32_t opcode, void __user *uname, void __user *value,
uint32_t *len, uint32_t flags);
int xfs_ioc_attr_list(struct xfs_inode *dp, void __user *ubuf,
size_t bufsize, int flags,
struct xfs_attrlist_cursor __user *ucursor);
extern struct dentry *
xfs_handle_to_dentry(
struct file *parfilp,
void __user *uhandle,
u32 hlen);
extern int
xfs_fileattr_get(
struct dentry *dentry,
struct fileattr *fa);
extern int
xfs_fileattr_set(
struct user_namespace *mnt_userns,
struct dentry *dentry,
struct fileattr *fa);
extern long
xfs_file_ioctl(
struct file *filp,
unsigned int cmd,
unsigned long p);
extern long
xfs_file_compat_ioctl(
struct file *file,
unsigned int cmd,
unsigned long arg);
int xfs_fsbulkstat_one_fmt(struct xfs_ibulk *breq,
const struct xfs_bulkstat *bstat);
int xfs_fsinumbers_fmt(struct xfs_ibulk *breq, const struct xfs_inumbers *igrp);
#endif