LKML Archive on
help / color / mirror / Atom feed
From: Dmitry Vyukov <>
To: Herbert Xu <>
Cc: Nikolay Aleksandrov <>,
	Thomas Graf <>,
	syzbot <>,,
	David Miller <>,
	LKML <>,
	netdev <>,
	Roopa Prabhu <>,
	syzkaller-bugs <>
Subject: Re: KASAN: use-after-free Read in br_mdb_ip_get
Date: Thu, 21 Feb 2019 11:54:42 +0100	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Wed, Feb 20, 2019 at 11:23 AM Herbert Xu <> wrote:
> On Mon, Jan 28, 2019 at 09:28:36AM +0100, Dmitry Vyukov wrote:
> >
> > > Weird, this is the kfree() on the error path of br_multicast_new_group()
> > > when rhashtable_lookup_insert_fast() fails, which means the entry should
> > > not be linked in the rhashtable or the hlist.
> > > All other frees are via kfree_rcu. I'll keep looking..
> >
> > Humm.... +rhashtable.c maintianers
> >
> > The code in br_multicast_new_group is effectively:
> >
> > mp = kzalloc(sizeof(*mp), GFP_ATOMIC);
> > err = rhashtable_lookup_insert_fast(&br->mdb_hash_tbl, &mp->rhnode,
> > br_mdb_rht_params);
> > if (err)
> >     kfree(mp);
> >
> > So it looks like rhashtable_lookup_insert_fast both returned an error
> > and left the new object linked in the table. Since it happened only
> > once, it may have something to do with concurrent resizing/shrinking.
> I've looked through the rhashtable code in question and everything
> looks OK.  So I suspect some earlier corruption has occured to cause
> this anomalous result.

Taking into account that this still happened only once, I tend to
write it off onto a previous silent memory corruption (we have dozens
of known bugs that corrupt memory). So if several people already
looked at it and don't see the root cause, it's probably time to stop
spending time on this until we have more info.

Although, there was also this one:
I have not checked if it can be the root cause of this report, but it
points suspiciously close to this stack and when I looked at it, it
the report looked legit.

> Is it possible to collect earlier alloc/free stack traces on the object in question?

You mean even before the alloc/free of the current incarnation this
object? This looks challenging from memory consumption point of view.
Also how many of them will we print in reports? Also the page can go
through page_alloc and then tracking will be even more challenging.
And in the end the object can be corrupted by an out-of-bounds write
or a like. Heap object reuse quarantine should take care of the common
case, and I don't see a reasonable way to handle all possible corner

  reply	other threads:[~2019-02-21 10:54 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-27 20:26 syzbot
2019-01-27 21:34 ` Nikolay Aleksandrov
2019-01-28  8:28   ` Dmitry Vyukov
2019-02-20 10:23     ` Herbert Xu
2019-02-21 10:54       ` Dmitry Vyukov [this message]
2019-05-29 14:58         ` Herbert Xu
2019-05-29 15:14           ` Dmitry Vyukov
2019-05-29 15:26             ` Herbert Xu
2019-05-31 11:31               ` Dmitry Vyukov

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:

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

  git send-email \ \ \ \ \ \ \ \ \ \ \ \ \
    --subject='Re: KASAN: use-after-free Read in br_mdb_ip_get' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).