UBSAN: invalid-load in __remove_hrtimer

UBSAN: invalid-load in __remove_hrtimer

[Zijing Yin]

Hi,

Fuzzing v7.1-rc1 (98878ed91b68) with a customized syzkaller on a
KASAN+UBSAN build, I hit the UBSAN invalid-load below in
__remove_hrtimer() (a bool field read as 255).  On the same run it
is immediately followed by a general protection fault on a
non-canonical pointer while __remove_hrtimer() walks the timer
rbtree.

The syzkaller reproducer (repro.prog), a C reproducer (repro.cprog), and
the kernel .config (repro.config) are attached.  It reproduces when the
reproducer is replayed on a KASAN+UBSAN kernel, though not on every run
(roughly 1 VM in 4 within a few minutes); still reachable on the current
mainline tip.  I can send the full dmesg, the disk image, or test a
debugging patch on request.

syzkaller repro: https://bugzilla.kernel.org/attachment.cgi?id=310263
C repro: https://bugzilla.kernel.org/attachment.cgi?id=310264
.config: https://bugzilla.kernel.org/attachment.cgi?id=310265

Full splat:

------------[ cut here ]------------
UBSAN: invalid-load in kernel/time/hrtimer.c:1147:14
load of value 255 is not a valid value for type 'bool' (aka '_Bool')
CPU: 0 UID: 0 PID: 1479 Comm: syz.5.22 Tainted: G    B               7.1.0-rc1-g98878ed91b68-dirty #3 PREEMPT(lazy)
Tainted: [B]=BAD_PAGE
Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
Call Trace:
 <IRQ>
 __dump_stack+0x21/0x30 lib/dump_stack.c:94
 dump_stack_lvl+0x5f/0x8c lib/dump_stack.c:120
 dump_stack+0x19/0x20 lib/dump_stack.c:129
 ubsan_epilogue+0xe/0x40 lib/ubsan.c:233
 __ubsan_handle_load_invalid_value+0xf2/0x100 lib/ubsan.c:527
 __remove_hrtimer+0x436/0x520 kernel/time/hrtimer.c:1147
 __hrtimer_run_queues+0x282/0x900 kernel/time/hrtimer.c:1910
 hrtimer_run_queues+0x1a4/0x210 kernel/time/hrtimer.c:2177
 update_process_times+0x34/0x2b0 kernel/time/timer.c:2420
 tick_nohz_handler+0x468/0x7d0 kernel/time/tick-sched.c:298
 tick_nohz_lowres_handler+0x68/0xd0 kernel/time/tick-sched.c:1531
 __sysvec_apic_timer_interrupt+0x5e/0x270 arch/x86/kernel/apic/apic.c:1050
 sysvec_apic_timer_interrupt+0x72/0x90 arch/x86/kernel/apic/apic.c:1061
 </IRQ>
 <TASK>
 asm_sysvec_apic_timer_interrupt+0x1f/0x30 arch/x86/include/asm/idtentry.h:697
RIP: 0010:memmove+0x1e/0x1b0 arch/x86/lib/memmove_64.S:45
Code: 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 48 89 f8 48 39 fe 7d 0f 49 89 f0 49 01 d0 49 39 f8 0f 8f b5 00 00 00 48 89 d1 <f3> a4 e9 96 ac d3 f8 66 2e 0f 1f 84 00 00 00 00 00 48 81 fa a8 02
RSP: 0018:ff110001273ce6c8 EFLAGS: 00000206
RAX: ff1100011372dea4 RBX: fffffffffffffff0 RCX: fffffffffd9786db
RDX: fffffffffffffff0 RSI: ff11000115db57cd RDI: ff11000115db57b9
RBP: ff110001273ce6f8 R08: ff1100011372de94 R09: 0000000000000000
R10: 00000000ffffffc3 R11: 0000000000000000 R12: 0000000000000000
R13: ffffffff82759003 R14: ff1100011372deb8 R15: ff1100011372dea4
 ext4_xattr_set_entry+0xc13/0x2390 fs/ext4/xattr.c:1763
 ext4_xattr_ibody_set+0x29e/0x740 fs/ext4/xattr.c:2275
 ext4_destroy_inline_data_nolock+0x24b/0x630 fs/ext4/inline.c:472
 ext4_destroy_inline_data+0x87/0x100 fs/ext4/inline.c:1806
 ext4_do_writepages+0x5c7/0x4e40 fs/ext4/inode.c:2827
 ext4_writepages+0x213/0x390 fs/ext4/inode.c:3042
 do_writepages+0x389/0x5c0 mm/page-writeback.c:2575
 file_write_and_wait_range+0x2f6/0x390 mm/filemap.c:388
 mmb_fsync_noflush+0x87/0x240 fs/buffer.c:645
 ext4_sync_file+0x3aa/0xba0 fs/ext4/fsync.c:92
 vfs_fsync_range+0x168/0x190 fs/sync.c:186
 ext4_buffered_write_iter+0x752/0x8a0 include/linux/fs.h:2654
 ext4_file_write_iter+0x707/0x1bf0
 iter_file_splice_write+0xa08/0x1230 fs/splice.c:736
 direct_splice_actor+0x123/0x180 fs/splice.c:936
 splice_direct_to_actor+0x548/0xcf0 fs/splice.c:1103
 do_splice_direct+0x192/0x290 fs/splice.c:1202
 do_sendfile+0x5cf/0xae0 fs/read_write.c:1372
 __se_sys_sendfile64+0x145/0x1b0 fs/read_write.c:1433
 __x64_sys_sendfile64+0x9f/0xb0 fs/read_write.c:1419
 x64_sys_call+0x2dce/0x3030 arch/x86/include/generated/asm/syscalls_64.h:41
 do_syscall_64+0xf7/0x3e0 arch/x86/entry/syscall_64.c:63
 entry_SYSCALL_64_after_hwframe+0x74/0x7c
RIP: 0033:0x7f56a8a20a3d
RSP: 002b:00007f56a8046048 EFLAGS: 00000212 ORIG_RAX: 0000000000000028
RAX: ffffffffffffffda RBX: 00007f56a8ac4ece RCX: 00007f56a8a20a3d
RDX: 0000000000000000 RSI: 0000000000000006 RDI: 0000000000000007
RBP: 00007f56a8046080 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000100000000 R11: 0000000000000212 R12: 00007f56a80466c0
R13: ffffffffffffffb0 R14: 000000000000000b R15: 00007fff53f1de10
 </TASK>
---[ end trace ]---
Oops: general protection fault, probably for non-canonical address 0xf1a7c288031699ea: 0000 [#1] KASAN NOPTI
KASAN: maybe wild-memory-access in range [0x8d3e344018b4cf50-0x8d3e344018b4cf57]
CPU: 0 UID: 0 PID: 1479 Comm: syz.5.22 Tainted: G    B               7.1.0-rc1-g98878ed91b68-dirty #3 PREEMPT(lazy)
Tainted: [B]=BAD_PAGE
RIP: 0010:rb_erase_linked+0x89/0x1a0 lib/rbtree.c:452
Call Trace:
 <IRQ>
 timerqueue_linked_del include/linux/timerqueue.h:66 [inline]
 __remove_hrtimer+0x162/0x520 kernel/time/hrtimer.c:1155
 __hrtimer_run_queues+0x282/0x900 kernel/time/hrtimer.c:1910
 hrtimer_run_queues+0x1a4/0x210 kernel/time/hrtimer.c:2177
 update_process_times+0x34/0x2b0 kernel/time/timer.c:2420
 tick_nohz_handler+0x468/0x7d0 kernel/time/tick-sched.c:298
 tick_nohz_lowres_handler+0x68/0xd0 kernel/time/tick-sched.c:1531
 __sysvec_apic_timer_interrupt+0x5e/0x270 arch/x86/kernel/apic/apic.c:1050
 sysvec_apic_timer_interrupt+0x72/0x90 arch/x86/kernel/apic/apic.c:1061
 </IRQ>
---[ end trace 0000000000000000 ]---

Thanks,
Zijing Yin <yzjaurora@gmail.com>

Re: UBSAN: invalid-load in __remove_hrtimer

[Thomas Gleixner]

On Thu, Jun 04 2026 at 10:10, Zijing Yin wrote:
> Fuzzing v7.1-rc1 (98878ed91b68) with a customized syzkaller on a
> KASAN+UBSAN build, I hit the UBSAN invalid-load below in

Please validate that this still is the case with the latest v7.1-rc6 or
ideally with the head of Linus tree.

> UBSAN: invalid-load in kernel/time/hrtimer.c:1147:14
> load of value 255 is not a valid value for type 'bool' (aka '_Bool')

That's memory corruption from some unknown place unrelated to the
hrtimer subsystem, which acts only as the messenger. 

Which becomes obvious due to this:

> Oops: general protection fault, probably for non-canonical address 0xf1a7c288031699ea: 0000 [#1] KASAN NOPTI

Thanks,

        tglx