All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chao Yu <chao@kernel.org>
To: Hungyu Lin <dennylin0707@gmail.com>, jaegeuk@kernel.org
Cc: chao@kernel.org, linux-f2fs-devel@lists.sourceforge.net,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] f2fs: require CAP_SYS_ADMIN for fallocate on pinned files
Date: Wed, 11 Nov 2026 17:42:29 +0800	[thread overview]
Message-ID: <64dfd4fe-46eb-45b5-9eb1-ab0564bc2d47@kernel.org> (raw)
In-Reply-To: <20261108075357.43331-1-dennylin0707@gmail.com>

On 11/8/26 15:53, Hungyu Lin wrote:
> fallocate() on a pinned file allocates blocks without zeroing them, so
> reading the file returns whatever the blocks held before.
> Documentation/filesystems/f2fs.rst describes this as "zero or random
> data". Commit cad3836f9eb2 ("f2fs: allocate blocks for pinned file")
> added this while F2FS_IOC_SET_PIN_FILE required CAP_SYS_ADMIN, but
> commit b13bdf03bb80 ("f2fs: allow all the users to pin a file") then let
> any user pin a file. Since then any user can create a file, pin it,
> fallocate() it and read back data of files that other users have
> deleted.

Android should be safe, as on-disk data from user is encrypted, it will be
decrypted only in memory w/ user's crypto key, there is no way to read the
plain data from disk directly.

> 
> Require CAP_SYS_ADMIN for fallocate() on a pinned file. The documented
> use of these blocks needs write access to the block device anyway, and
> Android's gsid, which creates pinned image files through libfiemap, has
> CAP_SYS_ADMIN. Users without CAP_SYS_ADMIN can still pin files, but can
> no longer preallocate blocks for them. fallocate() on files that are not
> pinned is not affected.

Or maybe we can call f2fs_secure_erase() on the blkaddr range after
preallocation and before return from fallocate().

> 
> Fixes: b13bdf03bb80 ("f2fs: allow all the users to pin a file")

Jaegeuk, do we suffer any permission issue before above commit?

Thanks,

> Cc: stable@vger.kernel.org
> Signed-off-by: Hungyu Lin <dennylin0707@gmail.com>
> ---
>  fs/f2fs/file.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/fs/f2fs/file.c b/fs/f2fs/file.c
> index e2c0f5083313..d1b52b41a1eb 100644
> --- a/fs/f2fs/file.c
> +++ b/fs/f2fs/file.c
> @@ -1973,6 +1973,9 @@ static int f2fs_expand_inode_data(struct inode *inode, loff_t offset,
>  	block_t expanded = 0;
>  	int err;
>  
> +	if (f2fs_is_pinned_file(inode) && !capable(CAP_SYS_ADMIN))
> +		return -EPERM;
> +
>  	err = inode_newsize_ok(inode, (len + offset));
>  	if (err)
>  		return err;


WARNING: multiple messages have this Message-ID (diff)
From: Chao Yu via Linux-f2fs-devel <linux-f2fs-devel@lists.sourceforge.net>
To: Hungyu Lin <dennylin0707@gmail.com>, jaegeuk@kernel.org
Cc: linux-kernel@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net
Subject: Re: [f2fs-dev] [PATCH] f2fs: require CAP_SYS_ADMIN for fallocate on pinned files
Date: Wed, 11 Nov 2026 17:42:29 +0800	[thread overview]
Message-ID: <64dfd4fe-46eb-45b5-9eb1-ab0564bc2d47@kernel.org> (raw)
In-Reply-To: <20261108075357.43331-1-dennylin0707@gmail.com>

On 11/8/26 15:53, Hungyu Lin wrote:
> fallocate() on a pinned file allocates blocks without zeroing them, so
> reading the file returns whatever the blocks held before.
> Documentation/filesystems/f2fs.rst describes this as "zero or random
> data". Commit cad3836f9eb2 ("f2fs: allocate blocks for pinned file")
> added this while F2FS_IOC_SET_PIN_FILE required CAP_SYS_ADMIN, but
> commit b13bdf03bb80 ("f2fs: allow all the users to pin a file") then let
> any user pin a file. Since then any user can create a file, pin it,
> fallocate() it and read back data of files that other users have
> deleted.

Android should be safe, as on-disk data from user is encrypted, it will be
decrypted only in memory w/ user's crypto key, there is no way to read the
plain data from disk directly.

> 
> Require CAP_SYS_ADMIN for fallocate() on a pinned file. The documented
> use of these blocks needs write access to the block device anyway, and
> Android's gsid, which creates pinned image files through libfiemap, has
> CAP_SYS_ADMIN. Users without CAP_SYS_ADMIN can still pin files, but can
> no longer preallocate blocks for them. fallocate() on files that are not
> pinned is not affected.

Or maybe we can call f2fs_secure_erase() on the blkaddr range after
preallocation and before return from fallocate().

> 
> Fixes: b13bdf03bb80 ("f2fs: allow all the users to pin a file")

Jaegeuk, do we suffer any permission issue before above commit?

Thanks,

> Cc: stable@vger.kernel.org
> Signed-off-by: Hungyu Lin <dennylin0707@gmail.com>
> ---
>  fs/f2fs/file.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/fs/f2fs/file.c b/fs/f2fs/file.c
> index e2c0f5083313..d1b52b41a1eb 100644
> --- a/fs/f2fs/file.c
> +++ b/fs/f2fs/file.c
> @@ -1973,6 +1973,9 @@ static int f2fs_expand_inode_data(struct inode *inode, loff_t offset,
>  	block_t expanded = 0;
>  	int err;
>  
> +	if (f2fs_is_pinned_file(inode) && !capable(CAP_SYS_ADMIN))
> +		return -EPERM;
> +
>  	err = inode_newsize_ok(inode, (len + offset));
>  	if (err)
>  		return err;



_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel

  reply	other threads:[~2026-11-11  9:42 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-08  7:53 [f2fs-dev] [PATCH] f2fs: require CAP_SYS_ADMIN for fallocate on pinned files Hungyu Lin
2026-11-08  7:53 ` Hungyu Lin
2026-11-11  9:42 ` Chao Yu [this message]
2026-11-11  9:42   ` [f2fs-dev] " Chao Yu via Linux-f2fs-devel

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=64dfd4fe-46eb-45b5-9eb1-ab0564bc2d47@kernel.org \
    --to=chao@kernel.org \
    --cc=dennylin0707@gmail.com \
    --cc=jaegeuk@kernel.org \
    --cc=linux-f2fs-devel@lists.sourceforge.net \
    --cc=linux-kernel@vger.kernel.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.