CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-35920 – media: mediatek: vcodec: adding lock to protect decoder context list
https://notcve.org/view.php?id=CVE-2024-35920
In the Linux kernel, the following vulnerability has been resolved: media: mediatek: vcodec: adding lock to protect decoder context list Add a lock for the ctx_list, to avoid accessing a NULL pointer within the 'vpu_dec_ipi_handler' function when the ctx_list has been deleted due to an unexpected behavior on the SCP IP block. Hardware name: Google juniper sku16 board (DT) pstate: 20400005 (nzCv daif +PAN -UAO -TCO BTYPE=--) pc : vpu_dec_ipi_handler+0x58/0x1f8 [mtk_vcodec_dec] lr : scp_ipi_handler+0xd0/0x194 [mtk_scp] sp : ffffffc0131dbbd0 x29: ffffffc0131dbbd0 x28: 0000000000000000 x27: ffffff9bb277f348 x26: ffffff9bb242ad00 x25: ffffffd2d440d3b8 x24: ffffffd2a13ff1d4 x23: ffffff9bb7fe85a0 x22: ffffffc0133fbdb0 x21: 0000000000000010 x20: ffffff9b050ea328 x19: ffffffc0131dbc08 x18: 0000000000001000 x17: 0000000000000000 x16: ffffffd2d461c6e0 x15: 0000000000000242 x14: 000000000000018f x13: 000000000000004d x12: 0000000000000000 x11: 0000000000000001 x10: fffffffffffffff0 x9 : ffffff9bb6e793a8 x8 : 0000000000000000 x7 : 0000000000000000 x6 : 000000000000003f x5 : 0000000000000040 x4 : fffffffffffffff0 x3 : 0000000000000020 x2 : ffffff9bb6e79080 x1 : 0000000000000010 x0 : ffffffc0131dbc08 Call trace: vpu_dec_ipi_handler+0x58/0x1f8 [mtk_vcodec_dec (HASH:6c3f 2)] scp_ipi_handler+0xd0/0x194 [mtk_scp (HASH:7046 3)] mt8183_scp_irq_handler+0x44/0x88 [mtk_scp (HASH:7046 3)] scp_irq_handler+0x48/0x90 [mtk_scp (HASH:7046 3)] irq_thread_fn+0x38/0x94 irq_thread+0x100/0x1c0 kthread+0x140/0x1fc ret_from_fork+0x10/0x30 Code: 54000088 f94ca50a eb14015f 54000060 (f9400108) ---[ end trace ace43ce36cbd5c93 ]--- Kernel panic - not syncing: Oops: Fatal exception SMP: stopping secondary CPUs Kernel Offset: 0x12c4000000 from 0xffffffc010000000 PHYS_OFFSET: 0xffffffe580000000 CPU features: 0x08240002,2188200c Memory Limit: none En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: media: mediatek: vcodec: agregar bloqueo para proteger la lista de contexto del decodificador. Agregue un bloqueo para ctx_list, para evitar acceder a un puntero NULL dentro de la función 'vpu_dec_ipi_handler' cuando se ha eliminado ctx_list debido a un comportamiento inesperado en el bloque de IP de SCP. Nombre del hardware: placa Google Juniper sku16 (DT) pstate: 20400005 (nzCv daif +PAN -UAO -TCO BTYPE=--) pc: vpu_dec_ipi_handler+0x58/0x1f8 [mtk_vcodec_dec] lr: scp_ipi_handler+0xd0/0x194 [mtk_scp] sp: 31dbbd0 x29: ffffffc0131dbbd0 x28: 0000000000000000 x27: ffffff9bb277f348 x26: ffffff9bb242ad00 x25: ffffffd2d440d3b8 x24: ffffffd2a13ff1d4 x23: ffffff9bb7fe85a0 22: ffffffc0133fbdb0 x21: 0000000000000010 x20: ffffff9b050ea328 x19: ffffffc0131dbc08 x18: 0000000000001000 x17: 0000000000000000 x16: 461c6e0 x15: 0000000000000242 x14: 000000000000018f x13: 000000000000004d x12: 0000000000000000 x11: 0000000000000001 x10: fffffffffffffff0 x9: ffffff9bb6e793a8 x8: 0000000000000000 x7: 00000000000 00000 x6: 000000000000003f x5: 0000000000000040 x4: fffffffffffffff0 x3: 0000000000000020 x2: ffffff9bb6e79080 x1: 0000000000000010 x0: ffffffc013 1dbc08 Rastreo de llamadas: vpu_dec_ipi_handler+0x58/0x1f8 [mtk_vcodec_dec (HASH:6c3f 2)] scp_ipi_handler+0xd0/0x194 [mtk_scp (HASH:7046 3)] mt8183_scp_irq_handler+0x44/0x88 [mtk_scp (HASH:7046 3)] scp_irq_handler+0x48/0x90 (HASH:7046 3)] irq_thread_fn +0x38/0x94 irq_thread+0x100/0x1c0 kthread+0x140/0x1fc ret_from_fork+0x10/0x30 Código: 54000088 f94ca50a eb14015f 54000060 (f9400108) ---[ end trace ace43ce36cbd5c93 ] --- Pánico del kernel: no se sincroniza: Ups: excepción fatal SMP : detener CPU secundarias Desplazamiento del kernel: 0x12c4000000 de 0xffffffc010000000 PHYS_OFFSET: 0xffffffe580000000 Características de la CPU: 0x08240002,2188200c Límite de memoria: ninguno • https://git.kernel.org/stable/c/655b86e52eacdce79c2e02c5ec7258a97fcc2e4a https://git.kernel.org/stable/c/0a2dc707aa42214f9c4827bd57e344e29a0841d6 https://git.kernel.org/stable/c/23aaf824121055ba81b55f75444355bd83c8eb38 https://git.kernel.org/stable/c/6467cda18c9f9b5f2f9a0aa1e2861c653e41f382 •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-35919 – media: mediatek: vcodec: adding lock to protect encoder context list
https://notcve.org/view.php?id=CVE-2024-35919
In the Linux kernel, the following vulnerability has been resolved: media: mediatek: vcodec: adding lock to protect encoder context list Add a lock for the ctx_list, to avoid accessing a NULL pointer within the 'vpu_enc_ipi_handler' function when the ctx_list has been deleted due to an unexpected behavior on the SCP IP block. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: media: mediatek: vcodec: añadir bloqueo para proteger la lista de contexto del codificador. Agregue un bloqueo para ctx_list, para evitar acceder a un puntero NULL dentro de la función 'vpu_enc_ipi_handler' cuando se ha eliminado ctx_list debido a un comportamiento inesperado en el bloque de IP de SCP. • https://git.kernel.org/stable/c/1972e32431ed14682909ad568c6fd660572ae6ab https://git.kernel.org/stable/c/41671f0c0182b2bae74ca7e3b0f155559e3e2fc5 https://git.kernel.org/stable/c/51c84a8aac6e3b59af2b0e92ba63cabe2e641a2d https://git.kernel.org/stable/c/afaaf3a0f647a24a7bf6a2145d8ade37baaf75ad •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2023-52699 – sysv: don't call sb_bread() with pointers_lock held
https://notcve.org/view.php?id=CVE-2023-52699
In the Linux kernel, the following vulnerability has been resolved: sysv: don't call sb_bread() with pointers_lock held syzbot is reporting sleep in atomic context in SysV filesystem [1], for sb_bread() is called with rw_spinlock held. A "write_lock(&pointers_lock) => read_lock(&pointers_lock) deadlock" bug and a "sb_bread() with write_lock(&pointers_lock)" bug were introduced by "Replace BKL for chain locking with sysvfs-private rwlock" in Linux 2.5.12. Then, "[PATCH] err1-40: sysvfs locking fix" in Linux 2.6.8 fixed the former bug by moving pointers_lock lock to the callers, but instead introduced a "sb_bread() with read_lock(&pointers_lock)" bug (which made this problem easier to hit). Al Viro suggested that why not to do like get_branch()/get_block()/ find_shared() in Minix filesystem does. And doing like that is almost a revert of "[PATCH] err1-40: sysvfs locking fix" except that get_branch() from with find_shared() is called without write_lock(&pointers_lock). En el kernel de Linux, se resolvió la siguiente vulnerabilidad: sysv: no llame a sb_bread() con pointers_lock retenido syzbot informa suspensión en contexto atómico en el sistema de archivos SysV [1], porque sb_bread() se llama con rw_spinlock retenido. Un error "write_lock(&pointers_lock) => read_lock(&pointers_lock) deadlock" y un error "sb_bread() with write_lock(&pointers_lock)" fueron introducidos por "Reemplazar BKL para bloqueo de cadena con sysvfs-private rwlock" en Linux 2.5.12. Luego, "[PATCH] err1-40: corrección de bloqueo de sysvfs" en Linux 2.6.8 solucionó el error anterior moviendo el bloqueo pointers_lock a las personas que llaman, pero en su lugar introdujo un error "sb_bread() con read_lock(&pointers_lock)" (que hizo que esto problema más fácil de abordar). • https://git.kernel.org/stable/c/13b33feb2ebddc2b1aa607f553566b18a4af1d76 https://git.kernel.org/stable/c/1b4fe801b5bedec2b622ddb18e5c9bf26c63d79f https://git.kernel.org/stable/c/674c1c4229e743070e09db63a23442950ff000d1 https://git.kernel.org/stable/c/fd203d2c671bdee9ab77090ff394d3b71b627927 https://git.kernel.org/stable/c/53cb1e52c9db618c08335984d1ca80db220ccf09 https://git.kernel.org/stable/c/89e8524135a3902e7563a5a59b7b5ec1bf4904ac https://git.kernel.org/stable/c/a69224223746ab96d43e5db9d22d136827b7e2d3 https://git.kernel.org/stable/c/f123dc86388cb669c3d6322702dc441ab •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-35917 – s390/bpf: Fix bpf_plt pointer arithmetic
https://notcve.org/view.php?id=CVE-2024-35917
In the Linux kernel, the following vulnerability has been resolved: s390/bpf: Fix bpf_plt pointer arithmetic Kui-Feng Lee reported a crash on s390x triggered by the dummy_st_ops/dummy_init_ptr_arg test [1]: [<0000000000000002>] 0x2 [<00000000009d5cde>] bpf_struct_ops_test_run+0x156/0x250 [<000000000033145a>] __sys_bpf+0xa1a/0xd00 [<00000000003319dc>] __s390x_sys_bpf+0x44/0x50 [<0000000000c4382c>] __do_syscall+0x244/0x300 [<0000000000c59a40>] system_call+0x70/0x98 This is caused by GCC moving memcpy() after assignments in bpf_jit_plt(), resulting in NULL pointers being written instead of the return and the target addresses. Looking at the GCC internals, the reordering is allowed because the alias analysis thinks that the memcpy() destination and the assignments' left-hand-sides are based on different objects: new_plt and bpf_plt_ret/bpf_plt_target respectively, and therefore they cannot alias. This is in turn due to a violation of the C standard: When two pointers are subtracted, both shall point to elements of the same array object, or one past the last element of the array object ... From the C's perspective, bpf_plt_ret and bpf_plt are distinct objects and cannot be subtracted. In the practical terms, doing so confuses the GCC's alias analysis. The code was written this way in order to let the C side know a few offsets defined in the assembly. While nice, this is by no means necessary. Fix the noncompliance by hardcoding these offsets. [1] https://lore.kernel.org/bpf/c9923c1d-971d-4022-8dc8-1364e929d34c@gmail.com/ En el kernel de Linux, se resolvió la siguiente vulnerabilidad: s390/bpf: Corrección de la aritmética del puntero bpf_plt Kui-Feng Lee informó un bloqueo en s390x provocado por la prueba dummy_st_ops/dummy_init_ptr_arg [1]: [<00000000000000002>] 0x2 [<00000000009d5cde> ] bpf_struct_ops_test_run+0x156/0x250 [<000000000033145a>] __sys_bpf+0xa1a/0xd00 [<00000000003319dc>] __s390x_sys_bpf+0x44/0x50 [<0000000000 c4382c>] __do_syscall+0x244/0x300 [<0000000000c59a40>] system_call+0x70/0x98 Esto es causado por GCC mueve memcpy() después de las asignaciones en bpf_jit_plt(), lo que da como resultado que se escriban punteros NULL en lugar de las direcciones de retorno y de destino. Al observar los aspectos internos de GCC, se permite el reordenamiento porque el análisis de alias piensa que el destino memcpy() y los lados izquierdos de las asignaciones se basan en objetos diferentes: new_plt y bpf_plt_ret/bpf_plt_target respectivamente y, por lo tanto, no pueden crear alias. • https://git.kernel.org/stable/c/f1d5df84cd8c3ec6460c78f5b86be7c84577a83f https://git.kernel.org/stable/c/c3062bdb859b6e2567e7f5c8cde20c0250bb130f https://git.kernel.org/stable/c/d3d74e45a060d218fe4b0c9174f0a77517509d8e https://git.kernel.org/stable/c/7ded842b356d151ece8ac4985940438e6d3998bb •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-35916 – dma-buf: Fix NULL pointer dereference in sanitycheck()
https://notcve.org/view.php?id=CVE-2024-35916
In the Linux kernel, the following vulnerability has been resolved: dma-buf: Fix NULL pointer dereference in sanitycheck() If due to a memory allocation failure mock_chain() returns NULL, it is passed to dma_fence_enable_sw_signaling() resulting in NULL pointer dereference there. Call dma_fence_enable_sw_signaling() only if mock_chain() succeeds. Found by Linux Verification Center (linuxtesting.org) with SVACE. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: dma-buf: corrige la desreferencia del puntero NULL en sanitycheck(). Si debido a un error en la asignación de memoria, mock_chain() devuelve NULL, se pasa a dma_fence_enable_sw_signaling(), lo que genera una desreferencia del puntero NULL allí. . Llame a dma_fence_enable_sw_signaling() solo si mock_chain() tiene éxito. Encontrado por el Centro de verificación de Linux (linuxtesting.org) con SVACE. • https://git.kernel.org/stable/c/d62c43a953ce02d54521ec06217d0c2ed6d489af https://git.kernel.org/stable/c/0336995512cdab0c65e99e4cdd47c4606debe14e https://git.kernel.org/stable/c/156c226cbbdcf5f3bce7b2408a33b59fab7fae2c https://git.kernel.org/stable/c/eabf131cba1db12005a68378305f13b9090a7a6b https://git.kernel.org/stable/c/2295bd846765c766701e666ed2e4b35396be25e6 •