CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2021-47048 – spi: spi-zynqmp-gqspi: fix use-after-free in zynqmp_qspi_exec_op
https://notcve.org/view.php?id=CVE-2021-47048
In the Linux kernel, the following vulnerability has been resolved: spi: spi-zynqmp-gqspi: fix use-after-free in zynqmp_qspi_exec_op When handling op->addr, it is using the buffer "tmpbuf" which has been freed. This will trigger a use-after-free KASAN warning. Let's use temporary variables to store op->addr.val and op->cmd.opcode to fix this issue. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: spi: spi-zynqmp-gqspi: corrige use-after-free en zynqmp_qspi_exec_op Al manejar op->addr, se utiliza el buffer "tmpbuf" que ha sido liberado. Esto activará una advertencia de KASAN de use-after-free. • https://git.kernel.org/stable/c/1c26372e5aa9e53391a1f8fe0dc7cd93a7e5ba9e https://git.kernel.org/stable/c/1231279389b5e638bc3b66b9741c94077aed4b5a https://git.kernel.org/stable/c/d67e0d6bd92ebbb0294e7062bbf5cdc773764e62 https://git.kernel.org/stable/c/23269ac9f123eca3aea7682d3345c02e71ed696c https://git.kernel.org/stable/c/a2c5bedb2d55dd27c642c7b9fb6886d7ad7bdb58 •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2021-47047 – spi: spi-zynqmp-gqspi: return -ENOMEM if dma_map_single fails
https://notcve.org/view.php?id=CVE-2021-47047
In the Linux kernel, the following vulnerability has been resolved: spi: spi-zynqmp-gqspi: return -ENOMEM if dma_map_single fails The spi controller supports 44-bit address space on AXI in DMA mode, so set dma_addr_t width to 44-bit to avoid using a swiotlb mapping. In addition, if dma_map_single fails, it should return immediately instead of continuing doing the DMA operation which bases on invalid address. This fixes the following crash which occurs in reading a big block from flash: [ 123.633577] zynqmp-qspi ff0f0000.spi: swiotlb buffer is full (sz: 4194304 bytes), total 32768 (slots), used 0 (slots) [ 123.644230] zynqmp-qspi ff0f0000.spi: ERR:rxdma:memory not mapped [ 123.784625] Unable to handle kernel paging request at virtual address 00000000003fffc0 [ 123.792536] Mem abort info: [ 123.795313] ESR = 0x96000145 [ 123.798351] EC = 0x25: DABT (current EL), IL = 32 bits [ 123.803655] SET = 0, FnV = 0 [ 123.806693] EA = 0, S1PTW = 0 [ 123.809818] Data abort info: [ 123.812683] ISV = 0, ISS = 0x00000145 [ 123.816503] CM = 1, WnR = 1 [ 123.819455] user pgtable: 4k pages, 48-bit VAs, pgdp=0000000805047000 [ 123.825887] [00000000003fffc0] pgd=0000000803b45003, p4d=0000000803b45003, pud=0000000000000000 [ 123.834586] Internal error: Oops: 96000145 [#1] PREEMPT SMP En el kernel de Linux, se resolvió la siguiente vulnerabilidad: spi: spi-zynqmp-gqspi: devuelve -ENOMEM si falla dma_map_single El controlador spi admite espacio de direcciones de 44 bits en AXI en modo DMA, por lo tanto, configure el ancho de dma_addr_t en 44 bits para Evite el uso de un mapeo swiotlb. Además, si dma_map_single falla, debería regresar inmediatamente en lugar de continuar realizando la operación DMA que se basa en una dirección no válida. Esto corrige el siguiente fallo que se produce al leer un bloque grande desde flash: [123.633577] zynqmp-qspi ff0f0000.spi: el búfer swiotlb está lleno (tamaño: 4194304 bytes), total 32768 (ranuras), usado 0 (ranuras) [123.644230] zynqmp-qspi ff0f0000.spi: ERR:rxdma:memoria no asignada [123.784625] No se puede manejar la solicitud de paginación del kernel en la dirección virtual 00000000003fffc0 [123.792536] Información de cancelación de memoria: [123.795313] ESR = 0x96000145 [1 23.798351] EC = 0x25: DABT (actual EL), IL = 32 bits [ 123.803655] SET = 0, FnV = 0 [ 123.806693] EA = 0, S1PTW = 0 [ 123.809818] Información de cancelación de datos: [ 123.812683] ISV = 0, ISS = 0x00000145 [ 123.816503] CM = 1 , WnR = 1 [ 123.819455] tabla de páginas de usuario: 4k páginas, VA de 48 bits, pgdp=0000000805047000 [ 123.825887] [00000000003fffc0] pgd=0000000803b45003, p4d=000000080 3b45003, pud=0000000000000000 [123.834586] Error interno: Ups: 96000145 [#1 ] ADVERTENCIA SMP • https://git.kernel.org/stable/c/1c26372e5aa9e53391a1f8fe0dc7cd93a7e5ba9e https://git.kernel.org/stable/c/5980a3b9c933408bc22b0e349b78c3ebd7cbf880 https://git.kernel.org/stable/c/c26c026eb496261dbc0adbf606cc81989cd2038c https://git.kernel.org/stable/c/bad5a23cf2b477fa78b85fd392736dae09a1e818 https://git.kernel.org/stable/c/126bdb606fd2802454e6048caef1be3e25dd121e •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2021-47046 – drm/amd/display: Fix off by one in hdmi_14_process_transaction()
https://notcve.org/view.php?id=CVE-2021-47046
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix off by one in hdmi_14_process_transaction() The hdcp_i2c_offsets[] array did not have an entry for HDCP_MESSAGE_ID_WRITE_CONTENT_STREAM_TYPE so it led to an off by one read overflow. I added an entry and copied the 0x0 value for the offset from similar code in drivers/gpu/drm/amd/display/modules/hdcp/hdcp_ddc.c. I also declared several of these arrays as having HDCP_MESSAGE_ID_MAX entries. This doesn't change the code, but it's just a belt and suspenders approach to try future proof the code. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: drm/amd/display: corrección por uno en hdmi_14_process_transaction() La matriz hdcp_i2c_offsets[] no tenía una entrada para HDCP_MESSAGE_ID_WRITE_CONTENT_STREAM_TYPE, por lo que provocó un desbordamiento de lectura desactivado por uno. Agregué una entrada y copié el valor 0x0 para el desplazamiento de un código similar en drivers/gpu/drm/amd/display/modules/hdcp/hdcp_ddc.c. • https://git.kernel.org/stable/c/4c283fdac08abf3211533f70623c90a34f41d08d https://git.kernel.org/stable/c/403c4528e5887af3deb9838cb77a557631d1e138 https://git.kernel.org/stable/c/6a58310d5d1e5b02d0fc9b393ba540c9367bced5 https://git.kernel.org/stable/c/080bd41d6478a64edf96704fddcda52b1fd5fed7 https://git.kernel.org/stable/c/8e6fafd5a22e7a2eb216f5510db7aab54cc545c1 •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2021-47044 – sched/fair: Fix shift-out-of-bounds in load_balance()
https://notcve.org/view.php?id=CVE-2021-47044
In the Linux kernel, the following vulnerability has been resolved: sched/fair: Fix shift-out-of-bounds in load_balance() Syzbot reported a handful of occurrences where an sd->nr_balance_failed can grow to much higher values than one would expect. A successful load_balance() resets it to 0; a failed one increments it. Once it gets to sd->cache_nice_tries + 3, this *should* trigger an active balance, which will either set it to sd->cache_nice_tries+1 or reset it to 0. However, in case the to-be-active-balanced task is not allowed to run on env->dst_cpu, then the increment is done without any further modification. This could then be repeated ad nauseam, and would explain the absurdly high values reported by syzbot (86, 149). VincentG noted there is value in letting sd->cache_nice_tries grow, so the shift itself should be fixed. That means preventing: """ If the value of the right operand is negative or is greater than or equal to the width of the promoted left operand, the behavior is undefined. """ Thus we need to cap the shift exponent to BITS_PER_TYPE(typeof(lefthand)) - 1. I had a look around for other similar cases via coccinelle: @expr@ position pos; expression E1; expression E2; @@ ( E1 >> E2@pos | E1 >> E2@pos ) @cst depends on expr@ position pos; expression expr.E1; constant cst; @@ ( E1 >> cst@pos | E1 << cst@pos ) @script:python depends on ! • https://git.kernel.org/stable/c/5a7f555904671c0737819fe4d19bd6143de3f6c0 https://git.kernel.org/stable/c/80862cbf76c2646f709a57c4517aefe0b094c774 https://git.kernel.org/stable/c/2f3eab368e313dba35fc2f51ede778bf7b030b54 https://git.kernel.org/stable/c/805cea93e66ca7deaaf6ad3b67224ce47c104c2f https://git.kernel.org/stable/c/39a2a6eb5c9b66ea7c8055026303b3aa681b49a5 •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2021-47043 – media: venus: core: Fix some resource leaks in the error path of 'venus_probe()'
https://notcve.org/view.php?id=CVE-2021-47043
In the Linux kernel, the following vulnerability has been resolved: media: venus: core: Fix some resource leaks in the error path of 'venus_probe()' If an error occurs after a successful 'of_icc_get()' call, it must be undone. Use 'devm_of_icc_get()' instead of 'of_icc_get()' to avoid the leak. Update the remove function accordingly and axe the now unneeded 'icc_put()' calls. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: media: venus: core: corrige algunas fugas de recursos en la ruta de error de 'venus_probe()' Si se produce un error después de una llamada exitosa a 'of_icc_get()', se debe deshacer . Utilice 'devm_of_icc_get()' en lugar de 'of_icc_get()' para evitar la fuga. Actualice la función de eliminación en consecuencia y elimine las llamadas 'icc_put()' ahora innecesarias. • https://git.kernel.org/stable/c/32f0a6ddc8c98a1aade2bf3d07c79d5d2c6ceb9a https://git.kernel.org/stable/c/00b68a7478343afdf83f30c43e64db5296057030 https://git.kernel.org/stable/c/940d01eceb3a7866fbfca136a55a5625fc75a565 https://git.kernel.org/stable/c/711acdf0228dc71601247f28b56f13e850e395c8 https://git.kernel.org/stable/c/5a465c5391a856a0c1e9554964d660676c35d1b2 •