All of lore.kernel.org
 help / color / mirror / Atom feed
From: Al Viro <viro@zeniv.linux.org.uk>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: linux-fsdevel@vger.kernel.org,
	Christian Brauner <brauner@kernel.org>,
	Arnd Bergmann <arnd@arndb.de>
Subject: [RFC][PATCH] get rid of bogus __user in struct xattr_args::value
Date: Tue, 16 Dec 2025 08:19:39 +0000	[thread overview]
Message-ID: <20251216081939.GQ1712166@ZenIV> (raw)

	The first member of struct xattr_args is declared as
	__aligned_u64 __user value;
which makes no sense whatsoever; __user is a qualifier and what that
declaration says is "all struct xattr_args instances have .value
_stored_ in user address space, no matter where the rest of the
structure happens to be".

	Something like "int __user *p" stands for "value of p is a pointer
to an instance of int that happens to live in user address space"; it
says nothing about location of p itself, just as const char *p declares a
pointer to unmodifiable char rather than an unmodifiable pointer to char.

	With xattr_args the intent clearly had been "the 64bit value
represents a _pointer_ to object in user address space", but __user has
nothing to do with that.  All it gets us is a couple of bogus warnings
in fs/xattr.c where (userland) instance of xattr_args is copied to local
variable of that type (in kernel address space), followed by access
to its members.  Since we've told sparse that args.value must somehow be
located in userland memory, we get warned that looking at that 64bit
unsigned integer (in a variable already on kernel stack) is not allowed.

	Note that sparse has no way to express "this integer shall never
be cast into a pointer to be dereferenced directly" and I don't see any
way to assign a sane semantics to that.  In any case, __user is not it.

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
---

PS: one variant we might implement in sparse is a type attribute similar
to __bitwise__ (__affine__, perhaps?) such that
T + integer => T, as long as integer type promotes to base type of T
T - integer => ditto
T - T => base type of T
T <comparison> T => int
and perhaps
T & integer => integer, for the sake of things like alignment checks, etc.
any other arithmetics on T => error
cast or conversion from T to anything other than qualified T => error
cast or conversion to T from anything other than qualified T => error
force-cast to or from T => allowed
Then we could have something like __encoded_uptr declared as __u64 with
such attribute in addition to __aligned(8) we already have on __aligned_u64,
with
static inline void __user *decode_uptr(__encoded_uptr v)
{
	return (__force void __user *)v;
}
with that helper used instead of u64_to_user_ptr() fs/xattr.c currently uses
for those.  It's not that hard to implement, but I'm not sure how useful would
that be...

diff --git a/include/uapi/linux/xattr.h b/include/uapi/linux/xattr.h
index c7c85bb504ba..2e5aef48fa7e 100644
--- a/include/uapi/linux/xattr.h
+++ b/include/uapi/linux/xattr.h
@@ -23,7 +23,7 @@
 #define XATTR_REPLACE	0x2	/* set value, fail if attr does not exist */
 
 struct xattr_args {
-	__aligned_u64 __user value;
+	__aligned_u64 value;
 	__u32 size;
 	__u32 flags;
 };

             reply	other threads:[~2025-12-16  8:19 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-12-16  8:19 Al Viro [this message]
2025-12-24 12:53 ` [RFC][PATCH] get rid of bogus __user in struct xattr_args::value Christian Brauner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20251216081939.GQ1712166@ZenIV \
    --to=viro@zeniv.linux.org.uk \
    --cc=arnd@arndb.de \
    --cc=brauner@kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.