Re: [PATCH] mm/mempolicy: fix memory leak in weighted_interleave_auto_store()

[Joshua Hahn <joshua.hahnjy@gmail.com>]

On Tue, 31 Mar 2026 12:21:04 -0700 Joshua Hahn <joshua.hahnjy@gmail.com> wrote:

> On Tue, 31 Mar 2026 12:01:10 -0700 Andrew Morton <akpm@linux-foundation.org> wrote:
> 
> > On Tue, 31 Mar 2026 12:53:40 -0400 Gregory Price <gourry@gourry.net> wrote:
> > 
> > > On Tue, Mar 31, 2026 at 06:07:40PM +0800, Jackie Liu wrote:
> > > > From: Jackie Liu <liuyun01@kylinos.cn>
> > > > 
> > > > Add the missing kfree(new_wi_state) when the auto mode is already set
> > > > to the requested value. When a user writes "false" to the auto sysfs
> > > > interface and the current mode is already manual (mode_auto == false),
> > > > the function returns early without freeing new_wi_state allocated at
> > > > the beginning of the function. This can be triggered repeatedly from
> > > > userspace, leaking memory on each write.
> > > > 
> > > > Fixes: e341f9c3c841 ("mm/mempolicy: Weighted Interleave Auto-tuning")
> > > > Signed-off-by: Jackie Liu <liuyun01@kylinos.cn>
> > > 
> > > ..
> > >
> > > > --- a/mm/mempolicy.c
> > > > +++ b/mm/mempolicy.c
> > > > @@ -3713,6 +3713,7 @@ static ssize_t weighted_interleave_auto_store(struct kobject *kobj,
> > > >  			goto update_wi_state;
> > > >  		if (input == old_wi_state->mode_auto) {
> > > >  			mutex_unlock(&wi_state_lock);
> > > > +			kfree(new_wi_state);
> > > >  			return count;
> > > >  		}
> > > >  
> > 
> > Thanks all.
> > 
> > Am I correct in believing that triggering this leak requires elevated
> > privileges?
> 
> Hello Andrew, I hope you are doing well : -)
> 
> Yes indeed, writing to the file requires elevated privileges.
> 
> While going to check this out, however, I noticed a different bug which is
> that the file is no longer called "auto", but called "__auto_type".
> I suspected this was the result of a newly defined macro, and surely...
> commit 6cce897a37dc "compiler_types.h: add "auto" as a macro for "__auto_type""
> seems to have defined auto to always expand out to __auto_type.
> 
> Of course for using the __ATTR(name, permissions, show, store) macro this
> is bad because writing "auto" there no longer works...
> 
> I'll send up a quick fix to just manually write out the name instead.
> Doing a quick grep for the pattern thankfully seems to only point to this.
> I do think it is a bit weird to pass a raw, unquoted string into the macro...

(I just want to clarify that I am not suggesting that 6cce897a37dc was
incorrect. In hindsight, I should have been more wary about using a name
like "auto" when it is already a C keyword)