linux-kernel - Re: [PATCH 3.10 099/180] fix d_walk()/non-delayed __d

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: <20160827211254.GA4310@1wt.eu>
Date:   Sat, 27 Aug 2016 23:12:54 +0200
From:   Willy Tarreau <w@....eu>
To:     Ben Hutchings <ben@...adent.org.uk>
Cc:     Al Viro <viro@...iv.linux.org.uk>,
        Jari Ruusu <jariruusu@...rs.sourceforge.net>,
        linux-kernel@...r.kernel.org, stable@...r.kernel.org,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Jiri Slaby <jslaby@...e.cz>
Subject: Re: [PATCH 3.10 099/180] fix d_walk()/non-delayed __d_free() race

On Sat, Aug 27, 2016 at 12:38:38PM +0100, Ben Hutchings wrote:
> On Sat, 2016-08-27 at 11:31 +0200, Willy Tarreau wrote:
> > Greg, Jiri,
> > 
> > I checked Jari's explanation below and found that v3.14.77 and v3.12.62
> > are missing the same fix as 3.10. In fact Al's original commit 3d56c25
> > ("fix d_walk()/non-delayed __d_free() race") used to mention to check 
> > this __d_materialise_dentry() function in the Cc: stable line, but this
> > got lost during the backports.
> > 
> > Normally all of our 3 kernels need to apply the following patch that
> > Ben correctly put in 3.16 and 3.2. I'm fixing the backport in 3.10.103
> > right now.
> 
> I never did get positive confirmation that this is the right change in
> __d_materialise_dentry().  Al, could you please comment?

Well in my experience Al checks our reviews and steps in when there's
a mistake. Also your patch seems to reproduce the fix for the code
that was later killed by commit 63cf427 ("kill __d_materialise_dentry()")
which factors it out into __d_move() so I'm inclined to think that what
you did makes sense.

Cheers,
Willy