linux-ext4 - Re: kernel BUG in zero_user

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <znfg4s5ysxqvrzeevkmtgixj5vztcyqbuny7waqkugnzkpg2zx@2vxwh57flvva>
Date: Thu, 1 May 2025 13:19:13 +0200
From: Jan Kara <jack@...e.cz>
To: Matthew Wilcox <willy@...radead.org>
Cc: Zhang Yi <yi.zhang@...wei.com>, Liebes Wang <wanghaichi0403@...il.com>, 
	Jan Kara <jack@...e.cz>, ojaswin@...ux.ibm.com, Theodore Ts'o <tytso@....edu>, 
	linux-fsdevel@...r.kernel.org, syzkaller@...glegroups.com, 
	Ext4 Developers List <linux-ext4@...r.kernel.org>
Subject: Re: kernel BUG in zero_user_segments

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@...e.com>
SUSE Labs, CR