netdev - Re: BUG: KASAN: stack-out-of-bounds in __ip_options

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4f3d231e-5ba8-08a9-e2d3-95edf5bb2dc7@huawei.com>
Date: Sat, 6 May 2023 11:01:42 +0800
From: "Fengtao (fengtao, Euler)" <fengtao40@...wei.com>
To: Florian Westphal <fw@...len.de>
CC: <jhs@...atatu.com>, <xiyou.wangcong@...il.com>, <jiri@...nulli.us>,
	<davem@...emloft.net>, <kuba@...nel.org>, <stephen@...workplumber.org>,
	<netdev@...r.kernel.org>, <linux-kernel@...r.kernel.org>, <yanan@...wei.com>,
	<caowangbao@...wei.com>
Subject: Re: BUG: KASAN: stack-out-of-bounds in __ip_options_echo



On 2023/5/5 13:58, Florian Westphal wrote:
> Fengtao (fengtao, Euler) <fengtao40@...wei.com> 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.