| Message ID | 20200801070750.7993-1-ap420073@gmail.com |
|---|---|
| State | Accepted |
| Delegated to: | David Miller |
| Headers | show |
| Series | [net] vxlan: fix memleak of fdb | expand |
On 8/1/20 12:07 AM, Taehee Yoo wrote: > External email: Use caution opening links or attachments > > > When vxlan interface is deleted, all fdbs are deleted by vxlan_flush(). > vxlan_flush() flushes fdbs but it doesn't delete fdb, which contains > all-zeros-mac because it is deleted by vxlan_uninit(). > But vxlan_uninit() deletes only the fdb, which contains both all-zeros-mac > and default vni. > So, the fdb, which contains both all-zeros-mac and non-default vni > will not be deleted. > > Test commands: > ip link add vxlan0 type vxlan dstport 4789 external > ip link set vxlan0 up > bridge fdb add to 00:00:00:00:00:00 dst 172.0.0.1 dev vxlan0 via lo \ > src_vni 10000 self permanent > ip link del vxlan0 > > kmemleak reports as follows: > unreferenced object 0xffff9486b25ced88 (size 96): > comm "bridge", pid 2151, jiffies 4294701712 (age 35506.901s) > hex dump (first 32 bytes): > 02 00 00 00 ac 00 00 01 40 00 09 b1 86 94 ff ff ........@....... > 46 02 00 00 00 00 00 00 a7 03 00 00 12 b5 6a 6b F.............jk > backtrace: > [<00000000c10cf651>] vxlan_fdb_append.part.51+0x3c/0xf0 [vxlan] > [<000000006b31a8d9>] vxlan_fdb_create+0x184/0x1a0 [vxlan] > [<0000000049399045>] vxlan_fdb_update+0x12f/0x220 [vxlan] > [<0000000090b1ef00>] vxlan_fdb_add+0x12a/0x1b0 [vxlan] > [<0000000056633c2c>] rtnl_fdb_add+0x187/0x270 > [<00000000dd5dfb6b>] rtnetlink_rcv_msg+0x264/0x490 > [<00000000fc44dd54>] netlink_rcv_skb+0x4a/0x110 > [<00000000dff433e7>] netlink_unicast+0x18e/0x250 > [<00000000b87fb421>] netlink_sendmsg+0x2e9/0x400 > [<000000002ed55153>] ____sys_sendmsg+0x237/0x260 > [<00000000faa51c66>] ___sys_sendmsg+0x88/0xd0 > [<000000006c3982f1>] __sys_sendmsg+0x4e/0x80 > [<00000000a8f875d2>] do_syscall_64+0x56/0xe0 > [<000000003610eefa>] entry_SYSCALL_64_after_hwframe+0x44/0xa9 > unreferenced object 0xffff9486b1c40080 (size 128): > comm "bridge", pid 2157, jiffies 4294701754 (age 35506.866s) > hex dump (first 32 bytes): > 00 00 00 00 00 00 00 00 f8 dc 42 b2 86 94 ff ff ..........B..... > 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk > backtrace: > [<00000000a2981b60>] vxlan_fdb_create+0x67/0x1a0 [vxlan] > [<0000000049399045>] vxlan_fdb_update+0x12f/0x220 [vxlan] > [<0000000090b1ef00>] vxlan_fdb_add+0x12a/0x1b0 [vxlan] > [<0000000056633c2c>] rtnl_fdb_add+0x187/0x270 > [<00000000dd5dfb6b>] rtnetlink_rcv_msg+0x264/0x490 > [<00000000fc44dd54>] netlink_rcv_skb+0x4a/0x110 > [<00000000dff433e7>] netlink_unicast+0x18e/0x250 > [<00000000b87fb421>] netlink_sendmsg+0x2e9/0x400 > [<000000002ed55153>] ____sys_sendmsg+0x237/0x260 > [<00000000faa51c66>] ___sys_sendmsg+0x88/0xd0 > [<000000006c3982f1>] __sys_sendmsg+0x4e/0x80 > [<00000000a8f875d2>] do_syscall_64+0x56/0xe0 > [<000000003610eefa>] entry_SYSCALL_64_after_hwframe+0x44/0xa9 > > Fixes: 3ad7a4b141eb ("vxlan: support fdb and learning in COLLECT_METADATA mode") > Signed-off-by: Taehee Yoo <ap420073@gmail.com> > --- Acked-by: Roopa Prabhu <roopa@cumulusnetworks.com> looks right, thanks
From: Taehee Yoo <ap420073@gmail.com> Date: Sat, 1 Aug 2020 07:07:50 +0000 > When vxlan interface is deleted, all fdbs are deleted by vxlan_flush(). > vxlan_flush() flushes fdbs but it doesn't delete fdb, which contains > all-zeros-mac because it is deleted by vxlan_uninit(). > But vxlan_uninit() deletes only the fdb, which contains both all-zeros-mac > and default vni. > So, the fdb, which contains both all-zeros-mac and non-default vni > will not be deleted. > > Test commands: > ip link add vxlan0 type vxlan dstport 4789 external > ip link set vxlan0 up > bridge fdb add to 00:00:00:00:00:00 dst 172.0.0.1 dev vxlan0 via lo \ > src_vni 10000 self permanent > ip link del vxlan0 > > kmemleak reports as follows: ... > Fixes: 3ad7a4b141eb ("vxlan: support fdb and learning in COLLECT_METADATA mode") > Signed-off-by: Taehee Yoo <ap420073@gmail.com> Applied and queued up for -stable, thank you.
diff --git a/drivers/net/vxlan.c b/drivers/net/vxlan.c index 5efe1e28f270..a7c3939264b0 100644 --- a/drivers/net/vxlan.c +++ b/drivers/net/vxlan.c @@ -3076,8 +3076,10 @@ static void vxlan_flush(struct vxlan_dev *vxlan, bool do_all) if (!do_all && (f->state & (NUD_PERMANENT | NUD_NOARP))) continue; /* the all_zeros_mac entry is deleted at vxlan_uninit */ - if (!is_zero_ether_addr(f->eth_addr)) - vxlan_fdb_destroy(vxlan, f, true, true); + if (is_zero_ether_addr(f->eth_addr) && + f->vni == vxlan->cfg.vni) + continue; + vxlan_fdb_destroy(vxlan, f, true, true); } spin_unlock_bh(&vxlan->hash_lock[h]); }
When vxlan interface is deleted, all fdbs are deleted by vxlan_flush(). vxlan_flush() flushes fdbs but it doesn't delete fdb, which contains all-zeros-mac because it is deleted by vxlan_uninit(). But vxlan_uninit() deletes only the fdb, which contains both all-zeros-mac and default vni. So, the fdb, which contains both all-zeros-mac and non-default vni will not be deleted. Test commands: ip link add vxlan0 type vxlan dstport 4789 external ip link set vxlan0 up bridge fdb add to 00:00:00:00:00:00 dst 172.0.0.1 dev vxlan0 via lo \ src_vni 10000 self permanent ip link del vxlan0 kmemleak reports as follows: unreferenced object 0xffff9486b25ced88 (size 96): comm "bridge", pid 2151, jiffies 4294701712 (age 35506.901s) hex dump (first 32 bytes): 02 00 00 00 ac 00 00 01 40 00 09 b1 86 94 ff ff ........@....... 46 02 00 00 00 00 00 00 a7 03 00 00 12 b5 6a 6b F.............jk backtrace: [<00000000c10cf651>] vxlan_fdb_append.part.51+0x3c/0xf0 [vxlan] [<000000006b31a8d9>] vxlan_fdb_create+0x184/0x1a0 [vxlan] [<0000000049399045>] vxlan_fdb_update+0x12f/0x220 [vxlan] [<0000000090b1ef00>] vxlan_fdb_add+0x12a/0x1b0 [vxlan] [<0000000056633c2c>] rtnl_fdb_add+0x187/0x270 [<00000000dd5dfb6b>] rtnetlink_rcv_msg+0x264/0x490 [<00000000fc44dd54>] netlink_rcv_skb+0x4a/0x110 [<00000000dff433e7>] netlink_unicast+0x18e/0x250 [<00000000b87fb421>] netlink_sendmsg+0x2e9/0x400 [<000000002ed55153>] ____sys_sendmsg+0x237/0x260 [<00000000faa51c66>] ___sys_sendmsg+0x88/0xd0 [<000000006c3982f1>] __sys_sendmsg+0x4e/0x80 [<00000000a8f875d2>] do_syscall_64+0x56/0xe0 [<000000003610eefa>] entry_SYSCALL_64_after_hwframe+0x44/0xa9 unreferenced object 0xffff9486b1c40080 (size 128): comm "bridge", pid 2157, jiffies 4294701754 (age 35506.866s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 f8 dc 42 b2 86 94 ff ff ..........B..... 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk backtrace: [<00000000a2981b60>] vxlan_fdb_create+0x67/0x1a0 [vxlan] [<0000000049399045>] vxlan_fdb_update+0x12f/0x220 [vxlan] [<0000000090b1ef00>] vxlan_fdb_add+0x12a/0x1b0 [vxlan] [<0000000056633c2c>] rtnl_fdb_add+0x187/0x270 [<00000000dd5dfb6b>] rtnetlink_rcv_msg+0x264/0x490 [<00000000fc44dd54>] netlink_rcv_skb+0x4a/0x110 [<00000000dff433e7>] netlink_unicast+0x18e/0x250 [<00000000b87fb421>] netlink_sendmsg+0x2e9/0x400 [<000000002ed55153>] ____sys_sendmsg+0x237/0x260 [<00000000faa51c66>] ___sys_sendmsg+0x88/0xd0 [<000000006c3982f1>] __sys_sendmsg+0x4e/0x80 [<00000000a8f875d2>] do_syscall_64+0x56/0xe0 [<000000003610eefa>] entry_SYSCALL_64_after_hwframe+0x44/0xa9 Fixes: 3ad7a4b141eb ("vxlan: support fdb and learning in COLLECT_METADATA mode") Signed-off-by: Taehee Yoo <ap420073@gmail.com> --- drivers/net/vxlan.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)