Re: [PATCH 2/3] security: Expand task_setscheduler LSM hook to include CPU affinity mask

On Sat, May 09, 2026 at 06:04:17PM +0000, [email protected] wrote:
> > diff --git a/arch/mips/kernel/mips-mt-fpaff.c b/arch/mips/kernel/mips-mt-fpaff.c
> > index 10172fc4f627b..a6a61393fc1a6 100644
> > --- a/arch/mips/kernel/mips-mt-fpaff.c
> > +++ b/arch/mips/kernel/mips-mt-fpaff.c
> [ ... ]
> > @@ -108,7 +108,7 @@ asmlinkage long mipsmt_sys_sched_setaffinity(pid_t pid, unsigned int len,
> >  		goto out_unlock;
> >  	}
> >  
> > -	retval = security_task_setscheduler(p);
> > +	retval = security_task_setscheduler(p, new_mask);
> 
> Does this pass uninitialized memory to the BPF LSM when CONFIG_CPUMASK_OFFSTACK
> is enabled?
> 
> In the existing code, copy_from_user() overwrites the pointer, and then
> alloc_cpumask_var() allocates new memory without zeroing it. Passing
> new_mask to the hook here exposes that uninitialized heap memory to
> the security modules.
> 
> I see this underlying memory corruption issue is fixed later in the series
> by commit 15fc15a070c4388ae44399001bd1e9ad8ec7a7be, but does passing it
> here introduce an intermediate information leak?

Yes. The next iteration will include a suitable prerequisite solution.
Patch 3 will contain the actual fix.

> > diff --git a/kernel/cgroup/cpuset.c b/kernel/cgroup/cpuset.c
> > index ecd8d45a0dd21..233430d94dfd3 100644
> > --- a/kernel/cgroup/cpuset.c
> > +++ b/kernel/cgroup/cpuset.c
> [ ... ]
> > @@ -3587,7 +3587,7 @@ static int cpuset_can_fork(struct task_struct *task, struct css_set *cset)
> >  	if (ret)
> >  		goto out_unlock;
> >  
> > -	ret = security_task_setscheduler(task);
> > +	ret = security_task_setscheduler(task, NULL);
> 
> Should this pass cs->effective_cpus instead of NULL?

Acknowledged. Indeed this should be cs->effective_cpus.


Kind regards,
-- 
Aaron Tomlin