Open-Mesh » batman-adv

Report from Sashiko which needs to be checked:

does the transmission path lack packet length validation which could lead to out-of-bounds reads?

Looking at batadv_interface_tx() in net/batman-adv/mesh-interface.c, it appears to process untrusted packets without any length check (such as pskb_may_pull() or skb->len >= ETH_HLEN) before calling batadv_get_vid() and accessing the Ethernet header:

        vid = batadv_get_vid(skb, 0);

        skb_reset_mac_header(skb);
        ethhdr = eth_hdr(skb);

        proto = ethhdr->h_proto;

Inside batadv_get_vid() in net/batman-adv/main.c, it seems to unconditionally dereference ethhdr->h_proto without ensuring the linear buffer contains enough data:

        struct ethhdr *ethhdr = (struct ethhdr *)(skb->data + header_len);
        struct vlan_ethhdr *vhdr;
        unsigned short vid;

        if (ethhdr->h_proto != htons(ETH_P_8021Q))
                return BATADV_NO_FLAGS;

Later in batadv_interface_tx(), the undersized packet's h_source might be read and passed to the translation table:

        if (!is_multicast_ether_addr(ethhdr->h_source) &&
            !batadv_bla_is_loopdetect_mac(ethhdr->h_source)) {
                client_added = batadv_tt_local_add(mesh_iface, ethhdr->h_source,
                                                   vid, skb->skb_iif,
                                                   skb->mark);

If a local user sends an undersized packet (e.g., an empty packet via an AF_PACKET socket), could this read uninitialized kernel memory from the trailing space and leak it to the network through B.A.T.M.A.N. translation table broadcasts?

See https://sashiko.dev/#/patchset/20260630134430.85786-1-sw@simonwunderlich.de?part=3