From: Christian Brauner <brauner@kernel.org>
To: Jan Polensky <japo@linux.ibm.com>
Cc: Vlastimil Babka <vbabka@suse.cz>, Mike Rapoport <rppt@kernel.org>,
jack@suse.cz, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org,
Paul Moore <paul@paul-moore.com>,
linux-security-module@vger.kernel.org
Subject: Re: [PATCH v1 1/1] fs: Fix use of incorrect flags with splice() on pipe from/to memfd
Date: Thu, 10 Jul 2025 13:34:12 +0200 [thread overview]
Message-ID: <20250710-geburt-aufbegehren-07813aabf939@brauner> (raw)
In-Reply-To: <20250708154352.3913726-1-japo@linux.ibm.com>
On Tue, Jul 08, 2025 at 05:43:52PM +0200, Jan Polensky wrote:
> Fix use of incorrect flags when using splice() with pipe ends and
> memfd secret. Ensure that pipe and memfd file descriptors are properly
> recognized and handled to prevent unintended EACCES errors in scenarios
> where EBADF or EINVAL are expected.
>
> This resolves failures in LTP's splice07 test case:
>
> ./ltp-bin/testcases/bin/splice07
> [skip]
> splice07.c:54: TFAIL: splice() on pipe read end -> memfd secret expected EBADF, EINVAL: EACCES (13)
> [skip]
> splice07.c:54: TFAIL: splice() on memfd secret -> pipe write end expected EBADF, EINVAL: EACCES (13)
> [skip]
>
> Fixes: cbe4134ea4bc ("fs: export anon_inode_make_secure_inode() and fix secretmem LSM bypass")
>
> Signed-off-by: Jan Polensky <japo@linux.ibm.com>
> ---
> fs/anon_inodes.c | 11 +++++++----
> include/linux/fs.h | 2 +-
> mm/secretmem.c | 2 +-
> 3 files changed, 9 insertions(+), 6 deletions(-)
>
> diff --git a/fs/anon_inodes.c b/fs/anon_inodes.c
> index 1d847a939f29..f4eade76273b 100644
> --- a/fs/anon_inodes.c
> +++ b/fs/anon_inodes.c
> @@ -104,6 +104,7 @@ static struct file_system_type anon_inode_fs_type = {
> * @name: [in] Name of the class of the newfile (e.g., "secretmem")
> * @context_inode:
> * [in] Optional parent inode for security inheritance
> + * @secmem [in] Indicates wheather the inode should be threaded as secretmem
> *
> * The function ensures proper security initialization through the LSM hook
> * security_inode_init_security_anon().
> @@ -111,7 +112,7 @@ static struct file_system_type anon_inode_fs_type = {
> * Return: Pointer to new inode on success, ERR_PTR on failure.
> */
> struct inode *anon_inode_make_secure_inode(struct super_block *sb, const char *name,
> - const struct inode *context_inode)
> + const struct inode *context_inode, bool secmem)
> {
> struct inode *inode;
> int error;
> @@ -119,8 +120,10 @@ struct inode *anon_inode_make_secure_inode(struct super_block *sb, const char *n
> inode = alloc_anon_inode(sb);
> if (IS_ERR(inode))
> return inode;
> - inode->i_flags &= ~S_PRIVATE;
> - inode->i_op = &anon_inode_operations;
> + if (!secmem) {
> + inode->i_flags &= ~S_PRIVATE;
> + inode->i_op = &anon_inode_operations;
> + }
That hides secret memory inodes from LSMs which is the exact opposite of
what the original commit was there to fix. I'm pretty sure that the
EACCES comes from the LSM layer because the relevant refpolicy or
however that works hasn't been updated to allow secret memory files to
use splice().
This is a chicken-and-egg problem withy anything that strips S_PRIVATE
from things that were previously S_PRIVATE.
next parent reply other threads:[~2025-07-10 11:34 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20250708154352.3913726-1-japo@linux.ibm.com>
2025-07-10 11:34 ` Christian Brauner [this message]
2025-07-11 14:01 ` Jan Polensky
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=20250710-geburt-aufbegehren-07813aabf939@brauner \
--to=brauner@kernel.org \
--cc=jack@suse.cz \
--cc=japo@linux.ibm.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-security-module@vger.kernel.org \
--cc=paul@paul-moore.com \
--cc=rppt@kernel.org \
--cc=vbabka@suse.cz \
/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