Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/display: la solución 'panel_cntl' podría ser nula en 'dcn21_set_backlight_level()'. La estructura 'panel_cntl' utilizada para controlar el panel de visualización podría ser nula, desreferenciarla podría conducir a un acceso de puntero nulo. Corrige lo siguiente: drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn21/dcn21_hwseq.c:269 Error de dcn21_set_backlight_level(): previamente asumimos que 'panel_cntl' podría ser nulo (consulte la línea 250)

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: tipc: verifique el tipo de portador antes de llamar a tipc_udp_nl_bearer_add() syzbot informó la siguiente falla de protección general [1]: falla de protección general, probablemente para la dirección no canónica 0xdffffc0000000010: 0000 [#1 ] PREEMPT SMP KASAN KASAN: null-ptr-deref en el rango [0x00000000000000080-0x0000000000000087] ... RIP: 0010:tipc_udp_is_known_peer+0x9c/0x250 net/tipc/udp_media.c:291 ... Seguimiento de llamadas: tipc_udp_ nl_bearer_add+ 0x212/0x2f0 net/tipc/udp_media.c:646 tipc_nl_bearer_add+0x21e/0x360 net/tipc/bearer.c:1089 genl_family_rcv_msg_doit+0x1fc/0x2e0 net/netlink/genetlink.c:972 genl_family_rcv_msg net/netlink/genetlink. c:1052 [en línea] genl_rcv_msg+0x561/0x800 net/netlink/genetlink.c:1067 netlink_rcv_skb+0x16b/0x440 net/netlink/af_netlink.c:2544 genl_rcv+0x28/0x40 net/netlink/genetlink.c:1076 netlink_unicast_kernel net/netlink/ af_netlink.c:1341 [en línea] netlink_unicast+0x53b/0x810 net/netlink/af_netlink.c:1367 netlink_sendmsg+0x8b7/0xd70 net/netlink/af_netlink.c:1909 sock_sendmsg_nosec net/socket.c:730 [en línea] __sock_sendmsg+0xd 5 /0x180 net/socket.c:745 ____sys_sendmsg+0x6ac/0x940 net/socket.c:2584 ___sys_sendmsg+0x135/0x1d0 net/socket.c:2638 __sys_sendmsg+0x117/0x1e0 net/socket.c:2667 do_syscall_x 64 arco/x86/ Entry/common.c:52 [en línea] do_syscall_64+0x40/0x110 arch/x86/entry/common.c:83 Entry_SYSCALL_64_after_hwframe+0x63/0x6b La causa de este problema es que cuando se llama a tipc_nl_bearer_add() con el atributo TIPC_NLA_BEARER_UDP_OPTS, tipc_udp_nl_bear er_añadir () se llama incluso si el portador no es UDP. tipc_udp_is_known_peer() llamado por tipc_udp_nl_bearer_add() supone que el campo media_ptr de tipc_bearer tiene un objeto de tipo udp_bearer, por lo que la función se vuelve loca para los portadores que no son UDP. Este parche soluciona el problema al verificar el tipo de portador antes de llamar a tipc_udp_nl_bearer_add() en tipc_nl_bearer_add().

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: hwmon: (coretemp) Arreglar el acceso a memoria fuera de los límites Arreglar un error que pdata->cpu_map[] está configurado antes de la verificación de los límites. El problema podría surgir en sistemas con más de 128 núcleos por paquete.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: túneles: corrige el acceso fuera de los límites al compilar el error IPv6 PMTU Si el error ICMPv6 se genera a partir de un skb no lineal, obtenemos el siguiente símbolo, ERROR: KASAN: slab-out- fuera de los límites en do_csum+0x220/0x240 Lectura de tamaño 4 en la dirección ffff88811d402c80 por tarea netperf/820 CPU: 0 PID: 820 Comm: netperf Not tainted 6.8.0-rc1+ #543 ... kasan_report+0xd8/0x110 do_csum+0x220 /0x240 csum_partial+0xc/0x20 skb_tunnel_check_pmtu+0xeb9/0x3280 vxlan_xmit_one+0x14c2/0x4080 vxlan_xmit+0xf61/0x5c00 dev_hard_start_xmit+0xfb/0x510 __dev_queue_xmit+0x7cd/0x32 a0 br_dev_queue_push_xmit+0x39d/0x6a0 Utilice skb_checksum en lugar de csum_partial, que no puede manejar SKB no lineales.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: wifi: mac80211: corrige el uso de RCU en TDLS fast-xmit Esto busca el enlace bajo protección de RCU, pero no se garantiza que realmente tenga protección. Arregla eso.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/msm/dpu: check for valid hw_pp en dpu_encoder_helper_phys_cleanup. El commit 8b45a26f2ba9 ("drm/msm/dpu: reserve bloques cdm para reescritura en caso de salida YUV") introdujo una coincidencia advertencia sobre otro bloque condicional en dpu_encoder_helper_phys_cleanup() que había asumido que hw_pp siempre será válido, lo que puede no ser necesariamente cierto. Arreglemos el otro bloque condicional asegurándonos de que hw_pp sea válido antes de eliminar la referencia a él. Remiendo: https://patchwork.freedesktop.org/patch/574878/

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: netfilter: nft_limit: rechazar configuraciones que causan desbordamiento de enteros Rechazar configuraciones falsas donde el contador de token interno se ajusta. Esto sólo ocurre con solicitudes muy grandes, como 17 gbytes/s. Es mejor rechazar esto en lugar de tener un límite de tasa incorrecto.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/sched: flower: descarga de plantilla de cadena fija Cuando se elimina una qdisc de un dispositivo de red, la pila indica al controlador subyacente que elimine su devolución de llamada de descarga de flujo del bloque de filtro asociado mediante el comando Comando 'FLOW_BLOCK_UNBIND'. Luego, la pila continúa reproduciendo la eliminación de los filtros en el bloque para este controlador iterando sobre las cadenas en el bloque e invocando la operación de "redescarga" del clasificador que se está utilizando. A su vez, el clasificador en su operación de 'redescarga' prepara y emite un comando 'FLOW_CLS_DESTROY' para cada filtro. Sin embargo, la pila no hace lo mismo con las plantillas de cadena y el controlador subyacente nunca recibe un comando 'FLOW_CLS_TMPLT_DESTROY' cuando se elimina una qdisc. Esto da como resultado una pérdida de memoria [1] que se puede reproducir usando [2]. Para solucionarlo, introduzca una operación 'tmplt_reoffload' y haga que la pila la invoque con los argumentos apropiados como parte de la reproducción. Implemente la operación en el único clasificador que admite plantillas de cadena (flor) emitiendo el comando 'FLOW_CLS_TMPLT_{CREATE,DESTROY}' en función de si una devolución de llamada de descarga de flujo está vinculada a un bloque de filtro o no está vinculada a uno. Por lo que puedo decir, el problema ocurre desde el commit que reordenó tcf_block_offload_unbind() antes de tcf_block_flush_all_chains() en __tcf_block_put(). El orden no se puede invertir ya que se espera que el bloque del filtro se libere después de lavar todas las cadenas. [1] objeto sin referencia 0xffff888107e28800 (tamaño 2048): comm "tc", pid 1079, jiffies 4294958525 (edad 3074.287s) volcado hexadecimal (primeros 32 bytes): b1 a6 7c 11 81 88 ff ff e0 5b b3 10 81 88 ff f ..|......[...... 01 00 00 00 00 00 00 00 e0 aa b0 84 ff ff ff ff ................ retroceso: [] __kmem_cache_alloc_node+0x1e8/0x320 [] __kmalloc+0x4e/0x90 [] mlxsw_sp_acl_ruleset_get+0x34d/0x7a0 [] mlxsw_sp_flower_tmplt_create+0x145/0x180 [] mlxsw_sp_flow_block_cb+0x1ea/0x280 [] tc_setup_cb_call+0x183/0x340 [] fl_tmplt_create+0x3da/0x4c0 [] tc_ctl_chain+0xa15/0x1170 [] rtnetlink_rcv_msg+0x3cc/0xed0 [] netlink_rcv_skb+0x170/0x440 [] netlink_unicast+0x540/0x820 [] netlink_sendmsg+0x8d8/0xda0 [] ____sys_sendmsg+0x30f/0xa80 [] ___sys_ enviarmsg+0x13a/0x1e0 [] __sys_sendmsg+0x11c/0x1f0 [] do_syscall_64+0x40/0xe0 objeto sin referencia 0xffff88816d2c0400 (tamaño 1024): comm "tc", pid 1079, santiamén 4294958525 (edad 3074.287s) volcado hexadecimal (primeros 32 bytes): 40 00 00 00 00 00 00 00 57 f6 38 be 00 00 00 00 @.......W.8..... 10 04 2c 6d 81 88 ff ff 10 04 2c 6d 81 88 ff ff ..,m......, m.... retroceso: [] __kmem_cache_alloc_node+0x1e8/0x320 [] __kmalloc_node+0x51/0x90 [] kvmalloc_node+0xa6/0x1f0 [] bucket_table_alloc.isra.0+0x83/ 0x460 [] rhashtable_init+0x43b/0x7c0 [] mlxsw_sp_acl_ruleset_get+0x428/0x7a0 [] mlxsw_sp_flower_tmplt_create+0x145/0x180 [] mlxsw_sp_flow_block_cb+0x1ea/0x280 [] tc_setup_cb_call+0x183/ 0x340 [] fl_tmplt_create+0x3da/0x4c0 [] tc_ctl_chain+0xa15/0x1170 [] rtnetlink_rcv_msg+0x3cc/0xed0 [] netlink_rcv_skb+0x170/0x440 [] netlink_unicast+0x540/ 0x820 [] netlink_sendmsg+0x8d8/0xda0 [] ____sys_sendmsg+0x30f/0xa80 [2] # ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: arm64: entrada: arreglar ARM64_WORKAROUND_SPECULATIVE_UNPRIV_LOAD Actualmente, la solución alternativa ARM64_WORKAROUND_SPECULATIVE_UNPRIV_LOAD no es del todo correcta, ya que se supone que debe aplicarse después del último acceso explícito a la memoria, pero va seguida inmediatamente por un LDR. La solución alternativa ARM64_WORKAROUND_SPECULATIVE_UNPRIV_LOAD se utiliza para manejar las erratas Cortex-A520 2966298 y Cortex-A510 erratas 3117295, que se describen en: * https://developer.arm.com/documentation/SDEN2444153/0600/?lang=en * https:// desarrollador.arm.com/documentation/SDEN1873361/1600/?lang=en En ambos casos, la solución se describe como: | Si el aislamiento de la tabla de páginas está deshabilitado, la lógica de cambio de contexto en | El kernel se puede actualizar para ejecutar la siguiente secuencia en los afectados | núcleos antes de salir a EL0 y después de todos los accesos explícitos a la memoria: | | 1. Un TLBI que no se puede compartir en cualquier contexto y/o dirección, incluido | contextos o direcciones no utilizados, como `TLBI VALE1 Xzr`. | | 2. Un OSD NSH para garantizar la finalización del TLBI. La parte importante es que el TLBI+DSB debe colocarse "después de todos los accesos explícitos a la memoria". Desafortunadamente, tal como se implementó, el TLBI+DSB es seguido inmediatamente por un LDR, como tenemos: | Alternative_if ARM64_WORKAROUND_SPECULATIVE_UNPRIV_LOAD | tlbi vale1, xzr | dsb nsh | alternativa_else_nop_endif | alternativa_si_no ARM64_UNMAP_KERNEL_AT_EL0 | ldr lr, [sp, #S_LR] | agregar sp, sp, #PT_REGS_SIZE // restaurar sp | eremita | alternativa_else_nop_endif | | [... Ruta de retorno de excepción KPTI...] Este parche soluciona este problema reelaborando la lógica para colocar TLBI+DSB inmediatamente antes de ERET, después de todos los accesos explícitos a la memoria. El ERET se encuentra actualmente en un bloque alternativo separado y las alternativas no se pueden anidar. Para tener en cuenta esto, el bloque alternativo para ARM64_UNMAP_KERNEL_AT_EL0 se reemplaza con una única rama alternativa para omitir la lógica KPTI, siendo la nueva forma de la lógica: | Alternative_insn "b .L_skip_tramp_exit_\@", nop, ARM64_UNMAP_KERNEL_AT_EL0 | [... Ruta de retorno de excepción KPTI...] | .L_skip_tramp_exit_\@: | | ldr lr, [sp, #S_LR] | agregar sp, sp, #PT_REGS_SIZE // restaurar sp | | Alternative_if ARM64_WORKAROUND_SPECULATIVE_UNPRIV_LOAD | tlbi vale1, xzr | dsb nsh | alternativa_else_nop_endif | eret La nueva estructura significa que la solución alternativa sólo se aplica cuando KPTI no está en uso; esto está bien, como se indica en las implicaciones documentadas de la fe de erratas: | El aislamiento de la tabla de paginación entre EL0 y los EL de nivel superior evita que | que ocurra el problema. ... y según la descripción de la solución citada anteriormente, la solución sólo es necesaria "si el aislamiento de la tabla de páginas está deshabilitado".

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: blk-mq: corrige el bloqueo de IO de la carrera de activación del mapa de bits En blk_mq_mark_tag_wait(), __add_wait_queue() se puede reordenar con el siguiente blk_mq_get_driver_tag() en caso de que se produzca un error en la etiqueta del controlador. Luego, en __sbitmap_queue_wake_up(), waitqueue_active() puede no observar al camarero agregado en blk_mq_mark_tag_wait() y no despertar nada, mientras tanto, blk_mq_mark_tag_wait() no puede obtener la etiqueta del controlador correctamente. Este problema se puede reproducir ejecutando la siguiente prueba en bucle, y se puede observar un bloqueo de fio en < 30 minutos cuando lo ejecuto en mi máquina virtual de prueba en una computadora portátil. modprobe -r scsi_debug modprobe scsi_debug delay=0 dev_size_mb=4096 max_queue=1 host_max_queue=1 submit_queues=4 dev=`ls -d /sys/bus/pseudo/drivers/scsi_debug/adapter*/host*/target*/*/block /* | cabeza -1 | xargs basename` fio --filename=/dev/"$dev" --direct=1 --rw=randrw --bs=4k --io Depth=1 \ --runtime=100 --numjobs=40 --time_based - -name=test \ --ioengine=libaio Solucione el problema agregando una barrera explícita en blk_mq_mark_tag_wait(), lo cual está bien en caso de quedarse sin etiqueta.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amdgpu: corrige la variable 'mca_funcs' desreferenciada antes de la comprobación NULL en 'amdgpu_mca_smu_get_mca_entry()' Corrige lo siguiente: drivers/gpu/drm/amd/amdgpu/amdgpu_mca.c:377 amdgpu_mca_smu_get_mca_entry() advertencia: variable desreferenciada antes de verificar 'mca_funcs' (ver línea 368) 357 int amdgpu_mca_smu_get_mca_entry(struct amdgpu_device *adev, enum amdgpu_mca_error_type type, 358 int idx, struct mca_bank_entry *entry) 359 { 360 const struct amdgpu_mca_smu_funcs *mca_funcs = adev- >mca.mca_funcs; 361 recuentos internacionales; 362 363 interruptor (tipo) { 364 caso AMDGPU_MCA_ERROR_TYPE_UE: 365 recuento = mca_funcs->max_ue_count; Aquí se elimina la referencia a mca_funcs. 366 descanso; 367 caso AMDGPU_MCA_ERROR_TYPE_CE: 368 recuento = mca_funcs->max_ce_count; Aquí se elimina la referencia a mca_funcs. 369 descanso; 370 predeterminado: 371 retorno -EINVAL; 372 } 373 374 si (idx >= recuento) 375 retorno -EINVAL; 376 377 if (mca_funcs && mca_funcs->mca_get_mca_entry) ^^^^^^^^^ ¡Comprobado demasiado tarde!

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: netfilter: nft_ct: desinfecta el número de protocolo de capa 3 y 4 en expectativas personalizadas - No permitir familias que no sean NFPROTO_{IPV4,IPV6,INET}. - No permitir el protocolo de capa 4 sin puertos, ya que el puerto de destino es un atributo obligatorio para este objeto.