In the Linux kernel, the following vulnerability has been resolved:nexthop: Fix memory leaks in nexthop notification chain listenerssyzkaller discovered memory leaks [1] that can be reduced to thefollowing commands: # ip nexthop add id 1 blackhole # devlink dev reload pci/0000:06:00.0As part of the reload flow, mlxsw will unregister its netdevs and thenunregister from the nexthop notification chain. Before unregisteringfrom the notification chain, mlxsw will receive delete notifications fornexthop objects using netdevs registered by mlxsw or their uppers. mlxswwill not receive notifications for nexthops using netdevs that are notdismantled as part of the reload flow. For example, the blackholenexthop above that internally uses the loopback netdev as its nexthopdevice.One way to fix this problem is to have listeners flush their nexthoptables after unregistering from the notification chain. This iserror-prone as evident by this patch and also not symmetric with theregistration path where a listener receives a dump of all the existingnexthops.Therefore, fix this problem by replaying delete notifications for thelistener being unregistered. This is symmetric to the registration pathand also consistent with the netdev notification chain.The above means that unregister_nexthop_notifier(), likeregister_nexthop_notifier(), will have to take RTNL in order to iterateover the existing nexthops and that any callers of the function cannothold RTNL. This is true for mlxsw and netdevsim, but not for the VXLANdriver. To avoid a deadlock, change the latter to unregister its nexthoplistener without holding RTNL, making it symmetric to the registrationpath.[1]unreferenced object 0xffff88806173d600 (size 512):  comm "syz-executor.0", pid 1290, jiffies 4295583142 (age 143.507s)  hex dump (first 32 bytes):    41 9d 1e 60 80 88 ff ff 08 d6 73 61 80 88 ff ff  A..`......sa....    08 d6 73 61 80 88 ff ff 01 00 00 00 00 00 00 00  ..sa............  backtrace:    [<ffffffff81a6b576>] kmemleak_alloc_recursive include/linux/kmemleak.h:43 [inline]    [<ffffffff81a6b576>] slab_post_alloc_hook+0x96/0x490 mm/slab.h:522    [<ffffffff81a716d3>] slab_alloc_node mm/slub.c:3206 [inline]    [<ffffffff81a716d3>] slab_alloc mm/slub.c:3214 [inline]    [<ffffffff81a716d3>] kmem_cache_alloc_trace+0x163/0x370 mm/slub.c:3231    [<ffffffff82e8681a>] kmalloc include/linux/slab.h:591 [inline]    [<ffffffff82e8681a>] kzalloc include/linux/slab.h:721 [inline]    [<ffffffff82e8681a>] mlxsw_sp_nexthop_obj_group_create drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c:4918 [inline]    [<ffffffff82e8681a>] mlxsw_sp_nexthop_obj_new drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c:5054 [inline]    [<ffffffff82e8681a>] mlxsw_sp_nexthop_obj_event+0x59a/0x2910 drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c:5239    [<ffffffff813ef67d>] notifier_call_chain+0xbd/0x210 kernel/notifier.c:83    [<ffffffff813f0662>] blocking_notifier_call_chain kernel/notifier.c:318 [inline]    [<ffffffff813f0662>] blocking_notifier_call_chain+0x72/0xa0 kernel/notifier.c:306    [<ffffffff8384b9c6>] call_nexthop_notifiers+0x156/0x310 net/ipv4/nexthop.c:244    [<ffffffff83852bd8>] insert_nexthop net/ipv4/nexthop.c:2336 [inline]    [<ffffffff83852bd8>] nexthop_add net/ipv4/nexthop.c:2644 [inline]    [<ffffffff83852bd8>] rtm_new_nexthop+0x14e8/0x4d10 net/ipv4/nexthop.c:2913    [<ffffffff833e9a78>] rtnetlink_rcv_msg+0x448/0xbf0 net/core/rtnetlink.c:5572    [<ffffffff83608703>] netlink_rcv_skb+0x173/0x480 net/netlink/af_netlink.c:2504    [<ffffffff833de032>] rtnetlink_rcv+0x22/0x30 net/core/rtnetlink.c:5590    [<ffffffff836069de>] netlink_unicast_kernel net/netlink/af_netlink.c:1314 [inline]    [<ffffffff836069de>] netlink_unicast+0x5ae/0x7f0 net/netlink/af_netlink.c:1340    [<ffffffff83607501>] netlink_sendmsg+0x8e1/0xe30 net/netlink/af_netlink.c:1929    [<ffffffff832fde84>] sock_sendmsg_nosec net/socket.c:704 [inline---truncated---
Weakness: CWE-400 Uncontrolled Resource Consumption