Page 390 of 5570 results (0.018 seconds)

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

In the Linux kernel, the following vulnerability has been resolved: ipv6: Fix potential uninit-value access in __ip6_make_skb() As it was done in commit fc1092f51567 ("ipv4: Fix uninit-value access in __ip_make_skb()") for IPv4, check FLOWI_FLAG_KNOWN_NH on fl6->flowi6_flags instead of testing HDRINCL on the socket to avoid a race condition which causes uninit-value access. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: ipv6: corrige el posible acceso a valores uninit en __ip6_make_skb() Como se hizo en el commit fc1092f51567 ("ipv4: corrige el acceso a valores uninit en __ip_make_skb()") para IPv4, verifique FLOWI_FLAG_KNOWN_NH en fl6->flowi6_flags en lugar de probar HDRINCL en el socket para evitar una condición de ejecución que provoque acceso a valores uninit. • https://git.kernel.org/stable/c/ea30388baebcce37fd594d425a65037ca35e59e8 https://git.kernel.org/stable/c/165370522cc48127da564a08584a7391e6341908 https://git.kernel.org/stable/c/f394f690a30a5ec0413c62777a058eaf3d6e10d5 https://git.kernel.org/stable/c/0cf600ca1bdf1d52df977516ee6cee0cadb1f6b1 https://git.kernel.org/stable/c/605b056d63302ae84eb136e88d4df49124bd5e0d https://git.kernel.org/stable/c/d65ff2fe877c471aa6e79efa7bd8ff66e147c317 https://git.kernel.org/stable/c/2c9cefc142c1dc2759e19a92d3b2b3715e985beb https://git.kernel.org/stable/c/02ed5700f40445af02d1c97db25ffc2d0 • CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition') •

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

In the Linux kernel, the following vulnerability has been resolved: ipv6: fib6_rules: avoid possible NULL dereference in fib6_rule_action() syzbot is able to trigger the following crash [1], caused by unsafe ip6_dst_idev() use. Indeed ip6_dst_idev() can return NULL, and must always be checked. [1] Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN PTI KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] CPU: 0 PID: 31648 Comm: syz-executor.0 Not tainted 6.9.0-rc4-next-20240417-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024 RIP: 0010:__fib6_rule_action net/ipv6/fib6_rules.c:237 [inline] RIP: 0010:fib6_rule_action+0x241/0x7b0 net/ipv6/fib6_rules.c:267 Code: 02 00 00 49 8d 9f d8 00 00 00 48 89 d8 48 c1 e8 03 42 80 3c 20 00 74 08 48 89 df e8 f9 32 bf f7 48 8b 1b 48 89 d8 48 c1 e8 03 <42> 80 3c 20 00 74 08 48 89 df e8 e0 32 bf f7 4c 8b 03 48 89 ef 4c RSP: 0018:ffffc9000fc1f2f0 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 1a772f98c8186700 RDX: 0000000000000003 RSI: ffffffff8bcac4e0 RDI: ffffffff8c1f9760 RBP: ffff8880673fb980 R08: ffffffff8fac15ef R09: 1ffffffff1f582bd R10: dffffc0000000000 R11: fffffbfff1f582be R12: dffffc0000000000 R13: 0000000000000080 R14: ffff888076509000 R15: ffff88807a029a00 FS: 00007f55e82ca6c0(0000) GS:ffff8880b9400000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000001b31d23000 CR3: 0000000022b66000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> fib_rules_lookup+0x62c/0xdb0 net/core/fib_rules.c:317 fib6_rule_lookup+0x1fd/0x790 net/ipv6/fib6_rules.c:108 ip6_route_output_flags_noref net/ipv6/route.c:2637 [inline] ip6_route_output_flags+0x38e/0x610 net/ipv6/route.c:2649 ip6_route_output include/net/ip6_route.h:93 [inline] ip6_dst_lookup_tail+0x189/0x11a0 net/ipv6/ip6_output.c:1120 ip6_dst_lookup_flow+0xb9/0x180 net/ipv6/ip6_output.c:1250 sctp_v6_get_dst+0x792/0x1e20 net/sctp/ipv6.c:326 sctp_transport_route+0x12c/0x2e0 net/sctp/transport.c:455 sctp_assoc_add_peer+0x614/0x15c0 net/sctp/associola.c:662 sctp_connect_new_asoc+0x31d/0x6c0 net/sctp/socket.c:1099 __sctp_connect+0x66d/0xe30 net/sctp/socket.c:1197 sctp_connect net/sctp/socket.c:4819 [inline] sctp_inet_connect+0x149/0x1f0 net/sctp/socket.c:4834 __sys_connect_file net/socket.c:2048 [inline] __sys_connect+0x2df/0x310 net/socket.c:2065 __do_sys_connect net/socket.c:2075 [inline] __se_sys_connect net/socket.c:2072 [inline] __x64_sys_connect+0x7a/0x90 net/socket.c:2072 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ipv6: fib6_rules: evita una posible desreferencia NULL en fib6_rule_action() syzbot es capaz de desencadenar el siguiente bloqueo [1], causado por el uso inseguro de ip6_dst_idev(). De hecho, ip6_dst_idev() puede devolver NULL y siempre debe verificarse. [1] Vaya: fallo de protección general, probablemente para la dirección no canónica 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN PTI KASAN: null-ptr-deref en el rango [0x0000000000000000-0x0000000000000007] CPU: 0 PID: 31648 Comm : syz- executor.0 No contaminado 6.9.0-rc4-next-20240417-syzkaller #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 27/03/2024 RIP: 0010:__fib6_rule_action net/ipv6/fib6_rules.c: 237 [en línea] RIP: 0010:fib6_rule_action+0x241/0x7b0 net/ipv6/fib6_rules.c:267 Código: 02 00 00 49 8d 9f d8 00 00 00 48 89 d8 48 c1 e8 03 42 80 3c 20 00 74 08 48 89 df e8 f9 32 bf f7 48 8b 1b 48 89 d8 48 c1 e8 03 &lt;42&gt; 80 3c 20 00 74 08 48 89 df e8 e0 32 bf f7 4c 8b 03 48 89 ef 4c RSP:ffffc9000fc1f2f 0 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 00000000000000000 RCX: 1a772f98c8186700 RDX: 0000000000000003 RSI: ffffffff8bcac4e0 RDI: ffffffff8c1f9760 RBP: ffff8880673f b980 R08: ffffffff8fac15ef R09: 1ffffffff1f582bd R10: dffffc0000000000 R11: ffffbfff1f582be R12: dffffc0000000000 R13: 0000000000000080 R14: ffff88807650 9000 R15: ffff88807a029a00 FS: 00007f55e82ca6c0(0000) GS :ffff8880b9400000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000001b31d23000 CR3: 0000000022b66000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 00000000000000000 DR6: 00000000ffe0ff0 DR7: 0000000000400 Seguimiento de llamadas: fib_rules_lookup+0x62c/0xdb0 net/core/fib_rules.c:317 fib6_rule_lookup+0x1fd/0x790 net/ipv6/fib6_rules.c:108 ip6_route_output_flags_noref net/ipv6/route.c:2637 [en línea] gs+0x38e/0x610 neto /ipv6/route.c:2649 ip6_route_output include/net/ip6_route.h:93 [en línea] ip6_dst_lookup_tail+0x189/0x11a0 net/ipv6/ip6_output.c:1120 ip6_dst_lookup_flow+0xb9/0x180 net/ipv6/ip6_output.c:1250 sctp_v6_get_dst +0x792/0x1e20 net/sctp/ipv6.c:326 sctp_transport_route+0x12c/0x2e0 net/sctp/transport.c:455 sctp_assoc_add_peer+0x614/0x15c0 net/sctp/associola.c:662 sctp_connect_new_asoc+0x31d/ 0x6c0 neto/sctp/ socket.c:1099 __sctp_connect+0x66d/0xe30 net/sctp/socket.c:1197 sctp_connect net/sctp/socket.c:4819 [en línea] sctp_inet_connect+0x149/0x1f0 net/sctp/socket.c:4834 __sys_connect_file net/socket .c:2048 [en línea] __sys_connect+0x2df/0x310 net/socket.c:2065 __do_sys_connect net/socket.c:2075 [en línea] __se_sys_connect net/socket.c:2072 [en línea] __x64_sys_connect+0x7a/0x90 net/socket. c:2072 do_syscall_x64 arch/x86/entry/common.c:52 [en línea] do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83 Entry_SYSCALL_64_after_hwframe+0x77/0x7f • https://git.kernel.org/stable/c/5e5f3f0f801321078c897a5de0b4b4304f234da0 https://git.kernel.org/stable/c/4a5a573387da6a6b23a4cc62147453ff1bc32afa https://git.kernel.org/stable/c/ddec23f206a944c73bcc2724358b85388837daff https://git.kernel.org/stable/c/674c951ab8a23f7aff9b4c3f2f865901bc76a290 https://git.kernel.org/stable/c/35297fc68de36826087e976f86a5b1f94fd0bf95 https://git.kernel.org/stable/c/7e3242c139c38e60844638e394c2877b16b396b0 https://git.kernel.org/stable/c/8745a8d74ba17dafe72b6ab461fa6c007d879747 https://git.kernel.org/stable/c/1876881c9a49613b5249fb400cbf53412 • CWE-476: NULL Pointer Dereference •

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

In the Linux kernel, the following vulnerability has been resolved: ipv6: prevent NULL dereference in ip6_output() According to syzbot, there is a chance that ip6_dst_idev() returns NULL in ip6_output(). Most places in IPv6 stack deal with a NULL idev just fine, but not here. syzbot reported: general protection fault, probably for non-canonical address 0xdffffc00000000bc: 0000 [#1] PREEMPT SMP KASAN PTI KASAN: null-ptr-deref in range [0x00000000000005e0-0x00000000000005e7] CPU: 0 PID: 9775 Comm: syz-executor.4 Not tainted 6.9.0-rc5-syzkaller-00157-g6a30653b604a #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024 RIP: 0010:ip6_output+0x231/0x3f0 net/ipv6/ip6_output.c:237 Code: 3c 1e 00 49 89 df 74 08 4c 89 ef e8 19 58 db f7 48 8b 44 24 20 49 89 45 00 49 89 c5 48 8d 9d e0 05 00 00 48 89 d8 48 c1 e8 03 <42> 0f b6 04 38 84 c0 4c 8b 74 24 28 0f 85 61 01 00 00 8b 1b 31 ff RSP: 0018:ffffc9000927f0d8 EFLAGS: 00010202 RAX: 00000000000000bc RBX: 00000000000005e0 RCX: 0000000000040000 RDX: ffffc900131f9000 RSI: 0000000000004f47 RDI: 0000000000004f48 RBP: 0000000000000000 R08: ffffffff8a1f0b9a R09: 1ffffffff1f51fad R10: dffffc0000000000 R11: fffffbfff1f51fae R12: ffff8880293ec8c0 R13: ffff88805d7fc000 R14: 1ffff1100527d91a R15: dffffc0000000000 FS: 00007f135c6856c0(0000) GS:ffff8880b9400000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020000080 CR3: 0000000064096000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> NF_HOOK include/linux/netfilter.h:314 [inline] ip6_xmit+0xefe/0x17f0 net/ipv6/ip6_output.c:358 sctp_v6_xmit+0x9f2/0x13f0 net/sctp/ipv6.c:248 sctp_packet_transmit+0x26ad/0x2ca0 net/sctp/output.c:653 sctp_packet_singleton+0x22c/0x320 net/sctp/outqueue.c:783 sctp_outq_flush_ctrl net/sctp/outqueue.c:914 [inline] sctp_outq_flush+0x6d5/0x3e20 net/sctp/outqueue.c:1212 sctp_side_effects net/sctp/sm_sideeffect.c:1198 [inline] sctp_do_sm+0x59cc/0x60c0 net/sctp/sm_sideeffect.c:1169 sctp_primitive_ASSOCIATE+0x95/0xc0 net/sctp/primitive.c:73 __sctp_connect+0x9cd/0xe30 net/sctp/socket.c:1234 sctp_connect net/sctp/socket.c:4819 [inline] sctp_inet_connect+0x149/0x1f0 net/sctp/socket.c:4834 __sys_connect_file net/socket.c:2048 [inline] __sys_connect+0x2df/0x310 net/socket.c:2065 __do_sys_connect net/socket.c:2075 [inline] __se_sys_connect net/socket.c:2072 [inline] __x64_sys_connect+0x7a/0x90 net/socket.c:2072 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ipv6: evita la desreferencia a NULL en ip6_output() Según syzbot, existe la posibilidad de que ip6_dst_idev() devuelva NULL en ip6_output(). La mayoría de los lugares en la pila IPv6 manejan un idev NULL muy bien, pero no aquí. syzbot informó: falla de protección general, probablemente para dirección no canónica 0xdffffc00000000bc: 0000 [#1] PREEMPT SMP KASAN PTI KASAN: null-ptr-deref en rango [0x00000000000005e0-0x00000000000005e7] CPU: 0 PID: 9775 Comm: ejecutor. 4 No contaminado 6.9.0-rc5-syzkaller-00157-g6a30653b604a #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 27/03/2024 RIP: 0010:ip6_output+0x231/0x3f0 net/ipv6/ip6_output. c:237 Código: 3c 1e 00 49 89 df 74 08 4c 89 ef e8 19 58 db f7 48 8b 44 24 20 49 89 45 00 49 89 c5 48 8d 9d e0 05 00 00 48 89 d8 48 c1 e8 &lt;42&gt; 0f b6 04 38 84 c0 4c 8b 74 24 28 0f 85 61 01 00 00 8b 1b 31 ff RSP: 0018:ffffc9000927f0d8 EFLAGS: 00010202 RAX: 00000000000000bc RBX: 000000000005e0 RCX: 0000000000040000 RDX: ffffc900131f9000 RSI: 0000000000004f47 RDI: 0000000000004f48 RBP: 00000000000000000 R08: ffffffff8a1f0b9a R09: 1ffffffff1f51fad R10: dffffc0000000000 R11: ffffbfff1f51fae R12: ffff8880293ec8c0 R13: ffff88805d7fc000 R14: R15: dffffc0000000000 FS: 00007f135c6856c0(0000) GS:ffff8880b9400000(0000) knlGS:00000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020000080 CR3: 0000000064096000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 00000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Seguimiento de llamadas: NF_HOOK include/linux/netfilter.h:314 [en línea] ip6_xmit+0xefe /0x17f0 net/ipv6/ip6_output.c:358 sctp_v6_xmit+0x9f2/0x13f0 net/sctp/ipv6.c:248 sctp_packet_transmit+0x26ad/0x2ca0 net/sctp/output.c:653 sctp_packet_singleton+0x22c/0x320 net /sctp/cola de salida. c:783 sctp_outq_flush_ctrl net/sctp/outqueue.c:914 [en línea] sctp_outq_flush+0x6d5/0x3e20 net/sctp/outqueue.c:1212 sctp_side_effects net/sctp/sm_sideeffect.c:1198 [en línea] 9cc/0x60c0 neto/ sctp/sm_sideeffect.c:1169 sctp_primitive_ASSOCIATE+0x95/0xc0 net/sctp/primitive.c:73 __sctp_connect+0x9cd/0xe30 net/sctp/socket.c:1234 sctp_connect net/sctp/socket.c:4819 [en línea] sctp_inet_connect+ 0x149/0x1f0 net/sctp/socket.c:4834 __sys_connect_file net/socket.c:2048 [en línea] __sys_connect+0x2df/0x310 net/socket.c:2065 __do_sys_connect net/socket.c:2075 [en línea] __se_sys_connect red/socket .c:2072 [en línea] __x64_sys_connect+0x7a/0x90 net/socket.c:2072 do_syscall_x64 arch/x86/entry/common.c:52 [en línea] do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83 entrada_SYSCALL_64_after_hwframe+0x77/0x7f • https://git.kernel.org/stable/c/778d80be52699596bf70e0eb0761cf5e1e46088d https://git.kernel.org/stable/c/9df3b2474a627994433a87cbf325a562555b17de https://git.kernel.org/stable/c/2272e2db38f2e85929278146d7c770f22f528579 https://git.kernel.org/stable/c/ea0cb87402f774b0e1214ffba0f57028b27cf155 https://git.kernel.org/stable/c/e31b25cc2066d3f2b6c38579253882008d4469b0 https://git.kernel.org/stable/c/55f7eb4001ef2a3b48cf039cf263f9ed0ec5a488 https://git.kernel.org/stable/c/4db783d68b9b39a411a96096c10828ff5dfada7a https://access.redhat.com/security/cve/CVE-2024-36901 • CWE-476: NULL Pointer Dereference •

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

In the Linux kernel, the following vulnerability has been resolved: net: hns3: fix kernel crash when devlink reload during initialization The devlink reload process will access the hardware resources, but the register operation is done before the hardware is initialized. So, processing the devlink reload during initialization may lead to kernel crash. This patch fixes this by registering the devlink after hardware initialization. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: hns3: soluciona el fallo del kernel cuando devlink se recarga durante la inicialización El proceso de recarga de devlink accederá a los recursos de hardware, pero la operación de registro se realiza antes de que se inicialice el hardware. Por lo tanto, procesar la recarga de devlink durante la inicialización puede provocar una falla del kernel. Este parche soluciona este problema registrando el devlink después de la inicialización del hardware. • https://git.kernel.org/stable/c/cd6242991d2e3990c828a7c2215d2d3321f1da39 https://git.kernel.org/stable/c/72ede790f5a03c3957487400a1b72ebce293a2e7 https://git.kernel.org/stable/c/5c623fe0534806b627054da09b6f51b7b2f7b9cd https://git.kernel.org/stable/c/c98bc78ce0909ccc92005e2cb6609ec6c7942f69 https://git.kernel.org/stable/c/35d92abfbad88cf947c010baf34b075e40566095 •

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

In the Linux kernel, the following vulnerability has been resolved: gpiolib: cdev: Fix use after free in lineinfo_changed_notify The use-after-free issue occurs as follows: when the GPIO chip device file is being closed by invoking gpio_chrdev_release(), watched_lines is freed by bitmap_free(), but the unregistration of lineinfo_changed_nb notifier chain failed due to waiting write rwsem. Additionally, one of the GPIO chip's lines is also in the release process and holds the notifier chain's read rwsem. Consequently, a race condition leads to the use-after-free of watched_lines. Here is the typical stack when issue happened: [free] gpio_chrdev_release() --> bitmap_free(cdev->watched_lines) <-- freed --> blocking_notifier_chain_unregister() --> down_write(&nh->rwsem) <-- waiting rwsem --> __down_write_common() --> rwsem_down_write_slowpath() --> schedule_preempt_disabled() --> schedule() [use] st54spi_gpio_dev_release() --> gpio_free() --> gpiod_free() --> gpiod_free_commit() --> gpiod_line_state_notify() --> blocking_notifier_call_chain() --> down_read(&nh->rwsem); <-- held rwsem --> notifier_call_chain() --> lineinfo_changed_notify() --> test_bit(xxxx, cdev->watched_lines) <-- use after free The side effect of the use-after-free issue is that a GPIO line event is being generated for userspace where it shouldn't. However, since the chrdev is being closed, userspace won't have the chance to read that event anyway. To fix the issue, call the bitmap_free() function after the unregistration of lineinfo_changed_nb notifier chain. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: gpiolib: cdev: corrige el use after free en lineinfo_changed_notify El problema de use after free ocurre de la siguiente manera: cuando el archivo del dispositivo del chip GPIO se cierra al invocar gpio_chrdev_release(), las líneas vigiladas son liberado por bitmap_free(), pero la cancelación del registro de la cadena de notificador lineinfo_changed_nb falló debido a la espera de escritura de rwsem. • https://git.kernel.org/stable/c/51c1064e82e77b39a49889287ca50709303e2f26 https://git.kernel.org/stable/c/95ca7c90eaf5ea8a8460536535101e3e81160e2a https://git.kernel.org/stable/c/ca710b5f40b8b16fdcad50bebd47f50e4c62d239 https://git.kernel.org/stable/c/02f6b0e1ec7e0e7d059dddc893645816552039da https://access.redhat.com/security/cve/CVE-2024-36899 https://bugzilla.redhat.com/show_bug.cgi?id=2284549 • CWE-416: Use After Free •