netdev - Fw: [Bug 106711] New: VXLAN: RTNL assertion failed at net/core/net

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>] [day] [month] [year] [list]
Date:	Wed, 28 Oct 2015 06:57:51 +0900
From:	Stephen Hemminger <stephen@...workplumber.org>
To:	netdev@...r.kernel.org
Subject: Fw: [Bug 106711] New: VXLAN: RTNL assertion failed at
 net/core/net_namespace.c:187



Begin forwarded message:

Date: Tue, 27 Oct 2015 14:05:08 +0000
From: "bugzilla-daemon@...zilla.kernel.org" <bugzilla-daemon@...zilla.kernel.org>
To: "shemminger@...ux-foundation.org" <shemminger@...ux-foundation.org>
Subject: [Bug 106711] New: VXLAN: RTNL assertion failed at net/core/net_namespace.c:187


https://bugzilla.kernel.org/show_bug.cgi?id=106711

            Bug ID: 106711
           Summary: VXLAN: RTNL assertion failed at
                    net/core/net_namespace.c:187
           Product: Networking
           Version: 2.5
    Kernel Version: 4.1.10
          Hardware: All
                OS: Linux
              Tree: Mainline
            Status: NEW
          Severity: normal
          Priority: P1
         Component: IPV4
          Assignee: shemminger@...ux-foundation.org
          Reporter: tuomo.turunen@...ia.com
        Regression: No

VXLAN packet receiving triggers ASSERT_RTNL() assertion failure if VXLAN
transport interface is in different network namespace than the VXLAN interface
itself:

[   38.891092] RTNL: assertion failed at
/build/distro/work/shared/linux-stable-30bb3a6af25f17c356252ac6cfbfd3ec04ae1a56/net/core/net_namespace.c
(187)
[   38.892738] CPU: 0 PID: 3 Comm: ksoftirqd/0 Not tainted
4.1.10-pc64-distro.git-v1.14 #1
[   38.893720] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
1.7.5-20140531_083030-gandalf 04/01/2014
[   38.894933]  ffff8800ba372280 ffff88013ab3f808 ffffffff8078a62a
ffff88013fc110f8
[   38.896059]  00000000ffffffff ffff88013ab3f838 ffffffff8068b7b5
ffff88013a7a3600
[   38.897172]  ffff8800bbbc2c00 ffff8801381262a0 ffff880138126300
ffff88013ab3f848
[   38.898354] Call Trace:
[   38.898763]  [<ffffffff8078a62a>] dump_stack+0x45/0x57
[   38.899436]  [<ffffffff8068b7b5>] __peernet2id+0xa5/0xb0
[   38.900099]  [<ffffffff8068b7d8>] peernet2id+0x18/0x30
[   38.900756]  [<ffffffffa003a2ba>] vxlan_fdb_info+0xfa/0x360 [vxlan]
[   38.901526]  [<ffffffff80682e57>] ? __alloc_skb+0x97/0x1e0
[   38.902216]  [<ffffffffa003a592>] vxlan_fdb_notify+0x72/0x100 [vxlan]
[   38.902994]  [<ffffffffa003b426>] vxlan_fdb_create+0x136/0x370 [vxlan]
[   38.903797]  [<ffffffffa003bf95>] vxlan_snoop+0x1c5/0x1d0 [vxlan]
[   38.904551]  [<ffffffffa003deba>] vxlan_rcv+0x35a/0x5c0 [vxlan]
[   38.905393]  [<ffffffff8069d48f>] ? dst_alloc+0x4f/0x180
[   38.906165]  [<ffffffffa003c208>] vxlan_udp_encap_recv+0x108/0x390 [vxlan]
[   38.907111]  [<ffffffffa003c100>] ? vxlan_encap_bypass.isra.37+0x160/0x160
[vxlan]
[   38.908278]  [<ffffffff806ff81b>] udp_queue_rcv_skb+0x35b/0x450
[   38.909119]  [<ffffffff806fff26>] __udp4_lib_rcv+0x126/0x750
[   38.909915]  [<ffffffff80700a7a>] udp_rcv+0x1a/0x20
[   38.910640]  [<ffffffff806ce5ae>] ip_local_deliver_finish+0xae/0x230
[   38.911529]  [<ffffffff806ce91a>] ip_local_deliver+0x9a/0xb0
[   38.912341]  [<ffffffff806ce218>] ip_rcv_finish+0x88/0x370
[   38.913277]  [<ffffffff806cec0f>] ip_rcv+0x2df/0x3c0
[   38.914000]  [<ffffffff80289343>] ? load_balance+0x233/0xa20
[   38.914807]  [<ffffffff80694b93>] __netif_receive_skb_core+0x6e3/0xa20
[   38.915714]  [<ffffffff8027661c>] ? update_rq_clock.part.81+0x1c/0x40
[   38.916613]  [<ffffffff80694eed>] __netif_receive_skb+0x1d/0x70
[   38.917461]  [<ffffffff80695d42>] process_backlog+0xc2/0x170
[   38.918291]  [<ffffffff806954ba>] net_rx_action+0x20a/0x340
[   38.919123]  [<ffffffff8025702f>] __do_softirq+0xef/0x320
[   38.919959]  [<ffffffff80257285>] run_ksoftirqd+0x25/0x60
[   38.920764]  [<ffffffff80273ecf>] smpboot_thread_fn+0x12f/0x190
[   38.921605]  [<ffffffff80273da0>] ? sort_range+0x30/0x30
[   38.922384]  [<ffffffff80270bb9>] kthread+0xc9/0xe0
[   38.923104]  [<ffffffff80270af0>] ? kthread_create_on_node+0x180/0x180
[   38.923994]  [<ffffffff80790e02>] ret_from_fork+0x42/0x70
[   38.924772]  [<ffffffff80270af0>] ? kthread_create_on_node+0x180/0x180


Seems to me that peernet2id() function should not be called while receiving
packets or then peernet2id() function should not use rtnl lock.

The issue can be reproduced with following configuration + ping (one host is
enough, real network is not needed):

ip netns add ns0
ip netns exec ns0 ip link set lo up
ip netns add ns1
ip netns exec ns1 ip link set lo up
ip netns add ns2
ip netns exec ns2 ip link set lo up
ip netns add ns3
ip netns exec ns3 ip link set lo up
ip link add type veth
ip link set veth0 netns ns0
ip netns exec ns0 ip link set veth0 up
ip netns exec ns0 ip addr add 10.0.0.1/24 dev veth0
ip link set veth1 netns ns1
ip netns exec ns1 ip link set veth1 up
ip netns exec ns1 ip addr add 10.0.0.2/24 dev veth1
ip netns exec ns0 ip link add name vxlan0 type vxlan id 1000 group 224.0.0.1
local 10.0.0.1 dev veth0 learning
ip netns exec ns0 ip link set vxlan0 netns ns2
ip netns exec ns2 ip link set vxlan0 up
ip netns exec ns2 ip addr add 20.0.0.1/24 dev vxlan0
ip netns exec ns1 ip link add name vxlan1 type vxlan id 1000 group 224.0.0.1
local 10.0.0.2 dev veth1 learning
ip netns exec ns1 ip link set vxlan1 netns ns3
ip netns exec ns3 ip link set vxlan1 up
ip netns exec ns3 ip addr add 20.0.0.2/24 dev vxlan1
ip netns exec ns2 ping 20.0.0.1

-- 
You are receiving this mail because:
You are the assignee for the bug.
--
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