linux-kernel - [PATCH 0/2] vfs, afs, bash: Fix miscomparison of foreign user IDs in the VFS

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <20250519161125.2981681-1-dhowells@redhat.com>
Date: Mon, 19 May 2025 17:11:21 +0100
From: David Howells <dhowells@...hat.com>
To: Christian Brauner <christian@...uner.io>
Cc: David Howells <dhowells@...hat.com>,
	Marc Dionne <marc.dionne@...istor.com>,
	linux-afs@...ts.infradead.org,
	linux-fsdevel@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: [PATCH 0/2] vfs, afs, bash: Fix miscomparison of foreign user IDs in the VFS

Hi Christian,

Here's a pair of fixes that deal with some places the VFS mishandles
foreign user ID checks.  By "foreign" I mean that the user IDs from the
filesystem do not belong in the same number space as the system's user IDs.
Network filesystems are prime examples of this, but it may also impact
things like USB drives or cdroms.

Take AFS as example: Whilst each file does have a numeric user ID, the file
may be accessed from a world-accessible public-facing server from some
other organisation with its own idea of what that user ID refers to.  IDs
from AFS may also collide with the system's own set of IDs and may also be
unrepresentable as a 32-bit UID (in the case of AuriStor servers).

Further, kAFS uses a key containing an authentication token to specify the
subject doing an RPC operation to the server - and, as such, this needs to
be used instead of current_fsuid() in determining whether the current user
has ownership rights over a file.

Additionally, filesystems (CIFS being a notable example) may also have user
identifiers that aren't simple integers.

Now the problem in the VFS is that there are a number of places where it
assumes it can directly compare i_uid (possibly id-mapped) to either than
on another inode or a UID drawn from elsewhere (e.g. current_uid()) - but
this doesn't work right.

This causes the write-to-sticky check to work incorrectly for AFS (though
this is currently masked by a workaround in bash that is slated to be
removed) whereby open(O_CREAT) of such a file will fail when it shouldn't.

Two patches are provided: The first specifically fixes the bash workaround
issue, delegating the check as to whether two inodes have the same owner
and the check as to whether the current user owns an inode to the
filesystem.

AFS then uses the result of a status-fetch with a suitable key to determine
file ownership and just compares the 64-bit owner IDs to determine if two
inodes have the same ownership.

The second patch expands the use of the VFS helper functions added by the
first to other VFS UID checks.

The patches can be found here:

	https://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git/log/?h=afs-fixes

Thanks,
David

David Howells (2):
  afs, bash: Fix open(O_CREAT) on an extant AFS file in a sticky dir
  vfs: Fix inode ownership checks with regard to foreign ownership

 fs/afs/dir.c       |  2 ++
 fs/afs/file.c      |  2 ++
 fs/afs/internal.h  |  3 ++
 fs/afs/security.c  | 52 ++++++++++++++++++++++++++++++
 fs/attr.c          | 58 ++++++++++++++++++++-------------
 fs/coredump.c      |  3 +-
 fs/inode.c         |  8 +++--
 fs/internal.h      |  1 +
 fs/locks.c         |  7 ++--
 fs/namei.c         | 80 ++++++++++++++++++++++++++++++++--------------
 fs/remap_range.c   | 20 ++++++------
 include/linux/fs.h |  3 ++
 12 files changed, 177 insertions(+), 62 deletions(-)