Re: [PATCH stable/linux-5.10.y 2/7] fs: move kmem_cache_zalloc() into alloc_empty_file*() helpers

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] API trap leading to cross-allocator slab corruption when handling errors in `init_file()`.
--

commit 4291ff6cf97e536c82d7fa5b99705d5c988c0fac
Author: Amir Goldstein <amir73il@gmail.com>

fs: move kmem_cache_zalloc() into alloc_empty_file*() helpers

Use a common helper init_file() instead of __alloc_file() for
alloc_empty_file*() helpers and improrve the documentation.

This is needed for a follow up patch that allocates a backing_file
container.

> diff --git a/fs/file_table.c b/fs/file_table.c
> index 7a3b4a7f68086..be24d724b4075 100644
> --- a/fs/file_table.c
> +++ b/fs/file_table.c
> @@ -93,20 +93,15 @@ int proc_nr_files(struct ctl_table *table, int write,
[ ... ]
> -static struct file *__alloc_file(int flags, const struct cred *cred)
> +static int init_file(struct file *f, int flags, const struct cred *cred)
>  {
> -	struct file *f;
>  	int error;
>  
> -	f = kmem_cache_zalloc(filp_cachep, GFP_KERNEL);
> -	if (unlikely(!f))
> -		return ERR_PTR(-ENOMEM);
> -
>  	f->f_cred = get_cred(cred);
>  	error = security_file_alloc(f);
>  	if (unlikely(error)) {
>  		file_free_rcu(&f->f_u.fu_rcuhead);
> -		return ERR_PTR(error);
> +		return error;
>  	}

[Severity: High]
If a follow-up patch allocates a struct backing_file container using kzalloc()
and passes its file field to init_file(), could this error path lead to
cross-allocator slab corruption?

Because file_free_rcu() checks f->f_mode & FMODE_BACKING to decide whether to
use kfree() or kmem_cache_free(filp_cachep, ...), it seems FMODE_BACKING would
need to be set before calling init_file() to ensure safe cleanup if
security_file_alloc() fails.

>  
>  	atomic_long_set(&f->f_count, 1);
>  	rwlock_init(&f->f_owner.lock);
>  	spin_lock_init(&f->f_lock);
>  	mutex_init(&f->f_pos_lock);
>  	eventpoll_init_file(f);
>  	f->f_flags = flags;
>  	f->f_mode = OPEN_FMODE(flags);

[Severity: High]
However, since init_file() unconditionally overwrites f->f_mode here, the
caller cannot safely set FMODE_BACKING beforehand without it being
overwritten upon success.

Could this lead to kzalloc allocated memory being incorrectly freed to
filp_cachep if security_file_alloc() encounters an error (e.g., under
memory pressure or LSM denial)?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260629070653.580879-1-caixinchen1@huawei.com?part=2