Open-Mesh » batman-adv

Looking at batadv_v_ogm_packet_recv() in net/batman-adv/bat_v_ogm.c, does iterating over aggregated OGM2 packets risk unaligned memory accesses?

        while (batadv_v_ogm_aggr_packet(ogm_offset, skb_headlen(skb),
                                        ogm_packet)) {
                ...
                ogm_offset += BATADV_OGM2_HLEN;
                ogm_offset += ntohs(ogm_packet->tvlv_len);

                packet_pos = skb->data + ogm_offset;
                ogm_packet = (struct batadv_ogm2_packet *)packet_pos;
        }

If the unvalidated tvlv_len from the packet payload is odd, ogm_offset will result in an unaligned packet_pos pointer for the next loop iteration.

Dereferencing 16-bit or 32-bit fields from an unaligned (odd) pointer can trigger a fatal alignment fault on architectures without hardware support for unaligned accesses (e.g., SPARC, older ARM).

A similar situation appears in batadv_tvlv_containers_process() in net/batman-adv/tvlv.c, where tvlv_value is advanced by an unvalidated tvlv_value_cont_len, potentially making the next tvlv_hdr pointer unaligned:

        tvlv_value = (u8 *)tvlv_value + tvlv_value_cont_len;
        tvlv_value_len -= tvlv_value_cont_len;

Would it be safer to enforce alignment or validate that these lengths are appropriately padded before advancing the pointers?

See https://sashiko.dev/#/patchset/20260604-kernel-doc-cleanup-v1-0-c4c4d4a77c31@narfation.org?part=4