All of lore.kernel.org
 help / color / mirror / Atom feed
From: Matthew Wilcox <willy@infradead.org>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Wang Hai <wanghai38@huawei.com>,
	cl@linux.com, penberg@kernel.org, rientjes@google.com,
	iamjoonsoo.kim@lge.com, akpm@linux-foundation.org,
	khlebnikov@yandex-team.ru, linux-mm@kvack.org,
	linux-kernel@vger.kernel.org
Subject: Re: kobject_init_and_add is easy to misuse
Date: Tue, 2 Jun 2020 07:57:21 -0700	[thread overview]
Message-ID: <20200602145721.GM19604@bombadil.infradead.org> (raw)
In-Reply-To: <20200602140404.GA3280145@kroah.com>

On Tue, Jun 02, 2020 at 04:04:04PM +0200, Greg Kroah-Hartman wrote:
> On Tue, Jun 02, 2020 at 05:10:35AM -0700, Matthew Wilcox wrote:
> > On Tue, Jun 02, 2020 at 07:50:33PM +0800, Wang Hai wrote:
> > > syzkaller reports for memory leak when kobject_init_and_add()
> > > returns an error in the function sysfs_slab_add() [1]
> > > 
> > > When this happened, the function kobject_put() is not called for the
> > > corresponding kobject, which potentially leads to memory leak.
> > > 
> > > This patch fixes the issue by calling kobject_put() even if
> > > kobject_init_and_add() fails.
> > 
> > I think this speaks to a deeper problem with kobject_init_and_add()
> > -- the need to call kobject_put() if it fails is not readily apparent
> > to most users.  This same bug appears in the first three users of
> > kobject_init_and_add() that I checked --
> > arch/ia64/kernel/topology.c
> > drivers/firmware/dmi-sysfs.c
> > drivers/firmware/efi/esrt.c
> > drivers/scsi/iscsi_boot_sysfs.c
> > 
> > Some do get it right --
> > arch/powerpc/kernel/cacheinfo.c
> > drivers/gpu/drm/ttm/ttm_bo.c
> > drivers/gpu/drm/ttm/ttm_memory.c
> > drivers/infiniband/hw/mlx4/sysfs.c
> 
> Why are random individual drivers calling kobject* functions?  That
> speaks to a larger problem here...

There's around 120 callers in the kernel today ... large, indeed.

> Anyway, yes, it's a tricky function, but the issue usually is that the
> kobject is embedded in something else and if you call init_and_add() you
> want to tear things down _before_ the final put happens.
> 
> The good thing is, that function is really hard to get to fail except if
> you abuse it with syzkaller :)

Yes ;-)

> > I'd argue that the current behaviour is wrong, that kobject_init_and_add()
> > should call kobject_put() if the add fails.  This would need a tree-wide
> > audit.  But somebody needs to do that anyway because based on my random
> > sampling, half of the users currently get it wrong.
> 
> As said above, this is "tricky", and might break things.

My audit may not be correct then.  The kobject_put() may be appropriately
being called at a higher level rather than in the same function as the
kobject_init_and_add().

  reply	other threads:[~2020-06-02 14:57 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-02 11:50 [PATCH] mm/slub: fix a memory leak in sysfs_slab_add() Wang Hai
2020-06-02 12:10 ` kobject_init_and_add is easy to misuse Matthew Wilcox
2020-06-02 13:48   ` Konstantin Khlebnikov
2020-06-02 14:04   ` Greg Kroah-Hartman
2020-06-02 14:57     ` Matthew Wilcox [this message]
2020-06-02 15:25   ` James Bottomley
2020-06-02 15:25     ` James Bottomley
2020-06-02 17:36     ` Greg Kroah-Hartman
2020-06-02 19:54       ` James Bottomley
2020-06-02 19:54         ` James Bottomley
2020-06-02 20:07         ` Greg Kroah-Hartman
2020-06-02 21:51           ` James Bottomley
2020-06-02 21:51             ` James Bottomley
2020-06-03  0:04             ` James Bottomley
2020-06-03  0:04               ` James Bottomley
2020-06-03  0:22             ` Jason Gunthorpe
2020-06-03 18:04               ` James Bottomley
2020-06-03 18:04                 ` James Bottomley
2020-06-03 18:36                 ` Jason Gunthorpe
2020-06-03 19:02                   ` James Bottomley
2020-06-03 19:02                     ` James Bottomley
2020-06-03 19:30                     ` Jason Gunthorpe
2020-06-03 20:56                       ` James Bottomley
2020-06-03 20:56                         ` James Bottomley
2020-06-04  0:23                         ` Jason Gunthorpe
2020-06-02 19:46   ` Jason Gunthorpe

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=20200602145721.GM19604@bombadil.infradead.org \
    --to=willy@infradead.org \
    --cc=akpm@linux-foundation.org \
    --cc=cl@linux.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=iamjoonsoo.kim@lge.com \
    --cc=khlebnikov@yandex-team.ru \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=penberg@kernel.org \
    --cc=rientjes@google.com \
    --cc=wanghai38@huawei.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.