CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2021-47531 – drm/msm: Fix mmap to include VM_IO and VM_DONTDUMP
https://notcve.org/view.php?id=CVE-2021-47531
In the Linux kernel, the following vulnerability has been resolved: drm/msm: Fix mmap to include VM_IO and VM_DONTDUMP In commit 510410bfc034 ("drm/msm: Implement mmap as GEM object function") we switched to a new/cleaner method of doing things. That's good, but we missed a little bit. Before that commit, we used to _first_ run through the drm_gem_mmap_obj() case where `obj->funcs->mmap()` was NULL. That meant that we ran: vma->vm_flags |= VM_IO | VM_PFNMAP | VM_DONTEXPAND | VM_DONTDUMP; vma->vm_page_prot = pgprot_writecombine(vm_get_page_prot(vma->vm_flags)); vma->vm_page_prot = pgprot_decrypted(vma->vm_page_prot); ...and _then_ we modified those mappings with our own. Now that `obj->funcs->mmap()` is no longer NULL we don't run the default code. It looks like the fact that the vm_flags got VM_IO / VM_DONTDUMP was important because we're now getting crashes on Chromebooks that use ARC++ while logging out. • https://git.kernel.org/stable/c/510410bfc034c57cc3caf1572aa47c1017bab2f9 https://git.kernel.org/stable/c/8e2b7fe5e8a4be5e571561d9afcfbd92097288ba https://git.kernel.org/stable/c/3466d9e217b337bf473ee629c608e53f9f3ab786 •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2021-47530 – drm/msm: Fix wait_fence submitqueue leak
https://notcve.org/view.php?id=CVE-2021-47530
In the Linux kernel, the following vulnerability has been resolved: drm/msm: Fix wait_fence submitqueue leak We weren't dropping the submitqueue reference in all paths. In particular, when the fence has already been signalled. Split out a helper to simplify handling this in the various different return paths. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: drm/msm: corrige la fuga de la cola de envío de wait_fence No estábamos eliminando la referencia de la cola de envío en todas las rutas. En particular, cuando la valla ya ha sido señalizada. • https://git.kernel.org/stable/c/a61acbbe9cf873f869fc634ae6f72f214f5994cc https://git.kernel.org/stable/c/4c3cdbf2540319ea674f1f3c54f31f14c6f39647 https://git.kernel.org/stable/c/ea0006d390a28012f8187717aea61498b2b341e5 •
CVSS: 5.5EPSS: 0%CPEs: 2EXPL: 0CVE-2021-47529 – iwlwifi: Fix memory leaks in error handling path
https://notcve.org/view.php?id=CVE-2021-47529
In the Linux kernel, the following vulnerability has been resolved: iwlwifi: Fix memory leaks in error handling path Should an error occur (invalid TLV len or memory allocation failure), the memory already allocated in 'reduce_power_data' should be freed before returning, otherwise it is leaking. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: iwlwifi: soluciona pérdidas de memoria en la ruta de manejo de errores. Si ocurre un error (lengua TLV no válida o falla en la asignación de memoria), la memoria ya asignada en 'reduce_power_data' debe liberarse antes de regresar; de lo contrario, está goteando. • https://git.kernel.org/stable/c/9dad325f9d57508b154f0bebbc341a8528e5729c https://git.kernel.org/stable/c/4768935c25403ba96e7a745645df24a51a774b7e https://git.kernel.org/stable/c/a571bc28326d9f3e13f5f2d9cda2883e0631b0ce • CWE-401: Missing Release of Memory after Effective Lifetime •
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 •