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: 4.4EPSS: 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 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: 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 •
CVSS: 4.4EPSS: 0%CPEs: 5EXPL: 0CVE-2024-26717 – HID: i2c-hid-of: fix NULL-deref on failed power up
https://notcve.org/view.php?id=CVE-2024-26717
In the Linux kernel, the following vulnerability has been resolved: HID: i2c-hid-of: fix NULL-deref on failed power up A while back the I2C HID implementation was split in an ACPI and OF part, but the new OF driver never initialises the client pointer which is dereferenced on power-up failures. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: HID: i2c-hid-of: corrige NULL-deref en caso de encendido fallido Hace un tiempo, la implementación de I2C HID se dividió en una parte ACPI y OF, pero el nuevo controlador OF nunca Inicializa el puntero del cliente al que se le quita la referencia en caso de fallos de encendido. • https://git.kernel.org/stable/c/b33752c300232d7f95dd9a4353947d0c9e6a0e52 https://git.kernel.org/stable/c/62f5d219edbd174829aa18d4b3d97cd5fefbb783 https://git.kernel.org/stable/c/d7d7a0e3b6f5adc45f23667cbb919e99093a5b5c https://git.kernel.org/stable/c/4cad91344a62536a2949873bad6365fbb6232776 https://git.kernel.org/stable/c/e28d6b63aeecbda450935fb58db0e682ea8212d3 https://git.kernel.org/stable/c/00aab7dcb2267f2aef59447602f34501efe1a07f https://access.redhat.com/security/cve/CVE-2024-26717 https://bugzilla.redhat.com/show_bug.cgi?id=2273148 • CWE-476: NULL Pointer Dereference •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-26716 – usb: core: Prevent null pointer dereference in update_port_device_state
https://notcve.org/view.php?id=CVE-2024-26716
In the Linux kernel, the following vulnerability has been resolved: usb: core: Prevent null pointer dereference in update_port_device_state Currently, the function update_port_device_state gets the usb_hub from udev->parent by calling usb_hub_to_struct_hub. However, in case the actconfig or the maxchild is 0, the usb_hub would be NULL and upon further accessing to get port_dev would result in null pointer dereference. Fix this by introducing an if check after the usb_hub is populated. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: usb: core: evita la desreferencia del puntero nulo en update_port_device_state Actualmente, la función update_port_device_state obtiene el usb_hub de udev->parent llamando a usb_hub_to_struct_hub. Sin embargo, en caso de que actconfig o maxchild sean 0, usb_hub sería NULL y, al acceder más para obtener port_dev, se produciría una desreferencia del puntero nulo. Solucione este problema introduciendo una verificación if después de que se complete usb_hub. • https://git.kernel.org/stable/c/83cb2604f641cecadc275ca18adbba4bf262320f https://git.kernel.org/stable/c/ed85777c640cf9e6920bb1b60ed8cd48e1f4d873 https://git.kernel.org/stable/c/465b545d1d7ef282192ddd4439b08279bdb13f6f https://git.kernel.org/stable/c/12783c0b9e2c7915a50d5ec829630ff2da50472c •