linux-kernel - Re: general protection fault in ip6_pol

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] [day] [month] [year] [list]

Message-ID: <20250205113334.1960-1-hdanton@sina.com>
Date: Wed,  5 Feb 2025 19:33:31 +0800
From: Hillf Danton <hdanton@...a.com>
To: Eric Dumazet <edumazet@...gle.com>
Cc: YAN KANG <kangyan91@...look.com>,
	netdev <netdev@...r.kernel.org>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: general protection fault in ip6_pol_route

On Tue, 4 Feb 2025 15:07:49 +0100 Eric Dumazet <edumazet@...gle.com>
> On Tue, Feb 4, 2025 at 2:47 PM YAN KANG <kangyan91@...look.com> wrote:
> >
> > Dear maintainers,
> >
> > I found a kernel  bug titiled "general protection fault in ip6_pol_route" while using modified syzkaller fuzzing tool. I Itested it on the latest Linux upstream version (6.13.0-rc7) .
> >
> >
> > After preliminary analysis, the rootcause may be in ip6_pol_route function  net/ipv6/route.c
> >     res is a stack object.    [1]
> >     fib6_select_path(net, &res, fl6, oif, false, skb, strict)  call  may initialize res->nh.[2]
> >     rt = rt6_get_pcpu_route( &res);   [3]
> >            pcpu_rt = this_cpu_read(*res->nh->rt6i_pcpu); // *res->nh is NULL, crash
> >
> >    in [2], res->nh can be initialized in several ways,possibly one of which initializes it to NULL.
> >
> >  Unfortunately, I don't have any reproducer for this bug yet.
> >
> > If you fix this issue, please add the following tag to the commit:
> > Reported-by: yan kang <kangyan91@...look.com>
> > Reported-by: yue sun <samsun1006219@...il.com
> >
> This is a dup of a syzbot report under investigation.
> 
> Unless you have a repro and/or a patch, I would recommend you not
> sending these fuzzer reports anymore.
> 
> Releasing such reports without a fix is an obvious security risk.
> 
Can you specify a bit why report like this one links to security risk, Eric,
given no fix yet delivered to the syzbot report [1] so far?

[1] https://yhbt.net/lore/lkml/67a21f26.050a0220.163cdc.0068.GAE@google.com/