[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <cef80ba1-b0c1-a8bd-387a-9c7d2730a766@redhat.com>
Date: Thu, 27 May 2021 11:51:37 +0200
From: Max Reitz <mreitz@...hat.com>
To: Greg Kurz <groug@...d.org>, Miklos Szeredi <miklos@...redi.hu>
Cc: linux-kernel@...r.kernel.org, stable@...r.kernel.org,
virtio-fs@...hat.com, linux-fsdevel@...r.kernel.org,
Vivek Goyal <vgoyal@...hat.com>
Subject: Re: [Virtio-fs] [PATCH 1/4] fuse: Fix crash in
fuse_dentry_automount() error path
On 25.05.21 17:02, Greg Kurz wrote:
> If fuse_fill_super_submount() returns an error, the error path
> triggers a crash:
>
> [ 26.206673] BUG: kernel NULL pointer dereference, address: 0000000000000000
> [...]
> [ 26.226362] RIP: 0010:__list_del_entry_valid+0x25/0x90
> [...]
> [ 26.247938] Call Trace:
> [ 26.248300] fuse_mount_remove+0x2c/0x70 [fuse]
> [ 26.248892] virtio_kill_sb+0x22/0x160 [virtiofs]
> [ 26.249487] deactivate_locked_super+0x36/0xa0
> [ 26.250077] fuse_dentry_automount+0x178/0x1a0 [fuse]
>
> The crash happens because fuse_mount_remove() assumes that the FUSE
> mount was already added to list under the FUSE connection, but this
> only done after fuse_fill_super_submount() has returned success.
>
> This means that until fuse_fill_super_submount() has returned success,
> the FUSE mount isn't actually owned by the superblock. We should thus
> reclaim ownership by clearing sb->s_fs_info, which will skip the call
> to fuse_mount_remove(), and perform rollback, like virtio_fs_get_tree()
> already does for the root sb.
>
> Fixes: bf109c64040f ("fuse: implement crossmounts")
> Cc: mreitz@...hat.com
> Cc: stable@...r.kernel.org # v5.10+
> Signed-off-by: Greg Kurz <groug@...d.org>
> ---
> fs/fuse/dir.c | 6 +++++-
> 1 file changed, 5 insertions(+), 1 deletion(-)
Reviewed-by: Max Reitz <mreitz@...hat.com>
Powered by blists - more mailing lists