Re: [PATCH] mm: thp: Fix refcount leak in thpsize_create() error path
From: Lance Yang
Date: Sat Apr 11 2026 - 23:25:20 EST
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.