CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2024-50134 – drm/vboxvideo: Replace fake VLA at end of vbva_mouse_pointer_shape with real VLA
https://notcve.org/view.php?id=CVE-2024-50134
In the Linux kernel, the following vulnerability has been resolved: drm/vboxvideo: Replace fake VLA at end of vbva_mouse_pointer_shape with real VLA Replace the fake VLA at end of the vbva_mouse_pointer_shape shape with a real VLA to fix a "memcpy: detected field-spanning write error" warning: [ 13.319813] memcpy: detected field-spanning write (size 16896) of single field "p->data" at drivers/gpu/drm/vboxvideo/hgsmi_base.c:154 (size 4) [ 13.319841] WARNING: CPU: 0 PID: 1105 at drivers/gpu/drm/vboxvideo/hgsmi_base.c:154 hgsmi_update_pointer_shape+0x192/0x1c0 [vboxvideo] [ 13.320038] Call Trace: [ 13.320173] hgsmi_update_pointer_shape [vboxvideo] [ 13.320184] vbox_cursor_atomic_update [vboxvideo] Note as mentioned in the added comment it seems the original length calculation for the allocated and send hgsmi buffer is 4 bytes too large. Changing this is not the goal of this patch, so this behavior is kept. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/vboxvideo: Reemplazar VLA falso al final de vbva_mouse_pointer_shape con VLA real Reemplace el VLA falso al final de la forma vbva_mouse_pointer_shape con un VLA real para corregir una advertencia "memcpy: error de escritura que abarca el campo detectado": [ 13.319813] memcpy: se detectó una escritura que abarca el campo (tamaño 16896) de un solo campo "p->data" en drivers/gpu/drm/vboxvideo/hgsmi_base.c:154 (tamaño 4) [ 13.319841] ADVERTENCIA: CPU: 0 PID: 1105 en drivers/gpu/drm/vboxvideo/hgsmi_base.c:154 hgsmi_update_pointer_shape+0x192/0x1c0 [vboxvideo] [ [13.320038] Seguimiento de llamadas: [13.320173] hgsmi_update_pointer_shape [vboxvideo] [13.320184] vbox_cursor_atomic_update [vboxvideo] Tenga en cuenta que, como se menciona en el comentario agregado, parece que el cálculo de longitud original para el búfer hgsmi asignado y enviado es 4 bytes más grande. Cambiar esto no es el objetivo de este parche, por lo que se mantiene este comportamiento. • https://git.kernel.org/stable/c/02c86c5d5ef4bbba17d38859c74872825f536617 https://git.kernel.org/stable/c/75f828e944dacaac8870418461d3d48a1ecf2331 https://git.kernel.org/stable/c/34a422274b693507025a7db21519865d1862afcb https://git.kernel.org/stable/c/7458a6cdaebb3dc59af8578ee354fae78a154c4a https://git.kernel.org/stable/c/9eb32bd23bbcec44bcbef27b7f282b7a7f3d0391 https://git.kernel.org/stable/c/fae9dc12c61ce23cf29d09824a741b7b1ff8f01f https://git.kernel.org/stable/c/d92b90f9a54d9300a6e883258e79f36dab53bfae •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-50133 – LoongArch: Don't crash in stack_top() for tasks without vDSO
https://notcve.org/view.php?id=CVE-2024-50133
In the Linux kernel, the following vulnerability has been resolved: LoongArch: Don't crash in stack_top() for tasks without vDSO Not all tasks have a vDSO mapped, for example kthreads never do. If such a task ever ends up calling stack_top(), it will derefence the NULL vdso pointer and crash. This can for example happen when using kunit: [<9000000000203874>] stack_top+0x58/0xa8 [<90000000002956cc>] arch_pick_mmap_layout+0x164/0x220 [<90000000003c284c>] kunit_vm_mmap_init+0x108/0x12c [<90000000003c1fbc>] __kunit_add_resource+0x38/0x8c [<90000000003c2704>] kunit_vm_mmap+0x88/0xc8 [<9000000000410b14>] usercopy_test_init+0xbc/0x25c [<90000000003c1db4>] kunit_try_run_case+0x5c/0x184 [<90000000003c3d54>] kunit_generic_run_threadfn_adapter+0x24/0x48 [<900000000022e4bc>] kthread+0xc8/0xd4 [<9000000000200ce8>] ret_from_kernel_thread+0xc/0xa4 En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: LoongArch: No se bloquea en stack_top() para tareas sin vDSO No todas las tareas tienen un vDSO asignado, por ejemplo, kthreads nunca lo tiene. Si alguna vez una tarea de este tipo termina llamando a stack_top(), desreferenciará el puntero vdso NULL y se bloqueará. Esto puede suceder, por ejemplo, al usar kunit: [<9000000000203874>] stack_top+0x58/0xa8 [<90000000002956cc>] arch_pick_mmap_layout+0x164/0x220 [<90000000003c284c>] kunit_vm_mmap_init+0x108/0x12c [<90000000003c1fbc>] __kunit_add_resource+0x38/0x8c [<90000000003c2704>] kunit_vm_mmap+0x88/0xc8 [<9000000000410b14>] usercopy_test_init+0xbc/0x25c [<90000000003c1db4>] kunit_try_run_case+0x5c/0x184 [<90000000003c3d54>] kunit_generic_run_threadfn_adapter+0x24/0x48 [<900000000022e4bc>] kthread+0xc8/0xd4 [<9000000000200ce8>] ret_from_kernel_thread+0xc/0xa4 • https://git.kernel.org/stable/c/803b0fc5c3f2baa6e54978cd576407896f789b08 https://git.kernel.org/stable/c/a67d4a02bf43e15544179895ede7d5f97b84b550 https://git.kernel.org/stable/c/a94c197d4d749954dfaa37e907fcc8c04e4aad7e https://git.kernel.org/stable/c/041cc3860b06770357876d1114d615333b0fbf31 https://git.kernel.org/stable/c/134475a9ab8487527238d270639a8cb74c10aab2 •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-50132 – tracing/probes: Fix MAX_TRACE_ARGS limit handling
https://notcve.org/view.php?id=CVE-2024-50132
In the Linux kernel, the following vulnerability has been resolved: tracing/probes: Fix MAX_TRACE_ARGS limit handling When creating a trace_probe we would set nr_args prior to truncating the arguments to MAX_TRACE_ARGS. However, we would only initialize arguments up to the limit. This caused invalid memory access when attempting to set up probes with more than 128 fetchargs. BUG: kernel NULL pointer dereference, address: 0000000000000020 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] PREEMPT SMP PTI CPU: 0 UID: 0 PID: 1769 Comm: cat Not tainted 6.11.0-rc7+ #8 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-1.fc39 04/01/2014 RIP: 0010:__set_print_fmt+0x134/0x330 Resolve the issue by applying the MAX_TRACE_ARGS limit earlier. Return an error when there are too many arguments instead of silently truncating. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: rastreo/sondas: Se corrige el manejo del límite MAX_TRACE_ARGS Al crear un trace_probe, estableceríamos nr_args antes de truncar los argumentos a MAX_TRACE_ARGS. Sin embargo, solo inicializaríamos los argumentos hasta el límite. • https://git.kernel.org/stable/c/035ba76014c096316fa809a46ce0a1b9af1cde0d https://git.kernel.org/stable/c/08ccd1a57c4d3882e9a877eb2dcc66e50a3b0279 https://git.kernel.org/stable/c/73f35080477e893aa6f4c8d388352b871b288fbc https://git.kernel.org/stable/c/6bc24db74fe4788cc7c2f30a113fc6aafba225a3 •
CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2024-50131 – tracing: Consider the NULL character when validating the event length
https://notcve.org/view.php?id=CVE-2024-50131
In the Linux kernel, the following vulnerability has been resolved: tracing: Consider the NULL character when validating the event length strlen() returns a string length excluding the null byte. If the string length equals to the maximum buffer length, the buffer will have no space for the NULL terminating character. This commit checks this condition and returns failure for it. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: rastreo: considerar el carácter NULL al validar la longitud del evento strlen() devuelve una longitud de cadena que excluye el byte nulo. Si la longitud de la cadena es igual a la longitud máxima del búfer, el búfer no tendrá espacio para el carácter de terminación NULL. Esta confirmación verifica esta condición y devuelve un error. • https://git.kernel.org/stable/c/dec65d79fd269d05427c8167090bfc9c3d0b56c4 https://git.kernel.org/stable/c/5e3231b352725ff4a3a0095e6035af674f2d8725 https://git.kernel.org/stable/c/02874ca52df2ca2423ba6122039315ed61c25972 https://git.kernel.org/stable/c/b86b0d6eea204116e4185acc35041ca4ff11a642 https://git.kernel.org/stable/c/f4ed40d1c669bba1a54407d8182acdc405683f29 https://git.kernel.org/stable/c/a14a075a14af8d622c576145455702591bdde09d https://git.kernel.org/stable/c/5fd942598ddeed9a212d1ff41f9f5b47bcc990a7 https://git.kernel.org/stable/c/0b6e2e22cb23105fcb171ab92f0f7516c •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-50130 – netfilter: bpf: must hold reference on net namespace
https://notcve.org/view.php?id=CVE-2024-50130
In the Linux kernel, the following vulnerability has been resolved: netfilter: bpf: must hold reference on net namespace BUG: KASAN: slab-use-after-free in __nf_unregister_net_hook+0x640/0x6b0 Read of size 8 at addr ffff8880106fe400 by task repro/72= bpf_nf_link_release+0xda/0x1e0 bpf_link_free+0x139/0x2d0 bpf_link_release+0x68/0x80 __fput+0x414/0xb60 Eric says: It seems that bpf was able to defer the __nf_unregister_net_hook() after exit()/close() time. Perhaps a netns reference is missing, because the netns has been dismantled/freed already. bpf_nf_link_attach() does : link->net = net; But I do not see a reference being taken on net. Add such a reference and release it after hook unreg. Note that I was unable to get syzbot reproducer to work, so I do not know if this resolves this splat. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: netfilter: bpf: debe contener referencia en el espacio de nombres net ERROR: KASAN: slab-use-after-free en __nf_unregister_net_hook+0x640/0x6b0 Lectura de tamaño 8 en la dirección ffff8880106fe400 por la tarea repro/72= bpf_nf_link_release+0xda/0x1e0 bpf_link_free+0x139/0x2d0 bpf_link_release+0x68/0x80 __fput+0x414/0xb60 Eric dice: Parece que bpf pudo diferir __nf_unregister_net_hook() después del tiempo de exit()/close(). Quizás falta una referencia a netns, porque netns ya se ha desmantelado/liberado. bpf_nf_link_attach() hace: link->net = net; Pero no veo que se tome ninguna referencia en net. Agregue dicha referencia y libérela después de anular el registro. Tenga en cuenta que no pude hacer que funcionara el reproductor syzbot, por lo que no sé si esto resuelve este problema. • https://git.kernel.org/stable/c/84601d6ee68ae820dec97450934797046d62db4b https://git.kernel.org/stable/c/f41bd93b3e0508edc7ba820357f949071dcc0acc https://git.kernel.org/stable/c/d0d7939543a1b3bb93af9a18d258a774daf8f162 https://git.kernel.org/stable/c/1230fe7ad3974f7bf6c78901473e039b34d4fb1f •