linux-kernel - Re: [PATCH] kernfs: fix UAF race condition in __kernfs

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]

Date:   Sun, 25 Sep 2022 18:52:22 +0200
From:   "Christian A. Ehrhardt" <lk@...e.de>
To:     Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>
Cc:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Tejun Heo <tj@...nel.org>,
        syzbot <syzbot+8bee3285b9e190f1509e@...kaller.appspotmail.com>,
        syzkaller-bugs@...glegroups.com, linux-kernel@...r.kernel.org,
        Hillf Danton <hdanton@...a.com>
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