linux-kernel - Re: [PATCH] cifs: Fix reacquisition of volume cookie on still-live connection

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

Date: Thu, 04 Apr 2024 13:07:24 -0300
From: Paulo Alcantara <pc@...guebit.com>
To: David Howells <dhowells@...hat.com>, Steve French <sfrench@...ba.org>
Cc: dhowells@...hat.com, Shyam Prasad N <sprasad@...rosoft.com>,
 linux-cifs@...r.kernel.org, linux-fsdevel@...r.kernel.org,
 linux-kernel@...r.kernel.org
Subject: Re: [PATCH] cifs: Fix reacquisition of volume cookie on still-live
 connection

Hi Dave,

David Howells <dhowells@...hat.com> writes:

> During mount, cifs_mount_get_tcon() gets a tcon resource connection record
> and then attaches an fscache volume cookie to it.  However, it does this
> irrespective of whether or not the tcon returned from cifs_get_tcon() is a
> new record or one that's already in use.  This leads to a warning about a
> volume cookie collision and a leaked volume cookie because tcon->fscache
> gets reset.
>
> Fix this be adding a mutex and a "we've already tried this" flag and only
> doing it once for the lifetime of the tcon.

Can't we just move the cookie acquisition to cifs_get_tcon() before it
gets added to list @ses->tcon_list.  This way we'll guarantee that the
cookie is set only once for the new tcon.

Besides, do we want to share a tcon with two different superblocks that
have 'fsc' and 'nofsc', respectively?  If not, it would be better to fix
match_tcon() as well to handle such case.

> [!] Note: Looking at cifs_mount_get_tcon(), a more general solution may
> actually be required.  Reacquiring the volume cookie isn't the only thing
> that function does: it also partially reinitialises the tcon record without
> any locking - which may cause live filesystem ops already using the tcon
> through a previous mount to malfunction.

Agreed.