linux-kernel - [PATCH 0/2] Fuse submount_lookup needs to be initialized

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-next>] [day] [month] [year] [list]

Date:   Thu, 9 Nov 2023 14:36:57 -0800
From:   Krister Johansen <kjlx@...pleofstupid.com>
To:     Miklos Szeredi <miklos@...redi.hu>, linux-fsdevel@...r.kernel.org
Cc:     Miklos Szeredi <mszeredi@...hat.com>, linux-kernel@...r.kernel.org,
        German Maglione <gmaglione@...hat.com>,
        Greg Kurz <groug@...d.org>, Max Reitz <mreitz@...hat.com>,
        Bernd Schubert <bernd.schubert@...tmail.fm>,
        "Borah, Chaitanya Kumar" <chaitanya.kumar.borah@...el.com>,
        Naresh Kamboju <naresh.kamboju@...aro.org>,
        Dan Carpenter <dan.carpenter@...aro.org>,
        "Kurmi, Suresh Kumar" <suresh.kumar.kurmi@...el.com>,
        "Saarinen, Jani" <jani.saarinen@...el.com>,
        lkft-triage@...ts.linaro.org, linux-kselftest@...r.kernel.org,
        regressions@...ts.linux.dev, intel-gfx@...ts.freedesktop.org
Subject: [PATCH 0/2] Fuse submount_lookup needs to be initialized

Hi Miklos,
I got a couple of bug reports[1][2] this morning from teams that are
tracking regresssions in linux-next.  My patch 513dfacefd71 ("fuse:
share lookup state between submount and its parent") is causing panics
in the fuse unmount path.  The reports came from users with SLUB_DEBUG
enabled, and the additional debug sanitization catches the fact that the
submount_lookup field isn't getting initialized which could lead to a
subsequently bogus attempt to access the submount_lookup structure and
adjust its refcount.

I've added SLUB_DEBUG to my testing kconfig, and have reproduced the
problem using the memfd self-test that was triggering the problem for
both reporters.  With the fix that follows this e-mail, I see no more
erroneous accesses of poisoned slub memory.

I'm a bit unsure of the desired approach for fixing these kinds of
problems.  I'm also away from the office on Nov 10th and Nov 13th, but
expect to be back on the console on the Nov 14th.  Given the gap, I've
prepared a pair of patches, but we only need one.

The first is simply a followup fix that addresses the problem in a
subsequent one-line commit.

If you'd rather revert the entire bad patch and go again, the second
patch in the series is a v5 of the original with the submount_lookup
initialization added.

Either should do, but I wasn't sure which approach was preferable.

Thanks, and my apologies for the inconvenience.

-K

[1] https://lore.kernel.org/linux-fsdevel/CA+G9fYue-dV7t-NrOhWwGshvyboXjb2B6HpCDVDe3bgG7fbnsg@mail.gmail.com/T/#u
[2] https://lore.kernel.org/intel-gfx/SJ1PR11MB6129508509896AD7D0E03114B9AFA@SJ1PR11MB6129.namprd11.prod.outlook.com/T/#u