CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2021-47282 – spi: bcm2835: Fix out-of-bounds access with more than 4 slaves
https://notcve.org/view.php?id=CVE-2021-47282
In the Linux kernel, the following vulnerability has been resolved: spi: bcm2835: Fix out-of-bounds access with more than 4 slaves Commit 571e31fa60b3 ("spi: bcm2835: Cache CS register value for ->prepare_message()") limited the number of slaves to 3 at compile-time. The limitation was necessitated by a statically-sized array prepare_cs[] in the driver private data which contains a per-slave register value. The commit sought to enforce the limitation at run-time by setting the controller's num_chipselect to 3: Slaves with a higher chipselect are rejected by spi_add_device(). However the commit neglected that num_chipselect only limits the number of *native* chipselects. If GPIO chipselects are specified in the device tree for more than 3 slaves, num_chipselect is silently raised by of_spi_get_gpio_numbers() and the result are out-of-bounds accesses to the statically-sized array prepare_cs[]. As a bandaid fix which is backportable to stable, raise the number of allowed slaves to 24 (which "ought to be enough for anybody"), enforce the limitation on slave ->setup and revert num_chipselect to 3 (which is the number of native chipselects supported by the controller). An upcoming for-next commit will allow an arbitrary number of slaves. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: spi: bcm2835: corrige el acceso fuera de los límites con más de 4 esclavos. La confirmación 571e31fa60b3 ("spi: bcm2835: valor de registro CS de caché para ->prepare_message()") limitó el número de esclavos a 3 en tiempo de compilación. La limitación fue necesaria por una matriz de tamaño estático prepare_cs[] en los datos privados del controlador que contiene un valor de registro por esclavo. • https://git.kernel.org/stable/c/571e31fa60b3697d5db26140e16d5c45c51c9815 https://git.kernel.org/stable/c/b5502580cf958b094f3b69dfe4eece90eae01fbc https://git.kernel.org/stable/c/82a8ffba54d31e97582051cb56ba1f988018681e https://git.kernel.org/stable/c/01415ff85a24308059e06ca3e97fd7bf75648690 https://git.kernel.org/stable/c/13817d466eb8713a1ffd254f537402f091d48444 •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2021-47281 – ALSA: seq: Fix race of snd_seq_timer_open()
https://notcve.org/view.php?id=CVE-2021-47281
In the Linux kernel, the following vulnerability has been resolved: ALSA: seq: Fix race of snd_seq_timer_open() The timer instance per queue is exclusive, and snd_seq_timer_open() should have managed the concurrent accesses. It looks as if it's checking the already existing timer instance at the beginning, but it's not right, because there is no protection, hence any later concurrent call of snd_seq_timer_open() may override the timer instance easily. This may result in UAF, as the leftover timer instance can keep running while the queue itself gets closed, as spotted by syzkaller recently. For avoiding the race, add a proper check at the assignment of tmr->timeri again, and return -EBUSY if it's been already registered. En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: ALSA: seq: Fix race of snd_seq_timer_open(). La instancia del temporizador por cola es exclusiva, y snd_seq_timer_open() debería haber gestionado los accesos concurrentes. • https://git.kernel.org/stable/c/bd7d88b0874f82f7b29d1a53e574cedaf23166ba https://git.kernel.org/stable/c/536a7646c00a0f14fee49e5e313109e5da2f6031 https://git.kernel.org/stable/c/83e197a8414c0ba545e7e3916ce05f836f349273 •
CVSS: -EPSS: 0%CPEs: 6EXPL: 0CVE-2021-47280 – drm: Fix use-after-free read in drm_getunique()
https://notcve.org/view.php?id=CVE-2021-47280
In the Linux kernel, the following vulnerability has been resolved: drm: Fix use-after-free read in drm_getunique() There is a time-of-check-to-time-of-use error in drm_getunique() due to retrieving file_priv->master prior to locking the device's master mutex. An example can be seen in the crash report of the use-after-free error found by Syzbot: https://syzkaller.appspot.com/bug?id=148d2f1dfac64af52ffd27b661981a540724f803 In the report, the master pointer was used after being freed. This is because another process had acquired the device's master mutex in drm_setmaster_ioctl(), then overwrote fpriv->master in drm_new_set_master(). The old value of fpriv->master was subsequently freed before the mutex was unlocked. To fix this, we lock the device's master mutex before retrieving the pointer from from fpriv->master. This patch passes the Syzbot reproducer test. • https://git.kernel.org/stable/c/17dab9326ff263c62dab1dbac4492e2938a049e4 https://git.kernel.org/stable/c/7d233ba700ceb593905ea82b42dadb4ec8ef85e9 https://git.kernel.org/stable/c/b246b4c70c1250e7814f409b243000f9c0bf79a3 https://git.kernel.org/stable/c/491d52e0078860b33b6c14f0a7ac74ca1b603bd6 https://git.kernel.org/stable/c/f773f8cccac13c7e7bbd9182e7996c727742488e https://git.kernel.org/stable/c/b436acd1cf7fac0ba987abd22955d98025c80c2b •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2021-47279 – usb: misc: brcmstb-usb-pinmap: check return value after calling platform_get_resource()
https://notcve.org/view.php?id=CVE-2021-47279
In the Linux kernel, the following vulnerability has been resolved: usb: misc: brcmstb-usb-pinmap: check return value after calling platform_get_resource() It will cause null-ptr-deref if platform_get_resource() returns NULL, we need check the return value. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: usb: misc: brcmstb-usb-pinmap: verifique el valor de retorno después de llamar a platform_get_resource() Causará un null-ptr-deref si platform_get_resource() devuelve NULL, necesitamos verificar el retorno valor. • https://git.kernel.org/stable/c/517c4c44b32372d2fdf4421822e21083c45e89f9 https://git.kernel.org/stable/c/2147684be1ebdaf845783139b9bc4eba3fecd9e4 https://git.kernel.org/stable/c/fbf649cd6d64d40c03c5397ecd6b1ae922ba7afc •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2021-47278 – bus: mhi: pci_generic: Fix possible use-after-free in mhi_pci_remove()
https://notcve.org/view.php?id=CVE-2021-47278
In the Linux kernel, the following vulnerability has been resolved: bus: mhi: pci_generic: Fix possible use-after-free in mhi_pci_remove() This driver's remove path calls del_timer(). However, that function does not wait until the timer handler finishes. This means that the timer handler may still be running after the driver's remove function has finished, which would result in a use-after-free. Fix by calling del_timer_sync(), which makes sure the timer handler has finished, and unable to re-schedule itself. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bus: mhi: pci_generic: corrige posible use after free en mhi_pci_remove(). La ruta de eliminación de este controlador llama a del_timer(). • https://git.kernel.org/stable/c/8562d4fe34a3ef52da077f77985994bb9ad1f83e https://git.kernel.org/stable/c/c597d5c59c7a6417dba06590f59b922e01188e8d https://git.kernel.org/stable/c/0b67808ade8893a1b3608ddd74fac7854786c919 •