Page 220 of 2732 results (0.015 seconds)

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

In the Linux kernel, the following vulnerability has been resolved: usb: typec: tcpm: Check for port partner validity before consuming it typec_register_partner() does not guarantee partner registration to always succeed. In the event of failure, port->partner is set to the error value or NULL. Given that port->partner validity is not checked, this results in the following crash: Unable to handle kernel NULL pointer dereference at virtual address xx pc : run_state_machine+0x1bc8/0x1c08 lr : run_state_machine+0x1b90/0x1c08 .. Call trace: run_state_machine+0x1bc8/0x1c08 tcpm_state_machine_work+0x94/0xe4 kthread_worker_fn+0x118/0x328 kthread+0x1d0/0x23c ret_from_fork+0x10/0x20 To prevent the crash, check for port->partner validity before derefencing it in all the call sites. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: usb: typec: tcpm: verifique la validez del socio del puerto antes de consumirlo. typec_register_partner() no garantiza que el registro del socio sea siempre exitoso. En caso de error, puerto->socio se establece en el valor de error o NULL. • https://git.kernel.org/stable/c/9b7cd3fe01f0d03cf5820b351a6be2a6e0a6da6f https://git.kernel.org/stable/c/c97cd0b4b54eb42aed7f6c3c295a2d137f6d2416 https://git.kernel.org/stable/c/31220bd89c22a18478f52fcd8069e8e2adb8f4f2 https://git.kernel.org/stable/c/2897b36d2482b84f35e659989d5cb4501fb31ccd https://git.kernel.org/stable/c/cbcf107780aecf51aba68488044a416d95060b6d https://git.kernel.org/stable/c/d56d2ca03cc22123fd7626967d096d8661324e57 https://git.kernel.org/stable/c/789326cafbd1f67f424436b6bc8bdb887a364637 https://git.kernel.org/stable/c/fc2b655cb6dd2b381f1f284989721002e • CWE-476: NULL Pointer Dereference •

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

In the Linux kernel, the following vulnerability has been resolved: maple_tree: fix mas_empty_area_rev() null pointer dereference Currently the code calls mas_start() followed by mas_data_end() if the maple state is MA_START, but mas_start() may return with the maple state node == NULL. This will lead to a null pointer dereference when checking information in the NULL node, which is done in mas_data_end(). Avoid setting the offset if there is no node by waiting until after the maple state is checked for an empty or single entry state. A user could trigger the events to cause a kernel oops by unmapping all vmas to produce an empty maple tree, then mapping a vma that would cause the scenario described above. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: maple_tree: corrige la desreferencia del puntero nulo mas_empty_area_rev() Actualmente el código llama a mas_start() seguido de mas_data_end() si el estado del arce es MA_START, pero mas_start() puede regresar con el estado del arce nodo == NULL. Esto dará lugar a una desreferencia del puntero nulo al verificar la información en el nodo NULL, lo cual se realiza en mas_data_end(). Evite establecer el desplazamiento si no hay ningún nodo esperando hasta que se verifique el estado del arce para detectar un estado vacío o de entrada única. • https://git.kernel.org/stable/c/54a611b605901c7d5d05b6b8f5d04a6ceb0962aa https://git.kernel.org/stable/c/883e5d542bbdddbddeba60250cb482baf3ae2415 https://git.kernel.org/stable/c/6c9c7c1e63b198a8b979ad963eb21410f10ccb00 https://git.kernel.org/stable/c/f3956791cf526540addd3295e4c1e0f0442486cc https://git.kernel.org/stable/c/955a923d2809803980ff574270f81510112be9cf • CWE-476: NULL Pointer Dereference •

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

In the Linux kernel, the following vulnerability has been resolved: mptcp: ensure snd_nxt is properly initialized on connect Christoph reported a splat hinting at a corrupted snd_una: WARNING: CPU: 1 PID: 38 at net/mptcp/protocol.c:1005 __mptcp_clean_una+0x4b3/0x620 net/mptcp/protocol.c:1005 Modules linked in: CPU: 1 PID: 38 Comm: kworker/1:1 Not tainted 6.9.0-rc1-gbbeac67456c9 #59 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.el7 04/01/2014 Workqueue: events mptcp_worker RIP: 0010:__mptcp_clean_una+0x4b3/0x620 net/mptcp/protocol.c:1005 Code: be 06 01 00 00 bf 06 01 00 00 e8 a8 12 e7 fe e9 00 fe ff ff e8 8e 1a e7 fe 0f b7 ab 3e 02 00 00 e9 d3 fd ff ff e8 7d 1a e7 fe <0f> 0b 4c 8b bb e0 05 00 00 e9 74 fc ff ff e8 6a 1a e7 fe 0f 0b e9 RSP: 0018:ffffc9000013fd48 EFLAGS: 00010293 RAX: 0000000000000000 RBX: ffff8881029bd280 RCX: ffffffff82382fe4 RDX: ffff8881003cbd00 RSI: ffffffff823833c3 RDI: 0000000000000001 RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000000000 R11: fefefefefefefeff R12: ffff888138ba8000 R13: 0000000000000106 R14: ffff8881029bd908 R15: ffff888126560000 FS: 0000000000000000(0000) GS:ffff88813bd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f604a5dae38 CR3: 0000000101dac002 CR4: 0000000000170ef0 Call Trace: <TASK> __mptcp_clean_una_wakeup net/mptcp/protocol.c:1055 [inline] mptcp_clean_una_wakeup net/mptcp/protocol.c:1062 [inline] __mptcp_retrans+0x7f/0x7e0 net/mptcp/protocol.c:2615 mptcp_worker+0x434/0x740 net/mptcp/protocol.c:2767 process_one_work+0x1e0/0x560 kernel/workqueue.c:3254 process_scheduled_works kernel/workqueue.c:3335 [inline] worker_thread+0x3c7/0x640 kernel/workqueue.c:3416 kthread+0x121/0x170 kernel/kthread.c:388 ret_from_fork+0x44/0x50 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:243 </TASK> When fallback to TCP happens early on a client socket, snd_nxt is not yet initialized and any incoming ack will copy such value into snd_una. If the mptcp worker (dumbly) tries mptcp-level re-injection after such ack, that would unconditionally trigger a send buffer cleanup using 'bad' snd_una values. We could easily disable re-injection for fallback sockets, but such dumb behavior already helped catching a few subtle issues and a very low to zero impact in practice. Instead address the issue always initializing snd_nxt (and write_seq, for consistency) at connect time. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: mptcp: asegúrese de que snd_nxt se inicialice correctamente al conectar Christoph informó un símbolo que indica un snd_una dañado: ADVERTENCIA: CPU: 1 PID: 38 en net/mptcp/protocol.c:1005 __mptcp_clean_una +0x4b3/0x620 net/mptcp/protocol.c:1005 Módulos vinculados en: CPU: 1 PID: 38 Comm: kworker/1:1 No contaminado 6.9.0-rc1-gbbeac67456c9 #59 Nombre del hardware: PC estándar QEMU (i440FX + PIIX, 1996), BIOS 1.11.0-2.el7 01/04/2014 Cola de trabajo: eventos mptcp_worker RIP: 0010:__mptcp_clean_una+0x4b3/0x620 net/mptcp/protocol.c:1005 Código: be 06 01 00 00 bf 06 01 00 00 e8 a8 12 e7 fe e9 00 fe ff ff e8 8e 1a e7 fe 0f b7 ab 3e 02 00 00 e9 d3 fd ff ff e8 7d 1a e7 fe &lt;0f&gt; 0b 4c 8b bb e0 05 00 00 e9 74 fc ff ff e8 6a 1a e7 fe 0f 0b e9 RSP: 0018:ffffc9000013fd48 EFLAGS: 00010293 RAX: 0000000000000000 RBX: ffff8881029bd280 RCX: ffffffff82382fe4 RDX: 3cbd00 RSI: ffffffff823833c3 RDI: 0000000000000001 RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000 R10: 00000000000000000 R11: fefefefefefefeff R12 : ffff888138ba8000 R13: 0000000000000106 R14: ffff8881029bd908 R15: ffff888126560000 FS: 00000000000000000(0000) GS:ffff88813bd00000(0000) nlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f604a5dae38 CR3: 0000000101dac002 CR4: 0000000000170ef0 Rastreo de llamadas: __mptcp_clean_una_wakeup net/mptcp/protocol.c:1055 [en línea] mptcp_clean_una_wakeup net/mptcp/protocol.c:1062 [en línea] __mptcp_retrans+0x7f/0x7e0 net/mptcp/protocol.c:2615 mptcp_worker+0x434/ 0x740 neto/ mptcp/protocol.c:2767 Process_one_work+0x1e0/0x560 kernel/workqueue.c:3254 Process_scheduled_works kernel/workqueue.c:3335 [en línea] work_thread+0x3c7/0x640 kernel/workqueue.c:3416 kthread+0x121/0x170 kernel/kthread .c:388 ret_from_fork+0x44/0x50 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:243 Cuando el retorno a TCP ocurre temprano en un socket de cliente , snd_nxt aún no está inicializado y cualquier confirmación entrante copiará dicho valor en snd_una. Si el trabajador mptcp (tontamente) intenta la reinyección a nivel de mptcp después de tal confirmación, eso desencadenaría incondicionalmente una sanitización del búfer de envío utilizando valores snd_una 'incorrectos'. Podríamos desactivar fácilmente la reinyección para los sockets de respaldo, pero un comportamiento tan tonto ya ayudó a detectar algunos problemas sutiles y un impacto de muy bajo a cero en la práctica. • https://git.kernel.org/stable/c/8fd738049ac3d67a937d36577763b47180aae1ad https://git.kernel.org/stable/c/99951b62bf20cec9247f633a3bea898338b9e5b4 https://git.kernel.org/stable/c/dc941fec0719d0471a5902424d6b2a17df233193 https://git.kernel.org/stable/c/39ca83ed73db9edcc6d70c0dc7a73085a4725012 https://git.kernel.org/stable/c/aa0c07c1f20e05b30019bff083ec43665536f06f https://git.kernel.org/stable/c/592f69b41766d366dbb8ff4ef5a67c4396527bbe https://git.kernel.org/stable/c/fb7a0d334894206ae35f023a82cad5a290fd7386 https://lists.debian.org/debian-lts-announce/2024/06/ • CWE-665: Improper Initialization •

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

In the Linux kernel, the following vulnerability has been resolved: tipc: fix UAF in error path Sam Page (sam4k) working with Trend Micro Zero Day Initiative reported a UAF in the tipc_buf_append() error path: BUG: KASAN: slab-use-after-free in kfree_skb_list_reason+0x47e/0x4c0 linux/net/core/skbuff.c:1183 Read of size 8 at addr ffff88804d2a7c80 by task poc/8034 CPU: 1 PID: 8034 Comm: poc Not tainted 6.8.2 #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.0-debian-1.16.0-5 04/01/2014 Call Trace: <IRQ> __dump_stack linux/lib/dump_stack.c:88 dump_stack_lvl+0xd9/0x1b0 linux/lib/dump_stack.c:106 print_address_description linux/mm/kasan/report.c:377 print_report+0xc4/0x620 linux/mm/kasan/report.c:488 kasan_report+0xda/0x110 linux/mm/kasan/report.c:601 kfree_skb_list_reason+0x47e/0x4c0 linux/net/core/skbuff.c:1183 skb_release_data+0x5af/0x880 linux/net/core/skbuff.c:1026 skb_release_all linux/net/core/skbuff.c:1094 __kfree_skb linux/net/core/skbuff.c:1108 kfree_skb_reason+0x12d/0x210 linux/net/core/skbuff.c:1144 kfree_skb linux/./include/linux/skbuff.h:1244 tipc_buf_append+0x425/0xb50 linux/net/tipc/msg.c:186 tipc_link_input+0x224/0x7c0 linux/net/tipc/link.c:1324 tipc_link_rcv+0x76e/0x2d70 linux/net/tipc/link.c:1824 tipc_rcv+0x45f/0x10f0 linux/net/tipc/node.c:2159 tipc_udp_recv+0x73b/0x8f0 linux/net/tipc/udp_media.c:390 udp_queue_rcv_one_skb+0xad2/0x1850 linux/net/ipv4/udp.c:2108 udp_queue_rcv_skb+0x131/0xb00 linux/net/ipv4/udp.c:2186 udp_unicast_rcv_skb+0x165/0x3b0 linux/net/ipv4/udp.c:2346 __udp4_lib_rcv+0x2594/0x3400 linux/net/ipv4/udp.c:2422 ip_protocol_deliver_rcu+0x30c/0x4e0 linux/net/ipv4/ip_input.c:205 ip_local_deliver_finish+0x2e4/0x520 linux/net/ipv4/ip_input.c:233 NF_HOOK linux/./include/linux/netfilter.h:314 NF_HOOK linux/./include/linux/netfilter.h:308 ip_local_deliver+0x18e/0x1f0 linux/net/ipv4/ip_input.c:254 dst_input linux/./include/net/dst.h:461 ip_rcv_finish linux/net/ipv4/ip_input.c:449 NF_HOOK linux/. • https://git.kernel.org/stable/c/1149557d64c97dc9adf3103347a1c0e8c06d3b89 https://git.kernel.org/stable/c/e19ec8ab0e25bc4803d7cc91c84e84532e2781bd https://git.kernel.org/stable/c/93bc2d6d16f2c3178736ba6b845b30475856dc40 https://git.kernel.org/stable/c/367766ff9e407f8a68409b7ce4dc4d5a72afeab1 https://git.kernel.org/stable/c/66116556076f0b96bc1aa9844008c743c8c67684 https://git.kernel.org/stable/c/21ea04aad8a0839b4ec27ef1691ca480620e8e14 https://git.kernel.org/stable/c/ffd4917c1edb3c3ff334fce3704fbe9c39f35682 https://git.kernel.org/stable/c/a0fbb26f8247e326a320e2cb4395bfb23 • CWE-416: Use After Free •

CVSS: -EPSS: 0%CPEs: 3EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: drm/nouveau/firmware: Fix SG_DEBUG error with nvkm_firmware_ctor() Currently, enabling SG_DEBUG in the kernel will cause nouveau to hit a BUG() on startup: kernel BUG at include/linux/scatterlist.h:187! invalid opcode: 0000 [#1] PREEMPT SMP NOPTI CPU: 7 PID: 930 Comm: (udev-worker) Not tainted 6.9.0-rc3Lyude-Test+ #30 Hardware name: MSI MS-7A39/A320M GAMING PRO (MS-7A39), BIOS 1.I0 01/22/2019 RIP: 0010:sg_init_one+0x85/0xa0 Code: 69 88 32 01 83 e1 03 f6 c3 03 75 20 a8 01 75 1e 48 09 cb 41 89 54 24 08 49 89 1c 24 41 89 6c 24 0c 5b 5d 41 5c e9 7b b9 88 00 <0f> 0b 0f 0b 0f 0b 48 8b 05 5e 46 9a 01 eb b2 66 66 2e 0f 1f 84 00 RSP: 0018:ffffa776017bf6a0 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffffa77600d87000 RCX: 000000000000002b RDX: 0000000000000001 RSI: 0000000000000000 RDI: ffffa77680d87000 RBP: 000000000000e000 R08: 0000000000000000 R09: 0000000000000000 R10: ffff98f4c46aa508 R11: 0000000000000000 R12: ffff98f4c46aa508 R13: ffff98f4c46aa008 R14: ffffa77600d4a000 R15: ffffa77600d4a018 FS: 00007feeb5aae980(0000) GS:ffff98f5c4dc0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f22cb9a4520 CR3: 00000001043ba000 CR4: 00000000003506f0 Call Trace: <TASK> ? die+0x36/0x90 ? do_trap+0xdd/0x100 ? sg_init_one+0x85/0xa0 ? • https://git.kernel.org/stable/c/1a88c18da464db0ba8ea25196d0a06490f65322e https://git.kernel.org/stable/c/e05af009302893f39b072811a68fa4a196284c75 https://git.kernel.org/stable/c/52a6947bf576b97ff8e14bb0a31c5eaf2d0d96e2 •