linux-kernel - Re: [PATCH 6.1] efivarfs: Move efivarfs list into superblock s_fs

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: <CAMj1kXEatQ6o8dt7x-1mkX0+ct01ThbXDE-kmctWtEnZbC1gEQ@mail.gmail.com>
Date: Fri, 21 Mar 2025 20:00:35 +0100
From: Ard Biesheuvel <ardb@...nel.org>
To: Alexey Nepomnyashih <sdl@...ct.ru>
Cc: Jeremy Kerr <jk@...abs.org>, linux-efi@...r.kernel.org, linux-kernel@...r.kernel.org, 
	lvc-project@...uxtesting.org, 
	syzbot+1902c359bfcaf39c46f2@...kaller.appspotmail.com, 
	syzbot+246ea4feed277471958a@...kaller.appspotmail.com
Subject: Re: [PATCH 6.1] efivarfs: Move efivarfs list into superblock s_fs_info

On Fri, 21 Mar 2025 at 19:40, Alexey Nepomnyashih <sdl@...ct.ru> wrote:
>
> From: Ard Biesheuvel <ardb@...nel.org>
>
> commit cdb46a8aefbf7fd36772bb206aaaf7e45d7cf8f6 upstream.
>
> syzbot reports issues with concurrent fsopen()/fsconfig() invocations on
> efivarfs, which are the result of the fact that the efivarfs list (which
> caches the names and GUIDs of existing EFI variables) is a global
> structure. In normal use, these issues are unlikely to trigger, even in
> the presence of multiple mounts of efivarfs, but the execution pattern
> used by the syzkaller reproducer may result in multiple instances of the
> superblock that share the global efivarfs list, and this causes list
> corruption when the list is reinitialized by one user while another is
> traversing it.
>
> So let's move the list head into the superblock s_fs_info field, so that
> it will never be shared between distinct instances of the superblock. In
> the common case, there will still be a single instance of this list, but
> in the artificial syzkaller case, no list corruption can occur any
> longer.
>
> Reported-by: syzbot+1902c359bfcaf39c46f2@...kaller.appspotmail.com
> Signed-off-by: Ard Biesheuvel <ardb@...nel.org>
> Reported-by: syzbot+246ea4feed277471958a@...kaller.appspotmail.com
> Closes: https://syzkaller.appspot.com/bug?extid=246ea4feed277471958a
> Signed-off-by: Alexey Nepomnyashih <sdl@...ct.ru>
> ---
>  fs/efivarfs/inode.c    |  3 ++-
>  fs/efivarfs/internal.h |  9 ++++++---
>  fs/efivarfs/super.c    | 26 +++++++++++++++++---------
>  fs/efivarfs/vars.c     |  5 +++--
>  4 files changed, 28 insertions(+), 15 deletions(-)
>

The original commit has

 fs/efivarfs/inode.c    |  3 ++-
 fs/efivarfs/internal.h |  6 +++---
 fs/efivarfs/super.c    | 19 ++++++++++---------
 fs/efivarfs/vars.c     |  5 +++--
 4 files changed, 18 insertions(+), 15 deletions(-)

so you will need to explain where those extra 10 lines came from.