CVSS: 7.8EPSS: 0%CPEs: 4EXPL: 0CVE-2024-26723 – lan966x: Fix crash when adding interface under a lag
https://notcve.org/view.php?id=CVE-2024-26723
In the Linux kernel, the following vulnerability has been resolved: lan966x: Fix crash when adding interface under a lag There is a crash when adding one of the lan966x interfaces under a lag interface. The issue can be reproduced like this: ip link add name bond0 type bond miimon 100 mode balance-xor ip link set dev eth0 master bond0 The reason is because when adding a interface under the lag it would go through all the ports and try to figure out which other ports are under that lag interface. And the issue is that lan966x can have ports that are NULL pointer as they are not probed. So then iterating over these ports it would just crash as they are NULL pointers. The fix consists in actually checking for NULL pointers before accessing something from the ports. Like we do in other places. • https://git.kernel.org/stable/c/cabc9d49333df72fe0f6d58bdcf9057ba341e701 https://git.kernel.org/stable/c/b9357489c46c7a43999964628db8b47d3a1f8672 https://git.kernel.org/stable/c/48fae67d837488c87379f0c9f27df7391718477c https://git.kernel.org/stable/c/2a492f01228b7d091dfe38974ef40dccf8f9f2f1 https://git.kernel.org/stable/c/15faa1f67ab405d47789d4702f587ec7df7ef03e • CWE-400: Uncontrolled Resource Consumption •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-26722 – ASoC: rt5645: Fix deadlock in rt5645_jack_detect_work()
https://notcve.org/view.php?id=CVE-2024-26722
In the Linux kernel, the following vulnerability has been resolved: ASoC: rt5645: Fix deadlock in rt5645_jack_detect_work() There is a path in rt5645_jack_detect_work(), where rt5645->jd_mutex is left locked forever. That may lead to deadlock when rt5645_jack_detect_work() is called for the second time. Found by Linux Verification Center (linuxtesting.org) with SVACE. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ASoC: rt5645: corrige el punto muerto en rt5645_jack_detect_work() Hay una ruta en rt5645_jack_detect_work(), donde rt5645->jd_mutex queda bloqueado para siempre. Eso puede provocar un punto muerto cuando se llama a rt5645_jack_detect_work() por segunda vez. Encontrado por el Centro de verificación de Linux (linuxtesting.org) con SVACE. • https://git.kernel.org/stable/c/48ce529c83522944f116f03884819051f44f0fb6 https://git.kernel.org/stable/c/b67005b284ddaf62043468d1ce5905c17d85b0e6 https://git.kernel.org/stable/c/ffe13302b8fd486f80c98019bdcb7f3e512d0eda https://git.kernel.org/stable/c/7a3ff8a2bb2620ba6a806f0967c38be1a8d306d9 https://git.kernel.org/stable/c/1613195bf31e68b192bc731bea71726773e3482f https://git.kernel.org/stable/c/8f82f2e4d9c4966282e494ae67b0bc05a6c2b904 https://git.kernel.org/stable/c/cdba4301adda7c60a2064bf808e48fccd352aaa9 https://git.kernel.org/stable/c/3dd2d99e2352903d0e0b8769e6c9b8293 •
CVSS: 5.5EPSS: 0%CPEs: 18EXPL: 0CVE-2024-26720 – mm/writeback: fix possible divide-by-zero in wb_dirty_limits(), again
https://notcve.org/view.php?id=CVE-2024-26720
In the Linux kernel, the following vulnerability has been resolved: mm/writeback: fix possible divide-by-zero in wb_dirty_limits(), again (struct dirty_throttle_control *)->thresh is an unsigned long, but is passed as the u32 divisor argument to div_u64(). On architectures where unsigned long is 64 bytes, the argument will be implicitly truncated. Use div64_u64() instead of div_u64() so that the value used in the "is this a safe division" check is the same as the divisor. Also, remove redundant cast of the numerator to u64, as that should happen implicitly. This would be difficult to exploit in memcg domain, given the ratio-based arithmetic domain_drity_limits() uses, but is much easier in global writeback domain with a BDI_CAP_STRICTLIMIT-backing device, using e.g. vm.dirty_bytes=(1<<32)*PAGE_SIZE so that dtc->thresh == (1<<32) En el kernel de Linux, se resolvió la siguiente vulnerabilidad: mm/writeback: corrige la posible división por cero en wb_dirty_limits(), nuevamente (struct dirty_throttle_control *)->thresh es un largo sin firmar, pero se pasa como argumento del divisor u32 a div_u64(). En arquitecturas donde la longitud sin firmar es de 64 bytes, el argumento se truncará implícitamente. Utilice div64_u64() en lugar de div_u64() para que el valor utilizado en la comprobación "¿Es esta una división segura" sea el mismo que el divisor? Además, elimine la conversión redundante del numerador a u64, ya que eso debería suceder implícitamente. • https://git.kernel.org/stable/c/f6789593d5cea42a4ecb1cbeab6a23ade5ebbba7 https://git.kernel.org/stable/c/c5fec566bef6a027e75c84c35ec970482eb88cea https://git.kernel.org/stable/c/c05d1fe6c19f4df2f0b8cba151a8f0c53b87d878 https://git.kernel.org/stable/c/3f7d325fbbe12e5ade71a1f90759c06ed2d27e3c https://git.kernel.org/stable/c/c593d26fb5d577ef31b6e49a31e08ae3ebc1bc1e https://git.kernel.org/stable/c/253f9ea7e8e53a5176bd80ceb174907b10724c1a https://git.kernel.org/stable/c/1f12e4b3284d6c863f272eb2de0d4248ed211cf4 https://git.kernel.org/stable/c/23a28f5f3f6ca1e4184bd0e9631cd0944 • CWE-369: Divide By Zero •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-26719 – nouveau: offload fence uevents work to workqueue
https://notcve.org/view.php?id=CVE-2024-26719
In the Linux kernel, the following vulnerability has been resolved: nouveau: offload fence uevents work to workqueue This should break the deadlock between the fctx lock and the irq lock. This offloads the processing off the work from the irq into a workqueue. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nuevo: descargar valla uevents work to workqueue Esto debería romper el punto muerto entre el bloqueo fctx y el bloqueo irq. Esto descarga el procesamiento del trabajo del irq a una cola de trabajo. • https://git.kernel.org/stable/c/cc0037fa592d56e4abb9c7d1c52c4d2dc25cd906 https://git.kernel.org/stable/c/985d053f7633d8b539ab1531738d538efac678a9 https://git.kernel.org/stable/c/39126abc5e20611579602f03b66627d7cd1422f0 •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2024-26718 – dm-crypt, dm-verity: disable tasklets
https://notcve.org/view.php?id=CVE-2024-26718
In the Linux kernel, the following vulnerability has been resolved: dm-crypt, dm-verity: disable tasklets Tasklets have an inherent problem with memory corruption. The function tasklet_action_common calls tasklet_trylock, then it calls the tasklet callback and then it calls tasklet_unlock. If the tasklet callback frees the structure that contains the tasklet or if it calls some code that may free it, tasklet_unlock will write into free memory. The commits 8e14f610159d and d9a02e016aaf try to fix it for dm-crypt, but it is not a sufficient fix and the data corruption can still happen [1]. There is no fix for dm-verity and dm-verity will write into free memory with every tasklet-processed bio. There will be atomic workqueues implemented in the kernel 6.9 [2]. They will have better interface and they will not suffer from the memory corruption problem. But we need something that stops the memory corruption now and that can be backported to the stable kernels. So, I'm proposing this commit that disables tasklets in both dm-crypt and dm-verity. • https://git.kernel.org/stable/c/39d42fa96ba1b7d2544db3f8ed5da8fb0d5cb877 https://git.kernel.org/stable/c/b825e0f9d68c178072bffd32dd34c39e3d2d597a https://git.kernel.org/stable/c/30884a44e0cedc3dfda8c22432f3ba4078ec2d94 https://git.kernel.org/stable/c/5735a2671ffb70ea29ca83969fe01316ee2ed6fc https://git.kernel.org/stable/c/0c45a20cbe68bc4d681734f5c03891124a274257 https://git.kernel.org/stable/c/0a9bab391e336489169b95cb0d4553d921302189 •