From: Jens Axboe <axboe@kernel.dk>
To: Al Viro <viro@zeniv.linux.org.uk>, linux-fsdevel@vger.kernel.org
Cc: audit@vger.kernel.org, io-uring@vger.kernel.org
Subject: Re: [RFC] struct filename, io_uring and audit troubles
Date: Mon, 23 Sep 2024 00:30:48 -0600 [thread overview]
Message-ID: <62104de8-6e9a-4566-bf85-f4c8d55bdb36@kernel.dk> (raw)
In-Reply-To: <20240923015044.GE3413968@ZenIV>
On 9/22/24 7:50 PM, Al Viro wrote:
> On Sun, Sep 22, 2024 at 01:49:01AM +0100, Al Viro wrote:
>
>> Another fun bit is that both audit_inode() and audit_inode_child()
>> may bump the refcount on struct filename. Which can get really fishy
>> if they get called by helper thread while the originator is exiting the
>> syscall - putname() from audit_free_names() in originator vs. refcount
>> increment in helper is Not Nice(tm), what with the refcount not being
>> atomic.
>
> *blink*
>
> OK, I really wonder which version had I been reading at the time; refcount
> is, indeed, atomic these days.
>
> Other problems (->aname pointing to other thread's struct audit_names
> and outliving reuse of those, as well as insane behaviour of audit predicates
> on symlink(2)) are, unfortunately, quite real - on the current mainline.
Traveling but took a quick look. As far as I can tell, for the "reuse
someone elses aname", we could do either:
1) Just don't reuse the entry. Then we can drop the struct
filename->aname completely as well. Yes that might incur an extra
alloc for the odd case of audit_enabled and being deep enough that
the preallocated names have been used, but doesn't anyone really
care? It'll be noise in the overhead anyway. Side note - that would
unalign struct filename again. Would be nice to drop audit_names from
a core fs struct...
2) Add a ref to struct audit_names, RCU kfree it when it drops to zero.
This would mean dropping struct audit_context->preallocated_names, as
otherwise we'd run into trouble there if a context gets blown away
while someone else has a ref to that audit_names struct. We could do
this without a ref as well, as long as we can store an audit_context
pointer in struct audit_names and be able to validate it under RCU.
If ctx doesn't match, don't use it.
And probably other ways too, those were just the two immediate ones I
thought it. Seems like option 1 is simpler and just fine? Quick hack:
diff --git a/fs/namei.c b/fs/namei.c
index 891b169e38c9..11263f779b96 100644
--- a/fs/namei.c
+++ b/fs/namei.c
@@ -206,7 +206,6 @@ getname_flags(const char __user *filename, int flags)
atomic_set(&result->refcnt, 1);
result->uptr = filename;
- result->aname = NULL;
audit_getname(result);
return result;
}
@@ -254,7 +253,6 @@ getname_kernel(const char * filename)
}
memcpy((char *)result->name, filename, len);
result->uptr = NULL;
- result->aname = NULL;
atomic_set(&result->refcnt, 1);
audit_getname(result);
diff --git a/include/linux/fs.h b/include/linux/fs.h
index 0df3e5f0dd2b..859244c877b4 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -2685,10 +2685,8 @@ struct filename {
const char *name; /* pointer to actual string */
const __user char *uptr; /* original userland pointer */
atomic_t refcnt;
- struct audit_names *aname;
const char iname[];
};
-static_assert(offsetof(struct filename, iname) % sizeof(long) == 0);
static inline struct mnt_idmap *file_mnt_idmap(const struct file *file)
{
diff --git a/kernel/auditsc.c b/kernel/auditsc.c
index cd57053b4a69..09caf8408225 100644
--- a/kernel/auditsc.c
+++ b/kernel/auditsc.c
@@ -2240,7 +2240,6 @@ void __audit_getname(struct filename *name)
n->name = name;
n->name_len = AUDIT_NAME_FULL;
- name->aname = n;
atomic_inc(&name->refcnt);
}
@@ -2325,22 +2324,6 @@ void __audit_inode(struct filename *name, const struct dentry *dentry,
if (!name)
goto out_alloc;
- /*
- * If we have a pointer to an audit_names entry already, then we can
- * just use it directly if the type is correct.
- */
- n = name->aname;
- if (n) {
- if (parent) {
- if (n->type == AUDIT_TYPE_PARENT ||
- n->type == AUDIT_TYPE_UNKNOWN)
- goto out;
- } else {
- if (n->type != AUDIT_TYPE_PARENT)
- goto out;
- }
- }
-
list_for_each_entry_reverse(n, &context->names_list, list) {
if (n->ino) {
/* valid inode number, use that for the comparison */
--
Jens Axboe
next prev parent reply other threads:[~2024-09-23 6:30 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-22 0:49 [RFC] struct filename, io_uring and audit troubles Al Viro
2024-09-22 4:10 ` Al Viro
2024-09-22 15:09 ` Al Viro
2024-09-23 1:50 ` Al Viro
2024-09-23 6:30 ` Jens Axboe [this message]
2024-09-23 12:54 ` Paul Moore
2024-09-23 14:48 ` Al Viro
2024-09-23 16:14 ` Paul Moore
2024-09-23 18:17 ` Al Viro
2024-09-23 23:49 ` Paul Moore
2024-09-23 20:36 ` Al Viro
2024-09-24 0:11 ` Paul Moore
2024-09-24 7:01 ` Al Viro
2024-09-24 23:17 ` Paul Moore
2024-09-25 20:44 ` Al Viro
2024-09-25 20:58 ` Paul Moore
2024-09-24 21:40 ` Al Viro
2024-09-25 6:01 ` Jens Axboe
2024-09-25 17:39 ` Al Viro
2024-09-25 17:58 ` Jens Axboe
2024-09-26 3:56 ` Al Viro
2024-09-23 15:07 ` Al Viro
2024-09-24 11:15 ` Jens Axboe
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=62104de8-6e9a-4566-bf85-f4c8d55bdb36@kernel.dk \
--to=axboe@kernel.dk \
--cc=audit@vger.kernel.org \
--cc=io-uring@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=viro@zeniv.linux.org.uk \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox