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 •
CVSS: 5.5EPSS: 0%CPEs: 9EXPL: 0CVE-2024-27388 – SUNRPC: fix some memleaks in gssx_dec_option_array
https://notcve.org/view.php?id=CVE-2024-27388
In the Linux kernel, the following vulnerability has been resolved: SUNRPC: fix some memleaks in gssx_dec_option_array The creds and oa->data need to be freed in the error-handling paths after their allocation. So this patch add these deallocations in the corresponding paths. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: SUNRPC: corrige algunas fugas de mem en gssx_dec_option_array Los creds y oa->data deben liberarse en las rutas de manejo de errores después de su asignación. Entonces este parche agrega estas desasignaciones en las rutas correspondientes. • https://git.kernel.org/stable/c/1d658336b05f8697d6445834f8867f8ad5e4f735 https://git.kernel.org/stable/c/b97c37978ca825557d331c9012e0c1ddc0e42364 https://git.kernel.org/stable/c/bfa9d86d39a0fe4685f90c3529aa9bd62a9d97a8 https://git.kernel.org/stable/c/bb336cd8d5ecb69c430ebe3e7bcff68471d93fa8 https://git.kernel.org/stable/c/dd292e884c649f9b1c18af0ec75ca90b390cd044 https://git.kernel.org/stable/c/934212a623cbab851848b6de377eb476718c3e4c https://git.kernel.org/stable/c/5e6013ae2c8d420faea553d363935f65badd32c3 https://git.kernel.org/stable/c/9806c2393cd2ab0a8e7bb9ffae02ce20e •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-27080 – btrfs: fix race when detecting delalloc ranges during fiemap
https://notcve.org/view.php?id=CVE-2024-27080
In the Linux kernel, the following vulnerability has been resolved: btrfs: fix race when detecting delalloc ranges during fiemap For fiemap we recently stopped locking the target extent range for the whole duration of the fiemap call, in order to avoid a deadlock in a scenario where the fiemap buffer happens to be a memory mapped range of the same file. This use case is very unlikely to be useful in practice but it may be triggered by fuzz testing (syzbot, etc). This however introduced a race that makes us miss delalloc ranges for file regions that are currently holes, so the caller of fiemap will not be aware that there's data for some file regions. This can be quite serious for some use cases - for example in coreutils versions before 9.0, the cp program used fiemap to detect holes and data in the source file, copying only regions with data (extents or delalloc) from the source file to the destination file in order to preserve holes (see the documentation for its --sparse command line option). This means that if cp was used with a source file that had delalloc in a hole, the destination file could end up without that data, which is effectively a data loss issue, if it happened to hit the race described below. The race happens like this: 1) Fiemap is called, without the FIEMAP_FLAG_SYNC flag, for a file that has delalloc in the file range [64M, 65M[, which is currently a hole; 2) Fiemap locks the inode in shared mode, then starts iterating the inode's subvolume tree searching for file extent items, without having the whole fiemap target range locked in the inode's io tree - the change introduced recently by commit b0ad381fa769 ("btrfs: fix deadlock with fiemap and extent locking"). It only locks ranges in the io tree when it finds a hole or prealloc extent since that commit; 3) Note that fiemap clones each leaf before using it, and this is to avoid deadlocks when locking a file range in the inode's io tree and the fiemap buffer is memory mapped to some file, because writing to the page with btrfs_page_mkwrite() will wait on any ordered extent for the page's range and the ordered extent needs to lock the range and may need to modify the same leaf, therefore leading to a deadlock on the leaf; 4) While iterating the file extent items in the cloned leaf before finding the hole in the range [64M, 65M[, the delalloc in that range is flushed and its ordered extent completes - meaning the corresponding file extent item is in the inode's subvolume tree, but not present in the cloned leaf that fiemap is iterating over; 5) When fiemap finds the hole in the [64M, 65M[ range by seeing the gap in the cloned leaf (or a file extent item with disk_bytenr == 0 in case the NO_HOLES feature is not enabled), it will lock that file range in the inode's io tree and then search for delalloc by checking for the EXTENT_DELALLOC bit in the io tree for that range and ordered extents (with btrfs_find_delalloc_in_range()). • https://git.kernel.org/stable/c/ded566b4637f1b6b4c9ba74e7d0b8493e93f19cf https://git.kernel.org/stable/c/b0ad381fa7690244802aed119b478b4bdafc31dd https://git.kernel.org/stable/c/89bca7fe6382d61e88c67a0b0e7bce315986fb8b https://git.kernel.org/stable/c/49d640d2946c35a17b051d54171a032dd95b0f50 https://git.kernel.org/stable/c/ced63fffd63072c0ca55d5a451010d71bf08c0b3 https://git.kernel.org/stable/c/978b63f7464abcfd364a6c95f734282c50f3decf •