mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: CJ <firefly0158@163.com>
To: shaggy@kernel.org, yun.zhou@windriver.com, kees@kernel.org
Cc: jfs-discussion@lists.sourceforge.net, linux-kernel@vger.kernel.org
Subject: [BUG] jfs: KASAN use-after-free in dbAllocBits
Date: Mon, 14 Sep 2026 17:07:03 +0800 (CST)	[thread overview]
Message-ID: <1b673213.898c.1a09f2b820a.Coremail.firefly0158@163.com> (raw)


Hi,


I am reporting a memory-safety failure in the JFS block-map allocation path,
triggered by a syzkaller reproducer that mounts a crafted JFS image.  The issue
is reproducible with HEAD commit cee9395acd8043be0644b25c34bfa86623f2b935
(v7.3-rc1, Linux 7.3.0-rc1).


The reproducer mounts a crafted JFS filesystem image on a loop device and then
sets an extended attribute, which makes JFS allocate new blocks for the
attribute's extent.


KASAN reports a use-after-free with an 8-byte read in dbAllocBits.  The call
path is dbAllocBits -> dbAllocDmap -> dbAlloc -> ea_get -> __jfs_setxattr, so
the failing read happens while the allocator walks the dmap structures it is
supposed to be updating.


On the kernel where this was first reported the same allocation path was
reported by UBSAN as an array-index-out-of-bounds at fs/jfs/jfs_dmap.c:2306,
where index 2000 was out of range for a s64[128] array.  The two kernels
therefore expose the failure differently: an out-of-bounds index on the older
one, a read of a freed object on v7.3-rc1.  One possible explanation is that the
out-of-bounds access corrupts or consumes allocator state and a later access on
the same path lands in freed memory; I am describing this as a likely recurrence
rather than a byte-identical one because the failure classes differ.


This appears to be a recurrence of the syzbot issue whose external id is
76c960a839deb49a86ec.  It remains reproducible on v7.3-rc1.


Reproducer:


syz reproducer: https://pastebin.com/raw/yDcERU48

console output: https://pastebin.com/raw/WNGvLrcf

kernel config: https://pastebin.com/raw/9EbVbhhc


Kernel:


HEAD commit: cee9395acd8043be0644b25c34bfa86623f2b935
git tree: upstream (linux.git), tested through the v7.3-rc1 annotated tag object
           e5e04726cdd043e309677071ab1b65a4b18f422b
kernel version: 7.3.0-rc1 #1 PREEMPT(full)
tested tag: v7.3-rc1 (Linux 7.3-rc1, 2026-08-30)


Let me know if you need more details or testing.


Best regards,
Changjian

                 reply	other threads:[~2026-09-14  9:07 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=1b673213.898c.1a09f2b820a.Coremail.firefly0158@163.com \
    --to=firefly0158@163.com \
    --cc=jfs-discussion@lists.sourceforge.net \
    --cc=kees@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=shaggy@kernel.org \
    --cc=yun.zhou@windriver.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®