Re: [PATCH 3/7] LSM: Two hooks for manipulating struct lsm_prop

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] security_secctx_to_lsmprop() fails to zero-initialize the output `struct lsm_prop` before invoking the LSM hooks, leading to uninitialized memory usage, kernel stack leaks, and memory exhaustion.
--

commit 13e7b169a884dc3bcbf465977a96e0509ce74a40
Author: Casey Schaufler <casey@schaufler-ca.com>

LSM: Two hooks for manipulating struct lsm_prop

This commit introduces security_update_lsmprop() to update a destination
LSM property from a source, and security_secctx_to_lsmprop() to set an
LSM property based on a security context. LSM specific implementations
will follow.

> diff --git a/security/security.c b/security/security.c
> index 71aea8fdf0142..1dec0037370ba 100644
> --- a/security/security.c
> +++ b/security/security.c
[ ... ]
> @@ -3982,6 +3989,31 @@ int security_secctx_to_secid(const char *secdata, u32 seclen, u32 *secid)
>  }
>  EXPORT_SYMBOL(security_secctx_to_secid);
>  
> +/**
> + * security_secctx_to_lsmprop() - Convert a secctx to a lsmprop
> + * @secdata: secctx
> + * @seclen: length of secctx
> + * @prop: prop
> + * @lsmid: which LSM the context is appropriate to.
> + *
> + * Convert security context to an lsmprop.
> + *
> + * Return: Returns 0 on success, error on failure.
> + */
> +int security_secctx_to_lsmprop(const char *secdata, u32 seclen,
> +			       struct lsm_prop *prop, int lsmid)
> +{
> +	struct lsm_static_call *scall;
> +
> +	lsm_for_each_hook(scall, secctx_to_lsmprop) {

[Severity: High]
Does this code leave prop partially uninitialized?

If callers allocate struct lsm_prop on the stack without zeroing it (such as
in nft_secmark_compute_secid or checkentry_lsm), failing to call
lsmprop_init(prop) here before invoking the LSM hooks might leave stack
garbage in untouched fields.

When a single LSM populates its specific field, the remainder of the struct
could retain this uninitialized data.

Later on, if the caller passes this struct to secxa_from_lsmprop(), the
memcmp used for deduplication will evaluate the entire struct. Because of the
stack garbage, identical security contexts could fail the memcmp check.

This could lead to uninitialized kernel stack data being copied into new heap
allocations in the xarray, and potentially cause unbounded memory consumption
since identical contexts wouldn't be deduplicated as expected.

Should lsmprop_init(prop) be called before iterating over the hooks?

> +		if (lsmid != LSM_ID_UNDEF && lsmid != scall->hl->lsmid->id)
> +			continue;
> +		return scall->hl->hook.secctx_to_lsmprop(secdata, seclen, prop);
> +	}
> +	return LSM_RET_DEFAULT(secctx_to_lsmprop);
> +}
> +EXPORT_SYMBOL(security_secctx_to_lsmprop);

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260831223748.4304-1-casey@schaufler-ca.com?part=3