Page 284 of 3662 results (0.014 seconds)

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 •

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

In the Linux kernel, the following vulnerability has been resolved: gpiolib: cdev: fix uninitialised kfifo If a line is requested with debounce, and that results in debouncing in software, and the line is subsequently reconfigured to enable edge detection then the allocation of the kfifo to contain edge events is overlooked. This results in events being written to and read from an uninitialised kfifo. Read events are returned to userspace. Initialise the kfifo in the case where the software debounce is already active. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: gpiolib: cdev: corrige kfifo no inicializado Si se solicita una línea con antirrebote, y eso resulta en un antirrebote en el software, y la línea se reconfigura posteriormente para habilitar la detección de bordes, entonces se realiza la asignación del Se pasa por alto kfifo para contener eventos de borde. Esto da como resultado que los eventos se escriban y lean desde un kfifo no inicializado. • https://git.kernel.org/stable/c/65cff70464068a823b3f4a28074000febdce0630 https://git.kernel.org/stable/c/1a51e24404d77bb3307c1e39eee0d8e86febb1a5 https://git.kernel.org/stable/c/883e4bbf06eb5fb7482679e4edb201093e9f55a2 https://git.kernel.org/stable/c/bd7139a70ee8d8ea872b223e043730cf6f5e2b0e https://git.kernel.org/stable/c/ee0166b637a5e376118e9659e5b4148080f1d27e •