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 for Android: free password hash cracker in your pocket

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

Message-ID: <1516017667.410.12.camel@sipsolutions.net>
Date:   Mon, 15 Jan 2018 13:01:07 +0100
From:   Johannes Berg <johannes@...solutions.net>
To:     Dmitry Vyukov <dvyukov@...gle.com>
Cc:     syzbot <syzbot+1ddfb3357e1d7bb5b5d3@...kaller.appspotmail.com>,
        David Miller <davem@...emloft.net>,
        LKML <linux-kernel@...r.kernel.org>,
        linux-wireless@...r.kernel.org, netdev <netdev@...r.kernel.org>,
        syzkaller-bugs@...glegroups.com
Subject: Re: WARNING in rfkill_alloc

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