In the Linux kernel, the following vulnerability has been resolved:<\/p>\n
vxlan: mdb: Fix use-after-free in vxlan_mdb_flush()<\/p>\n
vxlan_mdb_flush() iterates over the MDB entries using
\nhlist_for_each_entry_safe(), which only tolerates the removal of the
\ncurrent entry. Contrary to the comment above the loop, the removal of an
\nentry can trigger the removal of another entry.<\/p>\n
Flushing the remotes of a (*, G) entry also removes the (S, G) entries
\nthat were created for its source list, once they are left without
\nremotes:<\/p>\n
vxlan_mdb_remotes_flush()
\n-> vxlan_mdb_remote_del()
\n -> vxlan_mdb_remote_srcs_del()
\n -> vxlan_mdb_remote_src_del()
\n -> vxlan_mdb_remote_src_fwd_del()
\n -> __vxlan_mdb_del()
\n -> vxlan_mdb_entry_put()<\/p>\n
Such an entry can be located after the (*, G) entry in the list, as
\nvxlan_mdb_entry_get() returns an existing entry without moving it to the
\nhead of the list. This order is obtained by adding the (S, G) entry
\nbefore the (*, G) entry, the latter with NLM_F_REPLACE, as the addition
\nof the source otherwise fails with -EEXIST. The (S, G) entry is then the
\nentry saved by hlist_for_each_entry_safe() and it is freed while the
\n(*, G) entry is processed. The next iteration calls hlist_del() on it
\nagain, writing LIST_POISON1 to LIST_POISON2 [1].<\/p>\n
Besides device deletion, the flush is also reachable from RTM_DELMDB
\nwith NLM_F_BULK.<\/p>\n
Fix by re-reading the next entry after the remotes were flushed. The
\ncurrent entry cannot be removed by this flush, as source lists can only
\nbe configured on (*, G) entries and the removed entries are (S, G)
\nentries. It is therefore still linked and its next pointer reflects the
\nremovals.<\/p>\n
[1]
\nBUG: KASAN: wild-memory-access in vxlan_mdb_entry_put.part.0+0x328\/0x588
\nWrite of size 8 at addr dead000000000122 by task ip\/327<\/p>\n
CPU: 3 UID: 1000 PID: 327 Comm: ip Not tainted 7.2.0-rc7 #2 PREEMPT
\nCall trace:
\n vxlan_mdb_entry_put.part.0+0x328\/0x588
\n vxlan_mdb_flush+0x1d8\/0x25c
\n vxlan_mdb_fini+0x8c\/0x100
\n vxlan_uninit+0x1c\/0x7c
\n unregister_netdevice_many_notify+0x954\/0xd4c
\n rtnl_dellink+0x210\/0x530
\n rtnetlink_rcv_msg+0x434\/0x4d0
\n netlink_rcv_skb+0xc4\/0x204
\n rtnetlink_rcv+0x18\/0x24
\n netlink_unicast+0x4b8\/0x548
\n netlink_sendmsg+0x29c\/0x560
\n ____sys_sendmsg+0x390\/0x3ec
\n ___sys_sendmsg+0x114\/0x188
\n __sys_sendmsg+0xf0\/0x178
\n __arm64_sys_sendmsg+0x48\/0x60
\n invoke_syscall.constprop.0+0x58\/0x180
\n el0_svc_common.constprop.0+0x74\/0x140
\n do_el0_svc+0x30\/0x40
\n el0_svc+0x38\/0x98
\n el0t_64_sync_handler+0xa0\/0xe4
\n el0t_64_sync+0x198\/0x19c<\/p>\n","protected":false},"excerpt":{"rendered":"
In the Linux kernel, the following vulnerability has been resolved:<\/p>\n
vxlan: mdb: Fix use-after-free in vxlan_mdb_flush()<\/p>\n
vxlan_mdb_flush() iterates over the MDB entries using
\nhlist_for_each_entry_saf<\/p>\n","protected":false},"template":"","meta":[],"categories":[],"tags":[],"class_list":["post-28514","vuln","type-vuln","status-publish","hentry"],"_links":{"self":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/vuln\/28514","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/vuln"}],"about":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/types\/vuln"}],"wp:attachment":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=28514"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=28514"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=28514"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}