mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
* [PATCH v2] gfs2: reject journal extents with gaps
@ 2026-03-25 23:51 Deepanshu Kartikey
  2026-03-30  9:42 ` Deepanshu Kartikey
  2026-04-14  2:02 ` Deepanshu Kartikey
  0 siblings, 2 replies; 3+ messages in thread
From: Deepanshu Kartikey @ 2026-03-25 23:51 UTC (permalink / raw)
  To: agruenba, willy
  Cc: adas, gfs2, linux-kernel, Deepanshu Kartikey,
	syzbot+9013411dc43f3582823a

A malicious or corrupted GFS2 filesystem image can have a journal
extent list with gaps between extents. gfs2_find_jhead() advances
blocks_read sequentially through all page indices, but only grabs
pages for blocks it actually visits via filemap_grab_folio(). Pages
falling in the gaps between extents are never grabbed. When the
cleanup loop at out: calls gfs2_jhead_process_page() for these
pages, filemap_get_folio() returns ERR_PTR(-ENOENT) which is passed
directly to folio_wait_locked() without checking for errors, hanging
the kernel task in uninterruptible sleep (state D) forever,
triggering the hung task watchdog.

Fix this by rejecting journal extents with gaps at mapping time
in gfs2_add_jextent(). If the new extent does not start exactly
where the previous one ended, return -EINVAL to reject the
corrupted journal early, before any I/O is submitted.

Fixes: f4686c26ecc3 ("gfs2: read journal in large chunks")
Reported-by: syzbot+9013411dc43f3582823a@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=9013411dc43f3582823a
Link: https://lore.kernel.org/all/20260324033959.1456418-1-kartikey406@gmail.com/T/ [v1]
Suggested-by: Andreas Gruenbacher <agruenba@redhat.com>
Signed-off-by: Deepanshu Kartikey <kartikey406@gmail.com>

---
Changes in v2:
- Instead of checking ERR_PTR in gfs2_jhead_process_page(), reject
  the gap at extent mapping time in gfs2_add_jextent() as suggested
  by Andreas Gruenbacher.
---
 fs/gfs2/bmap.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/fs/gfs2/bmap.c b/fs/gfs2/bmap.c
index 1cd8ec0bce83..d3ba37291e4c 100644
--- a/fs/gfs2/bmap.c
+++ b/fs/gfs2/bmap.c
@@ -2219,6 +2219,8 @@ static int gfs2_add_jextent(struct gfs2_jdesc *jd, u64 lblock, u64 dblock, u64 b
 
 	if (!list_empty(&jd->extent_list)) {
 		jext = list_last_entry(&jd->extent_list, struct gfs2_journal_extent, list);
+		if (jext->lblock + jext->blocks != lblock)
+			return -EINVAL;
 		if ((jext->dblock + jext->blocks) == dblock) {
 			jext->blocks += blocks;
 			return 0;
-- 
2.43.0


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [PATCH v2] gfs2: reject journal extents with gaps
  2026-03-25 23:51 [PATCH v2] gfs2: reject journal extents with gaps Deepanshu Kartikey
@ 2026-03-30  9:42 ` Deepanshu Kartikey
  2026-04-14  2:02 ` Deepanshu Kartikey
  1 sibling, 0 replies; 3+ messages in thread
From: Deepanshu Kartikey @ 2026-03-30  9:42 UTC (permalink / raw)
  To: agruenba, willy; +Cc: adas, gfs2, linux-kernel, syzbot+9013411dc43f3582823a

On Thu, Mar 26, 2026 at 5:22 AM Deepanshu Kartikey
<kartikey406@gmail.com> wrote:
>
> A malicious or corrupted GFS2 filesystem image can have a journal
> extent list with gaps between extents. gfs2_find_jhead() advances
> blocks_read sequentially through all page indices, but only grabs
> pages for blocks it actually visits via filemap_grab_folio(). Pages
> falling in the gaps between extents are never grabbed. When the
> cleanup loop at out: calls gfs2_jhead_process_page() for these
> pages, filemap_get_folio() returns ERR_PTR(-ENOENT) which is passed
> directly to folio_wait_locked() without checking for errors, hanging
> the kernel task in uninterruptible sleep (state D) forever,
> triggering the hung task watchdog.
>
> Fix this by rejecting journal extents with gaps at mapping time
> in gfs2_add_jextent(). If the new extent does not start exactly
> where the previous one ended, return -EINVAL to reject the
> corrupted journal early, before any I/O is submitted.
>
> Fixes: f4686c26ecc3 ("gfs2: read journal in large chunks")
> Reported-by: syzbot+9013411dc43f3582823a@syzkaller.appspotmail.com
> Closes: https://syzkaller.appspot.com/bug?extid=9013411dc43f3582823a
> Link: https://lore.kernel.org/all/20260324033959.1456418-1-kartikey406@gmail.com/T/ [v1]
> Suggested-by: Andreas Gruenbacher <agruenba@redhat.com>
> Signed-off-by: Deepanshu Kartikey <kartikey406@gmail.com>
>
> ---
> Changes in v2:
> - Instead of checking ERR_PTR in gfs2_jhead_process_page(), reject
>   the gap at extent mapping time in gfs2_add_jextent() as suggested
>   by Andreas Gruenbacher.
> ---
>  fs/gfs2/bmap.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/fs/gfs2/bmap.c b/fs/gfs2/bmap.c
> index 1cd8ec0bce83..d3ba37291e4c 100644
> --- a/fs/gfs2/bmap.c
> +++ b/fs/gfs2/bmap.c
> @@ -2219,6 +2219,8 @@ static int gfs2_add_jextent(struct gfs2_jdesc *jd, u64 lblock, u64 dblock, u64 b
>
>         if (!list_empty(&jd->extent_list)) {
>                 jext = list_last_entry(&jd->extent_list, struct gfs2_journal_extent, list);
> +               if (jext->lblock + jext->blocks != lblock)
> +                       return -EINVAL;
>                 if ((jext->dblock + jext->blocks) == dblock) {
>                         jext->blocks += blocks;
>                         return 0;
> --
> 2.43.0
>
Hi Andreas,

gentle ping on this patch . Let me know if anything else required from my side

Thanks
Deepanshu

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [PATCH v2] gfs2: reject journal extents with gaps
  2026-03-25 23:51 [PATCH v2] gfs2: reject journal extents with gaps Deepanshu Kartikey
  2026-03-30  9:42 ` Deepanshu Kartikey
@ 2026-04-14  2:02 ` Deepanshu Kartikey
  1 sibling, 0 replies; 3+ messages in thread
From: Deepanshu Kartikey @ 2026-04-14  2:02 UTC (permalink / raw)
  To: agruenba, willy; +Cc: adas, gfs2, linux-kernel, syzbot+9013411dc43f3582823a

On Thu, Mar 26, 2026 at 5:22 AM Deepanshu Kartikey
<kartikey406@gmail.com> wrote:
>
> A malicious or corrupted GFS2 filesystem image can have a journal
> extent list with gaps between extents. gfs2_find_jhead() advances
> blocks_read sequentially through all page indices, but only grabs
> pages for blocks it actually visits via filemap_grab_folio(). Pages
> falling in the gaps between extents are never grabbed. When the
> cleanup loop at out: calls gfs2_jhead_process_page() for these
> pages, filemap_get_folio() returns ERR_PTR(-ENOENT) which is passed
> directly to folio_wait_locked() without checking for errors, hanging
> the kernel task in uninterruptible sleep (state D) forever,
> triggering the hung task watchdog.
>
> Fix this by rejecting journal extents with gaps at mapping time
> in gfs2_add_jextent(). If the new extent does not start exactly
> where the previous one ended, return -EINVAL to reject the
> corrupted journal early, before any I/O is submitted.
>
> Fixes: f4686c26ecc3 ("gfs2: read journal in large chunks")
> Reported-by: syzbot+9013411dc43f3582823a@syzkaller.appspotmail.com
> Closes: https://syzkaller.appspot.com/bug?extid=9013411dc43f3582823a
> Link: https://lore.kernel.org/all/20260324033959.1456418-1-kartikey406@gmail.com/T/ [v1]
> Suggested-by: Andreas Gruenbacher <agruenba@redhat.com>
> Signed-off-by: Deepanshu Kartikey <kartikey406@gmail.com>
>
> ---
> Changes in v2:
> - Instead of checking ERR_PTR in gfs2_jhead_process_page(), reject
>   the gap at extent mapping time in gfs2_add_jextent() as suggested
>   by Andreas Gruenbacher.
> ---
>  fs/gfs2/bmap.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/fs/gfs2/bmap.c b/fs/gfs2/bmap.c
> index 1cd8ec0bce83..d3ba37291e4c 100644
> --- a/fs/gfs2/bmap.c
> +++ b/fs/gfs2/bmap.c
> @@ -2219,6 +2219,8 @@ static int gfs2_add_jextent(struct gfs2_jdesc *jd, u64 lblock, u64 dblock, u64 b
>
>         if (!list_empty(&jd->extent_list)) {
>                 jext = list_last_entry(&jd->extent_list, struct gfs2_journal_extent, list);
> +               if (jext->lblock + jext->blocks != lblock)
> +                       return -EINVAL;
>                 if ((jext->dblock + jext->blocks) == dblock) {
>                         jext->blocks += blocks;
>                         return 0;
> --
> 2.43.0
>

Gentle ping on this patch. Please let me know the status of this patch

Thanks

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2026-04-14  2:02 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2026-03-25 23:51 [PATCH v2] gfs2: reject journal extents with gaps Deepanshu Kartikey
2026-03-30  9:42 ` Deepanshu Kartikey
2026-04-14  2:02 ` Deepanshu Kartikey

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®