CVSS: -EPSS: 0%CPEs: 9EXPL: 0CVE-2021-47474 – comedi: vmk80xx: fix bulk-buffer overflow
https://notcve.org/view.php?id=CVE-2021-47474
In the Linux kernel, the following vulnerability has been resolved: comedi: vmk80xx: fix bulk-buffer overflow The driver is using endpoint-sized buffers but must not assume that the tx and rx buffers are of equal size or a malicious device could overflow the slab-allocated receive buffer when doing bulk transfers. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: comedi: vmk80xx: corrige el desbordamiento masivo del búfer El controlador utiliza búferes del tamaño de un endpoint, pero no debe asumir que los búferes tx y rx son del mismo tamaño o un dispositivo malicioso podría desbordar el búfer de recepción asignado por losa al realizar transferencias masivas. • https://git.kernel.org/stable/c/985cafccbf9b7f862aa1c5ee566801e18b5161fb https://git.kernel.org/stable/c/e0e6a63fd97ad95fe05dfd77268a1952551e11a7 https://git.kernel.org/stable/c/7cfb35db607760698d299fd1cf7402dfa8f09973 https://git.kernel.org/stable/c/0866dcaa828c21bc2f94dac00e086078f11b5772 https://git.kernel.org/stable/c/063f576c43d589a4c153554b681d32b3f8317c7b https://git.kernel.org/stable/c/1ae4715121a57bc6fa29fd992127b01907f2f993 https://git.kernel.org/stable/c/b7fd7f3387f070215e6be341e68eb5c087eeecc0 https://git.kernel.org/stable/c/7b0e356189327287d0eb98ec081bd6dd9 •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2021-47473 – scsi: qla2xxx: Fix a memory leak in an error path of qla2x00_process_els()
https://notcve.org/view.php?id=CVE-2021-47473
In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Fix a memory leak in an error path of qla2x00_process_els() Commit 8c0eb596baa5 ("[SCSI] qla2xxx: Fix a memory leak in an error path of qla2x00_process_els()"), intended to change: bsg_job->request->msgcode == FC_BSG_HST_ELS_NOLOGIN bsg_job->request->msgcode != FC_BSG_RPT_ELS but changed it to: bsg_job->request->msgcode == FC_BSG_RPT_ELS instead. Change the == to a != to avoid leaking the fcport structure or freeing unallocated memory. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: scsi: qla2xxx: corrige una pérdida de memoria en una ruta de error de qla2x00_process_els() Commit 8c0eb596baa5 ("[SCSI] qla2xxx: corrige una pérdida de memoria en una ruta de error de qla2x00_process_els()" ), destinado a cambiar: bsg_job->request->msgcode == FC_BSG_HST_ELS_NOLOGIN bsg_job->request->msgcode != FC_BSG_RPT_ELS pero lo cambió a: bsg_job->request->msgcode == FC_BSG_RPT_ELS en su lugar. • https://git.kernel.org/stable/c/8c0eb596baa51f2b43949c698c644727ef17805c https://git.kernel.org/stable/c/96f0aebf29be25254fa585af43924e34aa21fd9a https://git.kernel.org/stable/c/a7fbb56e6c941d9f59437b96412a348e66388d3e https://git.kernel.org/stable/c/7fb223d0ad801f633c78cbe42b1d1b55f5d163ad •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2021-47471 – drm: mxsfb: Fix NULL pointer dereference crash on unload
https://notcve.org/view.php?id=CVE-2021-47471
In the Linux kernel, the following vulnerability has been resolved: drm: mxsfb: Fix NULL pointer dereference crash on unload The mxsfb->crtc.funcs may already be NULL when unloading the driver, in which case calling mxsfb_irq_disable() via drm_irq_uninstall() from mxsfb_unload() leads to NULL pointer dereference. Since all we care about is masking the IRQ and mxsfb->base is still valid, just use that to clear and mask the IRQ. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: drm: mxsfb: corrige el fallo de desreferencia del puntero NULL al descargar Es posible que mxsfb->crtc.funcs ya sea NULL al descargar el controlador, en cuyo caso se llama a mxsfb_irq_disable() a través de drm_irq_uninstall() desde mxsfb_unload() conduce a la desreferencia del puntero NULL. Dado que lo único que nos importa es enmascarar la IRQ y mxsfb->base sigue siendo válido, simplemente utilícelo para borrar y enmascarar la IRQ. • https://git.kernel.org/stable/c/ae1ed0093281939b80664a687689f12436c0e874 https://git.kernel.org/stable/c/f40c2281d2c0674d32ba732fee45222d76495472 https://git.kernel.org/stable/c/b0e6db0656ddfd8bb57303c2ef61ee1c1cc694a8 https://git.kernel.org/stable/c/3cfc183052c3dbf8eae57b6c1685dab00ed3db4a •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2021-47470 – mm, slub: fix potential use-after-free in slab_debugfs_fops
https://notcve.org/view.php?id=CVE-2021-47470
In the Linux kernel, the following vulnerability has been resolved: mm, slub: fix potential use-after-free in slab_debugfs_fops When sysfs_slab_add failed, we shouldn't call debugfs_slab_add() for s because s will be freed soon. And slab_debugfs_fops will use s later leading to a use-after-free. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: mm, slub: corrige el posible use-after-free en slab_debugfs_fops Cuando sysfs_slab_add falla, no debemos llamar a debugfs_slab_add() para s porque s se liberará pronto. Y slab_debugfs_fops usará s más tarde, lo que conducirá a un use-after-free. • https://git.kernel.org/stable/c/64dd68497be76ab4e237cca06f5324e220d0f050 https://git.kernel.org/stable/c/159d8cfbd0428d487c53be4722f33cdab0d25d83 https://git.kernel.org/stable/c/67823a544414def2a36c212abadb55b23bcda00c •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2021-47469 – spi: Fix deadlock when adding SPI controllers on SPI buses
https://notcve.org/view.php?id=CVE-2021-47469
In the Linux kernel, the following vulnerability has been resolved: spi: Fix deadlock when adding SPI controllers on SPI buses Currently we have a global spi_add_lock which we take when adding new devices so that we can check that we're not trying to reuse a chip select that's already controlled. This means that if the SPI device is itself a SPI controller and triggers the instantiation of further SPI devices we trigger a deadlock as we try to register and instantiate those devices while in the process of doing so for the parent controller and hence already holding the global spi_add_lock. Since we only care about concurrency within a single SPI bus move the lock to be per controller, avoiding the deadlock. This can be easily triggered in the case of spi-mux. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: spi: soluciona el punto muerto al agregar controladores SPI en buses SPI. Actualmente tenemos un spi_add_lock global que utilizamos cuando agregamos nuevos dispositivos para que podamos verificar que no estamos intentando reutilizar un selección de chip que ya está controlado. • https://git.kernel.org/stable/c/722ef19a161ce3fffb3d1b01ce2301c306639bdd https://git.kernel.org/stable/c/6098475d4cb48d821bdf453c61118c56e26294f0 •