* Re: [syzbot] [kernel?] BUG: unable to handle kernel NULL pointer dereference in hrtimer_active
[not found] <00000000000014671906112cb2ef@google.com>
@ 2024-02-12 23:01 ` Thomas Gleixner
2024-02-21 21:29 ` Jakub Kicinski
0 siblings, 1 reply; 2+ messages in thread
From: Thomas Gleixner @ 2024-02-12 23:01 UTC (permalink / raw)
To: syzbot, linux-kernel, syzkaller-bugs
Cc: netdev, Jakub Kicinski, Paolo Abeni, David S. Miller
Cc: +netdev
On Mon, Feb 12 2024 at 02:25, syzbot wrote:
> HEAD commit: 4a7bbe7519b6 Merge tag 'scsi-fixes' of git://git.kernel.or..
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=10476de0180000
> kernel config: https://syzkaller.appspot.com/x/.config?x=264238120cdb2bda
> dashboard link: https://syzkaller.appspot.com/bug?extid=039399a9b96297ddedca
> compiler: aarch64-linux-gnu-gcc (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40
> userspace arch: arm64
>
> Unfortunately, I don't have any reproducer for this issue yet.
>
> Downloadable assets:
> disk image (non-bootable): https://storage.googleapis.com/syzbot-assets/384ffdcca292/non_bootable_disk-4a7bbe75.raw.xz
> vmlinux: https://storage.googleapis.com/syzbot-assets/ee3f97d1ed38/vmlinux-4a7bbe75.xz
> kernel image: https://storage.googleapis.com/syzbot-assets/eb6f9f8f9f37/Image-4a7bbe75.gz.xz
>
> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> Reported-by: syzbot+039399a9b96297ddedca@syzkaller.appspotmail.com
>
> infiniband syz0: set active
> Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010
> CPU: 1 PID: 3665 Comm: syz-executor.0 Not tainted 6.8.0-rc3-syzkaller-00279-g4a7bbe7519b6 #0
> pc : __seqprop_raw_spinlock_sequence include/linux/seqlock.h:226 [inline]
That's:
seq = raw_read_seqcount_begin(&base->seq);
where base == NULL. That can only happen when hrtimer_cancel() is
invoked with a non-initialized timer.
> pc : hrtimer_active+0x4/0x60 kernel/time/hrtimer.c:1614
> lr : hrtimer_try_to_cancel+0x1c/0xf8 kernel/time/hrtimer.c:1331
> sp : ffff800082c63300
> x29: ffff800082c63300 x28: 0000000000000000 x27: 0000000000000000
> x26: 0000000000000340 x25: 0000000000000000 x24: f3ff00001ab7e9e0
> x23: 0000000000000000 x22: 000061100fc019e9 x21: 0000000000000009
> x20: 0000000000000000 x19: fbff00001abf9920 x18: 0000000000000000
> x17: 0000000000000000 x16: 0000000000000000 x15: ffff80008144d28c
> x14: ffff80008144d20c x13: ffff80008144d28c x12: ffff80008144d20c
> x11: ffff800080011558 x10: ffff800081907d14 x9 : ffff8000819078a4
> x8 : ffff800082c63408 x7 : 0000000000000000 x6 : ffff800080026d20
> x5 : f2ff000033f2c800 x4 : 000061100fc019e9 x3 : 0000000000000340
> x2 : 0000000000000000 x1 : 000000000000000d x0 : fbff00001abf9920
> Call trace:
> hrtimer_active+0x4/0x60 kernel/time/hrtimer.c:1613
> hrtimer_cancel+0x1c/0x38 kernel/time/hrtimer.c:1446
> napi_disable+0x5c/0x11c net/core/dev.c:6502
> veth_napi_del_range+0x64/0x1d8 drivers/net/veth.c:1109
> veth_napi_del drivers/net/veth.c:1129 [inline]
> veth_set_features+0x68/0x98 drivers/net/veth.c:1580
> __netdev_update_features+0x200/0x6ec net/core/dev.c:9872
> netdev_update_features+0x28/0x6c net/core/dev.c:9946
> veth_xdp_set drivers/net/veth.c:1681 [inline]
> veth_xdp+0x108/0x224 drivers/net/veth.c:1694
> dev_xdp_install+0x64/0xf8 net/core/dev.c:9243
> dev_xdp_attach+0x250/0x52c net/core/dev.c:9395
> dev_change_xdp_fd+0x16c/0x218 net/core/dev.c:9643
> do_setlink+0xdd0/0xf14 net/core/rtnetlink.c:3132
> rtnl_group_changelink net/core/rtnetlink.c:3452 [inline]
> __rtnl_newlink+0x460/0x898 net/core/rtnetlink.c:3711
> rtnl_newlink+0x50/0x7c net/core/rtnetlink.c:3748
> rtnetlink_rcv_msg+0x12c/0x380 net/core/rtnetlink.c:6615
> netlink_rcv_skb+0x5c/0x128 net/netlink/af_netlink.c:2543
> rtnetlink_rcv+0x18/0x24 net/core/rtnetlink.c:6633
> netlink_unicast_kernel net/netlink/af_netlink.c:1341 [inline]
> netlink_unicast+0x2f4/0x360 net/netlink/af_netlink.c:1367
> netlink_sendmsg+0x1a4/0x3e8 net/netlink/af_netlink.c:1908
> sock_sendmsg_nosec net/socket.c:730 [inline]
> __sock_sendmsg+0x54/0x60 net/socket.c:745
> ____sys_sendmsg+0x274/0x2ac net/socket.c:2584
> ___sys_sendmsg+0xac/0x100 net/socket.c:2638
> __sys_sendmsg+0x84/0xe0 net/socket.c:2667
> __do_sys_sendmsg net/socket.c:2676 [inline]
> __se_sys_sendmsg net/socket.c:2674 [inline]
> __arm64_sys_sendmsg+0x24/0x30 net/socket.c:2674
So something in that syzbot test case manages to tear down a napi
context which has not yet been fully initialized. While the rest of
napi_disable() does not care much as long as neither NAPIF_STATE_SCHED
nor NAPIF_STATE_NPSVC are set in napi->state, hrtimer_cancel() pretty
much cares as demonstrated by the NULL pointer dereference.
While it would be trivial to harden the hrtimer code for the case that a
non-initialized hrtimer is canceled, I wonder whether this invocation of
napi_disable() is harmless (aside of the hrtimer issue) or if there are
some hidden subtle issues with that.
Thanks,
tglx
^ permalink raw reply [flat|nested] 2+ messages in thread