CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2021-47234 – phy: phy-mtk-tphy: Fix some resource leaks in mtk_phy_init()
https://notcve.org/view.php?id=CVE-2021-47234
In the Linux kernel, the following vulnerability has been resolved: phy: phy-mtk-tphy: Fix some resource leaks in mtk_phy_init() Use clk_disable_unprepare() in the error path of mtk_phy_init() to fix some resource leaks. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: phy: phy-mtk-tphy: solucione algunas fugas de recursos en mtk_phy_init() Utilice clk_disable_unprepare() en la ruta de error de mtk_phy_init() para solucionar algunas fugas de recursos. • https://git.kernel.org/stable/c/9a17907946232d01aa2ec109da5f93b8d31dd425 https://git.kernel.org/stable/c/6472955af5e88b5489b6d78316082ad56ea3e489 https://git.kernel.org/stable/c/aaac9a1bd370338ce372669eb9a6059d16b929aa •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2021-47233 – regulator: rt4801: Fix NULL pointer dereference if priv->enable_gpios is NULL
https://notcve.org/view.php?id=CVE-2021-47233
In the Linux kernel, the following vulnerability has been resolved: regulator: rt4801: Fix NULL pointer dereference if priv->enable_gpios is NULL devm_gpiod_get_array_optional may return NULL if no GPIO was assigned. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: regulador: rt4801: corrige la desreferencia del puntero NULL si priv->enable_gpios es NULL, devm_gpiod_get_array_optional puede devolver NULL si no se asignó ningún GPIO. • https://git.kernel.org/stable/c/ba8a26a7ce8617f9f3d6230de34b2302df086b41 https://git.kernel.org/stable/c/dc68f0c9e4a001e02376fe87f4bdcacadb27e8a1 https://git.kernel.org/stable/c/cb2381cbecb81a8893b2d1e1af29bc2e5531df27 •
CVSS: -EPSS: 0%CPEs: 6EXPL: 0CVE-2021-47231 – can: mcba_usb: fix memory leak in mcba_usb
https://notcve.org/view.php?id=CVE-2021-47231
In the Linux kernel, the following vulnerability has been resolved: can: mcba_usb: fix memory leak in mcba_usb Syzbot reported memory leak in SocketCAN driver for Microchip CAN BUS Analyzer Tool. The problem was in unfreed usb_coherent. In mcba_usb_start() 20 coherent buffers are allocated and there is nothing, that frees them: 1) In callback function the urb is resubmitted and that's all 2) In disconnect function urbs are simply killed, but URB_FREE_BUFFER is not set (see mcba_usb_start) and this flag cannot be used with coherent buffers. Fail log: | [ 1354.053291][ T8413] mcba_usb 1-1:0.0 can0: device disconnected | [ 1367.059384][ T8420] kmemleak: 20 new suspected memory leaks (see /sys/kernel/debug/kmem) So, all allocated buffers should be freed with usb_free_coherent() explicitly NOTE: The same pattern for allocating and freeing coherent buffers is used in drivers/net/can/usb/kvaser_usb/kvaser_usb_core.c En el kernel de Linux, se resolvió la siguiente vulnerabilidad: can: mcba_usb: repara la pérdida de memoria en mcba_usb. Syzbot informó una pérdida de memoria en el controlador SocketCAN para la herramienta Microchip CAN BUS Analyzer. El problema estaba en usb_coherent no liberado. En mcba_usb_start() se asignan 20 buffers coherentes y no hay nada que los libere: 1) En la función de devolución de llamada, la urb se vuelve a enviar y eso es todo 2) En la función de desconexión, las urbs simplemente se eliminan, pero URB_FREE_BUFFER no está configurado (ver mcba_usb_start) y Esta bandera no se puede utilizar con buffers coherentes. • https://git.kernel.org/stable/c/51f3baad7de943780ce0c17bd7975df567dd6e14 https://git.kernel.org/stable/c/89df95ce32be204eef2e7d4b2f6fb552fb191a68 https://git.kernel.org/stable/c/a115198caaab6d663bef75823a3c5f0802306d60 https://git.kernel.org/stable/c/6f87c0e21ad20dd3d22108e33db1c552dfa352a0 https://git.kernel.org/stable/c/6bd3d80d1f019cefa7011056c54b323f1d8b8e83 https://git.kernel.org/stable/c/d0760a4ef85697bc756d06eae17ae27f3f055401 https://git.kernel.org/stable/c/91c02557174be7f72e46ed7311e3bea1939840b0 •
CVSS: -EPSS: 0%CPEs: 6EXPL: 0CVE-2021-47229 – PCI: aardvark: Fix kernel panic during PIO transfer
https://notcve.org/view.php?id=CVE-2021-47229
In the Linux kernel, the following vulnerability has been resolved: PCI: aardvark: Fix kernel panic during PIO transfer Trying to start a new PIO transfer by writing value 0 in PIO_START register when previous transfer has not yet completed (which is indicated by value 1 in PIO_START) causes an External Abort on CPU, which results in kernel panic: SError Interrupt on CPU0, code 0xbf000002 -- SError Kernel panic - not syncing: Asynchronous SError Interrupt To prevent kernel panic, it is required to reject a new PIO transfer when previous one has not finished yet. If previous PIO transfer is not finished yet, the kernel may issue a new PIO request only if the previous PIO transfer timed out. In the past the root cause of this issue was incorrectly identified (as it often happens during link retraining or after link down event) and special hack was implemented in Trusted Firmware to catch all SError events in EL3, to ignore errors with code 0xbf000002 and not forwarding any other errors to kernel and instead throw panic from EL3 Trusted Firmware handler. Links to discussion and patches about this issue: https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/commit/?id=3c7dcdac5c50 https://lore.kernel.org/linux-pci/20190316161243.29517-1-repk@triplefau.lt/ https://lore.kernel.org/linux-pci/971be151d24312cc533989a64bd454b4@www.loen.fr/ https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/1541 But the real cause was the fact that during link retraining or after link down event the PIO transfer may take longer time, up to the 1.44s until it times out. This increased probability that a new PIO transfer would be issued by kernel while previous one has not finished yet. After applying this change into the kernel, it is possible to revert the mentioned TF-A hack and SError events do not have to be caught in TF-A EL3. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: PCI: aardvark: solucionó el pánico del kernel durante la transferencia de PIO. Intentar iniciar una nueva transferencia de PIO escribiendo el valor 0 en el registro PIO_START cuando la transferencia anterior aún no se ha completado (que se indica con el valor 1). en PIO_START) provoca un aborto externo en la CPU, lo que resulta en pánico del kernel: Interrupción de SError en CPU0, código 0xbf000002 - Pánico del kernel de SError - no se sincroniza: Interrupción de SError asincrónica Para evitar el pánico del kernel, es necesario rechazar una nueva transferencia de PIO cuando el anterior aún no ha terminado. • https://git.kernel.org/stable/c/400e6b1860c8be61388d0b77814c53260f96e17a https://git.kernel.org/stable/c/b00a9aaa4be20ad6e3311fb78a485eae0899e89a https://git.kernel.org/stable/c/4c90f90a91d75c3c73dd633827c90e8746d9f54d https://git.kernel.org/stable/c/1a1dbc4473974867fe8c5f195c17b341c8e82867 https://git.kernel.org/stable/c/3d213a4ddf49a860be6e795482c17f87e0c82b2a https://git.kernel.org/stable/c/f18139966d072dab8e4398c95ce955a9742e04f7 •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2021-47224 – net: ll_temac: Make sure to free skb when it is completely used
https://notcve.org/view.php?id=CVE-2021-47224
In the Linux kernel, the following vulnerability has been resolved: net: ll_temac: Make sure to free skb when it is completely used With the skb pointer piggy-backed on the TX BD, we have a simple and efficient way to free the skb buffer when the frame has been transmitted. But in order to avoid freeing the skb while there are still fragments from the skb in use, we need to piggy-back on the TX BD of the skb, not the first. Without this, we are doing use-after-free on the DMA side, when the first BD of a multi TX BD packet is seen as completed in xmit_done, and the remaining BDs are still being processed. En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: net:ll_temac: Asegúrate de liberar skb cuando esté completamente utilizado. Con el puntero skb acoplado en la BD TX, tenemos una forma sencilla y eficaz de liberar el buffer skb. cuando la trama ha sido transmitida. Pero para evitar liberar el skb mientras todavía hay fragmentos del skb en uso, debemos aprovechar el BD TX del skb, no el primero. Sin esto, estamos haciendo use after free en el lado DMA, cuando el primer BD de un paquete BD de transmisión múltiple se considera completado en xmit_done y los BD restantes todavía se están procesando. • https://git.kernel.org/stable/c/6d120ab4dc39a543c6b63361e1d0541c382900a3 https://git.kernel.org/stable/c/019ab7d044d0ebf97e1236bb8935b7809be92358 https://git.kernel.org/stable/c/e8afe05bd359ebe12a61dbdc94c06c00ea3e8d4b https://git.kernel.org/stable/c/6aa32217a9a446275440ee8724b1ecaf1838df47 •