Re: [PATCH] mm: thp: Fix refcount leak in thpsize_create() error path

[Lance Yang <lance.yang@linux.dev>]

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?

Just a wording nit.