[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CANn89iKLiF7MLM5x4-M9CT+AFUUyx8vArUr9uwfLoUHk7GMp_A@mail.gmail.com>
Date: Mon, 5 Jun 2023 20:52:04 +0200
From: Eric Dumazet <edumazet@...gle.com>
To: Kuniyuki Iwashima <kuniyu@...zon.com>
Cc: "David S. Miller" <davem@...emloft.net>, Jakub Kicinski <kuba@...nel.org>,
Paolo Abeni <pabeni@...hat.com>, David Ahern <dsahern@...nel.org>,
Alexander Aring <alex.aring@...il.com>, Kuniyuki Iwashima <kuni1840@...il.com>, netdev@...r.kernel.org
Subject: Re: [PATCH v2 net] ipv6: rpl: Fix Route of Death.
On Mon, Jun 5, 2023 at 8:06 PM Kuniyuki Iwashima <kuniyu@...zon.com> wrote:
>
> A remote DoS vulnerability of RPL Source Routing is assigned CVE-2023-2156.
>
> The Source Routing Header (SRH) has the following format:
>
> 0 1 2 3
> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | Next Header | Hdr Ext Len | Routing Type | Segments Left |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | CmprI | CmprE | Pad | Reserved |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | |
> . .
> . Addresses[1..n] .
> . .
> | |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> The originator of an SRH places the first hop's IPv6 address in the IPv6
> header's IPv6 Destination Address and the second hop's IPv6 address as
> the first address in Addresses[1..n].
>
> The CmprI and CmprE fields indicate the number of prefix octets that are
> shared with the IPv6 Destination Address. When CmprI or CmprE is not 0,
> Addresses[1..n] are compressed as follows:
>
> 1..n-1 : (16 - CmprI) bytes
> n : (16 - CmprE) bytes
>
> Segments Left indicates the number of route segments remaining. When the
> value is not zero, the SRH is forwarded to the next hop. Its address
> is extracted from Addresses[n - Segment Left + 1] and swapped with IPv6
> Destination Address.
>
> When Segment Left is greater than or equal to 2, the size of SRH is not
> changed because Addresses[1..n-1] are decompressed and recompressed with
> CmprI.
>
> OTOH, when Segment Left changes from 1 to 0, the new SRH could have a
> different size because Addresses[1..n-1] are decompressed with CmprI and
> recompressed with CmprE.
>
> Let's say CmprI is 15 and CmprE is 0. When we receive SRH with Segment
> Left >= 2, Addresses[1..n-1] have 1 byte for each, and Addresses[n] has
> 16 bytes. When Segment Left is 1, Addresses[1..n-1] is decompressed to
> 16 bytes and not recompressed. Finally, the new SRH will need more room
> in the header, and the size is (16 - 1) * (n - 1) bytes.
>
> Here the max value of n is 255 as Segment Left is u8, so in the worst case,
> we have to allocate 3825 bytes in the skb headroom. However, now we only
> allocate a small fixed buffer that is IPV6_RPL_SRH_WORST_SWAP_SIZE (16 + 7
> bytes). If the decompressed size overflows the room, skb_push() hits BUG()
> below [0].
>
> Instead of allocating the fixed buffer for every packet, let's allocate
> enough headroom only when we receive SRH with Segment Left 1.
>
> [0]:
>
> Fixes: 8610c7c6e3bd ("net: ipv6: add support for rpl sr exthdr")
> Reported-by: Max VA
> Closes: https://www.interruptlabs.co.uk/articles/linux-ipv6-route-of-death
> Signed-off-by: Kuniyuki Iwashima <kuniyu@...zon.com>
> ---
> To maintainers:
> Please complement the Reported-by address from the security@ mailing list
> if possible, which checkpatch will complain about.
>
> v2:
> * Reload oldhdr@ after pskb_expand_head() (Eric Dumazet)
>
Reviewed-by: Eric Dumazet <edumazet@...gle.com>
Powered by blists - more mailing lists