CVSS: 5.1EPSS: 0%CPEs: 8EXPL: 0CVE-2021-47236 – net: cdc_eem: fix tx fixup skb leak
https://notcve.org/view.php?id=CVE-2021-47236
In the Linux kernel, the following vulnerability has been resolved: net: cdc_eem: fix tx fixup skb leak when usbnet transmit a skb, eem fixup it in eem_tx_fixup(), if skb_copy_expand() failed, it return NULL, usbnet_start_xmit() will have no chance to free original skb. fix it by free orginal skb in eem_tx_fixup() first, then check skb clone status, if failed, return NULL to usbnet. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: cdc_eem: corrige la fuga de skb de reparación de tx cuando usbnet transmite un skb, eem lo repara en eem_tx_fixup(), si skb_copy_expand() falla, devuelve NULL, usbnet_start_xmit() No tendrá posibilidad de liberar el skb original. solucionelo primero con skb original gratuito en eem_tx_fixup(), luego verifique el estado del clon de skb, si falla, devuelva NULL a usbnet. • https://git.kernel.org/stable/c/9f722c0978b04acba209f8ca1896ad05814bc3a3 https://git.kernel.org/stable/c/f12554b0ff639e74612cc01b3b4a049e098d2d65 https://git.kernel.org/stable/c/14184ec5c958b589ba934da7363a2877879204df https://git.kernel.org/stable/c/1bcacd6088d61c0ac6a990d87975600a81f3247e https://git.kernel.org/stable/c/f4e6a7f19c82f39b1803e91c54718f0d7143767d https://git.kernel.org/stable/c/81de2ed06df8b5451e050fe6a318af3263dbff3f https://git.kernel.org/stable/c/05b2b9f7d24b5663d9b47427fe1555bdafd3ea02 https://git.kernel.org/stable/c/b4f7a9fc9d094c0c4a66f2ad7c37b1dbe • CWE-402: Transmission of Private Resources into a New Sphere ('Resource Leak') •
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-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: 6.2EPSS: 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 •