mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Zhou, Yun" <yun.zhou@windriver.com>
To: Li Lingfeng <lilingfeng3@huawei.com>, shaggy@kernel.org
Cc: rand.sec96@gmail.com, contact@arnaud-lcm.com,
	kovalev@altlinux.org, zheng.yu@northwestern.edu, eadavis@qq.com,
	jfs-discussion@lists.sourceforge.net,
	linux-kernel@vger.kernel.org, linan122@huawei.com,
	yangerkun <yangerkun@huawei.com>
Subject: Re: [PATCH] jfs: add dmapctl integrity check to prevent invalid operations
Date: Fri, 28 Nov 2025 08:31:50 +0800	[thread overview]
Message-ID: <72461ffe-925a-46e4-bb25-19128d030f79@windriver.com> (raw)
In-Reply-To: <c201cbe0-5f52-4572-a04c-dc165eccff95@huawei.com>

Hi Lingfeng,



On 11/24/25 19:42, Li Lingfeng wrote:
> CAUTION: This email comes from a non Wind River email account!
> Do not click links or open attachments unless you recognize the sender 
> and know the content is safe.
>
> Hi Yun,
>
> Recently, we triggered a UBSAN warning through syzkaller:
> [  126.922474][  T769] UBSAN: shift-out-of-bounds in
> fs/jfs/jfs_dmap.c:2646:11
> [  126.923505][  T769] shift exponent 110 is too large for 32-bit type 
> 'int'
> [  126.924543][  T769] CPU: 14 UID: 0 PID: 769 Comm: repro Not tainted
> 6.18.0-rc6+ #127 PREEMPT(none)
> [  126.924549][  T769] Hardware name: QEMU Standard PC (i440FX + PIIX,
> 1996), BIOS 1.16.3-2.fc40 04/01/2014
> [  126.924552][  T769] Call Trace:
> [  126.924555][  T769]  <TASK>
> [  126.924557][  T769]  dump_stack_lvl+0x4b/0x70
> [  126.924572][  T769]  ubsan_epilogue+0x5/0x2b
> [  126.924583][  T769] __ubsan_handle_shift_out_of_bounds.cold+0x61/0xe6
> [  126.924588][  T769]  ? do_read_cache_folio+0x9c/0x330
> [  126.924598][  T769]  dbSplit+0x153/0x190
> [  126.924607][  T769]  dbAdjCtl+0x413/0x6b1
> [  126.924613][  T769]  dbAllocDmap+0xbc/0xe4
> [  126.924618][  T769]  dbAlloc+0x5df/0x803
> [  126.924624][  T769]  ea_write+0x26f/0x628
> [  126.924629][  T769]  ? ea_get+0x639/0x1260
> [  126.924634][  T769]  ? __pfx_ea_write+0x10/0x10
> [  126.924637][  T769]  ? __pfx__printk+0x10/0x10
> [  126.924645][  T769]  ? __pfx_ea_get+0x10/0x10
> [  126.924649][  T769]  ea_put+0x1b5/0x567
> [  126.924653][  T769]  __jfs_setxattr.cold+0x4e8/0x632
> [  126.924658][  T769]  ? __pfx___jfs_setxattr+0x10/0x10
> [  126.924661][  T769]  ? __pfx__printk+0x10/0x10
> [  126.924665][  T769]  ? mutex_lock+0x86/0xe0
> [  126.924675][  T769]  ? __pfx_mutex_lock+0x10/0x10
> [  126.924681][  T769]  __jfs_xattr_set+0xe4/0x149
> [  126.924685][  T769]  ? __pfx___jfs_xattr_set+0x10/0x10
> [  126.924689][  T769]  ? xattr_full_name+0x3a/0x80
> [  126.924693][  T769]  __vfs_setxattr+0x118/0x150
> [  126.924699][  T769]  ? __pfx___vfs_setxattr+0x10/0x10
> [  126.924703][  T769]  ? security_inode_setxattr+0x1a2/0x2a0
> [  126.924711][  T769]  __vfs_setxattr_noperm.cold+0x1f/0x59
> [  126.924716][  T769]  vfs_setxattr+0x11b/0x300
> [  126.924720][  T769]  ? __pfx_vfs_setxattr+0x10/0x10
> [  126.924724][  T769]  ? check_heap_object+0x6f/0x430
> [  126.924731][  T769]  ? do_setxattr+0xa7/0x150
> [  126.924734][  T769]  filename_setxattr+0x124/0x160
> [  126.924738][  T769]  ? __pfx_filename_setxattr+0x10/0x10
> [  126.924742][  T769]  ? getname_flags.part.0+0xf8/0x480
> [  126.924749][  T769]  path_setxattrat+0x215/0x290
> [  126.924753][  T769]  ? __pfx_path_setxattrat+0x10/0x10
> [  126.924757][  T769]  ? __call_rcu_common.constprop.0+0x341/0x970
> [  126.924767][  T769]  ? __pfx___call_rcu_common.constprop.0+0x10/0x10
> [  126.924772][  T769]  ? kmem_cache_free+0x3dd/0x5d0
> [  126.924778][  T769]  ? kmem_cache_free+0x40b/0x5d0
> [  126.924781][  T769]  ? fput_close_sync+0xdc/0x190
> [  126.924789][  T769]  ? fput_close_sync+0xdc/0x190
> [  126.924792][  T769]  ? __pfx_fput_close_sync+0x10/0x10
> [  126.924796][  T769]  ? file_close_fd_locked+0x178/0x2a0
> [  126.924803][  T769]  __x64_sys_lsetxattr+0xc9/0x140
> [  126.924807][  T769]  do_syscall_64+0x61/0x9d0
> [  126.924814][  T769]  entry_SYSCALL_64_after_hwframe+0x76/0x7e
> [  126.924818][  T769] RIP: 0033:0x44c84d
> [  126.924823][  T769] Code: 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 f3
> 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c
> 24 08 0f 05 <48> 3d 01 f0 ff ff 738
> [  126.924827][  T769] RSP: 002b:00007ffcbf892088 EFLAGS: 00000287
> ORIG_RAX: 00000000000000bd
> [  126.924833][  T769] RAX: ffffffffffffffda RBX: 00007ffcbf892278 RCX:
> 000000000044c84d
> [  126.924835][  T769] RDX: 0000000000000000 RSI: 0000200000000200 RDI:
> 0000200000000040
> [  126.924838][  T769] RBP: 00007ffcbf892090 R08: 0000000000000000 R09:
> 0000000000000001
> [  126.924840][  T769] R10: 0000000000000000 R11: 0000000000000287 R12:
> 0000000000000001
> [  126.924842][  T769] R13: 00007ffcbf892268 R14: 00000000004c38d0 R15:
> 0000000000000001
> [  126.924848][  T769]  </TASK>
> [  126.924850][  T769] ---[ end trace ]---
>
> The warning occurred because syzkaller constructed a malformed image, and
> JFS read an invalid leaf value from it.
>
> In our testing, this patch resolves the issue by preventing the use of 
> the
> invalid value:
> [   39.890789][  T765] dmapctl: leaf value 124 too large at index 341
> [   39.891684][  T765] ERROR: (device loop0): dbAdjCtl: Corrupt 
> dmapctl page
> [   39.891684][  T765]
> [   39.893343][  T765] ERROR: (device loop0): remounting filesystem as
> read-only
>
> However, I noticed that this patch triggers some build warnings.
> Could you please help address these warnings and push the fix upstream? 
I wonder what build warnings you encountered, since I have not seen it.

Thanks,
Yun

  reply	other threads:[~2025-11-28  0:33 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-11-20 15:44 Yun Zhou
2025-11-24 11:42 ` Li Lingfeng
2025-11-28  0:31   ` Zhou, Yun [this message]
2025-11-28  1:17     ` Li Lingfeng

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=72461ffe-925a-46e4-bb25-19128d030f79@windriver.com \
    --to=yun.zhou@windriver.com \
    --cc=contact@arnaud-lcm.com \
    --cc=eadavis@qq.com \
    --cc=jfs-discussion@lists.sourceforge.net \
    --cc=kovalev@altlinux.org \
    --cc=lilingfeng3@huawei.com \
    --cc=linan122@huawei.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rand.sec96@gmail.com \
    --cc=shaggy@kernel.org \
    --cc=yangerkun@huawei.com \
    --cc=zheng.yu@northwestern.edu \
    /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®