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
