mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: CJ <firefly0158@163.com>
To: rpeterso@redhat.com, agruenba@redhat.com
Cc: cluster-devel@redhat.com, linux-kernel@vger.kernel.org
Subject: [BUG] gfs2: WARNING in gfs2_check_blk_type on a crafted image
Date: Mon, 21 Sep 2026 16:53:15 +0800 (CST)	[thread overview]
Message-ID: <40b1fda4.85ed.1a0c32b638e.Coremail.firefly0158@163.com> (raw)


Hi,


I am reporting an issue triggered by a syzkaller reproducer on Linux
7.3.0-rc2. The issue is reproducible with HEAD commit
df2908090cda368b01ff43709f51890076c56157.


The reproducer mounts a crafted GFS2 image and then calls
open_by_handle_at() with a hand-built small file handle. No ordinary file
operation is needed; the failure comes from resolving that handle.


Resolving the handle runs gfs2_fh_to_dentry() -> gfs2_lookup_by_inum() ->
gfs2_inode_lookup() -> gfs2_check_blk_type(). The block address taken from
the handle cannot be mapped into its resource group, so
gfs2_rbm_from_block() returns an error and the WARN_ON_ONCE() in
gfs2_check_blk_type() fires. The work is done in the calling task's syscall
context.


This looks like the block number in the file handle being used before it is
checked against the resource group it claims to belong to. Because
open_by_handle_at() is reachable with unprivileged, user-supplied handles,
validating the block address against the resource group geometry before the
lookup would be the guard. I have not determined which field of the handle
carries the out-of-range block number.


This failure was reported earlier against the linux-6.1 longterm series at
https://syzkaller.appspot.com/bug?extid=17b1d6e43bf67dcfc9c7, and the
reproducer below is the one from that report. It still reproduces on the
tested mainline kernel.


Reproducer:


syz reproducer:  https://pastebin.com/raw/V7BaNMRd
console output: https://pastebin.com/raw/hskt7QKp
kernel config: https://syzkaller.appspot.com/text?tag=KernelConfig&x=e1e9066810307299


Kernel:


HEAD commit: df2908090cda368b01ff43709f51890076c56157
git tree: mainline
kernel version: 7.3.0-rc2
tested tag: v7.3-rc2 (annotated tag object 5e036ce12de91c6fd674dad33b169c6150be2a7a)


Let me know if you need more details or testing.


Best regards,
Changjian Liu 

                 reply	other threads:[~2026-09-21  8:53 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=40b1fda4.85ed.1a0c32b638e.Coremail.firefly0158@163.com \
    --to=firefly0158@163.com \
    --cc=agruenba@redhat.com \
    --cc=cluster-devel@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rpeterso@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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®