CVE-2021-47371

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