Vulnerabilidades

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: drm/amd/display: corrige un posible índice fuera de los límites en la función de transformación de color. Corrige el problema de índice fuera de los límites en la función de transformación de color. El problema podría ocurrir cuando el índice 'i' excede la cantidad de puntos de función de transferencia (TRANSFER_FUNC_POINTS). La solución agrega una verificación para garantizar que 'i' esté dentro de los límites antes de acceder a los puntos de función de transferencia. Si 'i' está fuera de los límites, se registra un mensaje de error y la función devuelve falso para indicar un error. Reportado por smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:405 cm_helper_translate_curve_to_hw_format() error: desbordamiento del búfer 'output_tf->tf_pts.red' 1025 <= controladores s32max/gpu /drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:406 cm_helper_translate_curve_to_hw_format() error: desbordamiento del búfer 'output_tf->tf_pts.green' 1025 <= controladores s32max/gpu/drm/amd/amdgpu/ ../display/dc/dcn10/dcn10_cm_common.c:407 error de cm_helper_translate_curve_to_hw_format(): desbordamiento del búfer 'output_tf->tf_pts.blue' 1025 <= s32max

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/mlx5: descartar la finalización de comandos en caso de error interno. Se corrige el use-after-free cuando llega la finalización del FW mientras el dispositivo está en estado de error interno. Evite llamar al controlador de finalización en este caso, ya que el dispositivo limpiará la interfaz de comando y activará todas las finalizaciones manualmente. Registro del kernel: ------------[ cortar aquí ]------------ refcount_t: underflow; use-after-free. ... RIP: 0010:refcount_warn_saturate+0xd8/0xe0 ... Seguimiento de llamadas: ? __advertir+0x79/0x120 ? refcount_warn_saturate+0xd8/0xe0? report_bug+0x17c/0x190? handle_bug+0x3c/0x60? exc_invalid_op+0x14/0x70? asm_exc_invalid_op+0x16/0x20? refcount_warn_saturate+0xd8/0xe0 cmd_ent_put+0x13b/0x160 [mlx5_core] mlx5_cmd_comp_handler+0x5f9/0x670 [mlx5_core] cmd_comp_notifier+0x1f/0x30 [mlx5_core] notifier_call_chain+0x35/0xb0 cadena+0x16/0x20 mlx5_eq_async_int+0xf6/0x290 [mlx5_core] notifier_call_chain+0x35 /0xb0 atomic_notifier_call_chain+0x16/0x20 irq_int_handler+0x19/0x30 [mlx5_core] __handle_irq_event_percpu+0x4b/0x160 handle_irq_event+0x2e/0x80 handle_edge_irq+0x98/0x230 __common_interrupt+0x3b/0 xa0 interrupción_común+0x7b/0xa0 asm_interrupción_común+0x22 /0x40

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/mlx5: agrega un tiempo de espera para adquirir el semáforo de la cola de comandos. Evita el manejo de finalización forzada en una entrada a la que aún no se le ha asignado un índice, lo que provoca un acceso fuera de los límites en idx = -22. En lugar de esperar indefinidamente el sem, el flujo de bloqueo ahora espera a que se asigne el índice o a que se agote el tiempo de espera de adquisición del sem antes de iniciar el temporizador para completar el FW. Ejemplo de registro del kernel: mlx5_core 0000:06:00.0: wait_func_handle_exec_timeout:1128:(pid 185911): cmd[-22]: CREATE_UCTX(0xa04) No se completó

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: openvswitch: corrige la sobrescritura de la tupla original de ct para ICMPv6 OVS_PACKET_CMD_EXECUTE tiene 3 atributos principales: - OVS_PACKET_ATTR_KEY - Metadatos de paquetes en formato netlink. - OVS_PACKET_ATTR_PACKET: contenido del paquete binario. - OVS_PACKET_ATTR_ACTIONS: acciones a ejecutar en el paquete. OVS_PACKET_ATTR_KEY se analiza primero para completar la estructura sw_flow_key con metadatos como el estado de conexión, el puerto de entrada, la identificación de recirculación, etc. Luego, el paquete en sí se analiza para completar el resto de las claves de los encabezados del paquete. Siempre que el código de análisis de paquetes comienza a analizar el encabezado ICMPv6, primero pone a cero los campos en la clave correspondiente a la información de descubrimiento de vecinos, incluso si no es un paquete ND. Es un campo 'ipv6.nd'. Sin embargo, 'ipv6' es una unión que comparte el espacio entre 'nd' y 'ct_orig' que contiene los metadatos de conntrack de tupla originales analizados a partir de OVS_PACKET_ATTR_KEY. Los paquetes ND normalmente no deberían tener estado de seguimiento, por lo que está bien compartir el espacio, pero los paquetes ICMPv6 Echo normales o tal vez otros tipos de ICMPv6 pueden tener el estado adjunto y no deben sobrescribirse. El problema provoca que todos, excepto los últimos 4 bytes de la dirección de destino, se borren de la tupla conntrack original, lo que provoca una coincidencia incorrecta de paquetes y, potencialmente, la ejecución de acciones incorrectas en caso de que este paquete recircule dentro de la ruta de datos o regrese al espacio de usuario. No se debe acceder a los campos ND en paquetes que no sean ND, por lo que no borrarlos debería estar bien. Ejecutar memset() solo para paquetes ND reales para evitar el problema. Es necesario inicializar todo antes del análisis porque es posible que el paquete ND no contenga todas las opciones. El problema solo afecta la ruta OVS_PACKET_CMD_EXECUTE y no afecta a los paquetes que ingresan a la ruta de datos OVS desde las interfaces de red, porque en este caso los metadatos CT se completan desde skb después de que el paquete ya se haya analizado.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bnxt_re: evita el comportamiento de cambio indefinido en bnxt_qplib_alloc_init_hwq El comportamiento indefinido se activa cuando se llama a bnxt_qplib_alloc_init_hwq con hwq_attr->aux_ Depth != 0 y hwq_attr->aux_stride == 0. En ese caso, " Se llama a roundup_pow_of_two(hwq_attr->aux_stride)". roundup_pow_of_two está documentado como indefinido para 0. Corríjalo en la única persona que llamó que tenía esta combinación. UBSAN detectó el comportamiento indefinido: UBSAN: desplazamiento fuera de los límites en ./include/linux/log2.h:57:13 el exponente de desplazamiento 64 es demasiado grande para CPU 'long unsigned int' de tipo de 64 bits: 24 PID: 1075 Comm: (udev-worker) Not tainted 6.9.0-rc6+ #4 Nombre del hardware: Abacus electric, sro - servis@abacus.cz Super Server/H12SSW-iN, BIOS 2.7 25/10/2023 Seguimiento de llamadas: < TAREA> dump_stack_lvl+0x5d/0x80 ubsan_epilogue+0x5/0x30 __ubsan_handle_shift_out_of_bounds.cold+0x61/0xec __roundup_pow_of_two+0x25/0x35 [bnxt_re] bnxt_qplib_alloc_init_hwq+0xa1/0x470 bnxt_re] bnxt_qplib_create_qp+0x19e/0x840 [bnxt_re] bnxt_re_create_qp+0x9b1/0xcd0 [bnxt_re ] ? srso_alias_return_thunk+0x5/0xfbef5? srso_alias_return_thunk+0x5/0xfbef5? __kmalloc+0x1b6/0x4f0 ? create_qp.part.0+0x128/0x1c0 [ib_core]? __pfx_bnxt_re_create_qp+0x10/0x10 [bnxt_re] create_qp.part.0+0x128/0x1c0 [ib_core] ib_create_qp_kernel+0x50/0xd0 [ib_core] create_mad_qp+0x8e/0xe0 [ib_core] ? __pfx_qp_event_handler+0x10/0x10 [ib_core] ib_mad_init_device+0x2be/0x680 [ib_core] add_client_context+0x10d/0x1a0 [ib_core] enable_device_and_get+0xe0/0x1d0 [ib_register_device+0x53c/0x63 0 [ib_core] ? srso_alias_return_thunk+0x5/0xfbef5 bnxt_re_probe+0xbd8/0xe50 [bnxt_re] ? __pfx_bnxt_re_probe+0x10/0x10 [bnxt_re] sonda_bus_auxiliar+0x49/0x80 ? driver_sysfs_add+0x57/0xc0 realmente_probe+0xde/0x340? pm_runtime_barrier+0x54/0x90? __pfx___driver_attach+0x10/0x10 __driver_probe_device+0x78/0x110 driver_probe_device+0x1f/0xa0 __driver_attach+0xba/0x1c0 bus_for_each_dev+0x8f/0xe0 bus_add_driver+0x146/0x220 driver_register+0x72/ 0xd0 __auxiliary_driver_register+0x6e/0xd0 ? __pfx_bnxt_re_mod_init+0x10/0x10 [bnxt_re] bnxt_re_mod_init+0x3e/0xff0 [bnxt_re] ? __pfx_bnxt_re_mod_init+0x10/0x10 [bnxt_re] do_one_initcall+0x5b/0x310 do_init_module+0x90/0x250 init_module_from_file+0x86/0xc0 idempotent_init_module+0x121/0x2b0 __x64_sys_finit _module+0x5e/0xb0 do_syscall_64+0x82/0x160 ? srso_alias_return_thunk+0x5/0xfbef5? syscall_exit_to_user_mode_prepare+0x149/0x170? srso_alias_return_thunk+0x5/0xfbef5? syscall_exit_to_user_mode+0x75/0x230? srso_alias_return_thunk+0x5/0xfbef5? do_syscall_64+0x8e/0x160? srso_alias_return_thunk+0x5/0xfbef5? __count_memcg_events+0x69/0x100? srso_alias_return_thunk+0x5/0xfbef5? count_memcg_events.constprop.0+0x1a/0x30? srso_alias_return_thunk+0x5/0xfbef5? handle_mm_fault+0x1f0/0x300? srso_alias_return_thunk+0x5/0xfbef5? do_user_addr_fault+0x34e/0x640? srso_alias_return_thunk+0x5/0xfbef5? srso_alias_return_thunk+0x5/0xfbef5 Entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7f4e5132821d Código: ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 9 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d e3 db 0c 00 f7 d8 64 89 01 48 RSP: 002b:00007ffca9c906a8 EFLAGS: 00000246 IG_RAX: 0000000000000139 RAX: ffffffffffffffda RBX: 0000563ec8a8f130 RCX: 00007f4e5132821d RDX: 0000000000000000 RSI: 00007f4e518fa07d RDI: 000000000000003b RBP: 00007ffca9c90760 R08: 00007f4e513f6b20 00007ffca9c906f0 R10: 0000563ec8a8faa0 R11: 0000000000000246 R12: 00007f4e518fa07d R13: 0000000000020000 R14: 0000563ec8409e90 R15: 0563ec8a8fa60 ---[ finalizar rastreo ] ---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: lib/test_hmm.c: maneja el error de asignación de src_pfns y dst_pfns El kcalloc() en dmirror_device_evict_chunk() devolverá nulo si la memoria física se ha agotado. Como resultado, si se desreferencia src_pfns o dst_pfns, se producirá el error de desreferencia del puntero nulo. Además, el dispositivo va a desaparecer. Si kcalloc() falla, las páginas que asignan un fragmento no podrán ser desalojadas. Entonces agregue una bandera __GFP_NOFAIL en kcalloc(). Finalmente, como no es necesario tener memoria físicamente contigua, cambie kcalloc() a kvcalloc() para evitar asignaciones fallidas.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm: vc4: corrige posible desreferencia del puntero nulo En vc4_hdmi_audio_init() of_get_address() puede devolver NULL, que luego se desreferencia. Corrija este error agregando una verificación NULL. Encontrado por el Centro de verificación de Linux (linuxtesting.org) con SVACE.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: media: atomisp: ssh_css: corrige una desreferencia de puntero nulo en load_video_binaries La falla de asignación de mycs->yuv_scaler_binary en load_video_binaries() va seguida de una desreferencia de mycs->yuv_scaler_binary después de siguiente cadena de llamadas: sh_css_pipe_load_binaries() |-> load_video_binaries(mycs->yuv_scaler_binary == NULL) | |-> sh_css_pipe_unload_binaries() |-> unload_video_binaries() En unload_video_binaries(), llama a ia_css_binary_unload con el argumento &pipe->pipe_settings.video.yuv_scaler_binary[i], que se refiere a la misma ranura de memoria que mycs->yuv_scaler_binary. Por lo tanto, se activa una desreferencia de puntero nulo.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: net: bridge: xmit: asegúrese de tener al menos el encabezado eth len bytes syzbot desencadenó un error de valor uninit[1] en la ruta xmit del dispositivo puente al enviar un mensaje corto (menos de ETH_HLEN bytes) skb. Para solucionarlo, compruebe si realmente podemos retirar esa cantidad en lugar de suponerla. Probado con dropwatch: soltar en: br_dev_xmit+0xb93/0x12d0 [puente] (0xffffffffc06739b3) origen: marca de tiempo del software: lunes 13 de mayo 11:31:53 2024 778214037 protocolo nsec: 0x88a8 longitud: 2 longitud original: 2 motivo de caída: PKT_TOO_SMALL [1 ] ERROR: KMSAN: valor uninit en br_dev_xmit+0x61d/0x1cb0 net/bridge/br_device.c:65 br_dev_xmit+0x61d/0x1cb0 net/bridge/br_device.c:65 __netdev_start_xmit include/linux/netdevice.h:4903 [en línea] netdev_start_xmit include/linux/netdevice.h:4917 [en línea] xmit_one net/core/dev.c:3531 [en línea] dev_hard_start_xmit+0x247/0xa20 net/core/dev.c:3547 __dev_queue_xmit+0x34db/0x5350 net/core/dev .c:4341 dev_queue_xmit include/linux/netdevice.h:3091 [en línea] __bpf_tx_skb net/core/filter.c:2136 [en línea] __bpf_redirect_common net/core/filter.c:2180 [en línea] __bpf_redirect+0x14a6/0x1620 net/ Core/Filter.C: 2187 ____BPF_CLONE_REDIRECT NET/CORE/FILTRO.C: 2460 [Inline] BPF_CLONE_REDIRECT+0x328/0x470 NET/Core/Filter.c: 2432 ___ BPF_PROG_RUN+0X13FE/0XE0F0 KERNEL/BPF/BPF/CORE. 0xb5/0xe0 kernel/bpf/core.c:2238 bpf_dispatcher_nop_func include/linux/bpf.h:1234 [en línea] __bpf_prog_run include/linux/filter.h:657 [en línea] bpf_prog_run include/linux/filter.h:664 [en línea ] bpf_test_run+0x499/0xc30 net/bpf/test_run.c:425 bpf_prog_test_run_skb+0x14ea/0x1f20 net/bpf/test_run.c:1058 bpf_prog_test_run+0x6b7/0xad0 kernel/bpf/syscall.c:4269 pf+0x6aa/0xd90 núcleo/ bpf/syscall.c:5678 __do_sys_bpf kernel/bpf/syscall.c:5767 [en línea] __se_sys_bpf kernel/bpf/syscall.c:5765 [en línea] __x64_sys_bpf+0xa0/0xe0 kernel/bpf/syscall.c:5765 ys_call+0x96b /0x3b50 arch/x86/include/generated/asm/syscalls_64.h:322 do_syscall_x64 arch/x86/entry/common.c:52 [en línea] do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83 Entry_SYSCALL_64_after_hwframe+ 0x77/0x7f

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: RDMA/cma: corrija kmemleak en rdma_core observado durante el uso de blktests nvme/rdma siw Al ejecutar blktests nvme/rdma, aparecerá el siguiente problema de kmemleak. kmemleak: detector de pérdida de memoria del kernel inicializado (mempool disponible: 36041) kmemleak: hilo de escaneo automático de memoria iniciado kmemleak: 2 nuevas pérdidas de memoria sospechosas (ver /sys/kernel/debug/kmemleak) kmemleak: 8 nuevas pérdidas de memoria sospechosas (ver /sys/ kernel/debug/kmemleak) kmemleak: 17 nuevas pérdidas de memoria sospechosas (ver /sys/kernel/debug/kmemleak) kmemleak: 4 nuevas pérdidas de memoria sospechosas (ver /sys/kernel/debug/kmemleak) objeto sin referencia 0xffff88855da53400 (tamaño 192): comm "rdma", pid 10630, sjiffies 4296575922 volcado hexadecimal (primeros 32 bytes): 37 00 00 00 00 00 00 00 c0 ff ff ff 1f 00 00 00 7................. 10 34 a5 5d 85 88 ff ff 10 34 a5 5d 85 88 ff ff .4.].....4.].... backtrace (crc 47f66721): [] kmalloc_trace+0x30d/0x3b0 [< ffffffffc2640ff7>] alloc_gid_entry+0x47/0x380 [ib_core] [] add_modify_gid+0x166/0x930 [ib_core] [] ib_cache_update.part.0+0x6d8/0x910 [ib_core] [] ib_cache_setup_one+0x24a/ 0x350 [ib_core] [] ib_register_device+0x9e/0x3a0 [ib_core] [] 0xffffffffc2a3d389 [] nldev_newlink+0x2b8/0x520 [ib_core] ffffffffc2645fe3>] rdma_nl_rcv_msg+0x2c3/0x520 [ib_core] [ ] rdma_nl_rcv_skb.constprop.0.isra.0+0x23c/0x3a0 [ib_core] [] netlink_unicast+0x445/0x710 [] 0 [] __sys_sendto+0x3a9/0x420 [] __x64_sys_sendto+0xdc/0x1b0 [] do_syscall_64+0x93/0x180 [] Entry_SYSCALL_64_after_hwframe+0x71/0x79 La causa raíz: _gid_attr no se llama cuando sgid_attr está configurado en ERR_PTR(-ENODEV).

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: of: módulo: agregar control de desbordamiento del búfer of_modalias() En of_modalias(), si el búfer es demasiado pequeño incluso para la primera llamada a snprintf(), el parámetro len se vuelve negativo y el parámetro str (si no es NULL inicialmente) apuntará más allá del final del búfer. Agregue la verificación de desbordamiento del búfer después de la primera llamada a snprintf() y corrija dicha verificación después de la llamada strlen() (teniendo en cuenta el carácter NUL de terminación).

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: RDMA/mana_ib: verificación de los límites antes de instalar devoluciones de llamadas de cq Agregue una verificación de los límites dentro de mana_ib_install_cq_cb para evitar el desbordamiento del índice.