netdev - Re: A regression introduced by 802.1ad support patches

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20130421093436.GA26775@macbook.localnet>
Date:	Sun, 21 Apr 2013 11:34:40 +0200
From:	Patrick McHardy <kaber@...sh.net>
To:	Cong Wang <amwang@...hat.com>
Cc:	netdev@...r.kernel.org, "David S. Miller" <davem@...emloft.net>
Subject: Re: A regression introduced by 802.1ad support patches

On Sun, Apr 21, 2013 at 03:43:04PM +0800, Cong Wang wrote:
> Hi, Patrick,
> 
> Your recent 802.1ad patches causes the following bug. After resetting
> HEAD to commit c296289 (Merge branch 'intel'), this bug is not
> reproducible any more.
> 
> It is pretty easy to reproduce in my KVM guest, just boot the guest and
> then shut it down, the following traces will be shown. Although it is
> not 100% reproducible, it appears more than 80% times at least.
> 
> I am glad to provide any other information if you need, and of course
> can test any fix if you want.
> 
> [   86.812073] kmemleak: Found object by alias at 0xffff88006ecc76f0
> [   86.816019] Pid: 739, comm: kworker/u:1 Not tainted 3.9.0-rc5+ #842
> [   86.816019] Call Trace:
> [   86.816019]  <IRQ>  [<ffffffff81151c58>] find_and_get_object
> +0x8c/0xdf
> [   86.816019]  [<ffffffff8190e90d>] ? vlan_info_rcu_free+0x33/0x49
> [   86.816019]  [<ffffffff81151cbe>] delete_object_full+0x13/0x2f
> [   86.816019]  [<ffffffff8194bbb6>] kmemleak_free+0x26/0x45
> [   86.816019]  [<ffffffff8113e8c7>] slab_free_hook+0x1e/0x7b
> [   86.816019]  [<ffffffff81141c05>] kfree+0xce/0x14b
> [   86.816019]  [<ffffffff8190e90d>] vlan_info_rcu_free+0x33/0x49
> [   86.816019]  [<ffffffff810d0b0b>] rcu_do_batch+0x261/0x4e7

Thanks. I think the attached patch should fix it.

View attachment "vlan-leak.diff" of type "text/plain" (1784 bytes)