2021-03-29 19:06:15

by syzbot

[permalink] [raw]
Subject: [syzbot] WARNING in xfrm_alloc_compat (2)

Hello,

syzbot found the following issue on:

HEAD commit: 6c996e19 net: change netdev_unregister_timeout_secs min va..
git tree: net-next
console output: https://syzkaller.appspot.com/x/log.txt?x=102e5926d00000
kernel config: https://syzkaller.appspot.com/x/.config?x=c0ac79756537274e
dashboard link: https://syzkaller.appspot.com/bug?extid=834ffd1afc7212eb8147
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=10a7b1aad00000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=17ae6b7cd00000

The issue was bisected to:

commit 5f3eea6b7e8f58cf5c8a9d4b9679dc19e9e67ba3
Author: Dmitry Safonov <[email protected]>
Date: Mon Sep 21 14:36:53 2020 +0000

xfrm/compat: Attach xfrm dumps to 64=>32 bit translator

bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=10694b3ad00000
final oops: https://syzkaller.appspot.com/x/report.txt?x=12694b3ad00000
console output: https://syzkaller.appspot.com/x/log.txt?x=14694b3ad00000

IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: [email protected]
Fixes: 5f3eea6b7e8f ("xfrm/compat: Attach xfrm dumps to 64=>32 bit translator")

netlink: 208 bytes leftover after parsing attributes in process `syz-executor193'.
------------[ cut here ]------------
unsupported nla_type 356
WARNING: CPU: 1 PID: 8423 at net/xfrm/xfrm_compat.c:280 xfrm_xlate64_attr net/xfrm/xfrm_compat.c:280 [inline]
WARNING: CPU: 1 PID: 8423 at net/xfrm/xfrm_compat.c:280 xfrm_xlate64 net/xfrm/xfrm_compat.c:301 [inline]
WARNING: CPU: 1 PID: 8423 at net/xfrm/xfrm_compat.c:280 xfrm_alloc_compat+0xf39/0x10d0 net/xfrm/xfrm_compat.c:328
Modules linked in:
CPU: 1 PID: 8423 Comm: syz-executor193 Not tainted 5.12.0-rc4-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
RIP: 0010:xfrm_xlate64_attr net/xfrm/xfrm_compat.c:280 [inline]
RIP: 0010:xfrm_xlate64 net/xfrm/xfrm_compat.c:301 [inline]
RIP: 0010:xfrm_alloc_compat+0xf39/0x10d0 net/xfrm/xfrm_compat.c:328
Code: de e8 5b d7 c3 f9 84 db 0f 85 b0 f8 ff ff e8 9e d0 c3 f9 8b 74 24 08 48 c7 c7 80 42 76 8a c6 05 39 2e 02 06 01 e8 74 b7 16 01 <0f> 0b e9 8d f8 ff ff e8 7b d0 c3 f9 8b 14 24 48 c7 c7 40 42 76 8a
RSP: 0018:ffffc90000fff4b8 EFLAGS: 00010282
RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
RDX: ffff88801b1554c0 RSI: ffffffff815c4d75 RDI: fffff520001ffe89
RBP: 00000000000000d8 R08: 0000000000000000 R09: 0000000000000000
R10: ffffffff815bdb0e R11: 0000000000000000 R12: 00000000ffffffa1
R13: ffff8880248eb8f8 R14: ffff888013256dc0 R15: ffff8880132568c0
FS: 000000000092f300(0000) GS:ffff8880b9d00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00000000200001e0 CR3: 0000000023271000 CR4: 00000000001506e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
xfrm_alloc_userspi+0x66a/0xa30 net/xfrm/xfrm_user.c:1448
xfrm_user_rcv_msg+0x42c/0x8b0 net/xfrm/xfrm_user.c:2812
netlink_rcv_skb+0x153/0x420 net/netlink/af_netlink.c:2502
xfrm_netlink_rcv+0x6b/0x90 net/xfrm/xfrm_user.c:2824
netlink_unicast_kernel net/netlink/af_netlink.c:1312 [inline]
netlink_unicast+0x533/0x7d0 net/netlink/af_netlink.c:1338
netlink_sendmsg+0x856/0xd90 net/netlink/af_netlink.c:1927
sock_sendmsg_nosec net/socket.c:654 [inline]
sock_sendmsg+0xcf/0x120 net/socket.c:674
____sys_sendmsg+0x6e8/0x810 net/socket.c:2350
___sys_sendmsg+0xf3/0x170 net/socket.c:2404
__sys_sendmsg+0xe5/0x1b0 net/socket.c:2433
do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46
entry_SYSCALL_64_after_hwframe+0x44/0xae
RIP: 0033:0x43f009
Code: 28 c3 e8 2a 14 00 00 66 2e 0f 1f 84 00 00 00 00 00 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 73 01 c3 48 c7 c1 c0 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007ffe0986bcb8 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
RAX: ffffffffffffffda RBX: 0000000000400488 RCX: 000000000043f009
RDX: 0000000000000000 RSI: 0000000020000580 RDI: 0000000000000003
RBP: 0000000000402ff0 R08: 0000000000000000 R09: 0000000000400488
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000403080
R13: 0000000000000000 R14: 00000000004ac018 R15: 0000000000400488


---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at [email protected].

syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
For information about bisection process see: https://goo.gl/tpsmEJ#bisection
syzbot can test patches for this issue, for details see:
https://goo.gl/tpsmEJ#testing-patches


2021-03-29 19:59:12

by Dmitry Safonov

[permalink] [raw]
Subject: Re: [syzbot] WARNING in xfrm_alloc_compat (2)

Hi,

On 3/29/21 8:04 PM, syzbot wrote:
> Hello,
>
> syzbot found the following issue on:
>
> HEAD commit: 6c996e19 net: change netdev_unregister_timeout_secs min va..
> git tree: net-next
> console output: https://syzkaller.appspot.com/x/log.txt?x=102e5926d00000
> kernel config: https://syzkaller.appspot.com/x/.config?x=c0ac79756537274e
> dashboard link: https://syzkaller.appspot.com/bug?extid=834ffd1afc7212eb8147
> syz repro: https://syzkaller.appspot.com/x/repro.syz?x=10a7b1aad00000
> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=17ae6b7cd00000
>
> The issue was bisected to:
>
> commit 5f3eea6b7e8f58cf5c8a9d4b9679dc19e9e67ba3
> Author: Dmitry Safonov <[email protected]>
> Date: Mon Sep 21 14:36:53 2020 +0000
>
> xfrm/compat: Attach xfrm dumps to 64=>32 bit translator
>
> bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=10694b3ad00000
> final oops: https://syzkaller.appspot.com/x/report.txt?x=12694b3ad00000
> console output: https://syzkaller.appspot.com/x/log.txt?x=14694b3ad00000
>
> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> Reported-by: [email protected]
> Fixes: 5f3eea6b7e8f ("xfrm/compat: Attach xfrm dumps to 64=>32 bit translator")
>
> netlink: 208 bytes leftover after parsing attributes in process `syz-executor193'.
> ------------[ cut here ]------------
> unsupported nla_type 356

This doesn't seem to be an issue.
Userspace sent message with nla_type 356, which is > __XFRM_MSG_MAX, so
this warning is expected. I've added it so when a new XFRM_MSG_* will be
added, to make sure that there will be translations to such messages in
xfrm_compat.ko (if the translation needed).
This is WARN_ON_ONCE(), so it can't be used as DOS.

Ping me if you'd expect something else than once-a-boot warning for
this. Not sure how-to close syzkaller bug, docs have only `invalid' tag,
which isn't `not-a-bug'/`expected' tag:
https://github.com/google/syzkaller/blob/master/docs/syzbot.md


> WARNING: CPU: 1 PID: 8423 at net/xfrm/xfrm_compat.c:280 xfrm_xlate64_attr net/xfrm/xfrm_compat.c:280 [inline]
> WARNING: CPU: 1 PID: 8423 at net/xfrm/xfrm_compat.c:280 xfrm_xlate64 net/xfrm/xfrm_compat.c:301 [inline]
> WARNING: CPU: 1 PID: 8423 at net/xfrm/xfrm_compat.c:280 xfrm_alloc_compat+0xf39/0x10d0 net/xfrm/xfrm_compat.c:328
> Modules linked in:
> CPU: 1 PID: 8423 Comm: syz-executor193 Not tainted 5.12.0-rc4-syzkaller #0
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
> RIP: 0010:xfrm_xlate64_attr net/xfrm/xfrm_compat.c:280 [inline]
> RIP: 0010:xfrm_xlate64 net/xfrm/xfrm_compat.c:301 [inline]
> RIP: 0010:xfrm_alloc_compat+0xf39/0x10d0 net/xfrm/xfrm_compat.c:328
> Code: de e8 5b d7 c3 f9 84 db 0f 85 b0 f8 ff ff e8 9e d0 c3 f9 8b 74 24 08 48 c7 c7 80 42 76 8a c6 05 39 2e 02 06 01 e8 74 b7 16 01 <0f> 0b e9 8d f8 ff ff e8 7b d0 c3 f9 8b 14 24 48 c7 c7 40 42 76 8a
> RSP: 0018:ffffc90000fff4b8 EFLAGS: 00010282
> RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
> RDX: ffff88801b1554c0 RSI: ffffffff815c4d75 RDI: fffff520001ffe89
> RBP: 00000000000000d8 R08: 0000000000000000 R09: 0000000000000000
> R10: ffffffff815bdb0e R11: 0000000000000000 R12: 00000000ffffffa1
> R13: ffff8880248eb8f8 R14: ffff888013256dc0 R15: ffff8880132568c0
> FS: 000000000092f300(0000) GS:ffff8880b9d00000(0000) knlGS:0000000000000000
> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 00000000200001e0 CR3: 0000000023271000 CR4: 00000000001506e0
> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> Call Trace:
> xfrm_alloc_userspi+0x66a/0xa30 net/xfrm/xfrm_user.c:1448
> xfrm_user_rcv_msg+0x42c/0x8b0 net/xfrm/xfrm_user.c:2812
> netlink_rcv_skb+0x153/0x420 net/netlink/af_netlink.c:2502
> xfrm_netlink_rcv+0x6b/0x90 net/xfrm/xfrm_user.c:2824
> netlink_unicast_kernel net/netlink/af_netlink.c:1312 [inline]
> netlink_unicast+0x533/0x7d0 net/netlink/af_netlink.c:1338
> netlink_sendmsg+0x856/0xd90 net/netlink/af_netlink.c:1927
> sock_sendmsg_nosec net/socket.c:654 [inline]
> sock_sendmsg+0xcf/0x120 net/socket.c:674
> ____sys_sendmsg+0x6e8/0x810 net/socket.c:2350
> ___sys_sendmsg+0xf3/0x170 net/socket.c:2404
> __sys_sendmsg+0xe5/0x1b0 net/socket.c:2433
> do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46
> entry_SYSCALL_64_after_hwframe+0x44/0xae
> RIP: 0033:0x43f009
> Code: 28 c3 e8 2a 14 00 00 66 2e 0f 1f 84 00 00 00 00 00 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 73 01 c3 48 c7 c1 c0 ff ff ff f7 d8 64 89 01 48
> RSP: 002b:00007ffe0986bcb8 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
> RAX: ffffffffffffffda RBX: 0000000000400488 RCX: 000000000043f009
> RDX: 0000000000000000 RSI: 0000000020000580 RDI: 0000000000000003
> RBP: 0000000000402ff0 R08: 0000000000000000 R09: 0000000000400488
> R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000403080
> R13: 0000000000000000 R14: 00000000004ac018 R15: 0000000000400488
>
>
> ---
> This report is generated by a bot. It may contain errors.
> See https://goo.gl/tpsmEJ for more information about syzbot.
> syzbot engineers can be reached at [email protected].
>
> syzbot will keep track of this issue. See:
> https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
> For information about bisection process see: https://goo.gl/tpsmEJ#bisection
> syzbot can test patches for this issue, for details see:
> https://goo.gl/tpsmEJ#testing-patches
>

Thanks,
Dmitry

2021-03-29 20:32:46

by Eric Dumazet

[permalink] [raw]
Subject: Re: [syzbot] WARNING in xfrm_alloc_compat (2)



On 3/29/21 9:57 PM, Dmitry Safonov wrote:
> Hi,
>
> On 3/29/21 8:04 PM, syzbot wrote:
>> Hello,
>>
>> syzbot found the following issue on:
>>
>> HEAD commit: 6c996e19 net: change netdev_unregister_timeout_secs min va..
>> git tree: net-next
>> console output: https://syzkaller.appspot.com/x/log.txt?x=102e5926d00000
>> kernel config: https://syzkaller.appspot.com/x/.config?x=c0ac79756537274e
>> dashboard link: https://syzkaller.appspot.com/bug?extid=834ffd1afc7212eb8147
>> syz repro: https://syzkaller.appspot.com/x/repro.syz?x=10a7b1aad00000
>> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=17ae6b7cd00000
>>
>> The issue was bisected to:
>>
>> commit 5f3eea6b7e8f58cf5c8a9d4b9679dc19e9e67ba3
>> Author: Dmitry Safonov <[email protected]>
>> Date: Mon Sep 21 14:36:53 2020 +0000
>>
>> xfrm/compat: Attach xfrm dumps to 64=>32 bit translator
>>
>> bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=10694b3ad00000
>> final oops: https://syzkaller.appspot.com/x/report.txt?x=12694b3ad00000
>> console output: https://syzkaller.appspot.com/x/log.txt?x=14694b3ad00000
>>
>> IMPORTANT: if you fix the issue, please add the following tag to the commit:
>> Reported-by: [email protected]
>> Fixes: 5f3eea6b7e8f ("xfrm/compat: Attach xfrm dumps to 64=>32 bit translator")
>>
>> netlink: 208 bytes leftover after parsing attributes in process `syz-executor193'.
>> ------------[ cut here ]------------
>> unsupported nla_type 356
>
> This doesn't seem to be an issue.
> Userspace sent message with nla_type 356, which is > __XFRM_MSG_MAX, so
> this warning is expected. I've added it so when a new XFRM_MSG_* will be
> added, to make sure that there will be translations to such messages in
> xfrm_compat.ko (if the translation needed).
> This is WARN_ON_ONCE(), so it can't be used as DOS.
>
> Ping me if you'd expect something else than once-a-boot warning for
> this. Not sure how-to close syzkaller bug, docs have only `invalid' tag,
> which isn't `not-a-bug'/`expected' tag:
> https://github.com/google/syzkaller/blob/master/docs/syzbot.md
>

You should not use WARN_ON_ONCE() for this case (if user space can trigger it)

https://lwn.net/Articles/769365/

<quote>
Greg Kroah-Hartman raised the problem of core kernel API code that will use WARN_ON_ONCE() to complain about bad usage; that will not generate the desired result if WARN_ON_ONCE() is configured to crash the machine. He was told that the code should just call pr_warn() instead, and that the called function should return an error in such situations. It was generally agreed that any WARN_ON() or WARN_ON_ONCE() calls that can be triggered from user space need to be fixed.
</quote>


2021-03-29 20:44:26

by Dmitry Safonov

[permalink] [raw]
Subject: Re: [syzbot] WARNING in xfrm_alloc_compat (2)

On 3/29/21 9:31 PM, Eric Dumazet wrote:
>
>
> On 3/29/21 9:57 PM, Dmitry Safonov wrote:
[..]
>>> ------------[ cut here ]------------
>>> unsupported nla_type 356
>>
>> This doesn't seem to be an issue.
>> Userspace sent message with nla_type 356, which is > __XFRM_MSG_MAX, so
>> this warning is expected. I've added it so when a new XFRM_MSG_* will be
>> added, to make sure that there will be translations to such messages in
>> xfrm_compat.ko (if the translation needed).
>> This is WARN_ON_ONCE(), so it can't be used as DOS.
>>
>> Ping me if you'd expect something else than once-a-boot warning for
>> this. Not sure how-to close syzkaller bug, docs have only `invalid' tag,
>> which isn't `not-a-bug'/`expected' tag:
>> https://github.com/google/syzkaller/blob/master/docs/syzbot.md
>>
>
> You should not use WARN_ON_ONCE() for this case (if user space can trigger it)
>
> https://lwn.net/Articles/769365/
>
> <quote>
> Greg Kroah-Hartman raised the problem of core kernel API code that will use WARN_ON_ONCE() to complain about bad usage; that will not generate the desired result if WARN_ON_ONCE() is configured to crash the machine. He was told that the code should just call pr_warn() instead, and that the called function should return an error in such situations. It was generally agreed that any WARN_ON() or WARN_ON_ONCE() calls that can be triggered from user space need to be fixed.
> </quote>

Yeah, fair enough, I've already thought after sending the reply that
WARN_ON*() prints registers and that may be unwanted.
I'll cook a patch to convert this and other WARNs in the module.

I wish there was something like pr_warn_backtrace_once(), but I guess
it's fine without dumpstack(), after all.

Thanks,
Dmitry