Re: [PATCH] resource: use kstrdup_const to prevent wild pointer issues

[Andrew Morton]

On Thu, 02 Jan 2025 09:59:26 +0800 "Huang, Ying" <ying.huang@xxxxxxxxxxxxxxxxx> wrote:

> > From: King Dix <kingdix10@xxxxxx>
> >
> > When a stack string variable is passed during the request resource
> > operation, it causes an oops problem when executing cat /proc/iomem.
> >
> > In the original code, in functions like __request_region_locked, the name
> > member of the resource structure was directly assigned the stack string
> > pointer without proper memory management.
> >
> > This fix changes the assignment of res->name to use kstrdup_const for
> > string copying, ensuring the correct storage and release of the string
> > and thus avoiding potential memory errors and oops issues.
> >
> > Signed-off-by: King Dix <kingdix10@xxxxxx>
> 
> In general, I think that it's good to improve the resource requesting
> API.  However, it's not good to use so many GFP_ATOMIC too.  Why do you
> need to call resource requesting API with stack variable?  If it's just
> some programming bugs, we should add more checks instead of hiding the
> bugs.  For example, if we only allows kernel rodata and slab memory to be
> used in resource requesting.  We can add a VM_WARN_ON() to check that.

I agree.  It may not be a very good idea, but request_region() requires
that the caller pass in a `name' string which is permanently available.

__request_region() kerneldoc doesn't document this, and it should.

Because of this present interface design, calling request_region() with
an on-stack string must be considered a bug in the calling code.