Port flags#

Most of the features of the driver depend on the existing port flags the device has been initialized during the WDA negociation. The Network Interface Control Manager (NICM) will run after the boot startup a negociation with the WDA (the baseband) to know which kind of features and protocol versions he can handle and according to this negociation it will initilize the port flags of the rmnet device. From an attacker perspective if we need to trigger a code path which is not enabled by the current configuration we can still force a renegociation by specific QRTR packets through SMEM (which is not too difficult given we have control over the DMA). These are the possible outcomes of a nicm negociation I identified:

To reach rmnet_frag_command, the port needs RMNET_FLAGS_INGRESS_MAP_COMMANDS (0x02). The WDA parsing path in this NICM build does not set that bit. It can be enabled by AP-side RMNET link configuration when a virtual device is created or changed. On the fragmented path, the downlink marker handler runs first when its flags are set, so 0x02 alone does not guarantee that rmnet_frag_command is called.

Prior IP Accelerator (IPA) parsing#

This is actually a tricky part which tricked me a lot because I was not used to this design in other baseband manufacturers. rmnet is not handling the DMA directly, it is receiving a skb from the IPA driver which is the one actually accessing the DMA, fortunately for us is does not perform a lot of sanity checks on the downlink (DL) map packets (the qmap packets sent from the baseband to the AP). That’s why we can assume in the poc and in the fuzzer that the input from rmnet_rx_handler is mostly attacker controlled.

It is worth noting that the IPA is actually very proactive when the AP is sending uplink / tx frames.

pktlen-overflow#

After spending some time reversing and building the fuzzer with unicornafl I ultimately came to two different findings within the same function: rmnet_frag_command (callstack: rmnet_rx_handler => rmnet_frag_ingress_handler => rmnet_frag_command). Here is a pseudo-code of the function:

void *rmnet_frag_command(struct rmnet_frag_descriptor *desc,
                         struct rmnet_map_header *hdr,
                         struct rmnet_port *port)
{
    struct rmnet_endpoint *ep;
    struct sk_buff *skb = NULL;
    struct net_device *dev;
    struct rmnet_map_header *hdr;
    u32 pkt_len;
    u8 cmd;

    // 1. Extract command header pointer
    hdr = rmnet_frag_header_ptr(desc, 4, 16, &hdr);
    if (!hdr)
        goto out;

    cmd = *(u8 *)hdr;

...

    // cmd == 1 is FLOW_DISABLE, cmd == 2 is FLOW_ENABLE
    if (rmnet_vnd_do_flow_control(ep->vnd, (cmd == 2) ? 1 : 0) != 0 && cmd == FLOW_DISABLE)
        goto out;

    result = (void *)_alloc_skb(
                       a1: (unsigned __int16)((__builtin_bswap32(hdr->pkt_len) >> 16) + 64),
                       a2: 2080,
                       a3: 0,
                       a4: 0xFFFFFFFFLL);
    if ( result != nullptr )
    {
        v9 = (void **)result;
        v10 = *((_DWORD *)result + 52) + 32;
        *((_QWORD *)result + 28) += 32LL;
        *((_DWORD *)result + 52) = v10;
        skb_put(a1: result, a2: __builtin_bswap32(hdr->pkt_len) >> 16);
        memcpy(dest: v9[28], src: hdr, n: __builtin_bswap32(hdr->pkt_len) >> 16);
        skb_push(a1: v9, a2: 4);

        // Mark packet as an outgoing MAP command ACK 
        u8 *flags = skb_mac_header(skb) + 5;
        *flags = (*flags & 0xFC) | 0x01;
    }

    // 4. forward the ack to the ipa driver
    netif_tx_lock(dev);
    if (dev->netdev_ops && dev->netdev_ops->ndo_start_xmit) {
        dev->netdev_ops->ndo_start_xmit(skb, dev);
    }
    netif_tx_unlock(dev);

    return skb;
}

This function processes flow control commands, and if successful, builds and sends back to the modem an ACK packet containing the original command payload.

In this threat model we assume the attacker can write arbitrary content into the DMA shared between the CP and the AP, it means here that we can control what is written over the hdr struct which is basically a map_header.

If you are familiar with vulnerability research the two bug should be straightforward:

• (unsigned __int16)((__builtin_bswap32(hdr->pkt_len) >> 16) + 64 might wrap around because of the u16 cast which will cause an fully attacker-controlled out-of-bounds write… well, not exactly.

- The second bug is more specific to the threat model, because we are dealing with a DMA, the attacker might abuse the double fetch between skb_put / _alloc_skb and the memcpy, leading to an out-of-bounds write as well. => doesn’t work because IPA is not exposing the DMA directly, it is issuing already filled skbs.

Final Outcome: Well, the primitive would be so neat if we could just reach the memcpy and corrupt the heap memory but unfortunately the skb_put will very likely crash because old_tail + len > end which will cause a BUG() and a crash…

coalesce-shinfo#

To trigger an actual out-of-bound write we need to find another path, that’s why I started looking into the coalescing path in _rmnet_map_ingress_handler, especially rmnet_map_process_next_hdr_packet and __rmnet_map_segment_coal_skb. The root-cause analysis is quite long so I will start from a given buggy input:

 offset          bytes (hex)          field / meaning
 ------          -----------          ----------------------------------------
 0x0000          40                   QMAP: next_hdr=1, cd_bit=0, pad_len=0
 0x0001          42                   mux_id=0x42
 0x0002          0E F0                QMAP pkt_len=3824 (frame size minus 4)

 0x0004          02                   MAPv5 header type=COALESCING
 0x0005          10                   num_nlos=1, csum_valid=0
 0x0006          00                   close_type=0 (avoids reuse shortcut)
 0x0007          00                   virtual_channel_id=0
 0x0008          0E C0                NLO pkt_len=3776
 0x000A          01                   checksum-error bit for packet 0
 0x000B          01                   num_packets=1
 0x000C..0x001F  00 x 20              remaining NLO entries

 0x0020          60 00 00 00          IPv6 version=6
 0x0024          0E AC                IPv6 payload_len=3756
 0x0026          00                   next header=Hop-by-Hop (not TCP)
 0x0027          40                   hop limit=64
 0x0028..0x0047  00 x 32              IPv6 source and destination addresses

 0x0048          3C FF                Hop-by-Hop: next=Destination Options,
                                      length=(255+1)*8=2048
 0x004A..0x0847  00 x 2046            Pad1 option bytes

 0x0848          06 D2                Destination Options: next=TCP,
                                      length=(210+1)*8=1688
 0x084A..0x0EDF  00 x 1686            Pad1 option bytes

 0x0EE0..0x0EF3  00 x 20              TCP bytes; doff at 0x0EEC is 00
 0x0EF4                               end of frame (3828 bytes total)

The code flow with this input in rmnet_map_process_next_hdr_packet and __rmnet_map_segment_coal_skb from will be:

// rmnet_map_process_next_hdr_packet
coal = skb->data + 4;
if (coal->header_type != COALESCING || coal->num_nlos != 1)
    return -EINVAL;

skb_pull(skb, 4 + 28);                 // skb->data = frame offset 0x0020

ip_len = ipv6_skip_exthdr(skb, 40, ...);
// 40 + ((0xFF + 1) * 8) + ((0xD2 + 1) * 8) = 3776
// TCP is at frame offset 0x0020 + 3776 = 0x0EE0

tcp = skb->data + ip_len;
tcp_len = tcp->doff * 4;              // byte 0x0EEC = 0 -> tcp_len=0
seg_len = ntohs(coal->nl_pairs[0].pkt_len) - ip_len - tcp_len;
//        3776                              - 3776   - 0 = 0

// Extension headers disable GRO reuse; close_type=0 avoids the other shortcut.
__rmnet_map_segment_coal_skb(skb, ip_len, tcp_len, seg_len,
                             pkt_count=1, csum_valid=false);

// __rmnet_map_segment_coal_skb
dlen = pkt_count * seg_len;            // 0
hlen = ip_len + tcp_len;               // 3776
skbn = alloc_skb(hlen + dlen);         // 3776 data bytes; skb->end=3776

skb_reserve(skbn, hlen);               // data = head + 3776
skb_put(skbn, dlen);                   // put 0
skb_push(skbn, tcp_len);               // push 0
th = tcp_hdr(skbn);                    // th = skb_shared_info

th->seq = ...;                         // store at skb_shared_info + 4
check = &th->check;                    // points to skb_shared_info + 16

skb_push(skbn, ip_len);                // push IPv6 and extension headers
memcpy(skbn->data, ip, ip_len);
*check = pseudo_checksum;              // store at +16
*check = corrupted_checksum;           // second store at +16

The missing doff >= 5 check in rmnet_map_process_next_hdr_packet and the zero segment length lets __rmnet_map_segment_coal_skb write TCP fields despite reserving zero TCP bytes which end up overwriting the skb_shared_info fields. In terms of flags requirements this code path requires RMNET_FLAGS_INGRESS_COALESCE or RMNET_PRIV_FLAGS_INGRESS_MAP_CKSUMV5 and requires a linear skb (which is the default).

Related to this bug rmnet_frag_ipv6_skip_exthdr allows ip_len to be large enough to wrap the addition in rmnet_alloc_skb:

u16 hdr_len = frag_desc->ip_len + frag_desc->trans_len;  /* 65536 -> 0 */
head_skb = alloc_skb(hdr_len + 32, GFP_ATOMIC);          /* alloc_skb(32) */
skb_reserve(head_skb, 32);
skb_put(head_skb, hdr_len);                              /* skb_put(0) */

It leads to an out-of-bounds write when the checksum gets written (like in the previous bug), but this time far beyonf the skb allocation. The only reason why i do not treat this bug as an actual finding is that it requires the MAP frame to be over 65KB which is not realstic for a default IPA configuration. It means that IPA is most of the time unable to deliver single-skb over 65KB long.

Exploitability#

Overwriting skb_shared_info is indeed an out-of-bounds write but realistically the kernel stack will just drop the packet and so far I don’t think we can get interesting primitives out of these two bugs (which is very frustrating but it is what it is).