CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2021-47535 – drm/msm/a6xx: Allocate enough space for GMU registers
https://notcve.org/view.php?id=CVE-2021-47535
In the Linux kernel, the following vulnerability has been resolved: drm/msm/a6xx: Allocate enough space for GMU registers In commit 142639a52a01 ("drm/msm/a6xx: fix crashstate capture for A650") we changed a6xx_get_gmu_registers() to read 3 sets of registers. Unfortunately, we didn't change the memory allocation for the array. That leads to a KASAN warning (this was on the chromeos-5.4 kernel, which has the problematic commit backported to it): BUG: KASAN: slab-out-of-bounds in _a6xx_get_gmu_registers+0x144/0x430 Write of size 8 at addr ffffff80c89432b0 by task A618-worker/209 CPU: 5 PID: 209 Comm: A618-worker Tainted: G W 5.4.156-lockdep #22 Hardware name: Google Lazor Limozeen without Touchscreen (rev5 - rev8) (DT) Call trace: dump_backtrace+0x0/0x248 show_stack+0x20/0x2c dump_stack+0x128/0x1ec print_address_description+0x88/0x4a0 __kasan_report+0xfc/0x120 kasan_report+0x10/0x18 __asan_report_store8_noabort+0x1c/0x24 _a6xx_get_gmu_registers+0x144/0x430 a6xx_gpu_state_get+0x330/0x25d4 msm_gpu_crashstate_capture+0xa0/0x84c recover_worker+0x328/0x838 kthread_worker_fn+0x32c/0x574 kthread+0x2dc/0x39c ret_from_fork+0x10/0x18 Allocated by task 209: __kasan_kmalloc+0xfc/0x1c4 kasan_kmalloc+0xc/0x14 kmem_cache_alloc_trace+0x1f0/0x2a0 a6xx_gpu_state_get+0x164/0x25d4 msm_gpu_crashstate_capture+0xa0/0x84c recover_worker+0x328/0x838 kthread_worker_fn+0x32c/0x574 kthread+0x2dc/0x39c ret_from_fork+0x10/0x18 En el kernel de Linux, se resolvió la siguiente vulnerabilidad: drm/msm/a6xx: asigne suficiente espacio para los registros GMU. En el commit 142639a52a01 ("drm/msm/a6xx: corrija la captura del estado de falla para A650") cambiamos a6xx_get_gmu_registers() para que diga 3 conjuntos de registros. Desafortunadamente, no cambiamos la asignación de memoria para la matriz. • https://git.kernel.org/stable/c/142639a52a01e90c512a9a8d2156997e02a65b53 https://git.kernel.org/stable/c/d646856a600e8635ba498f20b194219b158626e8 https://git.kernel.org/stable/c/83e54fcf0b14ca2d869dd37abe1bb6542805f538 https://git.kernel.org/stable/c/b4d25abf9720b69a03465b09d0d62d1998ed6708 •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2021-47534 – drm/vc4: kms: Add missing drm_crtc_commit_put
https://notcve.org/view.php?id=CVE-2021-47534
In the Linux kernel, the following vulnerability has been resolved: drm/vc4: kms: Add missing drm_crtc_commit_put Commit 9ec03d7f1ed3 ("drm/vc4: kms: Wait on previous FIFO users before a commit") introduced a global state for the HVS, with each FIFO storing the current CRTC commit so that we can properly synchronize commits. However, the refcounting was off and we thus ended up leaking the drm_crtc_commit structure every commit. Add a drm_crtc_commit_put to prevent the leakage. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: drm/vc4: kms: agregar drm_crtc_commit_put faltante el commit 9ec03d7f1ed3 ("drm/vc4: kms: esperar a los usuarios FIFO anteriores antes de una confirmación") introdujo un estado global para HVS, con cada FIFO almacena El commit CRTC actual para que podamos sincronizar correctamente las confirmaciones. Sin embargo, el recuento no se realizó y, por lo tanto, terminamos filtrando la estructura drm_crtc_commit en cada confirmación. Agregue un drm_crtc_commit_put para evitar la fuga. • https://git.kernel.org/stable/c/9ec03d7f1ed394897891319a4dda75f52c5d292d https://git.kernel.org/stable/c/53f9601e908d42481addd67cdb01a9288c611124 https://git.kernel.org/stable/c/049cfff8d53a30cae3349ff71a4c01b7d9981bc2 •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2021-47533 – drm/vc4: kms: Clear the HVS FIFO commit pointer once done
https://notcve.org/view.php?id=CVE-2021-47533
In the Linux kernel, the following vulnerability has been resolved: drm/vc4: kms: Clear the HVS FIFO commit pointer once done Commit 9ec03d7f1ed3 ("drm/vc4: kms: Wait on previous FIFO users before a commit") introduced a wait on the previous commit done on a given HVS FIFO. However, we never cleared that pointer once done. Since drm_crtc_commit_put can free the drm_crtc_commit structure directly if we were the last user, this means that it can lead to a use-after free if we were to duplicate the state, and that stale pointer would even be copied to the new state. Set the pointer to NULL once we're done with the wait so that we don't carry over a pointer to a free'd structure. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/vc4: kms: borre el puntero de commit FIFO de HVS una vez realizado. El commit 9ec03d7f1ed3 ("drm/vc4: kms: espere a los usuarios FIFO anteriores antes de una confirmación") introdujo una espera en el commit anterior realizada en un HVS FIFO determinado. Sin embargo, nunca borramos ese puntero una vez hecho. • https://git.kernel.org/stable/c/9ec03d7f1ed394897891319a4dda75f52c5d292d https://git.kernel.org/stable/c/2931db9a5ed219546cf2ae0546698faf78281b89 https://git.kernel.org/stable/c/d134c5ff71c7f2320fc7997f2fbbdedf0c76889a •
CVSS: 5.5EPSS: 0%CPEs: 2EXPL: 0CVE-2021-47528 – usb: cdnsp: Fix a NULL pointer dereference in cdnsp_endpoint_init()
https://notcve.org/view.php?id=CVE-2021-47528
In the Linux kernel, the following vulnerability has been resolved: usb: cdnsp: Fix a NULL pointer dereference in cdnsp_endpoint_init() In cdnsp_endpoint_init(), cdnsp_ring_alloc() is assigned to pep->ring and there is a dereference of it in cdnsp_endpoint_init(), which could lead to a NULL pointer dereference on failure of cdnsp_ring_alloc(). Fix this bug by adding a check of pep->ring. This bug was found by a static analyzer. The analysis employs differential checking to identify inconsistent security operations (e.g., checks or kfrees) between two code paths and confirms that the inconsistent operations are not recovered in the current function or the callers, so they constitute bugs. Note that, as a bug found by static analysis, it can be a false positive or hard to trigger. Multiple researchers have cross-reviewed the bug. Builds with CONFIG_USB_CDNSP_GADGET=y show no new warnings, and our static analyzer no longer warns about this code. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: usb: cdnsp: corrige una desreferencia de puntero NULL en cdnsp_endpoint_init() En cdnsp_endpoint_init(), cdnsp_ring_alloc() se asigna a pep->ring y hay una desreferencia del mismo en cdnsp_endpoint_init( ), lo que podría provocar una desreferencia del puntero NULL en caso de falla de cdnsp_ring_alloc(). Corrija este error agregando una marca de pep->ring. • https://git.kernel.org/stable/c/3d82904559f4f5a2622db1b21de3edf2eded7664 https://git.kernel.org/stable/c/7d94bc8e335cb33918e52efdbe192c36707bfa24 https://git.kernel.org/stable/c/37307f7020ab38dde0892a578249bf63d00bca64 • CWE-476: NULL Pointer Dereference •
CVSS: 5.5EPSS: 0%CPEs: 7EXPL: 0CVE-2021-47527 – serial: core: fix transmit-buffer reset and memleak
https://notcve.org/view.php?id=CVE-2021-47527
In the Linux kernel, the following vulnerability has been resolved: serial: core: fix transmit-buffer reset and memleak Commit 761ed4a94582 ("tty: serial_core: convert uart_close to use tty_port_close") converted serial core to use tty_port_close() but failed to notice that the transmit buffer still needs to be freed on final close. Not freeing the transmit buffer means that the buffer is no longer cleared on next open so that any ioctl() waiting for the buffer to drain might wait indefinitely (e.g. on termios changes) or that stale data can end up being transmitted in case tx is restarted. Furthermore, the buffer of any port that has been opened would leak on driver unbind. Note that the port lock is held when clearing the buffer pointer due to the ldisc race worked around by commit a5ba1d95e46e ("uart: fix race between uart_put_char() and uart_shutdown()"). Also note that the tty-port shutdown() callback is not called for console ports so it is not strictly necessary to free the buffer page after releasing the lock (cf. d72402145ace ("tty/serial: do not free trasnmit buffer page under port lock")). En el kernel de Linux, se resolvió la siguiente vulnerabilidad: serial: core: fix transmit-buffer reset y memleak commit 761ed4a94582 ("tty: serial_core: convert uart_close to use tty_port_close") núcleo serial convertido para usar tty_port_close() pero no se dio cuenta que el búfer de transmisión todavía necesita ser liberado en el cierre final. No liberar el búfer de transmisión significa que el búfer ya no se borra en la próxima apertura, por lo que cualquier ioctl() que espere a que se drene el búfer podría esperar indefinidamente (por ejemplo, en cambios de termios) o que los datos obsoletos pueden terminar transmitiéndose en caso de que tx sea reiniciado. Además, el búfer de cualquier puerto que se haya abierto se filtraría al desvincular el controlador. Tenga en cuenta que el bloqueo del puerto se mantiene al borrar el puntero del búfer debido a la ejecución de ldisc solucionada mediante el commit a5ba1d95e46e ("uart: corrige la ejecución entre uart_put_char() y uart_shutdown()"). • https://git.kernel.org/stable/c/761ed4a94582ab291aa24dcbea4e01e8936488c8 https://git.kernel.org/stable/c/011f6c92b5bf6e1fbfdedc8b5232f64c1c493206 https://git.kernel.org/stable/c/e74d9663fd57640fc3394abb5c76fa95b9cc2f2e https://git.kernel.org/stable/c/1179b168fa3f3a6aae3bd140000455a0e58457db https://git.kernel.org/stable/c/c5da8aa441053958594f94254592bb41264bdfbf https://git.kernel.org/stable/c/e1722acf4f0d4d67b60f57e08ce16f8b66cd4b8f https://git.kernel.org/stable/c/64e491c1634b73d3bddc081d08620bdc92ab2c12 https://git.kernel.org/stable/c/00de977f9e0aa9760d9a79d1e41ff780f • CWE-400: Uncontrolled Resource Consumption •