Messages in this thread |  | | Date | Sun, 25 Sep 2022 18:52:22 +0200 | From | "Christian A. Ehrhardt" <> | Subject | Re: [PATCH] kernfs: fix UAF race condition in __kernfs_remove() |
| |
Hi,
On Sun, Sep 25, 2022 at 10:52:56PM +0900, Tetsuo Handa wrote: > On 2022/09/25 22:40, Greg Kroah-Hartman wrote: > > On Sun, Sep 25, 2022 at 10:20:27PM +0900, Tetsuo Handa wrote: > >> On 2022/09/25 22:13, Greg Kroah-Hartman wrote: > >>> Isn't this already handled by: > >>> https://lore.kernel.org/r/20220913121723.691454-1-lk@c--e.de > >>> > >>> that will show up in the next linux-next tree. > >> > >> Oh, I didn't know that patch. > >> > >> But is that patch complete, for there are three __kernfs_remove() callers? > >> > > > > syzbot seems to think it works :) > > syzbot's reproducer tested only kernfs_remove_by_name_ns() case. > I'm not sure whether e.g. __kernfs_remove() from kernfs_remove() is safe.
I had an older version of the patch that was rejected by Tejun Heo on the grounds that external kernfs_remove callers must hold a reference on their own or the race can happen even befor kernfs_remoe takes the lock.
See https://lore.kernel.org/all/20220907200811.654034-1-lk@c--e.de/ for the details. I did convince myself that other callers of kernfs_remove() have other means to ensure that there are no parallel removes for the same node.
IMHO the kernfs interface's use of ref-counts is slightly unintuitive but I think it is safe, now.
regards Christian
|  |