[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <6fb6a4c3-9703-4ab3-ab93-06c8c62bb99a@uliege.be>
Date: Mon, 19 Feb 2024 12:18:08 +0100
From: Justin Iurman <justin.iurman@...ege.be>
To: Paolo Abeni <pabeni@...hat.com>, netdev@...r.kernel.org
Cc: davem@...emloft.net, edumazet@...gle.com, kuba@...nel.org,
shuah@...nel.org, linux-kselftest@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH net 1/2] ioam6: fix write to cloned skb in ipv6_hop_ioam()
On 2/19/24 10:05, Paolo Abeni wrote:
> On Sat, 2024-02-17 at 00:43 +0100, Justin Iurman wrote:
>> ioam6_fill_trace_data() writes inside the skb payload without ensuring
>> it's writeable (e.g., not cloned). This function is called both from the
>> input and output path. The output path (ioam6_iptunnel) already does the
>> check. This commit provides a fix for the input path, inside
>> ipv6_hop_ioam().
>>
>> Fixes: 9ee11f0fff20 ("ipv6: ioam: Data plane support for Pre-allocated Trace ")
>> Reported-by: Paolo Abeni <pabeni@...hat.com>
>> Signed-off-by: Justin Iurman <justin.iurman@...ege.be>
>> ---
>> net/ipv6/exthdrs.c | 8 ++++++++
>> 1 file changed, 8 insertions(+)
>>
>> diff --git a/net/ipv6/exthdrs.c b/net/ipv6/exthdrs.c
>> index 4952ae792450..f68e5faab3aa 100644
>> --- a/net/ipv6/exthdrs.c
>> +++ b/net/ipv6/exthdrs.c
>> @@ -943,6 +943,14 @@ static bool ipv6_hop_ioam(struct sk_buff *skb, int optoff)
>> if (!skb_valid_dst(skb))
>> ip6_route_input(skb);
>>
>> + if (skb_cloned(skb)) {
>> + if (pskb_expand_head(skb, 0, 0, GFP_ATOMIC))
>> + goto drop;
>
> My personal preference would be for using skb_ensure_writable() here,
> with write_len == optoff + hdr->opt_len.
OK, will do!
>> +
>> + hdr = (struct ioam6_hdr *)(skb_network_header(skb) + optoff);
>> + trace = (struct ioam6_trace_hdr *)((u8 *)hdr + sizeof(*hdr));
>
> Note that this can potentially change the network header ptr and the
> caller - ip6_parse_tlv() - has cached such value in 'nh'. You also need
> to update ip6_parse_tlv() to reload such pointer.
+1, I completely missed it, thanks!
> Side note: a bunch of self-tests are apparently stuck after this
> series. I think it's an unrelated problem. I'll try to have a better
> look.
Can you share the config to observe such behavior? I'll try to
investigate too.
> Cheers,
>
> Paolo
>
Powered by blists - more mailing lists