netdev - Re: Posible memory corruption from "mac80211: do not accept/forward invalid EAPOL frames"

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:   Fri, 02 Jul 2021 08:54:53 +0200
From:   Johannes Berg <johannes@...solutions.net>
To:     Davis Mosenkovs <davikovs@...il.com>, Felix Fietkau <nbd@....name>
Cc:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        linux-wireless@...r.kernel.org, netdev@...r.kernel.org
Subject: Re: Posible memory corruption from "mac80211: do not accept/forward
 invalid EAPOL frames"

On Thu, 2021-07-01 at 23:54 +0300, Davis Mosenkovs wrote:
> 
> > > > It seems that the 4.4 backport is broken. The problem is the fact that
> > > > skb_mac_header is called before eth_type_trans(). This means that the
> > > > mac header offset still has the default value of (u16)-1, resulting in
> > > > the 64 KB memory offset that you observed.

Agree.

> > > > I think that for 4.4, the code should be changed to use skb->data
> > > > instead of skb_mac_header. 4.9 looks broken in the same way.
> > > > 5.4 seems fine, so newer kernels should be fine as well.

Also agree.

> > > Thanks for looking into this, can you submit a patch to fix this up in
> > > the older kernel trees?
> > Sorry, I don't have time to prepare and test the patches at the moment.
> > 
> If testing procedure mentioned in my first email is sufficient (and
> using skb->data is the correct solution in kernel trees where current
> code doesn't work properly), I can make and test the patches.
> Should I do that?

Yes, please do.

Thanks,
johannes