Messages in this thread |  | | From | Zi Yan <> | | Subject | Re: [PATCH] mm: thp: Fix refcount leak in thpsize_create() error path | | Date | Sun, 12 Apr 2026 09:33:29 -0400 |
| |
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
|  |