Received-SPF: pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
From:   Davis <davikovs@gmail.com>
Date:   Tue, 29 Jun 2021 07:48:00 +0300
Message-ID: <CAHQn7pKcyC_jYmGyTcPCdk9xxATwW5QPNph=bsZV8d-HPwNsyA@mail.gmail.com>
Subject: Posible memory corruption from "mac80211: do not accept/forward
 invalid EAPOL frames"
To:     linux-wireless@vger.kernel.org, netdev@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

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.

Br,
Davis