Re: BUG: KASAN: stack-out-of-bounds in __ip_options_echo

[Fengtao (fengtao, Euler)]

On 2023/5/5 13:58, Florian Westphal wrote:
> Fengtao (fengtao, Euler) <fengtao40@xxxxxxxxxx> wrote:
>> Hi
>>
>> I have tested the patch, the panic not happend.
>> And I search the similar issue in kernel, and found commit:
>> [1]https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ed0de45a1008
>> [2]https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3da1ed7ac398
>>
>> So I tested another patch like this:
>> ------------[ cut here ]------------
>> --- .//net/ipv4/netfilter/nf_reject_ipv4.c      2023-05-02 13:03:35.427896081 +0000
>> +++ .//net/ipv4/netfilter/nf_reject_ipv4.c.new  2023-05-02 13:03:00.433897970 +0000
>> @@ -187,6 +187,7 @@ > 
>>  void nf_send_unreach(struct sk_buff *skb_in, int code, int hook)
>>  {
>> +       struct ip_options opt;
>>         struct iphdr *iph = ip_hdr(skb_in);
>>         u8 proto = iph->protocol;
>>
>> @@ -196,13 +197,18 @@
>>         if (hook == NF_INET_PRE_ROUTING && nf_reject_fill_skb_dst(skb_in))
>>                 return;
>>
>> +       memset(&opt, 0, sizeof(opt));
>> +       opt.optlen = iph->ihl*4 - sizeof(struct iphdr);
>> +       if (__ip_options_compile(dev_net(skb_in->dev), &opt, skb_in, NULL))
>> +               return;
>> +
>>         if (skb_csum_unnecessary(skb_in) || !nf_reject_verify_csum(proto)) {
>> -               icmp_send(skb_in, ICMP_DEST_UNREACH, code, 0);
>> +               __icmp_send(skb_in, ICMP_DEST_UNREACH, code, 0, &opt);
>>                 return;
>>         }
>>
>>         if (nf_ip_checksum(skb_in, hook, ip_hdrlen(skb_in), proto) == 0)
>> -               icmp_send(skb_in, ICMP_DEST_UNREACH, code, 0);
>> +               __icmp_send(skb_in, ICMP_DEST_UNREACH, code, 0, &opt);
>>  }
>>  EXPORT_SYMBOL_GPL(nf_send_unreach);
>> ------------[ cut here ]------------
>>
>> This can also fix the issue :)
> 
> No, it papers over the problem, by only fixing this specific instance
> (icmpv4).  What about ipv6?  What about all other IPCB accesses?
> 
That make sense

>> BTW, I think the problem is more then ipvlan? Maybe some other scenarios that can trigger such issue.
> 
> Such as?
> 
> I don't see how this is fixable, just have have a look at "git grep
> IPCB", how do you envision stack to know how such access is valid or
> not?
> 
> .
> 
Hi, Floian
I already tested your patch for 24 hours, and the panic never happened; Could you send your commit to kernel-upstream?
If you do not have time, I would be happy to sent this patch and add your SOB.