Route of Root: Bring a "DoS only" bug to LPE and bypass the existing patch to win $10,500 in kernelCTF

Summary

One step further from Route of Death (CVE-2023-2156)

Three years ago there was a bug on this same receive path, CVE-2023-2156 (“Route of Death”). The RPL SRH receive code was added in 8610c7c6e3bd (“net: ipv6: add support for rpl sr exthdr”, v5.7), and the original writeup covers this path, with good figures showing how the OOB happens.

Everyone who looked at CVE-2023-2156 considered it crash-only:

• The Interrupt Labs’ original writeup stated that skb_push() will detect the bug and panic before the out-of-bounds write can happen.
• ZDI-23-547: “Assertion Denial-of-Service”
• Red Hat: “reachable assertion leading to DoS”
• CVSS vector classified as: AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H (availability only, nothing on confidentiality or integrity).

The 2023 PoC used CmprI = 15, CmprE = 0 and segments_left = 1, the largest amplification the header format allows, turning a 48-byte address vector into 528 bytes. The panic log reads put:576 against 16 bytes of reserve, so data lands hundreds of bytes below head and gets easily detected by skb_push().

Here, ipv6_rpl_srh_rcv() in net/ipv6/exthdrs.c processes incoming RPL type-3 routing headers. It decompresses the SRH, swaps the current segment into ipv6_hdr(skb)->daddr, recompresses, pulls the old header, then pushes the new IPv6 header and the recompressed SRH back.

1
skb_pull(skb, ((hdr->hdrlen + 1) << 3));
2
... // header may have grown
3
skb_push(skb, ((chdr->hdrlen + 1) << 3) + sizeof(struct ipv6hdr));
4
skb_reset_network_header(skb);
5
skb_mac_header_rebuild(skb);  // still may have grown!

In skb_push():

1
  skb->data -= len;
2
  skb->len  += len;
3
  if (unlikely(skb->data < skb->head))
4
    skb_under_panic(skb, len, __builtin_return_address(0));

But actually, that skb_push() is the only safety check on the vulnerability trigger path, and it only compares data against head. However, after passing that check, skb_mac_header_rebuild() will subtract mac_len from data - head, and store the result into a __u16 with no check of its own.

So if we make the evil packet perfectly fit into head <= data < head + mac_len, skb_push() will return quietly (no panic any more!) and the later subtraction will get a negative value (underflow from u16). The truncated offset then puts the MAC header copy roughly 64 KB past head.

With that, we can copy a MAC header as OOB payload at the offset ~65,535. Which is enough to turn this “DoS only” bug into Local Privilege Escalation.

Turn an N-day into a 0-day

Now we know we can exploit that “DoS only” N-day, but we won’t stop here.

Let’s take a deeper look at the code after the fix:

The fix added pskb_expand_head() to grow the headroom when the recompressed header no longer fits. Normally, pskb_expand_head() is called only when segments_left drops to zero, on the assumption that the recompressed SRH can only grow at the final hop (but that assumption is not correct):

1
skb_pull(skb, ((hdr->hdrlen + 1) << 3));
2
...
3
if (unlikely(!hdr->segments_left)) {
4
  if (pskb_expand_head(skb,
5
           sizeof(struct ipv6hdr) + ((chdr->hdrlen + 1) << 3),
6
           0, GFP_ATOMIC))
7
    ...
8
  oldhdr = ipv6_hdr(skb);
9
}
10
skb_push(skb, ((chdr->hdrlen + 1) << 3) + sizeof(struct ipv6hdr));
11
skb_reset_network_header(skb);
12
skb_mac_header_rebuild(skb);

On an intermediate hop segments_left stays non-zero, so the headroom is never grown, even though the recompressed SRH can still get bigger. This gives the same initial primitive Route of Death had:

The skb_push() that follows leaves fewer than mac_len bytes of headroom. skb_mac_header_rebuild() then calls skb_set_mac_header(skb, -skb->mac_len), which resets skb->mac_header to data - head and subtracts mac_len from that, which will cause an integer underflow and return the offset as something around 0xffff.

The skb_mac_header() on the next line resolves to head plus that offset (~0xffff), and the memmove() copies the MAC header there, which gives us a 14-byte controllable OOB write.

As long as CONFIG_IPV6 is enabled, the vulnerable code is compiled into the kernel (even in Android).

Triggering the wrap

Now, with the intermediate hop bypass, we can exploit “Route of Root” on the latest kernel using the same so-called “DoS only” primitive to get LPE and win a $10,500 bounty from Google!

The RPL receive path is reachable by an unprivileged user. RPL is gated by net.ipv6.conf.*.rpl_seg_enabled, which only needs CAP_NET_ADMIN in the current namespace. At the time we exploited this bug, Container-Optimized OS was still a valid target and unprivileged namespaces were enabled in COS.

To trigger the exploitable bug, we can use the following SRH parameters to produce a 16-byte growth:

• CmprI = 5, CmprE = 15
• N = 5 compressed segments
• segments_left = 2
• no padding

Original SRH:

old_segdata_len = 5 * (16 - 5) + (16 - 15) = 56
old_rh_len      = 8 + 56 = 64

segments_left after the decrement is 1, so the pskb_expand_head() will be skipped. The selected segment index is:

i = N - (segments_left - 1) = 4

Two bytes of the compressed segment data are controlled:

1
rh->data[4 * (16 - CMPRI)] = 0x44;
2
rh->data[N * (16 - CMPRI)] = 0x77;

After the destination swap the last segment no longer shares the original 15-byte prefix with the new daddr. CmprE drops to 5, the compressed segment data grows to 66 bytes, and padding rounds the SRH to 80 bytes, so we get 16 bytes of growth.

Raw IPv6 with IPV6_HDRINCL on loopback puts the IPv6 header at head + 16 (hard_header_len = 14, LL_RESERVED_SPACE() gives 16). On loopback receive eth_type_trans() leaves skb->mac_len = 14. The pull/push sequence then leaves:

final data - head = 16 + old_srh_len - new_srh_len = 16 - growth

To wrap skb->mac_header, data - head must be below 14. To pass the skb_push() underflow check it must be non-negative. SRH lengths are 8-byte aligned, so only two growth values are useful:

growth =  8 -> data - head = 8 -> mac_header = 0xfffa -> page offset ffa
growth = 16 -> data - head = 0 -> mac_header = 0xfff2 -> page offset ff2

This exploit uses growth = 16, landing the wrapped write at page offset ff2.

Background of used tricks

Prefetch ASLR Leak

A prefetch on a given address runs in a different number of cycles depending on whether that address is mapped in the current page tables, so an unprivileged process can time prefetch across the kernel range and read off which addresses are mapped (the prefetch paper has the details).

It works here as Linux barely randomizes the base of its default kernel image (~9 bits of entropy for text base), so a little averaging can recover the KASLR base with near 100% reliability.

In theory any CPU with prefetch and without proper Kernel Page-Table Isolation is affected. But in practice it is more of an x86 technique (unless the ARM target runs KPTI off).

kernelCTF images keep KPTI disabled, but even with KPTI on, prefetch paired with EntryBleed can still recover the kernel image base through the trampoline.

pgv spray

pg_vec is the page vector behind an AF_PACKET mmap ring, the kernel’s fast path for passing packets to and from userspace. It is basically an array of pointers (every 8-byte entry points at a page-sized buffer). And its length is almost free to choose, which is what makes it easy to spray.

The more useful part is that the ring can be mmaped back into userspace, and that mmap does not check the permissions of the buffer a pg_vec entry points at.
So if we overwrite one of those pointers and aim it at kernel .text, mmap will hand back a writable mapping of that code page, and we patch the kernel straight from userspace.

That is basically the USMA trick.

However there’s one constraint. Attaching a pg_vec to a socket needs CAP_NET_RAW in the current namespace, so this only works where unprivileged {user + network} namespaces are available.