From: Felix Fietkau <nbd@nbd.name>
To: Davis <davikovs@gmail.com>,
linux-wireless@vger.kernel.org, netdev@vger.kernel.org
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Johannes Berg <johannes@sipsolutions.net>
Subject: Re: Posible memory corruption from "mac80211: do not accept/forward invalid EAPOL frames"
Date: Tue, 29 Jun 2021 19:26:03 +0200 [thread overview]
Message-ID: <a7f11cc2-7bef-4727-91b7-b51da218d2ee@nbd.name> (raw)
In-Reply-To: <CAHQn7pKcyC_jYmGyTcPCdk9xxATwW5QPNph=bsZV8d-HPwNsyA@mail.gmail.com>
Hi,
On 2021-06-29 06:48, Davis wrote:
> Greetings!
>
> Could it be possible that
> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=v5.12.13&id=a8c4d76a8dd4fb9666fc8919a703d85fb8f44ed8
> or at least its backport to 4.4 has the potential for memory
> corruption due to incorrect pointer calculation?
> Shouldn't the line:
> struct ethhdr *ehdr = (void *)skb_mac_header(skb);
> be:
> struct ethhdr *ehdr = (struct ethhdr *) skb->data;
>
> Later ehdr->h_dest is referenced, read and (when not equal to expected
> value) written:
> if (unlikely(skb->protocol == sdata->control_port_protocol &&
> !ether_addr_equal(ehdr->h_dest, sdata->vif.addr)))
> ether_addr_copy(ehdr->h_dest, sdata->vif.addr);
>
> In my case after cherry-picking
> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=v4.4.273&id=e3d4030498c304d7c36bccc6acdedacf55402387
> to 4.4 kernel of an ARM device occasional memory corruption was observed.
>
> To investigate this issue logging was added - the pointer calculation
> was expressed as:
> struct ethhdr *ehdr = (void *)skb_mac_header(skb);
> struct ethhdr *ehdr2 = (struct ethhdr *) skb->data;
> and memory writing was replaced by logging:
> if (unlikely(skb->protocol == sdata->control_port_protocol &&
> (!ether_addr_equal(ehdr->h_dest, sdata->vif.addr) ||
> !ether_addr_equal(ehdr2->h_dest, sdata->vif.addr))))
> printk(KERN_ERR "Matching1: %u, matching2: %u, addr1: %px, addr2:
> %px", !ether_addr_equal(ehdr->h_dest, sdata->vif.addr),
> !ether_addr_equal(ehdr2->h_dest, sdata->vif.addr), ehdr->h_dest,
> ehdr2->h_dest);
>
> During normal use of wifi (in residential environment) logging was
> triggered several times, in all cases matching1 was 1 and matching2
> was 0.
> This makes me think that normal control frames were received and
> correctly validated by !ether_addr_equal(ehdr2->h_dest,
> sdata->vif.addr), however !ether_addr_equal(ehdr->h_dest,
> sdata->vif.addr) was checking incorrect buffer and identified the
> frames as malformed/correctable.
> This also explains memory corruption - offset difference between both
> buffers (addr1 and addr2) was close to 64 KB in all cases, virtually
> always a random memory location (around 64 KB away from the correct
> buffer) will belong to something else, will have a value that differs
> from the expected MAC address and will get overwritten by the
> cherry-picked code.
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.
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.
- Felix
next prev parent reply other threads:[~2021-06-29 17:26 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-29 4:48 Posible memory corruption from "mac80211: do not accept/forward invalid EAPOL frames" Davis
2021-06-29 17:26 ` Felix Fietkau [this message]
2021-06-29 17:49 ` Greg Kroah-Hartman
2021-06-30 18:01 ` Felix Fietkau
2021-07-01 20:54 ` Davis Mosenkovs
2021-07-02 6:54 ` Johannes Berg
2021-07-09 19:48 ` Davis Mosenkovs
2021-07-10 6:33 ` Greg Kroah-Hartman
2021-07-10 18:59 ` Davis Mosenkovs
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=a7f11cc2-7bef-4727-91b7-b51da218d2ee@nbd.name \
--to=nbd@nbd.name \
--cc=davikovs@gmail.com \
--cc=gregkh@linuxfoundation.org \
--cc=johannes@sipsolutions.net \
--cc=linux-wireless@vger.kernel.org \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).