netdev - Re: WARNING in rfkill

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 15 Jan 2018 09:57:41 +0100
From:   Johannes Berg <johannes@...solutions.net>
To:     syzbot <syzbot+1ddfb3357e1d7bb5b5d3@...kaller.appspotmail.com>,
        davem@...emloft.net, linux-kernel@...r.kernel.org,
        linux-wireless@...r.kernel.org, netdev@...r.kernel.org,
        syzkaller-bugs@...glegroups.com
Subject: Re: WARNING in rfkill_alloc

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