lkml.org 
[lkml]   [2026]   [Apr]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCH] mm: thp: Fix refcount leak in thpsize_create() error path
Date
On 11 Apr 2026, at 23:24, Lance Yang wrote:

> On 2026/4/12 09:49, Zi Yan wrote:
>> On 11 Apr 2026, at 10:28, Lance Yang wrote:
>>
>>> On Sat, Apr 11, 2026 at 02:21:52PM +0800, Guangshuo Li wrote:
>>>> After kobject_init_and_add(), the lifetime of the embedded struct
>>>> kobject is expected to be managed through the kobject core reference
>>>> counting.
>>>>
>>>> In thpsize_create(), if kobject_init_and_add() fails, thpsize is freed
>>>> directly with kfree() rather than releasing the kobject reference with
>>>> kobject_put(). This may leave the reference count of the embedded struct
>>>
>>> Right. As documented for kobject_init_and_add(), once it has been
>>> called, the error path should go through kobject_put():
>>>
>>> /**
>>> * kobject_init_and_add() - Initialize a kobject structure and add it to
>>> * the kobject hierarchy.
>>> ...
>>> *
>>> * This function combines the call to kobject_init() and kobject_add().
>>> *
>>> * If this function returns an error, kobject_put() must be called to
>>> * properly clean up the memory associated with the object. This is the
>>> ...
>>> */
>>> int kobject_init_and_add(struct kobject *kobj, const struct kobj_type *ktype,
>>> struct kobject *parent, const char *fmt, ...)
>>>
>>>> kobject unbalanced, resulting in a refcount leak and potentially leading
>>>> to a use-after-free.
>>>
>>> IIUC, this looks more like wrong kobject lifetime handling and likely a
>>> leak, not a clear UAF :)
>>
>> kobject_put() ends up with calling kobj_type->release(), which is just
>> kfree(to_thpsize(kobj)), equivalent to kfree(thpsize) in the old code.
>> IIUC, there is no leak. Let me know if I miss anything.
>
> Right, the fix is correct. I was only commenting on the changelog
> wording, especially:
>
> "resulting in a refcount leak and potentially leading to a use-after-free"
>
> The old code does skip the required kobject cleanup path, but is
> a UAF actually possible there?

That is my question too. The original code might not cause any real issue.

Guangshuo, let us know if we get it wrong. Thanks.

>
> Just a wording nit.


--
Best Regards,
Yan, Zi

\
 
 \ /
  Last update: 2026-04-12 15:34    [W:0.077 / U:7.972 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and my Meterkast|Read the blog