fkie_cve-2021-47371
Vulnerability from fkie_nvd
Published
2024-05-21 15:15
Modified
2025-04-02 14:53
Severity ?
Summary
In the Linux kernel, the following vulnerability has been resolved:
nexthop: Fix memory leaks in nexthop notification chain listeners
syzkaller discovered memory leaks [1] that can be reduced to the
following commands:
# ip nexthop add id 1 blackhole
# devlink dev reload pci/0000:06:00.0
As part of the reload flow, mlxsw will unregister its netdevs and then
unregister from the nexthop notification chain. Before unregistering
from the notification chain, mlxsw will receive delete notifications for
nexthop objects using netdevs registered by mlxsw or their uppers. mlxsw
will not receive notifications for nexthops using netdevs that are not
dismantled as part of the reload flow. For example, the blackhole
nexthop above that internally uses the loopback netdev as its nexthop
device.
One way to fix this problem is to have listeners flush their nexthop
tables after unregistering from the notification chain. This is
error-prone as evident by this patch and also not symmetric with the
registration path where a listener receives a dump of all the existing
nexthops.
Therefore, fix this problem by replaying delete notifications for the
listener being unregistered. This is symmetric to the registration path
and also consistent with the netdev notification chain.
The above means that unregister_nexthop_notifier(), like
register_nexthop_notifier(), will have to take RTNL in order to iterate
over the existing nexthops and that any callers of the function cannot
hold RTNL. This is true for mlxsw and netdevsim, but not for the VXLAN
driver. To avoid a deadlock, change the latter to unregister its nexthop
listener without holding RTNL, making it symmetric to the registration
path.
[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---
References
Impacted products
Vendor | Product | Version | |
---|---|---|---|
linux | linux_kernel | * | |
linux | linux_kernel | 5.15 | |
linux | linux_kernel | 5.15 |
{ "configurations": [ { "nodes": [ { "cpeMatch": [ { "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "matchCriteriaId": "1B31D6C1-A751-438D-906B-0C56B789D498", "versionEndExcluding": "5.14.9", "versionStartIncluding": "5.11", "vulnerable": true }, { "criteria": "cpe:2.3:o:linux:linux_kernel:5.15:rc1:*:*:*:*:*:*", "matchCriteriaId": "E46C74C6-B76B-4C94-A6A4-FD2FFF62D644", "vulnerable": true }, { "criteria": "cpe:2.3:o:linux:linux_kernel:5.15:rc2:*:*:*:*:*:*", "matchCriteriaId": "60134C3A-06E4-48C1-B04F-2903732A4E56", "vulnerable": true } ], "negate": false, "operator": "OR" } ] } ], "cveTags": [], "descriptions": [ { "lang": "en", "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nnexthop: Fix memory leaks in nexthop notification chain listeners\n\nsyzkaller discovered memory leaks [1] that can be reduced to the\nfollowing commands:\n\n # ip nexthop add id 1 blackhole\n # devlink dev reload pci/0000:06:00.0\n\nAs part of the reload flow, mlxsw will unregister its netdevs and then\nunregister from the nexthop notification chain. Before unregistering\nfrom the notification chain, mlxsw will receive delete notifications for\nnexthop objects using netdevs registered by mlxsw or their uppers. mlxsw\nwill not receive notifications for nexthops using netdevs that are not\ndismantled as part of the reload flow. For example, the blackhole\nnexthop above that internally uses the loopback netdev as its nexthop\ndevice.\n\nOne way to fix this problem is to have listeners flush their nexthop\ntables after unregistering from the notification chain. This is\nerror-prone as evident by this patch and also not symmetric with the\nregistration path where a listener receives a dump of all the existing\nnexthops.\n\nTherefore, fix this problem by replaying delete notifications for the\nlistener being unregistered. This is symmetric to the registration path\nand also consistent with the netdev notification chain.\n\nThe above means that unregister_nexthop_notifier(), like\nregister_nexthop_notifier(), will have to take RTNL in order to iterate\nover the existing nexthops and that any callers of the function cannot\nhold RTNL. This is true for mlxsw and netdevsim, but not for the VXLAN\ndriver. To avoid a deadlock, change the latter to unregister its nexthop\nlistener without holding RTNL, making it symmetric to the registration\npath.\n\n[1]\nunreferenced object 0xffff88806173d600 (size 512):\n comm \"syz-executor.0\", pid 1290, jiffies 4295583142 (age 143.507s)\n hex dump (first 32 bytes):\n 41 9d 1e 60 80 88 ff ff 08 d6 73 61 80 88 ff ff A..`......sa....\n 08 d6 73 61 80 88 ff ff 01 00 00 00 00 00 00 00 ..sa............\n backtrace:\n [\u003cffffffff81a6b576\u003e] kmemleak_alloc_recursive include/linux/kmemleak.h:43 [inline]\n [\u003cffffffff81a6b576\u003e] slab_post_alloc_hook+0x96/0x490 mm/slab.h:522\n [\u003cffffffff81a716d3\u003e] slab_alloc_node mm/slub.c:3206 [inline]\n [\u003cffffffff81a716d3\u003e] slab_alloc mm/slub.c:3214 [inline]\n [\u003cffffffff81a716d3\u003e] kmem_cache_alloc_trace+0x163/0x370 mm/slub.c:3231\n [\u003cffffffff82e8681a\u003e] kmalloc include/linux/slab.h:591 [inline]\n [\u003cffffffff82e8681a\u003e] kzalloc include/linux/slab.h:721 [inline]\n [\u003cffffffff82e8681a\u003e] mlxsw_sp_nexthop_obj_group_create drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c:4918 [inline]\n [\u003cffffffff82e8681a\u003e] mlxsw_sp_nexthop_obj_new drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c:5054 [inline]\n [\u003cffffffff82e8681a\u003e] mlxsw_sp_nexthop_obj_event+0x59a/0x2910 drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c:5239\n [\u003cffffffff813ef67d\u003e] notifier_call_chain+0xbd/0x210 kernel/notifier.c:83\n [\u003cffffffff813f0662\u003e] blocking_notifier_call_chain kernel/notifier.c:318 [inline]\n [\u003cffffffff813f0662\u003e] blocking_notifier_call_chain+0x72/0xa0 kernel/notifier.c:306\n [\u003cffffffff8384b9c6\u003e] call_nexthop_notifiers+0x156/0x310 net/ipv4/nexthop.c:244\n [\u003cffffffff83852bd8\u003e] insert_nexthop net/ipv4/nexthop.c:2336 [inline]\n [\u003cffffffff83852bd8\u003e] nexthop_add net/ipv4/nexthop.c:2644 [inline]\n [\u003cffffffff83852bd8\u003e] rtm_new_nexthop+0x14e8/0x4d10 net/ipv4/nexthop.c:2913\n [\u003cffffffff833e9a78\u003e] rtnetlink_rcv_msg+0x448/0xbf0 net/core/rtnetlink.c:5572\n [\u003cffffffff83608703\u003e] netlink_rcv_skb+0x173/0x480 net/netlink/af_netlink.c:2504\n [\u003cffffffff833de032\u003e] rtnetlink_rcv+0x22/0x30 net/core/rtnetlink.c:5590\n [\u003cffffffff836069de\u003e] netlink_unicast_kernel net/netlink/af_netlink.c:1314 [inline]\n [\u003cffffffff836069de\u003e] netlink_unicast+0x5ae/0x7f0 net/netlink/af_netlink.c:1340\n [\u003cffffffff83607501\u003e] netlink_sendmsg+0x8e1/0xe30 net/netlink/af_netlink.c:1929\n [\u003cffffffff832fde84\u003e] sock_sendmsg_nosec net/socket.c:704 [inline\n---truncated---" }, { "lang": "es", "value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nexthop: corrige p\u00e9rdidas de memoria en los oyentes de la cadena de notificaciones de nexthop syzkaller descubri\u00f3 p\u00e9rdidas de memoria [1] que se pueden reducir a los siguientes comandos: # ip nexthop add id 1 blackhole # devlink dev reload pci /0000:06:00.0 Como parte del flujo de recarga, mlxsw cancelar\u00e1 el registro de sus netdevs y luego cancelar\u00e1 el registro de la cadena de notificaci\u00f3n de nexthop. Antes de cancelar el registro de la cadena de notificaciones, mlxsw recibir\u00e1 notificaciones de eliminaci\u00f3n de objetos de nexthop utilizando netdevs registrados por mlxsw o sus superiores. mlxsw no recibir\u00e1 notificaciones de nexthops que utilicen netdevs que no est\u00e9n desmantelados como parte del flujo de recarga. Por ejemplo, el blackhole nexthop anterior que utiliza internamente el loopback netdev como su dispositivo nexthop. Una forma de solucionar este problema es hacer que los oyentes vac\u00eden sus tablas de nexthop despu\u00e9s de darse de baja de la cadena de notificaciones. Esto es propenso a errores, como lo demuestra este parche, y tampoco es sim\u00e9trico con la ruta de registro donde un oyente recibe un volcado de todos los nexthops existentes. Por lo tanto, solucione este problema reproduciendo las notificaciones de eliminaci\u00f3n del oyente que se est\u00e1 cancelando el registro. Esto es sim\u00e9trico a la ruta de registro y tambi\u00e9n consistente con la cadena de notificaci\u00f3n de netdev. Lo anterior significa que unregister_nexthop_notifier(), al igual que Register_nexthop_notifier(), tendr\u00e1 que tomar RTNL para poder iterar sobre los nexthops existentes y que cualquier persona que llame a la funci\u00f3n no puede mantener RTNL. Esto es cierto para mlxsw y netdevsim, pero no para el controlador VXLAN. Para evitar un punto muerto, cambie este \u00faltimo para cancelar el registro de su oyente nexthop sin mantener presionado RTNL, haci\u00e9ndolo sim\u00e9trico a la ruta de registro. [1] objeto sin referencia 0xffff88806173d600 (tama\u00f1o 512): comm \"syz-executor.0\", pid 1290, jiffies 4295583142 (edad 143.507s) volcado hexadecimal (primeros 32 bytes): 41 9d 1e 60 80 88 ff ff 08 d6 73 1 80 88 ff ff A..`......sa.... 08 d6 73 61 80 88 ff ff 01 00 00 00 00 00 00 00 ..sa............ backtrace: [] kmemleak_alloc_recursive include/linux/kmemleak.h:43 [en l\u00ednea] [] slab_post_alloc_hook+0x96/0x490 mm/slab.h:522 [] mm/slub.c:3206 [en l\u00ednea] [] slab_alloc mm/slub.c:3214 [en l\u00ednea] [] kmem_cache_alloc_trace+0x163/0x370 mm/slub.c:3231 [] kmalloc include/linux/slab.h: 591 [en l\u00ednea] [] kzalloc include/linux/slab.h:721 [en l\u00ednea] [] mlxsw_sp_nexthop_obj_group_create drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c:4918 [ ] mlxsw_sp_nexthop_obj_new drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c:5054 [en l\u00ednea] [] mlxsw_sp_nexthop_obj_event+0x59a/0x2910 drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c:523 9 [] notifier_call_chain+0xbd/0x210 kernel/notifier.c:83 [] blocking_notifier_call_chain kernel/notifier.c:318 [en l\u00ednea] [] blocking_notifier_call_chain+0x72/0xa0 kernel/notifier.c:306 [] call_nexthop_notifiers+0x156/0x310 net/ipv4/nexthop.c:244 [] insert_nexthop net/ipv4/nexthop.c:2336 [en l\u00ednea] [] nexthop_add net/ipv4/nexthop.c:2644 [en l\u00ednea] [] rtm_new_nexthop+0x14e8/0x4d10 net/ipv4/nexthop.c:2913 [] rtnetlink_rcv_msg+0x448/0xbf0 net/core/rtnetlink.c:5572 [ ] netlink_rcv_skb+0x173/0x480 neto/ netlink/af_netlink.c: 2504 [] rtnetlink_rcv+0x22/0x30 net/core/rtnetlink.c: 5590 [] netlink_unicast_kernel net/netlink/af_fffffff.c: 1314 [faff. 6069de\u0026gt;] netlink_unicast +0x5ae/0x7f0 net/netlink/af_netlink.c:1340 [] --- truncado--" } ], "id": "CVE-2021-47371", "lastModified": "2025-04-02T14:53:12.310", "metrics": { "cvssMetricV31": [ { "cvssData": { "attackComplexity": "LOW", "attackVector": "LOCAL", "availabilityImpact": "HIGH", "baseScore": 7.1, "baseSeverity": "HIGH", "confidentialityImpact": "NONE", "integrityImpact": "HIGH", "privilegesRequired": "LOW", "scope": "UNCHANGED", "userInteraction": "NONE", "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H", "version": "3.1" }, "exploitabilityScore": 1.8, "impactScore": 5.2, "source": "134c704f-9b21-4f2e-91b3-4a467353bcc0", "type": "Secondary" } ] }, "published": "2024-05-21T15:15:23.000", "references": [ { "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "tags": [ "Patch" ], "url": "https://git.kernel.org/stable/c/3106a0847525befe3e22fc723909d1b21eb0d520" }, { "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "tags": [ "Patch" ], "url": "https://git.kernel.org/stable/c/741760fa6252628a3d3afad439b72437d4b123d9" }, { "source": "af854a3a-2127-422b-91ae-364da2661108", "tags": [ "Patch" ], "url": "https://git.kernel.org/stable/c/3106a0847525befe3e22fc723909d1b21eb0d520" }, { "source": "af854a3a-2127-422b-91ae-364da2661108", "tags": [ "Patch" ], "url": "https://git.kernel.org/stable/c/741760fa6252628a3d3afad439b72437d4b123d9" } ], "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "vulnStatus": "Analyzed", "weaknesses": [ { "description": [ { "lang": "en", "value": "CWE-400" } ], "source": "134c704f-9b21-4f2e-91b3-4a467353bcc0", "type": "Secondary" } ] }
Loading…
Loading…
Sightings
Author | Source | Type | Date |
---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or seen somewhere by the user.
- Confirmed: The vulnerability is confirmed from an analyst perspective.
- Exploited: This vulnerability was exploited and seen by the user reporting the sighting.
- Patched: This vulnerability was successfully patched by the user reporting the sighting.
- Not exploited: This vulnerability was not exploited or seen by the user reporting the sighting.
- Not confirmed: The user expresses doubt about the veracity of the vulnerability.
- Not patched: This vulnerability was not successfully patched by the user reporting the sighting.
Loading…
Loading…