netdev - Re: [PATCH net-next v2 0/2] Fix dangling pointer at f6i->gc

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]

Date: Wed, 13 Dec 2023 18:32:24 +0100
From: Eric Dumazet <edumazet@...gle.com>
To: David Ahern <dsahern@...nel.org>
Cc: thinker.li@...il.com, netdev@...r.kernel.org, martin.lau@...ux.dev, 
	kernel-team@...a.com, davem@...emloft.net, kuba@...nel.org, pabeni@...hat.com, 
	sinquersw@...il.com, kuifeng@...a.com
Subject: Re: [PATCH net-next v2 0/2] Fix dangling pointer at f6i->gc_link.

On Wed, Dec 13, 2023 at 6:22 PM David Ahern <dsahern@...nel.org> wrote:
>
> On 12/8/23 12:45 PM, thinker.li@...il.com wrote:
> > From: Kui-Feng Lee <thinker.li@...il.com>
> >
> > According to a report [1], f6i->gc_link may point to a free block
> > causing use-after-free. According the stacktraces in the report, it is
> > very likely that a f6i was added to the GC list after being removed
> > from the tree of a fib6_table. The reason this can happen is the
> > current implementation determines if a f6i is on a tree in a wrong
> > way. It believes a f6i is on a tree if f6i->fib6_table is not NULL.
> > However, f6i->fib6_table is not reset when f6i is removed from a tree.
> >
> > The new solution is to check if f6i->fib6_node is not NULL as well.
> > f6i->fib6_node is set/or reset when the f6i is added/or removed from
> > from a tree. It can be used to determines if a f6i is on a tree
> > reliably.
> >
> > The other change is to determine if a f6i is on a GC list.  The
> > current implementation relies on RTF_EXPIRES on fib6_flags. It needs
> > to consider if a f6i is on a tree as well. The new solution is
> > checking hlist_unhashed() on f6i->gc_link, a clear evidence, instead.
> >
> > [1] https://lore.kernel.org/all/20231205173250.2982846-1-edumazet@google.com/
> >
>
> Eric: can you release the syzbot report for the backtrace listed in [1].
> I would like to make "very likely that a f6i was added to the GC list
> after being removed from the tree of a fib6_table" more certain. Thanks,

I have one, not sure if the tree is recent enough.