I will just mention in passing that we augment the XFS_IOC_ALLOC ioctl to perform explicit near-to-block allocation. I’m not suggesting you shouldn’t withdraw the ioctls, just referencing xkcd 1172.
—
Roger
> On 13 Jan 2022, at 03:47, Dave Chinner <david@xxxxxxxxxxxxx> wrote:
>
> On Tue, Jan 11, 2022 at 03:22:46PM -0800, Darrick J. Wong wrote:
>> From: Darrick J. Wong <djwong@xxxxxxxxxx>
>>
>> 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: 983d8e60f508 ("xfs: map unwritten blocks in XFS_IOC_{ALLOC,FREE}SP just like fallocate")
>> Signed-off-by: Darrick J. Wong <djwong@xxxxxxxxxx>
>> Reviewed-by: Eric Sandeen <sandeen@xxxxxxxxxx>
>
> Looks good now.
>
> Reviewed-by: Dave Chinner <dchinner@xxxxxxxxxx>
> --
> Dave Chinner
> david@xxxxxxxxxxxxx
>
