Page 171 of 2825 results (0.054 seconds)

CVSS: 5.5EPSS: 0%CPEs: 8EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: net: fix uninit-value in caif_seqpkt_sendmsg When nr_segs equal to zero in iovec_from_user, the object msg->msg_iter.iov is uninit stack memory in caif_seqpkt_sendmsg which is defined in ___sys_sendmsg. So we cann't just judge msg->msg_iter.iov->base directlly. We can use nr_segs to judge msg in caif_seqpkt_sendmsg whether has data buffers. ===================================================== BUG: KMSAN: uninit-value in caif_seqpkt_sendmsg+0x693/0xf60 net/caif/caif_socket.c:542 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x1c9/0x220 lib/dump_stack.c:118 kmsan_report+0xf7/0x1e0 mm/kmsan/kmsan_report.c:118 __msan_warning+0x58/0xa0 mm/kmsan/kmsan_instr.c:215 caif_seqpkt_sendmsg+0x693/0xf60 net/caif/caif_socket.c:542 sock_sendmsg_nosec net/socket.c:652 [inline] sock_sendmsg net/socket.c:672 [inline] ____sys_sendmsg+0x12b6/0x1350 net/socket.c:2343 ___sys_sendmsg net/socket.c:2397 [inline] __sys_sendmmsg+0x808/0xc90 net/socket.c:2480 __compat_sys_sendmmsg net/compat.c:656 [inline] En el kernel de Linux, se resolvió la siguiente vulnerabilidad: net: corrige el valor uninit en caif_seqpkt_sendmsg. Cuando nr_segs es igual a cero en iovec_from_user, el objeto msg->msg_iter.iov es la memoria de pila uninit en caif_seqpkt_sendmsg que está definida en ___sys_sendmsg. Entonces no podemos simplemente juzgar msg->msg_iter.iov->base directamente. • https://git.kernel.org/stable/c/bece7b2398d073d11b2e352405a3ecd3a1e39c60 https://git.kernel.org/stable/c/d9d646acad2c3590e189bb5d5c86ab8bd8a2dfc3 https://git.kernel.org/stable/c/5c6d8e2f7187b8e45a18c27acb7a3885f03ee3db https://git.kernel.org/stable/c/ffe31dd70b70a40cd6b21b78c1713a23e021843a https://git.kernel.org/stable/c/452c3ed7bf63721b07bc2238ed1261bb26027e85 https://git.kernel.org/stable/c/9413c0abb57f70a953b1116318d6aa478013c35d https://git.kernel.org/stable/c/1582a02fecffcee306663035a295e28e1c4aaaff https://git.kernel.org/stable/c/d4c7797ab1517515f0d08b3bc1c6b4888 •

CVSS: 5.5EPSS: 0%CPEs: 4EXPL: 0

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: 0

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: 0

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: 0

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 •