Re: [PATCH] jfs: add dmapctl integrity check to prevent invalid operations

[Li Lingfeng <lilingfeng3@huawei.com>]

Hi Yun,

在 2025/11/28 8:31, Zhou, Yun 写道:
> 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.

Here is the build warning noticed by kernel test robot:
https://lore.kernel.org/all/202511211750.bjcw3Ucd-lkp@intel.com/

These build warnings appear to be caused by comparisons between unsigned
values and zero. I'm not familiar with JFS, so I'm not sure whether this
logic is necessary or if there is an alternative way to handle the checks.
Could you take a look?

Thanks,
Lingfeng.

>
> Thanks,
> Yun