CVE-2021-47048 – spi: spi-zynqmp-gqspi: fix use-after-free in zynqmp_qspi_exec_op
https://notcve.org/view.php?id=CVE-2021-47048
28 Feb 2024 — 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, s... • https://git.kernel.org/stable/c/1c26372e5aa9e53391a1f8fe0dc7cd93a7e5ba9e •
CVE-2021-47047 – spi: spi-zynqmp-gqspi: return -ENOMEM if dma_map_single fails
https://notcve.org/view.php?id=CVE-2021-47047
28 Feb 2024 — 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-... • https://git.kernel.org/stable/c/1c26372e5aa9e53391a1f8fe0dc7cd93a7e5ba9e •
CVE-2021-47046 – drm/amd/display: Fix off by one in hdmi_14_process_transaction()
https://notcve.org/view.php?id=CVE-2021-47046
28 Feb 2024 — 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, ... • https://git.kernel.org/stable/c/4c283fdac08abf3211533f70623c90a34f41d08d •
CVE-2021-47045 – scsi: lpfc: Fix null pointer dereference in lpfc_prep_els_iocb()
https://notcve.org/view.php?id=CVE-2021-47045
28 Feb 2024 — In the Linux kernel, the following vulnerability has been resolved: scsi: lpfc: Fix null pointer dereference in lpfc_prep_els_iocb() It is possible to call lpfc_issue_els_plogi() passing a did for which no matching ndlp is found. A call is then made to lpfc_prep_els_iocb() with a null pointer to a lpfc_nodelist structure resulting in a null pointer dereference. Fix by returning an error status if no valid ndlp is found. Fix up comments regarding ndlp reference counting. En el kernel de Linux, se ha resuelto... • https://git.kernel.org/stable/c/4430f7fd09ecb037570119e0aacbf0c17b8f98b2 •
CVE-2021-47044 – sched/fair: Fix shift-out-of-bounds in load_balance()
https://notcve.org/view.php?id=CVE-2021-47044
28 Feb 2024 — 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-balanc... • https://git.kernel.org/stable/c/5a7f555904671c0737819fe4d19bd6143de3f6c0 • CWE-125: Out-of-bounds Read •
CVE-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
28 Feb 2024 — 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 d... • https://git.kernel.org/stable/c/32f0a6ddc8c98a1aade2bf3d07c79d5d2c6ceb9a •
CVE-2021-47042 – drm/amd/display: Free local data after use
https://notcve.org/view.php?id=CVE-2021-47042
28 Feb 2024 — In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Free local data after use Fixes the following memory leak in dc_link_construct(): unreferenced object 0xffffa03e81471400 (size 1024): comm "amd_module_load", pid 2486, jiffies 4294946026 (age 10.544s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<000000000bdf5c4a>] kmem_cache_alloc_trace+0x30a/0x4a0 [<... • https://git.kernel.org/stable/c/3a00c04212d1cfe1426338b78f4ead623508c874 •
CVE-2021-47041 – nvmet-tcp: fix incorrect locking in state_change sk callback
https://notcve.org/view.php?id=CVE-2021-47041
28 Feb 2024 — In the Linux kernel, the following vulnerability has been resolved: nvmet-tcp: fix incorrect locking in state_change sk callback We are not changing anything in the TCP connection state so we should not take a write_lock but rather a read lock. This caused a deadlock when running nvmet-tcp and nvme-tcp on the same system, where state_change callbacks on the host and on the controller side have causal relationship and made lockdep report on this with blktests: ================================ WARNING: incons... • https://git.kernel.org/stable/c/872d26a391da92ed8f0c0f5cb5fef428067b7f30 •
CVE-2021-47040 – io_uring: fix overflows checks in provide buffers
https://notcve.org/view.php?id=CVE-2021-47040
28 Feb 2024 — In the Linux kernel, the following vulnerability has been resolved: io_uring: fix overflows checks in provide buffers Colin reported before possible overflow and sign extension problems in io_provide_buffers_prep(). As Linus pointed out previous attempt did nothing useful, see d81269fecb8ce ("io_uring: fix provide_buffers sign extension"). Do that with help of check_
CVE-2021-47039 – ataflop: potential out of bounds in do_format()
https://notcve.org/view.php?id=CVE-2021-47039
28 Feb 2024 — In the Linux kernel, the following vulnerability has been resolved: ataflop: potential out of bounds in do_format() The function uses "type" as an array index: q = unit[drive].disk[type]->queue; Unfortunately the bounds check on "type" isn't done until later in the function. Fix this by moving the bounds check to the start. En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: ataflop: potencial fuera de los límites en do_format() La función utiliza "tipo" como índice de matriz: q = unidad[unida... • https://git.kernel.org/stable/c/bf9c0538e485b591a2ee02d9adb8a99db4be5a2a •