netdev - spurious ip forwarding inside namespaces

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-next>] [day] [month] [year] [list]

Date:	Tue, 5 Nov 2013 22:32:16 -0800
From:	Alexei Starovoitov <ast@...mgrid.com>
To:	Isaku Yamahata <yamahata@...inux.co.jp>,
	Nicolas Dichtel <nicolas.dichtel@...nd.com>
Cc:	"David S. Miller" <davem@...emloft.net>, netdev@...r.kernel.org
Subject: spurious ip forwarding inside namespaces

Hi All,

commit 06a23fe31c
"core/dev: set pkt_type after eth_type_trans() in dev_forward_skb()"
and refactoring 64261f230a
"dev: move skb_scrub_packet() after eth_type_trans()"

are forcing pkt_type to be PACKET_HOST when skb traverses veth.

which means that ip forwarding will kick in inside netns
even if skb->eth->h_dest != dev->dev_addr

The way we hit the problem is the following:
create 4 or more of netns with veth and attach them to a bridge.
disable learning on a bridge (via setageing 0), so it will flood
packets to all namespaces.
Since ip forwarding and icmp redirect by default is on,
single icmp request packet from one netns creates a storm of packets,
since every netns receives it and incorrectly does ip forward on it
and also incorrectly sends icmp redirect which are multiplied once
again by flooding in the bridge.
ping -c1 generates 1 outgoing packet and ~13K incoming packets with
just 4 netns.
Running any tcp traffic between such namespaces becomes impossible
and ksoftirqd cpu usage goes to 100% on all cpus.

Please suggest how to fix this cleanly.

Thanks
Alexei
--
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