All of lore.kernel.org
 help / color / mirror / Atom feed
From: "gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>
To: Ryder Wang <rydercoding@hotmail.com>
Cc: Chenyuan Yang <chenyuan0y@gmail.com>,
	"linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>,
	"richard@nod.at" <richard@nod.at>,
	"miquel.raynal@bootlin.com" <miquel.raynal@bootlin.com>,
	Zhihao Cheng <chengzhihao1@huawei.com>,
	"vigneshr@ti.com" <vigneshr@ti.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"syzkaller@googlegroups.com" <syzkaller@googlegroups.com>,
	Zijie Zhao <zzjas98@gmail.com>,
	"rafael@kernel.org" <rafael@kernel.org>,
	"akpm@linux-foundation.org" <akpm@linux-foundation.org>
Subject: Re: [Linux Kernel Bug] memory leak in ubi_attach
Date: Tue, 15 Oct 2024 08:54:54 +0200	[thread overview]
Message-ID: <2024101539-ravage-talon-d70c@gregkh> (raw)
In-Reply-To: <MEYP282MB31641A7FD666B1EA23C1C22FBF452@MEYP282MB3164.AUSP282.PROD.OUTLOOK.COM>

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

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

WARNING: multiple messages have this Message-ID (diff)
From: "gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>
To: Ryder Wang <rydercoding@hotmail.com>
Cc: Chenyuan Yang <chenyuan0y@gmail.com>,
	"linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>,
	"richard@nod.at" <richard@nod.at>,
	"miquel.raynal@bootlin.com" <miquel.raynal@bootlin.com>,
	Zhihao Cheng <chengzhihao1@huawei.com>,
	"vigneshr@ti.com" <vigneshr@ti.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"syzkaller@googlegroups.com" <syzkaller@googlegroups.com>,
	Zijie Zhao <zzjas98@gmail.com>,
	"rafael@kernel.org" <rafael@kernel.org>,
	"akpm@linux-foundation.org" <akpm@linux-foundation.org>
Subject: Re: [Linux Kernel Bug] memory leak in ubi_attach
Date: Tue, 15 Oct 2024 08:54:54 +0200	[thread overview]
Message-ID: <2024101539-ravage-talon-d70c@gregkh> (raw)
In-Reply-To: <MEYP282MB31641A7FD666B1EA23C1C22FBF452@MEYP282MB3164.AUSP282.PROD.OUTLOOK.COM>

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

  reply	other threads:[~2024-10-15  6:55 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-23  3:53 [Linux Kernel Bug] memory leak in ubi_attach Chenyuan Yang
2024-01-23  3:53 ` Chenyuan Yang
2024-01-23  4:55 ` Zhihao Cheng
2024-01-23  4:55   ` Zhihao Cheng
2024-01-23  4:57   ` Chenyuan Yang
2024-01-24 12:44     ` Zhihao Cheng
2024-01-24 12:44       ` Zhihao Cheng
2024-01-24 14:41       ` Chenyuan Yang
2024-01-24 14:41         ` Chenyuan Yang
2024-01-29 11:51         ` Zhihao Cheng
2024-01-29 11:51           ` Zhihao Cheng
2024-10-11  1:23           ` Chenyuan Yang
2024-10-11  1:23             ` Chenyuan Yang
2024-10-11  5:35             ` Greg KH
2024-10-11  5:35               ` Greg KH
2024-10-15  3:41             ` Ryder Wang
2024-10-15  3:41               ` Ryder Wang
2024-10-15  6:54               ` gregkh [this message]
2024-10-15  6:54                 ` gregkh
     [not found] <PH0PR11MB7496D8FBFAC72061A9C5F07CD1242@PH0PR11MB7496.namprd11.prod.outlook.com>
2024-11-15 14:11 ` syzbot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2024101539-ravage-talon-d70c@gregkh \
    --to=gregkh@linuxfoundation.org \
    --cc=akpm@linux-foundation.org \
    --cc=chengzhihao1@huawei.com \
    --cc=chenyuan0y@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=miquel.raynal@bootlin.com \
    --cc=rafael@kernel.org \
    --cc=richard@nod.at \
    --cc=rydercoding@hotmail.com \
    --cc=syzkaller@googlegroups.com \
    --cc=vigneshr@ti.com \
    --cc=zzjas98@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.