CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2021-47283 – net:sfc: fix non-freed irq in legacy irq mode
https://notcve.org/view.php?id=CVE-2021-47283
In the Linux kernel, the following vulnerability has been resolved: net:sfc: fix non-freed irq in legacy irq mode SFC driver can be configured via modparam to work using MSI-X, MSI or legacy IRQ interrupts. In the last one, the interrupt was not properly released on module remove. It was not freed because the flag irqs_hooked was not set during initialization in the case of using legacy IRQ. Example of (trimmed) trace during module remove without this fix: remove_proc_entry: removing non-empty directory 'irq/125', leaking at least '0000:3b:00.1' WARNING: CPU: 39 PID: 3658 at fs/proc/generic.c:715 remove_proc_entry+0x15c/0x170 ...trimmed... Call Trace: unregister_irq_proc+0xe3/0x100 free_desc+0x29/0x70 irq_free_descs+0x47/0x70 mp_unmap_irq+0x58/0x60 acpi_unregister_gsi_ioapic+0x2a/0x40 acpi_pci_irq_disable+0x78/0xb0 pci_disable_device+0xd1/0x100 efx_pci_remove+0xa1/0x1e0 [sfc] pci_device_remove+0x38/0xa0 __device_release_driver+0x177/0x230 driver_detach+0xcb/0x110 bus_remove_driver+0x58/0xd0 pci_unregister_driver+0x2a/0xb0 efx_exit_module+0x24/0xf40 [sfc] __do_sys_delete_module.constprop.0+0x171/0x280 ? exit_to_user_mode_prepare+0x83/0x1d0 do_syscall_64+0x3d/0x80 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7f9f9385800b ...trimmed... En el kernel de Linux, se resolvió la siguiente vulnerabilidad: net:sfc: corrige irq no liberado en modo irq heredado. El controlador SFC se puede configurar mediante modparam para que funcione usando interrupciones MSI-X, MSI o IRQ heredadas. • https://git.kernel.org/stable/c/8d717c9135a3340ae62d1699484850bfb4112b0c https://git.kernel.org/stable/c/81c4d1d83f88e15b26f4522a35cba6ffd8c5dfdd https://git.kernel.org/stable/c/8f03eeb6e0a0a0b8d617ee0a4bce729e47130036 •
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 •