Hey Colin,
This looks to be intentional? Afaict, the -EFBIG might ceome directly
from vfs_fallocate():
/* Check for wrap through zero too */
if (((offset + len) > inode->i_sb->s_maxbytes) || ((offset + len) < 0))
return -EFBIG;
and you should see the same behavior for 64bit if you pass in -1 as
offset:
brauner@wittgenstein|~/Downloads
> sudo ./fallocate
got signal SIGXFSZ
offset: 65536 (0x10000), fallocate returned: -1
got signal SIGXFSZ
offset: 4294966271 (0xfffffbff), fallocate returned: -1
offset: 18446744073709551615 (0xffffffffffffffff), fallocate returned: -1
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1994079
Title:
fallocate on 32 bit boundary on 32 bit systems with setrlimit fails to
generate SIGXFSZ signal
Status in Linux:
Confirmed
Status in linux package in Ubuntu:
New
Bug description:
This is a corner case on 32 bit systems when using large file offsets,
fallocate and setrlimit.
Setting the RLIMIT_FSIZE with setrlimit to 0xffffffff and then
fallocating 1 or more bytes at the offset of 0xffffffff should make
the fallocate fail with EFBIG and generate a SIGXFSZ signal. On 64 bit
platforms this works, on 32 bit platforms such as i386 Ubuntu bionic
with 4.15 kernels it fails to generate EFBIG errors and SIGXFSZ.
Attached is a test program to illustrate the problem. It sets the file
size limit and allocates 1024 bytes at the boundary file size limit
for 3 offsets:
On 64 bit systems we get the expected results:
got signal SIGXFSZ
offset: 65536 (0x10000), fallocate returned: -1
got signal SIGXFSZ
offset: 4294966271 (0xfffffbff), fallocate returned: -1
got signal SIGXFSZ
offset: 4294967295 (0xffffffff), fallocate returned: -1
On 32 bit systems the code fails on the 0xffffffff offset:
got signal SIGXFSZ
offset: 65536 (0x10000), fallocate returned: -1
got signal SIGXFSZ
offset: 4294966271 (0xfffffbff), fallocate returned: -1
offset: 4294967295 (0xffffffff), fallocate returned: 0
Attached is the reproducer.
I found this while developing a file limit boundary test case in
stress-ng and discovered it breaks on all 32 bit kernels (armhf, i386,
etc), even with recent 5.15 kernels.
This could be seen as a security issue; the sysadmin can set the file
size limit and yet a 32 bit system can use a corner case like this to
fallocate a much larger file by using the 0xffffffff offset and a huge
fallocate size.
To manage notifications about this bug go to:
https://bugs.launchpad.net/linux/+bug/1994079/+subscriptions
--
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help : https://help.launchpad.net/ListHelp
