From: syzbot <syzbot+6acef9e0a4d1f46c83d4@syzkaller.appspotmail.com>
To: jchapman@katalix.com
Cc: davem@davemloft.net, edumazet@google.com, jchapman@katalix.com,
kuba@kernel.org, linux-kernel@vger.kernel.org,
netdev@vger.kernel.org, pabeni@redhat.com,
syzkaller-bugs@googlegroups.com
Subject: Re: [syzbot] [net?] BUG: unable to handle kernel paging request in net_generic
Date: Mon, 29 Jul 2024 04:49:49 -0700 [thread overview]
Message-ID: <0000000000005060f2061e6175b6@google.com> (raw)
In-Reply-To: <6b40e022-369c-8083-07d4-3036de1d3e65@katalix.com>
> On 26/07/2024 16:02, Jakub Kicinski wrote:
>> CC: James [L2TP]
>>
>> On Thu, 25 Jul 2024 03:37:24 -0700 syzbot wrote:
>>> Hello,
>>>
>>> syzbot found the following issue on:
>>>
>>> HEAD commit: c912bf709078 Merge remote-tracking branches 'origin/arm64-..
>>> git tree: git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git for-kernelci
>>> console output: https://syzkaller.appspot.com/x/log.txt?x=1625a15e980000
>>> kernel config: https://syzkaller.appspot.com/x/.config?x=79a49b0b9ffd6585
>>> dashboard link: https://syzkaller.appspot.com/bug?extid=6acef9e0a4d1f46c83d4
>>> compiler: Debian clang version 15.0.6, 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: https://storage.googleapis.com/syzbot-assets/fea69a9d153c/disk-c912bf70.raw.xz
>>> vmlinux: https://storage.googleapis.com/syzbot-assets/be06762a72ef/vmlinux-c912bf70.xz
>>> kernel image: https://storage.googleapis.com/syzbot-assets/6c8e58b4215d/Image-c912bf70.gz.xz
>>>
>>> IMPORTANT: if you fix the issue, please add the following tag to the commit:
>>> Reported-by: syzbot+6acef9e0a4d1f46c83d4@syzkaller.appspotmail.com
>>>
>>> Unable to handle kernel paging request at virtual address dfff800000000257
>>> KASAN: probably user-memory-access in range [0x00000000000012b8-0x00000000000012bf]
> >> ...
>>> Call trace:
>>> net_generic+0xd0/0x250 include/net/netns/generic.h:46
>>> l2tp_pernet net/l2tp/l2tp_core.c:125 [inline]
>>> l2tp_tunnel_get+0x90/0x464 net/l2tp/l2tp_core.c:207
>>> l2tp_udp_recv_core net/l2tp/l2tp_core.c:852 [inline]
>>> l2tp_udp_encap_recv+0x314/0xb3c net/l2tp/l2tp_core.c:933
>>> udpv6_queue_rcv_one_skb+0x1870/0x1ad4 net/ipv6/udp.c:727
>>> udpv6_queue_rcv_skb+0x3bc/0x574 net/ipv6/udp.c:789
>>> udp6_unicast_rcv_skb+0x1cc/0x320 net/ipv6/udp.c:929
>>> __udp6_lib_rcv+0xbcc/0x1330 net/ipv6/udp.c:1018
>>> udpv6_rcv+0x88/0x9c net/ipv6/udp.c:1133
>>> ip6_protocol_deliver_rcu+0x988/0x12a4 net/ipv6/ip6_input.c:438
>>> ip6_input_finish+0x164/0x298 net/ipv6/ip6_input.c:483
>>> ...
>
> This crash is the result of a call to net_generic() being unable to
> dereference net when handling a received l2tpv2 packet.
>
> The stack frame indicates that l2tp_udp_recv_core finds that the
> packet's tunnel_id does not match the tunnel pointer derived from
> sk_user_data of the receiving socket. This can happen when more than one
> socket shares the same 5-tuple address. When a tunnel ID mismatch is
> detected, l2tp looks up the tunnel using the ID from the packet. It is
> this lookup which segfaults in net_generic() when l2tp tries to access
> its per-net tunnel list.
>
> The code implicated by the crash, which added support for aliased
> sockets, is no longer in linux-net or net-next. l2tp no longer looks up
> tunnels in the datapath; instead it looks up sessions without finding
> the parent tunnel first. The commits are:
>
> * support for aliased sockets was added in 628bc3e5a1be ("l2tp:
> Support several sockets with same IP/port quadruple") May 2024.
>
> * l2tp's receive path was refactored in ff6a2ac23cb0 ("l2tp: refactor
> udp recv to lookup to not use sk_user_data") June 2024.
>
> Is 628bc3e5a1be in any LTS or stable kernel? I didn't find it in
> linux-stable.git
>
> A possible fix is attached.
>
> #syz test: git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git
This crash does not have a reproducer. I cannot test it.
> for-kernelci
prev parent reply other threads:[~2024-07-29 11:49 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-25 10:37 [syzbot] [net?] BUG: unable to handle kernel paging request in net_generic syzbot
2024-07-26 15:02 ` Jakub Kicinski
2024-07-29 11:49 ` James Chapman
2024-07-29 11:49 ` syzbot [this message]
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=0000000000005060f2061e6175b6@google.com \
--to=syzbot+6acef9e0a4d1f46c83d4@syzkaller.appspotmail.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=jchapman@katalix.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=syzkaller-bugs@googlegroups.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.