CVSS: 5.5EPSS: 0%CPEs: 5EXPL: 0CVE-2024-27393 – xen-netfront: Add missing skb_mark_for_recycle
https://notcve.org/view.php?id=CVE-2024-27393
In the Linux kernel, the following vulnerability has been resolved: xen-netfront: Add missing skb_mark_for_recycle Notice that skb_mark_for_recycle() is introduced later than fixes tag in commit 6a5bcd84e886 ("page_pool: Allow drivers to hint on SKB recycling"). It is believed that fixes tag were missing a call to page_pool_release_page() between v5.9 to v5.14, after which is should have used skb_mark_for_recycle(). Since v6.6 the call page_pool_release_page() were removed (in commit 535b9c61bdef ("net: page_pool: hide page_pool_release_page()") and remaining callers converted (in commit 6bfef2ec0172 ("Merge branch 'net-page_pool-remove-page_pool_release_page'")). This leak became visible in v6.8 via commit dba1b8a7ab68 ("mm/page_pool: catch page_pool memory leaks"). En el kernel de Linux, se resolvió la siguiente vulnerabilidad: xen-netfront: agrega skb_mark_for_recycle faltante. Tenga en cuenta que skb_mark_for_recycle() se introduce más tarde que la etiqueta de corrección en el commit 6a5bcd84e886 ("page_pool: permitir que los controladores indiquen el reciclaje de SKB"). Se cree que a la etiqueta de correcciones le faltaba una llamada a page_pool_release_page() entre v5.9 y v5.14, después de lo cual debería haber usado skb_mark_for_recycle(). Desde v6.6, la llamada page_pool_release_page() se eliminó (en el commit 535b9c61bdef ("net: page_pool: hide page_pool_release_page()") y las personas que llaman restantes se convirtieron (en el commit 6bfef2ec0172 ("Merge Branch 'net-page_pool-remove-page_pool_release_page'") ). • https://git.kernel.org/stable/c/6c5aa6fc4defc2a0977a2c59e4710d50fa1e834c https://git.kernel.org/stable/c/4143b9479caa29bb2380f3620dcbe16ea84eb3b1 https://git.kernel.org/stable/c/7c1250796b6c262b505a46192f4716b8c6a6a8c6 https://git.kernel.org/stable/c/27aa3e4b3088426b7e34584274ad45b5afaf7629 https://git.kernel.org/stable/c/c8b7b2f158d9d4fb89cd2f68244af154f7549bb4 https://git.kernel.org/stable/c/037965402a010898d34f4e35327d22c0a95cd51f http://www.openwall.com/lists/oss-security/2024/05/08/4 http://xenbits.xen.org/xsa/advisory-457.html https:& •
CVSS: -EPSS: 0%CPEs: 8EXPL: 1CVE-2023-52654 – io_uring/af_unix: disable sending io_uring over sockets
https://notcve.org/view.php?id=CVE-2023-52654
In the Linux kernel, the following vulnerability has been resolved: io_uring/af_unix: disable sending io_uring over sockets File reference cycles have caused lots of problems for io_uring in the past, and it still doesn't work exactly right and races with unix_stream_read_generic(). The safest fix would be to completely disallow sending io_uring files via sockets via SCM_RIGHT, so there are no possible cycles invloving registered files and thus rendering SCM accounting on the io_uring side unnecessary. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: io_uring/af_unix: deshabilita el envío de io_uring a través de sockets Los ciclos de referencia de archivos han causado muchos problemas para io_uring en el pasado, y todavía no funciona exactamente correctamente y corre con unix_stream_read_generic(). La solución más segura sería no permitir por completo el envío de archivos io_uring a través de sockets a través de SCM_RIGHT, de modo que no haya ciclos posibles que involucren archivos registrados y, por lo tanto, hagan innecesaria la contabilidad SCM en el lado io_uring. • https://github.com/FoxyProxys/CVE-2023-52654 https://git.kernel.org/stable/c/04df9719df1865f6770af9bc7880874af0e594b2 https://git.kernel.org/stable/c/c378c479c5175833bb22ff71974cda47d7b05401 https://git.kernel.org/stable/c/813d8fe5d30388f73a21d3a2bf46b0a1fd72498c https://git.kernel.org/stable/c/0091bfc81741b8d3aeb3b7ab8636f911b2de6e80 https://git.kernel.org/stable/c/b4293c01ee0d0ecdd3cb5801e13f62271144667a https://git.kernel.org/stable/c/75e94c7e8859e58aadc15a98cc9704edff47d4f2 https://git.kernel.org/stable/c/18824f592aad4124d79751bbc1500ea86ac3ff29 https:/& •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2024-27391 – wifi: wilc1000: do not realloc workqueue everytime an interface is added
https://notcve.org/view.php?id=CVE-2024-27391
In the Linux kernel, the following vulnerability has been resolved: wifi: wilc1000: do not realloc workqueue everytime an interface is added Commit 09ed8bfc5215 ("wilc1000: Rename workqueue from "WILC_wq" to "NETDEV-wq"") moved workqueue creation in wilc_netdev_ifc_init in order to set the interface name in the workqueue name. However, while the driver needs only one workqueue, the wilc_netdev_ifc_init is called each time we add an interface over a phy, which in turns overwrite the workqueue with a new one. This can be observed with the following commands: for i in $(seq 0 10) do iw phy phy0 interface add wlan1 type managed iw dev wlan1 del done ps -eo pid,comm|grep wlan 39 kworker/R-wlan0 98 kworker/R-wlan1 102 kworker/R-wlan1 105 kworker/R-wlan1 108 kworker/R-wlan1 111 kworker/R-wlan1 114 kworker/R-wlan1 117 kworker/R-wlan1 120 kworker/R-wlan1 123 kworker/R-wlan1 126 kworker/R-wlan1 129 kworker/R-wlan1 Fix this leakage by putting back hif_workqueue allocation in wilc_cfg80211_init. Regarding the workqueue name, it is indeed relevant to set it lowercase, however it is not attached to a specific netdev, so enforcing netdev name in the name is not so relevant. Still, enrich the name with the wiphy name to make it clear which phy is using the workqueue. • https://git.kernel.org/stable/c/09ed8bfc5215ad5aac91c50008277b5586b9ef24 https://git.kernel.org/stable/c/515cc676dfbce40d93c92b1ff3c1070e917f4e52 https://git.kernel.org/stable/c/4041c60a9d543b3ad50225385b072ba68e96166e https://git.kernel.org/stable/c/90ae293d1d255f622318fce6eeea2e18f9fde5c1 https://git.kernel.org/stable/c/9ab0c303ccabfd6bdce14432792d41090070008c https://git.kernel.org/stable/c/328efda22af81130c2ad981c110518cb29ff2f1d •
CVSS: -EPSS: 0%CPEs: 6EXPL: 0CVE-2024-27390 – ipv6: mcast: remove one synchronize_net() barrier in ipv6_mc_down()
https://notcve.org/view.php?id=CVE-2024-27390
In the Linux kernel, the following vulnerability has been resolved: ipv6: mcast: remove one synchronize_net() barrier in ipv6_mc_down() As discussed in the past (commit 2d3916f31891 ("ipv6: fix skb drops in igmp6_event_query() and igmp6_event_report()")) I think the synchronize_net() call in ipv6_mc_down() is not needed. Under load, synchronize_net() can last between 200 usec and 5 ms. KASAN seems to agree as well. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: ipv6: mcast: elimina una barrera de sincronización_net() en ipv6_mc_down() Como se discutió en el pasado (commit 2d3916f31891 ("ipv6: corrige caídas de skb en igmp6_event_query() e igmp6_event_report()" )) Creo que la llamada sincronizar_net() en ipv6_mc_down() no es necesaria. Bajo carga, sincronizar_net() puede durar entre 200 usos y 5 ms. KASAN parece estar de acuerdo también. • https://git.kernel.org/stable/c/f185de28d9ae6c978135993769352e523ee8df06 https://git.kernel.org/stable/c/9d159d6637ccce25f879d662a480541ef4ba3a50 https://git.kernel.org/stable/c/a03ede2282ebbd181bd6f5c38cbfcb5765afcd04 https://git.kernel.org/stable/c/26d4bac55750d535f1f0b8790dc26daf6089e373 https://git.kernel.org/stable/c/7eb06ee5921189812e6b4bfe7b0f1e878be16df7 https://git.kernel.org/stable/c/5da9a218340a2bc804dc4327e5804392e24a0b88 https://git.kernel.org/stable/c/17ef8efc00b34918b966388b2af0993811895a8c •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2024-27389 – pstore: inode: Only d_invalidate() is needed
https://notcve.org/view.php?id=CVE-2024-27389
In the Linux kernel, the following vulnerability has been resolved: pstore: inode: Only d_invalidate() is needed Unloading a modular pstore backend with records in pstorefs would trigger the dput() double-drop warning: WARNING: CPU: 0 PID: 2569 at fs/dcache.c:762 dput.part.0+0x3f3/0x410 Using the combo of d_drop()/dput() (as mentioned in Documentation/filesystems/vfs.rst) isn't the right approach here, and leads to the reference counting problem seen above. Use d_invalidate() and update the code to not bother checking for error codes that can never happen. --- En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: pstore: inode: solo se necesita d_invalidate(). La descarga de un backend modular de pstore con registros en pstorefs activaría la advertencia de doble caída de dput(): ADVERTENCIA: CPU: 0 PID: 2569 en fs/dcache.c:762 dput.part.0+0x3f3/0x410 Usar la combinación de d_drop()/dput() (como se menciona en Documentation/filesystems/vfs.rst) no es el enfoque correcto aquí, y conduce al problema de recuento de referencias visto anteriormente. Utilice d_invalidate() y actualice el código para no molestarse en buscar códigos de error que nunca sucederán. • https://git.kernel.org/stable/c/609e28bb139e53621521130f0d4aea27a725d465 https://git.kernel.org/stable/c/db6e5e16f1ee9e3b01d2f71c7f0ba945f4bf0f4e https://git.kernel.org/stable/c/4cdf9006fc095af71da80e9b5f48a32e991b9ed3 https://git.kernel.org/stable/c/cb9e802e49c24eeb3af35e9e8c04d526f35f112a https://git.kernel.org/stable/c/340682ed1932b8e3bd0bfc6c31a0c6354eb57cc6 https://git.kernel.org/stable/c/a43e0fc5e9134a46515de2f2f8d4100b74e50de3 •