[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHc6FU5YgChLiiUtEmS8pJGHUUhHAK3eYrrGd+FaNMDLti786g@mail.gmail.com>
Date: Mon, 13 Jan 2025 16:41:36 +0100
From: Andreas Gruenbacher <agruenba@...hat.com>
To: Jan Kara <jack@...e.cz>
Cc: viro@...iv.linux.org.uk, brauner@...nel.org, linux-fsdevel@...r.kernel.org,
linux-kernel@...r.kernel.org,
"jjtan24@...udan.edu.cn" <jjtan24@...udan.edu.cn>, gfs2@...ts.linux.dev,
Kun Hu <huk23@...udan.edu.cn>
Subject: Re: Bug: slab-out-of-bounds Write in __bh_read
Hi Jan,
Am Fr., 10. Jan. 2025 um 18:18 Uhr schrieb Kun Hu <huk23@...udan.edu.cn>:
> > Thanks. Based on the crash report and the reproducer it indeed looks like
> > some mixing of iomap_folio_state and buffer heads attached to a folio
> > (iomap_folio_state is attached there but we end up calling
> > __block_write_begin_int() which expects buffer heads there) in GFS2. GFS2
> > guys, care to have a look?
> >
>
> Thanks to Jan.
>
> Hi Andreas,
>
> It seems that iomap_write_begin is expected to handle I/O directly based on folio, rather than entering the buffer head path. Is it possible that GFS2 incorrectly passes data related to buffer head to iomap_write_begin?
>
> Could you please help us to check the exact cause of the issue?
32generated_program.c memory maps the filesystem image, mounts it, and
then modifies it through the memory map. It's those modifications that
cause gfs2 to crash, so the test case is invalid.
Is disabling CONFIG_BLK_DEV_WRITE_MOUNTED supposed to prevent that? If
so, then it doesn't seem to be working.
Thanks,
Andreas
Powered by blists - more mailing lists