CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-26721 – drm/i915/dsc: Fix the macro that calculates DSCC_/DSCA_ PPS reg address
https://notcve.org/view.php?id=CVE-2024-26721
In the Linux kernel, the following vulnerability has been resolved: drm/i915/dsc: Fix the macro that calculates DSCC_/DSCA_ PPS reg address Commit bd077259d0a9 ("drm/i915/vdsc: Add function to read any PPS register") defines a new macro to calculate the DSC PPS register addresses with PPS number as an input. This macro correctly calculates the addresses till PPS 11 since the addresses increment by 4. So in that case the following macro works correctly to give correct register address: _MMIO(_DSCA_PPS_0 + (pps) * 4) However after PPS 11, the register address for PPS 12 increments by 12 because of RC Buffer memory allocation in between. Because of this discontinuity in the address space, the macro calculates wrong addresses for PPS 12 - 16 resulting into incorrect DSC PPS parameter value read/writes causing DSC corruption. This fixes it by correcting this macro to add the offset of 12 for PPS >=12. v3: Add correct paranthesis for pps argument (Jani Nikula) (cherry picked from commit 6074be620c31dc2ae11af96a1a5ea95580976fb5) En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: drm/i915/dsc: corrige la macro que calcula la dirección de registro DSCC_/DSCA_ PPS Commit bd077259d0a9 ("drm/i915/vdsc: Agregar función para leer cualquier registro PPS") define un Nueva macro para calcular las direcciones de registro DSC PPS con el número PPS como entrada. Esta macro calcula correctamente las direcciones hasta PPS 11 ya que las direcciones se incrementan en 4. • https://git.kernel.org/stable/c/bd077259d0a9c9bf453e7e9751bf41f1996e6585 https://git.kernel.org/stable/c/ff5999fb03f467e1e7159f0ddb199c787f7512b9 https://git.kernel.org/stable/c/962ac2dce56bb3aad1f82a4bbe3ada57a020287c •
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 •
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 •