]> git.ipfire.org Git - thirdparty/xfsprogs-dev.git/commit
xfs: verify extent size hint is valid in inode verifier
authorDave Chinner <dchinner@redhat.com>
Thu, 28 Jun 2018 20:11:58 +0000 (15:11 -0500)
committerEric Sandeen <sandeen@redhat.com>
Thu, 28 Jun 2018 20:11:58 +0000 (15:11 -0500)
commit316d5a9f3c1e3fa221840465188e44d8e2ce7e9c
tree965c0ec38a7b99430542ff7818caf9d9e1aa33bd
parent595add55ed086797de1e9c6997a82c7e3f5cdfa4
xfs: verify extent size hint is valid in inode verifier

Source kernel commit: 7d71a671a2d900606d3a62ed5976d3b0feada3a6

There are rules for vald extent size hints. We enforce them when
applications set them, but fuzzers violate those rules and that
screws us over.

This results in alignment assertion failures when setting up
allocations such as this in direct IO:

XFS: Assertion failed: ap->length, file: fs/xfs/libxfs/xfs_bmap.c, line: 3432
....
Call Trace:
xfs_bmap_btalloc+0x415/0x910
xfs_bmapi_write+0x71c/0x12e0
xfs_iomap_write_direct+0x2a9/0x420
xfs_file_iomap_begin+0x4dc/0xa70
iomap_apply+0x43/0x100
iomap_file_buffered_write+0x62/0x90
xfs_file_buffered_aio_write+0xba/0x300
__vfs_write+0xd5/0x150
vfs_write+0xb6/0x180
ksys_write+0x45/0xa0
do_syscall_64+0x5a/0x180
entry_SYSCALL_64_after_hwframe+0x49/0xbe

And from xfs_db:

core.extsize = 10380288

Which is not an integer multiple of the block size, and so violates
Rule #7 for setting extent size hints. Validate extent size hint
rules in the inode verifier to catch this.

Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Carlos Maiolino <cmaiolino@redhat.com>
Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Eric Sandeen <sandeen@sandeen.net>
libxfs/xfs_inode_buf.c