From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-172.mta0.migadu.com (out-172.mta0.migadu.com [91.218.175.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E56931A0BF3 for ; Sun, 12 Apr 2026 03:25:03 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=91.218.175.172 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775964306; cv=none; b=E2YssrWOINzLZRumnwBo9DT/fYIt6n+Htb0sFyyt3uf4DZe6+Ys7kjQ2CD7xk26cJan5+lN2pU17bfkl7LsREezjVXIRm/K4ZzDehCDw75MueGzMtKUlTO/oHN86YjRSJryencLgMRqCwCWL4ofb+WzWnW0HCQHxzYcuep8Qom8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775964306; c=relaxed/simple; bh=6DKS+kta3wZMzy28C00x/4732l2px1rBCzdvhowZKvA=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=mkt+w3hoal11Au7R/dGxmqQyIjk+77FktOPvsqR5nP6ZtRxq7js/dxdxAUqWHU/qtAncmq0cA4nAtFHADsR1eW2LQL/mY+iPgkfTCSUex7ogqjO/ssMGM2MsgrbcpZO6BRrU3o44WscXrey7TPAareg2HYHZ+3ejG7bIYfhHCKk= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b=ZgMuV62l; arc=none smtp.client-ip=91.218.175.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b="ZgMuV62l" Message-ID: <3e688ea1-05ba-4e75-9d92-2751ff6f3b7b@linux.dev> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1775964301; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=P7F6ExSq2zsiYKOQxY6wgG6WKAhk4DvCSTWfDleLB2Y=; b=ZgMuV62lY8nfvrhh5RSEipLHno6dZ7PcK6Aduun7TThkr7wr8/4Wo+FK+uadqLJmEPPwDm /jk/E3QAMoEs6mZc7ViZUSXUVArA6w3AtTPhcp13XBglkOqPtHd7/4exmgI3DE70o7tSXt ed14obd+deDrohCEwy/u61pg3hAPDNQ= Date: Sun, 12 Apr 2026 11:24:53 +0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Subject: Re: [PATCH] mm: thp: Fix refcount leak in thpsize_create() error path Content-Language: en-US To: Zi Yan Cc: lgs201920130244@gmail.com, akpm@linux-foundation.org, david@kernel.org, lorenzo.stoakes@oracle.com, baolin.wang@linux.alibaba.com, Liam.Howlett@oracle.com, npache@redhat.com, ryan.roberts@arm.com, dev.jain@arm.com, baohua@kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, stable@vger.kernel.org References: <20260411062152.2092967-1-lgs201920130244@gmail.com> <20260411142858.85496-1-lance.yang@linux.dev> <848180C7-F98C-44B2-AB1F-579BF9EEA28E@nvidia.com> X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Lance Yang In-Reply-To: <848180C7-F98C-44B2-AB1F-579BF9EEA28E@nvidia.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Migadu-Flow: FLOW_OUT 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.