Impact

RIOT-OS contains a network stack with the ability to process 6LoWPAN frames. An attacker can send a crafted frame to the device resulting in an out of bounds write in the packet buffer. The overflow can be used to corrupt other packets and the allocator metadata. Corrupting a pointer will easily lead to denial of service. While carefully manipulating the allocator metadata gives an attacker the possibility to write data to arbitrary locations and thus execute arbitrary code.

Patches

• master
• 2022.10

Workarounds

• Disabling support for fragmented IP datagrams, or
• Backport the patches listed above

For more information

If you have any questions or comments about this advisory:

• Open an issue in RIOT
• Email us at RIOT-security

Bug Details

During reassembling of 6LoWPAN packets _rbuf_add is used to add incoming fragments to the buffer.
In _rbuf_add the datagram_size is retrieved from the fragment (source):

    datagram_size = sixlowpan_frag_datagram_size(pkt->data);

If it is the first fragment, datagram_size is used to create a new reassembly buffer in _rbuf_get:

    else if ((res = _rbuf_get(src, netif_hdr->src_l2addr_len,
                              dst, netif_hdr->dst_l2addr_len,
                              datagram_size, datagram_tag, page)) < 0) {

Afterwards the fragment size is checked to not exceed the datagram size.
But this check doesn't consider the increased size due to header decompression (source):

    if ((offset + frag_size) > entry.super->datagram_size) {

Later the 6LoWPAN fragment is decompressed into the reassembly buffer (source):

    gnrc_sixlowpan_iphc_recv(pkt, entry.rbuf, 0);

For unfragmented packets gnrc_sixlowpan_iphc_recv reallocates the buffer to the proper size (source):

    if ((rbuf == NULL) &&
        /* (rbuf == NULL) => forwarding is not affected by this */
        (gnrc_pktbuf_realloc_data(ipv6, uncomp_hdr_len + payload_len) != 0)) {

But for fragmented packets this is not the case and no additional check is performed.
(Also: reallocation size should be payload_len + sizeof(ipv6_hdr_t) as payload_len already includes uncomp_hdr_len).

The buffer is now assumed to be large enough for the packet payload.
But due to the uncompressed IPv6 header being larger than the 6LoWPAN header this is no longer true.
While copying the payload from the 6LoWPAN snippet to the IPv6 snippet an out of bounds write in the packet buffer occurs (source):

    memcpy(((uint8_t *)ipv6->data) + uncomp_hdr_len,
           ((uint8_t *)sixlo->data) + payload_offset,
           sixlo->size - payload_offset);