netdev - Re: [PATCH net] vxlan: fix memleak of fdb

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]

Message-ID: <2df4a274-c14e-d9fa-3053-a543feb07a4c@nvidia.com>
Date:   Sat, 1 Aug 2020 10:09:42 -0700
From:   Roopa Prabhu <roopa@...dia.com>
To:     Taehee Yoo <ap420073@...il.com>, <davem@...emloft.net>,
        <kuba@...nel.org>, <netdev@...r.kernel.org>
CC:     <roopa@...ulusnetworks.com>
Subject: Re: [PATCH net] vxlan: fix memleak of fdb


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@...il.com>
> ---

Acked-by: Roopa Prabhu <roopa@...ulusnetworks.com>


looks right, thanks