CVSS: 4.2EPSS: 0%CPEs: 5EXPL: 0CVE-2021-47293 – net/sched: act_skbmod: Skip non-Ethernet packets
https://notcve.org/view.php?id=CVE-2021-47293
In the Linux kernel, the following vulnerability has been resolved: net/sched: act_skbmod: Skip non-Ethernet packets Currently tcf_skbmod_act() assumes that packets use Ethernet as their L2 protocol, which is not always the case. As an example, for CAN devices: $ ip link add dev vcan0 type vcan $ ip link set up vcan0 $ tc qdisc add dev vcan0 root handle 1: htb $ tc filter add dev vcan0 parent 1: protocol ip prio 10 \ matchall action skbmod swap mac Doing the above silently corrupts all the packets. Do not perform skbmod actions for non-Ethernet packets. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/sched: act_skbmod: omitir paquetes que no sean Ethernet. Actualmente, tcf_skbmod_act() asume que los paquetes usan Ethernet como protocolo L2, lo cual no siempre es el caso. • https://git.kernel.org/stable/c/86da71b57383d40993cb90baafb3735cffe5d800 https://git.kernel.org/stable/c/e4fdca366806f6bab374d1a95e626a10a3854b0c https://git.kernel.org/stable/c/a88414fb1117f2fe65fb88e45ba694e1d09d5024 https://git.kernel.org/stable/c/071729150be9e1d1b851b70efb6d91ee9269d57b https://git.kernel.org/stable/c/34f1e1f657fae2891b485a3b2b95fe4d2aef9f0d https://git.kernel.org/stable/c/727d6a8b7ef3d25080fad228b2c4a1d4da5999c6 https://access.redhat.com/security/cve/CVE-2021-47293 https://bugzilla.redhat.com/show_bug.cgi?id=2282504 • CWE-20: Improper Input Validation •
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 •