CVSS: 5.5EPSS: 0%CPEs: 4EXPL: 0CVE-2021-47289 – ACPI: fix NULL pointer dereference
https://notcve.org/view.php?id=CVE-2021-47289
In the Linux kernel, the following vulnerability has been resolved: ACPI: fix NULL pointer dereference Commit 71f642833284 ("ACPI: utils: Fix reference counting in for_each_acpi_dev_match()") started doing "acpi_dev_put()" on a pointer that was possibly NULL. That fails miserably, because that helper inline function is not set up to handle that case. Just make acpi_dev_put() silently accept a NULL pointer, rather than calling down to put_device() with an invalid offset off that NULL pointer. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: ACPI: corrige la desreferencia del puntero NULL. La confirmación 71f642833284 ("ACPI: utils: corrige el recuento de referencias en for_each_acpi_dev_match()") comenzó a hacer "acpi_dev_put()" en un puntero que posiblemente era NULL. Eso falla estrepitosamente, porque esa función auxiliar en línea no está configurada para manejar ese caso. • https://git.kernel.org/stable/c/38f54217b423c0101d03a00feec6fb8ec608b12e https://git.kernel.org/stable/c/cae3fa3d8165761f3000f523b11cfa1cd35206bc https://git.kernel.org/stable/c/ccf23a0888077a25a0793a746c3941db2a7562e4 https://git.kernel.org/stable/c/fc68f42aa737dc15e7665a4101d4168aadb8e4c4 https://access.redhat.com/security/cve/CVE-2021-47289 https://bugzilla.redhat.com/show_bug.cgi?id=2282508 • CWE-476: NULL Pointer Dereference •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2021-47288 – media: ngene: Fix out-of-bounds bug in ngene_command_config_free_buf()
https://notcve.org/view.php?id=CVE-2021-47288
In the Linux kernel, the following vulnerability has been resolved: media: ngene: Fix out-of-bounds bug in ngene_command_config_free_buf() Fix an 11-year old bug in ngene_command_config_free_buf() while addressing the following warnings caught with -Warray-bounds: arch/alpha/include/asm/string.h:22:16: warning: '__builtin_memcpy' offset [12, 16] from the object at 'com' is out of the bounds of referenced subobject 'config' with type 'unsigned char' at offset 10 [-Warray-bounds] arch/x86/include/asm/string_32.h:182:25: warning: '__builtin_memcpy' offset [12, 16] from the object at 'com' is out of the bounds of referenced subobject 'config' with type 'unsigned char' at offset 10 [-Warray-bounds] The problem is that the original code is trying to copy 6 bytes of data into a one-byte size member _config_ of the wrong structue FW_CONFIGURE_BUFFERS, in a single call to memcpy(). This causes a legitimate compiler warning because memcpy() overruns the length of &com.cmd.ConfigureBuffers.config. It seems that the right structure is FW_CONFIGURE_FREE_BUFFERS, instead, because it contains 6 more members apart from the header _hdr_. Also, the name of the function ngene_command_config_free_buf() suggests that the actual intention is to ConfigureFreeBuffers, instead of ConfigureBuffers (which takes place in the function ngene_command_config_buf(), above). Fix this by enclosing those 6 members of struct FW_CONFIGURE_FREE_BUFFERS into new struct config, and use &com.cmd.ConfigureFreeBuffers.config as the destination address, instead of &com.cmd.ConfigureBuffers.config, when calling memcpy(). This also helps with the ongoing efforts to globally enable -Warray-bounds and get us closer to being able to tighten the FORTIFY_SOURCE routines on memcpy(). En el kernel de Linux, se resolvió la siguiente vulnerabilidad: medios: ngene: corrige un error fuera de los límites en ngene_command_config_free_buf(). • https://git.kernel.org/stable/c/dae52d009fc950b5c209260d50fcc000f5becd3c https://git.kernel.org/stable/c/4487b968e5eacd02c493303dc2b61150bb7fe4b2 https://git.kernel.org/stable/c/c6ddeb63dd543b5474b0217c4e47538b7ffd7686 https://git.kernel.org/stable/c/e818f2ff648581a6c553ae2bebc5dcef9a8bb90c https://git.kernel.org/stable/c/ec731c6ef564ee6fc101fc5d73e3a3a953d09a00 https://git.kernel.org/stable/c/e617fa62f6cf859a7b042cdd6c73af905ff8fca3 https://git.kernel.org/stable/c/e991457afdcb5f4dbc5bc9d79eaf775be33e7092 https://git.kernel.org/stable/c/b9a178f189bb6d75293573e181928735f •
CVSS: 5.5EPSS: 0%CPEs: 8EXPL: 0CVE-2021-47284 – isdn: mISDN: netjet: Fix crash in nj_probe:
https://notcve.org/view.php?id=CVE-2021-47284
In the Linux kernel, the following vulnerability has been resolved: isdn: mISDN: netjet: Fix crash in nj_probe: 'nj_setup' in netjet.c might fail with -EIO and in this case 'card->irq' is initialized and is bigger than zero. A subsequent call to 'nj_release' will free the irq that has not been requested. Fix this bug by deleting the previous assignment to 'card->irq' and just keep the assignment before 'request_irq'. The KASAN's log reveals it: [ 3.354615 ] WARNING: CPU: 0 PID: 1 at kernel/irq/manage.c:1826 free_irq+0x100/0x480 [ 3.355112 ] Modules linked in: [ 3.355310 ] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.13.0-rc1-00144-g25a1298726e #13 [ 3.355816 ] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01/2014 [ 3.356552 ] RIP: 0010:free_irq+0x100/0x480 [ 3.356820 ] Code: 6e 08 74 6f 4d 89 f4 e8 5e ac 09 00 4d 8b 74 24 18 4d 85 f6 75 e3 e8 4f ac 09 00 8b 75 c8 48 c7 c7 78 c1 2e 85 e8 e0 cf f5 ff <0f> 0b 48 8b 75 c0 4c 89 ff e8 72 33 0b 03 48 8b 43 40 4c 8b a0 80 [ 3.358012 ] RSP: 0000:ffffc90000017b48 EFLAGS: 00010082 [ 3.358357 ] RAX: 0000000000000000 RBX: ffff888104dc8000 RCX: 0000000000000000 [ 3.358814 ] RDX: ffff8881003c8000 RSI: ffffffff8124a9e6 RDI: 00000000ffffffff [ 3.359272 ] RBP: ffffc90000017b88 R08: 0000000000000000 R09: 0000000000000000 [ 3.359732 ] R10: ffffc900000179f0 R11: 0000000000001d04 R12: 0000000000000000 [ 3.360195 ] R13: ffff888107dc6000 R14: ffff888107dc6928 R15: ffff888104dc80a8 [ 3.360652 ] FS: 0000000000000000(0000) GS:ffff88817bc00000(0000) knlGS:0000000000000000 [ 3.361170 ] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 3.361538 ] CR2: 0000000000000000 CR3: 000000000582e000 CR4: 00000000000006f0 [ 3.362003 ] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 3.362175 ] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 3.362175 ] Call Trace: [ 3.362175 ] nj_release+0x51/0x1e0 [ 3.362175 ] nj_probe+0x450/0x950 [ 3.362175 ] ? pci_device_remove+0x110/0x110 [ 3.362175 ] local_pci_probe+0x45/0xa0 [ 3.362175 ] pci_device_probe+0x12b/0x1d0 [ 3.362175 ] really_probe+0x2a9/0x610 [ 3.362175 ] driver_probe_device+0x90/0x1d0 [ 3.362175 ] ? mutex_lock_nested+0x1b/0x20 [ 3.362175 ] device_driver_attach+0x68/0x70 [ 3.362175 ] __driver_attach+0x124/0x1b0 [ 3.362175 ] ? device_driver_attach+0x70/0x70 [ 3.362175 ] bus_for_each_dev+0xbb/0x110 [ 3.362175 ] ? • https://git.kernel.org/stable/c/958cb1078ca60d214826fd90a0961a447fade59a https://git.kernel.org/stable/c/4c1fcb6ec964b44edbf84235134582a5ffae1521 https://git.kernel.org/stable/c/a0a37e4454ca1c0b424edc2c9c2487c2c46a1be6 https://git.kernel.org/stable/c/bf78e25bd3f487208e042c67c8a31706c2dba265 https://git.kernel.org/stable/c/9d7d4649dc1c53acf76df260fd519db698ed20d7 https://git.kernel.org/stable/c/143fc7220961220eecc04669e5909af8847bf8c8 https://git.kernel.org/stable/c/6249193e03709ea625e10706ecaf17fea0427d3d https://git.kernel.org/stable/c/9f6f852550d0e1b7735651228116ae9d3 • CWE-400: Uncontrolled Resource Consumption CWE-590: Free of Memory not on the Heap •
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: 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 •