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
| ||
|
Date: Wed, 04 Aug 2010 18:30:58 +0200 From: Patrick McHardy <kaber@...sh.net> To: Herbert Xu <herbert@...dor.apana.org.au> CC: Stephen Hemminger <shemminger@...tta.com>, netdev@...r.kernel.org Subject: Re: Yet another bridge netfilter crash Am 23.07.2010 17:26, schrieb Herbert Xu: > On Fri, Jul 23, 2010 at 05:17:42PM +0200, Patrick McHardy wrote: >> >>> There's also the matter of fragments jumping between bridges. >> >> Conntrack zones can be used to avoid that, but that currently needs >> manual configuration. > > I think this is something that we need to fix. Because as it > stands, it can still crash if you get the wrong nf_bridge. > > The reason is that skb->dev does not hold a ref count. So the > reassembly code just throws it away and always uses the dev of > the last fragment. > > This breaks when two bridges combine to reassemble a single > packet, as the nf_bridge attribute of the reassembled packet > may come from an skb whose device is now dead. This is then > used to fill in the skb->dev (via nf_bridge->physindev). We could perform a new device lookup on reassembly as we do when expiring a fragment queue, but we probably shouldn't even be reassembling fragments from different bridges. One way to avoid this would be to automatically assign each bridge device to a different conntrack zone, but conntrack zones are limited to 2^16 and this might also have other unwanted side-effects. Until we come up with something better the best fix seems to be to perform the device lookup based on the iif. -- 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
Powered by blists - more mailing lists