From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 E1EF9172BCE for ; Tue, 15 Oct 2024 06:55:00 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1728975301; cv=none; b=C9jP/Qy0SxFijHuGRcWBhDQxJAN+LGhG8wT3MzK7q5iK9t1hwWApsBmIGE1JwSxsczETomLnlwYR3sZke2YCXPWFKcI0kJ54Etb8eAmIrtYCvu+d/tywuRm86D4/zvea5CbvR1ViFH0R0Pc6oZtHNaZcAVg142sGPQS0eWBHjAY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1728975301; c=relaxed/simple; bh=QBfRr33XPaqKkgF7ME2PD+/ZxPGLqwI2g+WHuNvDTMs=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=QGgL5LgvoaIAinCuzogNvW/P0rsyR8JHSFokQfTiU9vVNkTLmD15SbyDnBup5j+u0+6oH6riBdaw9HNjWKN5SsUokOp1rUpZC8rv49ZsgIKLoa8EHO1IT9iwil4+W85Waj44sy5PSpT7xxkLLYL7qETNO16rRa1qomwPEwEqYvE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b=SHqVTHaj; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b="SHqVTHaj" Received: by smtp.kernel.org (Postfix) with ESMTPSA id E26CDC4CECE; Tue, 15 Oct 2024 06:54:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1728975300; bh=QBfRr33XPaqKkgF7ME2PD+/ZxPGLqwI2g+WHuNvDTMs=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=SHqVTHajwpQjvTLtehNGRsmEHBLtLw3wkYhcIj3CNxeJbci+CcEgthqkZ5WmsPqGH jHOSQWzPhQV2usAyb5Rl2mhOOWnTYSWQJ1xeJM2+NJfIQZeAM2f0fKQ8+1n7yDGTaD md2w07n7k28TfmFh/KWj5qRZsJ3IyJQ3G+yt030w= Date: Tue, 15 Oct 2024 08:54:54 +0200 From: "gregkh@linuxfoundation.org" To: Ryder Wang Cc: Chenyuan Yang , "linux-mtd@lists.infradead.org" , "richard@nod.at" , "miquel.raynal@bootlin.com" , Zhihao Cheng , "vigneshr@ti.com" , "linux-kernel@vger.kernel.org" , "syzkaller@googlegroups.com" , Zijie Zhao , "rafael@kernel.org" , "akpm@linux-foundation.org" Subject: Re: [Linux Kernel Bug] memory leak in ubi_attach Message-ID: <2024101539-ravage-talon-d70c@gregkh> References: <10779b09-3413-6374-b4a1-1efd8821c5f2@huawei.com> <7138a98c-1562-3059-07b6-4d918bec9d1a@huawei.com> <0171b6cc-95ee-3538-913b-65a391a446b3@huawei.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: On Tue, Oct 15, 2024 at 03:41:24AM +0000, Ryder Wang wrote: > By walking through all the related code, it looks to be a bug in slub.c rather than kobject or ubifs. > > sysfs_slab_add() calls kobject_init_and_add(): > - If kobject_init_and_add fails, sysfs_slab_add() will go to *out*. But unluckily, *out* code block will never release s->kobj, but it is expected to do so. > > Below is the function comment of kobject_init_and_add(): > * If this function returns an error, kobject_put() must be called to properly clean up the memory associated with the object. * > ==> It means sysfs_slab_add() shall release the related kobject. Yup, that's a bug, please send a patch to fix this! thanks, greg k-h