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]

Message-ID: <deb7d2b6-1314-4d39-aa6f-2930e5de8d82@kernel.org>
Date: Wed, 13 Dec 2023 09:22:36 -0800
From: David Ahern <dsahern@...nel.org>
To: 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, edumazet@...gle.com
Cc: sinquersw@...il.com, kuifeng@...a.com
Subject: Re: [PATCH net-next v2 0/2] Fix dangling pointer at f6i->gc_link.

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,