[syzbot] WARNING in xfrm_alloc_compat (2)

[syzbot] WARNING in xfrm_alloc_compat (2)

[syzbot]

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 <dima@arista.com>
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: syzbot+834ffd1afc7212eb8147@syzkaller.appspotmail.com
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 syzkaller@googlegroups.com.

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

Re: [syzbot] WARNING in xfrm_alloc_compat (2)

[Dmitry Safonov]

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 <dima@arista.com>
> 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: syzbot+834ffd1afc7212eb8147@syzkaller.appspotmail.com
> 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 syzkaller@googlegroups.com.
> 
> 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

Re: [syzbot] WARNING in xfrm_alloc_compat (2)

[Eric Dumazet]

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 <dima@arista.com>
>> 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: syzbot+834ffd1afc7212eb8147@syzkaller.appspotmail.com
>> 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>

Re: [syzbot] WARNING in xfrm_alloc_compat (2)

[Dmitry Safonov]

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