CVE-2022-50220
Vulnérabilité non évaluée dans Linux (Linux)
Description
In the Linux kernel, the following vulnerability has been resolved: usbnet: Fix linkwatch use-after-free on disconnect usbnet uses the work usbnet_deferred_kevent() to perform tasks which may sleep. On disconnect, completion of the work was originally awaited in ->ndo_stop(). But in 2003, that was moved to ->disconnect() by historic commit "[PATCH] USB: usbnet, prevent exotic rtnl deadlock": https://git.kernel.org/tglx/history/c/0f138bbfd83c The change was made because back then, the kernel's workqueue implementation did not allow waiting for a single work. One had to wait for completion of *all* work by calling flush_scheduled_work(), and that could deadlock when waiting for usbnet_deferred_kevent() with rtnl_mutex held in ->ndo_stop(). The commit solved one problem but created another: It causes a use-after-free in USB Ethernet drivers aqc111.c, asix_devices.c, ax88179_178a.c, ch9200.c and smsc75xx.c: * If the drivers receive a link change interrupt immediately before disconnect, they raise EVENT_LINK_RESET in their (non-sleepable) ->status() callback and schedule usbnet_deferred_kevent(). * usbnet_deferred_kevent() invokes the driver's ->link_reset() callback, which calls netif_carrier_{on,off}(). * That in turn schedules the work linkwatch_event(). Because usbnet_deferred_kevent() is awaited after unregister_netdev(), netif_carrier_{on,off}() may operate on an unregistered netdev and linkwatch_event() may run after free_netdev(), causing a use-after-free. In 2010, usbnet was changed to only wait for a single instance of usbnet_deferred_kevent() instead of *all* work by commit 23f333a2bfaf ("drivers/net: don't use flush_scheduled_work()"). Unfortunately the commit neglected to move the wait back to ->ndo_stop(). Rectify that omission at long last.
Gravité et risque d'exploitation
CVE-2022-50220 obtient un score CVSS de 0.0/10, soit une gravité non évaluée. Selon le modèle EPSS, la probabilité qu'elle soit exploitée dans les 30 prochains jours est de 0.24 %, ce qui la place devant 14.2 % des CVE référencées.
Que faire ?
- Vérifiez si Linux (versions <a69e617e533edddf3fa3123149900f36e0a6dc74, 0, <2.6.38, 4.14.291, 5.19.2, <d49bb8cf9bfaa06aa527eb30f1a52a071da2e32f, <7f77dcbc030c2faa6d8e8a594985eeb34018409e, <135199a2edd459d2b123144efcd7f9bcd95128e4, <=4.9.*, <=5.10.*, <=4.14.*, 6.0, 5.10.137, <635fd8953e4309b54ca6a81bed1d4a87668694f4, 5.4.211, 2.6.38, <e2a521a7dcc463c5017b4426ca0804e151faeff7, <=5.18.*, <=5.4.*, <=4.19.*, 5.15.61, 4.19.256, <d2d6b530d89b0a912148018027386aa049f0a309, 5.18.18, <db3b738ae5f726204876f4303c49cfdf4311403f, <=*, <=5.15.*, 4.9.326, <=5.19.*, 23f333a2bfafba80339315b724808982a9de57d9, <8b4588b8b00b299be16a35be67b331d8fdba03f3) est présent sur votre parc.
- Appliquez le correctif ou la version corrigée indiqués dans les références de l'éditeur.
- À défaut de correctif, limitez l'exposition (filtrage réseau, désactivation du composant).
- Automatisez la détection : les agents CVE Heimdall (gratuits, open source) corrèlent l'inventaire de vos serveurs avec la base CVE.
Références
- https://git.kernel.org/stable/c/d2d6b530d89b0a912148018027386aa049f0a309
- https://git.kernel.org/stable/c/e2a521a7dcc463c5017b4426ca0804e151faeff7
- https://git.kernel.org/stable/c/7f77dcbc030c2faa6d8e8a594985eeb34018409e
- https://git.kernel.org/stable/c/8b4588b8b00b299be16a35be67b331d8fdba03f3
- https://git.kernel.org/stable/c/135199a2edd459d2b123144efcd7f9bcd95128e4
- https://git.kernel.org/stable/c/635fd8953e4309b54ca6a81bed1d4a87668694f4
- https://git.kernel.org/stable/c/d49bb8cf9bfaa06aa527eb30f1a52a071da2e32f
- https://git.kernel.org/stable/c/db3b738ae5f726204876f4303c49cfdf4311403f
- https://git.kernel.org/stable/c/a69e617e533edddf3fa3123149900f36e0a6dc74
