Page 359 of 2797 results (0.011 seconds)

CVSS: -EPSS: 0%CPEs: 8EXPL: 0

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: 0

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 *)-&gt;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: 4.4EPSS: 0%CPEs: 3EXPL: 0

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 https://access.redhat.com/security/cve/CVE-2024-26719 https://bugzilla.redhat.com/show_bug.cgi?id=2273143 • CWE-833: Deadlock •

CVSS: -EPSS: 0%CPEs: 7EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: usb: dwc3: gadget: Fix NULL pointer dereference in dwc3_gadget_suspend In current scenario if Plug-out and Plug-In performed continuously there could be a chance while checking for dwc->gadget_driver in dwc3_gadget_suspend, a NULL pointer dereference may occur. Call Stack: CPU1: CPU2: gadget_unbind_driver dwc3_suspend_common dwc3_gadget_stop dwc3_gadget_suspend dwc3_disconnect_gadget CPU1 basically clears the variable and CPU2 checks the variable. Consider CPU1 is running and right before gadget_driver is cleared and in parallel CPU2 executes dwc3_gadget_suspend where it finds dwc->gadget_driver which is not NULL and resumes execution and then CPU1 completes execution. CPU2 executes dwc3_disconnect_gadget where it checks dwc->gadget_driver is already NULL because of which the NULL pointer deference occur. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: usb: dwc3: gadget: corrige la desreferencia del puntero NULL en dwc3_gadget_suspend En el escenario actual, si el Plug-out y el Plug-In se ejecutan continuamente, podría haber una posibilidad al verificar dwc-&gt;gadget_driver en dwc3_gadget_suspend, puede ocurrir una desreferencia del puntero NULL. Pila de llamadas: CPU1: CPU2: gadget_unbind_driver dwc3_suspend_common dwc3_gadget_stop dwc3_gadget_suspend dwc3_disconnect_gadget CPU1 básicamente borra la variable y CPU2 verifica la variable. Considere que CPU1 se está ejecutando y justo antes de que se borre gadget_driver y en paralelo CPU2 ejecuta dwc3_gadget_suspend donde encuentra dwc-&gt;gadget_driver que no es NULL y reanuda la ejecución y luego CPU1 completa la ejecución. • https://git.kernel.org/stable/c/9772b47a4c2916d645c551228b6085ea24acbe5d https://git.kernel.org/stable/c/8cca5c85393a7a490d4d7942c24d73d29cc77b3e https://git.kernel.org/stable/c/df2ca3271569367352835f981618e284fdc4ca94 https://git.kernel.org/stable/c/88936ceab6b426f1312327e9ef849c215c6007a7 https://git.kernel.org/stable/c/57e2e42ccd3cd6183228269715ed032f44536751 https://git.kernel.org/stable/c/c7ebd8149ee519d27232e6e4940e9c02071b568b https://git.kernel.org/stable/c/36695d5eeeefe5a64b47d0336e7c8fc144e78182 https://git.kernel.org/stable/c/61a348857e869432e6a920ad8ea9132e8 •

CVSS: 4.4EPSS: 0%CPEs: 7EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: powerpc/kasan: Fix addr error caused by page alignment In kasan_init_region, when k_start is not page aligned, at the begin of for loop, k_cur = k_start & PAGE_MASK is less than k_start, and then `va = block + k_cur - k_start` is less than block, the addr va is invalid, because the memory address space from va to block is not alloced by memblock_alloc, which will not be reserved by memblock_reserve later, it will be used by other places. As a result, memory overwriting occurs. for example: int __init __weak kasan_init_region(void *start, size_t size) { [...] /* if say block(dcd97000) k_start(feef7400) k_end(feeff3fe) */ block = memblock_alloc(k_end - k_start, PAGE_SIZE); [...] for (k_cur = k_start & PAGE_MASK; k_cur < k_end; k_cur += PAGE_SIZE) { /* at the begin of for loop * block(dcd97000) va(dcd96c00) k_cur(feef7000) k_start(feef7400) * va(dcd96c00) is less than block(dcd97000), va is invalid */ void *va = block + k_cur - k_start; [...] } [...] } Therefore, page alignment is performed on k_start before memblock_alloc() to ensure the validity of the VA address. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: powerpc/kasan: corrige el error de dirección causado por la alineación de la página En kasan_init_region, cuando k_start no está alineado con la página, al comienzo del bucle for, k_cur = k_start y PAGE_MASK es menor que k_start. y luego `va = block + k_cur - k_start` es menor que block, la dirección va no es válida, porque memblock_alloc no asigna el espacio de direcciones de memoria de va al bloque, que no será reservado por memblock_reserve más adelante, se utilizará por otros lugares. Como resultado, se produce una sobrescritura de la memoria. por ejemplo: int __init __weak kasan_init_region(void *start, size_t size) { [...] /* if say block(dcd97000) k_start(feef7400) k_end(feeff3fe) */ block = memblock_alloc(k_end - k_start, PAGE_SIZE); [...] for (k_cur = k_start &amp; PAGE_MASK; k_cur &lt; k_end; k_cur += PAGE_SIZE) { /* al comienzo del bucle for * block(dcd97000) va(dcd96c00) k_cur(feef7000) k_start(feef7400) * va (dcd96c00) es menor que block(dcd97000), va no es válido */ void *va = block + k_cur - k_start; [...] } [...] } Por lo tanto, la alineación de la página se realiza en k_start antes de memblock_alloc() para garantizar la validez de la dirección VA. • https://git.kernel.org/stable/c/663c0c9496a69f80011205ba3194049bcafd681d https://git.kernel.org/stable/c/5ce93076d8ee2a0fac3ad4adbd2e91b6197146db https://git.kernel.org/stable/c/230e89b5ad0a33f530a2a976b3e5e4385cb27882 https://git.kernel.org/stable/c/2738e0aa2fb24a7ab9c878d912dc2b239738c6c6 https://git.kernel.org/stable/c/0c09912dd8387e228afcc5e34ac5d79b1e3a1058 https://git.kernel.org/stable/c/0516c06b19dc64807c10e01bb99b552bdf2d7dbe https://git.kernel.org/stable/c/70ef2ba1f4286b2b73675aeb424b590c92d57b25 https://git.kernel.org/stable/c/4a7aee96200ad281a5cc4cf5c7a2e2a49 • CWE-20: Improper Input Validation •