On Wed 30-04-25 04:14:32, Matthew Wilcox wrote:
> On Tue, Apr 29, 2025 at 03:55:18PM +0800, Zhang Yi wrote:
> > After debugging, I found that this problem is caused by punching a hole
> > with an offset variable larger than max_end on a corrupted ext4 inode,
> > whose i_size is larger than maxbyte. It will result in a negative length
> > in the truncate_inode_partial_folio(), which will trigger this problem.
>
> It seems to me like we're asking for trouble when we allow an inode with
> an i_size larger than max_end to be instantiated. There are probably
> other places which assume it is smaller than max_end. We should probably
> decline to create the bad inode in the first place?
Indeed somewhat less quirky fix could be to make ext4_max_bitmap_size()
return one block smaller limit. Something like:
/* Compute how many blocks we can address by block tree */
res += ppb;
res += ppb * ppb;
res += ((loff_t)ppb) * ppb * ppb;
+ /*
+ * Hole punching assumes it can map the block past end of hole to
+ * tree offsets
+ */
+ res -= 1;
/* Compute how many metadata blocks are needed */
meta_blocks = 1;
meta_blocks += 1 + ppb;
The slight caveat is that in theory there could be filesystems out there
with so large files and then we'd stop allowing access to such files. But I
guess the chances are so low that it's probably worth trying.
Honza
--
Jan Kara <jack@xxxxxxxx>
SUSE Labs, CR
