WARNING in rfkill_alloc

[syzbot]

Hello,

syzkaller hit the following crash on
6bd39bc3da0f4a301fae69c4a32db2768f5118be
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/master
compiler: gcc (GCC) 7.1.1 20170620
.config is attached
Raw console output is attached.
C reproducer is attached
syzkaller reproducer is attached. See https://goo.gl/kgGztJ
for information about syzkaller reproducers


IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+1ddfb3...@syzkaller.appspotmail.com
It will help syzbot understand when the bug is fixed. See footer for
details.
If you forward the report, please keep this part and the footer.

RBP: 000000000000004a R08: 0000000000000001 R09: 0000000000000034
R10: 0000000000000000 R11: 0000000000000246 R12: 00007ffe2d4c85d0
R13: 0000000000000048 R14: 0000000000000000 R15: 0000000000000000
WARNING: CPU: 1 PID: 3655 at net/rfkill/core.c:930 rfkill_alloc+0x2c0/0x380
net/rfkill/core.c:930
Kernel panic - not syncing: panic_on_warn set ...

CPU: 1 PID: 3655 Comm: syzkaller881442 Not tainted 4.15.0-rc7+ #187
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:17 [inline]
dump_stack+0x194/0x257 lib/dump_stack.c:53
panic+0x1e4/0x41c kernel/panic.c:183
__warn+0x1dc/0x200 kernel/panic.c:547
report_bug+0x211/0x2d0 lib/bug.c:184
fixup_bug.part.11+0x37/0x80 arch/x86/kernel/traps.c:178
fixup_bug arch/x86/kernel/traps.c:247 [inline]
do_error_trap+0x2d7/0x3e0 arch/x86/kernel/traps.c:296
do_invalid_op+0x1b/0x20 arch/x86/kernel/traps.c:315
invalid_op+0x22/0x40 arch/x86/entry/entry_64.S:1079
RIP: 0010:rfkill_alloc+0x2c0/0x380 net/rfkill/core.c:930
RSP: 0018:ffff8801bb9b6a60 EFLAGS: 00010293
RAX: ffff8801bb4a8540 RBX: 1ffff10037736d50 RCX: ffffffff855c85c0
RDX: 0000000000000000 RSI: ffff8801c3150900 RDI: ffff8801c31502e8
RBP: ffff8801bb9b6b08 R08: ffff8801c31502c0 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000000 R12: ffff8801c31502d8
R13: 0000000000000000 R14: dffffc0000000000 R15: 0000000000000001
wiphy_new_nm+0x159c/0x21d0 net/wireless/core.c:487
ieee80211_alloc_hw_nm+0x4b4/0x2140 net/mac80211/main.c:531
mac80211_hwsim_new_radio+0x220/0x2b90
drivers/net/wireless/mac80211_hwsim.c:2486
hwsim_new_radio_nl+0x5b7/0x7c0 drivers/net/wireless/mac80211_hwsim.c:3157
genl_family_rcv_msg+0x7b7/0xfb0 net/netlink/genetlink.c:599
genl_rcv_msg+0xb2/0x140 net/netlink/genetlink.c:624
netlink_rcv_skb+0x224/0x470 net/netlink/af_netlink.c:2441
genl_rcv+0x28/0x40 net/netlink/genetlink.c:635
netlink_unicast_kernel net/netlink/af_netlink.c:1308 [inline]
netlink_unicast+0x4c4/0x6b0 net/netlink/af_netlink.c:1334
netlink_sendmsg+0xa4a/0xe60 net/netlink/af_netlink.c:1897
sock_sendmsg_nosec net/socket.c:630 [inline]
sock_sendmsg+0xca/0x110 net/socket.c:640
___sys_sendmsg+0x767/0x8b0 net/socket.c:2020
__sys_sendmsg+0xe5/0x210 net/socket.c:2054
SYSC_sendmsg net/socket.c:2065 [inline]
SyS_sendmsg+0x2d/0x50 net/socket.c:2061
entry_SYSCALL_64_fastpath+0x23/0x9a
RIP: 0033:0x4404e9
RSP: 002b:00007ffe2d4c85c8 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
RAX: ffffffffffffffda RBX: 0000000000000001 RCX: 00000000004404e9
RDX: 0000000000000000 RSI: 0000000020b3dfc8 RDI: 0000000000000049
RBP: 000000000000004a R08: 0000000000000001 R09: 0000000000000034
R10: 0000000000000000 R11: 0000000000000246 R12: 00007ffe2d4c85d0
R13: 0000000000000048 R14: 0000000000000000 R15: 0000000000000000
Dumping ftrace buffer:
(ftrace buffer empty)
Kernel Offset: disabled
Rebooting in 86400 seconds..


---
This bug is generated by a dumb bot. It may contain errors.
See https://goo.gl/tpsmEJ for details.
Direct all questions to syzk...@googlegroups.com.

syzbot will keep track of this bug report.
If you forgot to add the Reported-by tag, once the fix for this bug is
merged
into any tree, please reply to this email with:
#syz fix: exact-commit-title
If you want to test a patch for this bug, please reply with:
#syz test: git://repo/address.git branch
and provide the patch inline or as an attachment.
To mark this as a duplicate of another syzbot report, please reply with:
#syz dup: exact-subject-of-another-report
If it's a one-off invalid bug report, please reply with:
#syz invalid
Note: if the crash happens again, it will cause creation of a new bug
report.
Note: all commands must start from beginning of the line in the email body.

[Johannes Berg]

Hi,

> RIP: 0010:rfkill_alloc+0x2c0/0x380 net/rfkill/core.c:930

This seems pretty obvious - there's no name given.

> wiphy_new_nm+0x159c/0x21d0 net/wireless/core.c:487
> ieee80211_alloc_hw_nm+0x4b4/0x2140 net/mac80211/main.c:531

which is strange, because we try to validate the name here.

Can you help me read this?

sendmsg$nl_generic(r1, &(0x7f0000b3e000-0x38)={&(0x7f0000d4a000-
0xc)={0x10, 0x0, 0x0, 0x0}, 0xc,
&(0x7f0000007000)={&(0x7f00001ca000)={0x14, 0x1c, 0x109,
0xffffffffffffffff, 0xffffffffffffffff, {0x4, 0x0, 0x0}, []}, 0x14},
0x1, 0x0, 0x0, 0x0}, 0x0)

I've reformatted it as

sendmsg$nl_generic(
r1,
&(0x7f0000b3e000-0x38)={
addr= &(0x7f0000d4a000-0xc)={
0x10, 0x0, 0x0, 0x0
},
addrlen=0xc,
vec= &(0x7f0000007000)={
ptr= &(0x7f00001ca000)={
0x14, 0x1c, 0x109, 0xffffffffffffffff,
0xffffffffffffffff, {0x4, 0x0, 0x0}, []
},
len= 0x14
},
vlen= 0x1,
ctrl= 0x0,
ctrllen=0x0,
f= 0x0
},
0x0
)

but am still getting lost - what exactly is the *byte* sequence inside
the (full) message (including headers)?


Ah, then again, now I see the fault injection - I guess dev_set_name()
just failed and we didn't check the return value, will fix that.

johannes

[Dmitry Vyukov]

Hi,

I think you decoded it correctly. The netlink message is:

{0x14, 0x1c, 0x109, 0xffffffffffffffff, 0xffffffffffffffff, {0x4, 0x0, 0x0}, []}

0x14 length, 0x1c is type, etc

These numbers are input data for there descriptions:
https://github.com/google/syzkaller/blob/master/sys/linux/socket_netlink.txt
which generally match C structures as you expect.

However, there can be some surprising things, for example, executing
one ioctl/setsockopt with data meant for another one, or these
0xffffffffffffffff are actually mean 0 (for involved reasons), or we
can simply have bugs in these descriptions so they don't match C
structures and then all data is messed/shifted.

If this representation does not make sense to you right away, your
best bet is looking at/running the C reproducer where you can see true
data layout:

*(uint64_t*)0x20b3dfc8 = 0x20d49ff4;
*(uint32_t*)0x20b3dfd0 = 0xc;
*(uint64_t*)0x20b3dfd8 = 0x20007000;
*(uint64_t*)0x20b3dfe0 = 1;
*(uint64_t*)0x20b3dfe8 = 0;
*(uint64_t*)0x20b3dff0 = 0;
*(uint32_t*)0x20b3dff8 = 0;
*(uint16_t*)0x20d49ff4 = 0x10;
*(uint16_t*)0x20d49ff6 = 0;
*(uint32_t*)0x20d49ff8 = 0;
*(uint32_t*)0x20d49ffc = 0;
*(uint64_t*)0x20007000 = 0x201ca000;
*(uint64_t*)0x20007008 = 0x14;
*(uint32_t*)0x201ca000 = 0x14;
*(uint16_t*)0x201ca004 = 0x1c;
*(uint16_t*)0x201ca006 = 0x109;
*(uint32_t*)0x201ca008 = 0;
*(uint32_t*)0x201ca00c = 0;
*(uint8_t*)0x201ca010 = 4;
*(uint8_t*)0x201ca011 = 0;
*(uint16_t*)0x201ca012 = 0;
syscall(__NR_sendmsg, r[1], 0x20b3dfc8, 0);

> Ah, then again, now I see the fault injection - I guess dev_set_name()
> just failed and we didn't check the return value, will fix that.

Yes, it's highly likely the root cause. The raw.log file shows there
there was an immediately preceding fault in kmalloc in the same
process, in a close stack.

[Johannes Berg]

On Mon, 2018-01-15 at 10:12 +0100, Dmitry Vyukov wrote:

> However, there can be some surprising things, for example, executing
> one ioctl/setsockopt with data meant for another one, or these
> 0xffffffffffffffff are actually mean 0 (for involved reasons),

I think those fff was actually what was throwing me off.

> or we
> can simply have bugs in these descriptions so they don't match C
> structures and then all data is messed/shifted.

No, I think this part was OK.

> If this representation does not make sense to you right away, your
> best bet is looking at/running the C reproducer where you can see true
> data layout:
>
>

[...]
Yeah, good point, I should've just done that.

> > Ah, then again, now I see the fault injection - I guess dev_set_name()
> > just failed and we didn't check the return value, will fix that.
>
> Yes, it's highly likely the root cause. The raw.log file shows there
> there was an immediately preceding fault in kmalloc in the same
> process, in a close stack.

Yep, I submitted the fix now (with the correct reported-by).

Also for the other one, the wiphy_register() warning.

johannes

[Dmitry Vyukov]

Thanks!