netdev - Re: [PATCH net] net: neighbour: add neighbour dead check for neigh_timer

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]

Date:	Wed, 18 Dec 2013 15:27:15 +0100
From:	Hannes Frederic Sowa <hannes@...essinduktion.org>
To:	Ding Tianhong <dthxman@...il.com>
Cc:	Ding Tianhong <dingtianhong@...wei.com>,
	Eric Dumazet <eric.dumazet@...il.com>,
	David Miller <davem@...emloft.net>, yoshfuji@...ux-ipv6.org,
	joe@...ches.com, vfalico@...hat.com, netdev@...r.kernel.org
Subject: Re: [PATCH net] net: neighbour: add neighbour dead check for neigh_timer_handler()

On Wed, Dec 18, 2013 at 07:57:40PM +0800, Ding Tianhong wrote:
> yes, I cannot repruduce the bug again.

Hmm, it actually seems hard to hit even if the race happens. Even if slab
poisoning is active it would only hit if ->solicit would be called again,
because that is the only pointer dereference directly used in the old memory.

neigh_alloc allocates memory with kzalloc, so it would null out that memory,
so the race would not only have to race with kfree, the memory needs to be
reallocated in the mean time.

I would suggest adding some poisoning manually in neigh_release before kfree
and check for this in all periodic called functions. Maybe we can see it
again?

Greetings,

  Hannes

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html