Vulnerabilidades

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: virtio_net: corrige la advertencia de napi_skb_cache_put Después de que se fusionó el commit bdacf3e34945 ("net: Use bloqueo de BH anidado para napi_alloc_cache."), comenzó a aparecer la siguiente advertencia: ADVERTENCIA: CPU: 5 PID: 1 en net/core/skbuff.c:1451 napi_skb_cache_put+0x82/0x4b0 __warn+0x12f/0x340 napi_skb_cache_put+0x82/0x4b0 napi_skb_cache_put+0x82/0x4b0 report_bug+0x165/0x370 x80 exc_invalid_op+0x1a/0x50 asm_exc_invalid_op+ 0x1a/0x20 __free_old_xmit+0x1c8/0x510 napi_skb_cache_put+0x82/0x4b0 __free_old_xmit+0x1c8/0x510 __free_old_xmit+0x1c8/0x510 __pfx___free_old_xmit+0x10/0x10 El problema surge porque virtio asumiendo que se está ejecutando en el contexto NAPI incluso cuando no lo es, como en netpoll caso. Para resolver esto, modifique virtnet_poll_tx() para configurar NAPI solo cuando haya presupuesto disponible. Lo mismo ocurre con virtnet_poll_cleantx(), que siempre asumió que estaba en un contexto NAPI.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf: Se corrigió la desreferencia del puntero nulo en resolve_prog_type() para BPF_PROG_TYPE_EXT Al cargar un programa EXT sin especificar `attr->attach_prog_fd`, el `prog->aux->dst_prog` será nulo. En este momento, llamar a resolve_prog_type() en cualquier lugar dará como resultado una desreferencia del puntero nulo. Ejemplo de seguimiento de pila: [8.107863] No se puede manejar la desreferencia del puntero NULL del kernel en la dirección virtual 0000000000000004 [8.108262] Información de cancelación de memoria: [8.108384] ESR = 0x0000000096000004 [8.108547] EC = 0x25: DABT (EL actual), IL = 32 bits [8.108722 ] SET = 0, FnV = 0 [8.108827] EA = 0, S1PTW = 0 [8.108939] FSC = 0x04: error de traducción de nivel 0 [8.109102] Información de cancelación de datos: [8.109203] ISV = 0, ISS = 0x00000004, ISS2 = 00 [ 8.109399] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 8.109614] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 8.109836] tabla de páginas de usuario: páginas de 4k, VA de 48 bits, pgdp=0000000101354000 [8.110011] [00000000000000004] pgd=0000000000000000, p4d=0000000000000000 [8.112624] Error interno: Vaya: 0000000096000 004 [#1] PREEMPT SMP [8.112783] Módulos vinculados en: [8.113120] CPU: 0 PID: 99 Comm: may_access_dire No contaminado 6.10.0-rc3-next-20240613-dirty #1 [8.113230] Nombre de hardware: linux,dummy-virt (DT) [8.113390] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE= --) [8.113429] pc: may_access_direct_pkt_data+0x24/0xa0 [8.113746] lr: add_subprog_and_kfunc+0x634/0x8e8 [8.113798] sp: ffff80008283b9f0 [8.113813] x29: 83b9f0 x28: ffff800082795048 x27: 00000000000000001 [ 8.113881] x26: ffff0000c0bb2600 x25: 0000000000000000 x24: 0000000000000000 [8.113897] x23: ffff0000c1134000 x22: 000000000001864f x21: ffff0000c1138000 [8.113912] x20: 0000000000000001 x19: ffff0000c12b8000 x18: ffffffffffffffff [ 8.113929] x17: 0000000000000000 x16: 00000000000000000 x15: 0720072007200720 [ 8.113944] x14: 20072007200720 x13: 0720072007200720 x12: 0720072007200720 [8.113958] x11: 0720072007200720 x10: 0000000000f9fca4 x9: ffff80008021f4e4 [8.113991] x8: 0101010101010101 x7: 46f72705f6d656d x6: 000000001e0e0f5f [8.114006] x5: 000000000001864f x4: ffff0000c12b8000 x3: 000000000000001c [8.114020] x2: 00000000002 x1: 0000000000000000 x0: 0000000000000000 [ 8.114126] Seguimiento de llamadas: [8.114159] may_access_direct_pkt_data+0x24/0xa0 [8.114202] bpf_check+0x3bc/0x28c0 [8.114214] bpf_prog_load+0x658/0xa58 [8.114227] xc50/0x2250 [8.114240] __arm64_sys_bpf+0x28/0x40 [8.114254] invoke_syscall. constprop.0+0x54/0xf0 [8.114273] do_el0_svc+0x4c/0xd8 [8.114289] el0_svc+0x3c/0x140 [8.114305] el0t_64_sync_handler+0x134/0x150 [8.114331] _sync+0x168/0x170 [8.114477] Código: 7100707f 54000081 f9401c00 f9403800 (b9400403 ) [8.118672] ---[ end trace 0000000000000000 ]--- Una forma de solucionarlo es forzando que `attach_prog_fd` no esté vacío cuando bpf_prog_load(). Pero esto provocará que se rompa la API `libbpf_probe_bpf_prog_type`, que utiliza el registro del verificador para sondear el tipo de programa y no registrará nada si rechazamos el programa EXT no válido antes de bpf_check(). Otra forma es agregando una verificación nula en resolve_prog_type(). El problema fue introducido por el commit 4a9c7bbe2ed4 ("bpf: Resolve to prog->aux->dst_prog->type only for BPF_PROG_TYPE_EXT") que quería corregir la resolución de tipos para los programas BPF_PROG_TYPE_TRACING. Antes de eso, la resolución de tipo del programa BPF_PROG_TYPE_EXT en realidad sigue la siguiente lógica: prog->aux->dst_prog ? prog->aux->dst_prog->tipo : prog->tipo; Implica que cuando el programa EXT aún no está adjunto a `dst_prog`, el tipo de programa debe ser EXT. Este código funcionó bien en el pasado. Así que sigue usándolo. Solucione este problema devolviendo `prog->type` para BPF_PROG_TYPE_EXT si `dst_prog` no está presente en resolve_prog_type().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bna: ajuste el tamaño del buf 'nombre' de las estructuras bna_tcb y bna_ccb para tener suficiente espacio para escribir todos los argumentos posibles de sprintf(). Actualmente el tamaño de 'nombre' es 16, pero es posible que el primer especificador '%s' ya necesite al menos 16 caracteres, ya que allí se usa 'bnad->netdev->name'. Para los especificadores '%d', supongamos que requieren: * 1 carácter para la suma 'tx_id + tx_info->tcb[i]->id', BNAD_MAX_TXQ_PER_TX es 8 * 2 caracteres para 'rx_id + rx_info->rx_ctrl[i]. ccb->id', BNAD_MAX_RXP_PER_RX es 16 y reemplace sprintf con snprintf. Detectado utilizando la herramienta de análisis estático - Svace.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: virt_wifi: evita informar el éxito de la conexión con un SSID incorrecto Cuando el usuario emite una conexión con un SSID diferente al que virt_wifi ha anunciado, __cfg80211_connect_result() activará la advertencia: WARN_ON( bss_not_found). El problema se debe a que el código de conexión en virt_wifi no verifica el SSID desde el espacio del usuario (solo verifica el BSSID), y virt_wifi llamará a cfg80211_connect_result() con WLAN_STATUS_SUCCESS incluso si el SSID es diferente del que virt_wifi ha anunciado. Eventualmente, cfg80211 no podrá encontrar cfg80211_bss y generar la advertencia. Se solucionó verificando el SSID (del espacio de usuario) en el código de conexión.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: rtw89: corrige el error de índice de matriz en rtw89_sta_info_get_iter() En rtw89_sta_info_get_iter() 'status->he_gi' se compara con el tamaño de la matriz. Pero luego se usa 'rate->he_gi' como índice de matriz en lugar de 'status->he_gi'. Esto puede llevar a ir más allá de los límites de la matriz en caso de que 'rate->he_gi' no sea igual a 'status->he_gi' y sea mayor que el tamaño de la matriz. Parece un error de "copiar y pegar". Corrija este error reemplazando 'rate->he_gi' con 'status->he_gi'. Encontrado por el Centro de verificación de Linux (linuxtesting.org) con SVACE.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: lib: objagg: soluciona un fallo de protección general. La librería admite la agregación de objetos en otros objetos sólo si el objeto principal no tiene un padre en sí. Es decir, no se admite el anidamiento. La agregación ocurre en dos casos: sin y con sugerencias, donde las sugerencias son una recomendación calculada previamente sobre cómo agregar los objetos proporcionados. El anidamiento no es posible en el primer caso debido a una verificación que lo impide, pero en el segundo caso no hay verificación porque se supone que el anidamiento no puede ocurrir cuando se crean objetos basados en sugerencias. La violación de este supuesto conduce a diversas advertencias y eventualmente a un fallo de protección general [1]. Antes de solucionar la causa raíz, elimine el error cuando se produzca el anidamiento y advierta. [1] falla de protección general, probablemente para la dirección no canónica 0xdead000000000d90: 0000 [#1] CPU PREEMPT SMP PTI: 1 PID: 1083 Comm: kworker/1:9 Tainted: GW 6.9.0-rc6-custom-gd9b4f1cca7fb #7 Nombre del hardware: Mellanox Technologies Ltd. MSN3700/VMOD0005, BIOS 5.11 06/01/2019 Cola de trabajo: mlxsw_core mlxsw_sp_acl_tcam_vregion_rehash_work RIP: 0010:mlxsw_sp_acl_erp_bf_insert+0x25/0x80 [...] Rastreo de llamadas: acl_atcam_entry_add+0x256/0x3c0 mlxsw_sp_acl_tcam_entry_create+0x5e /0xa0 mlxsw_sp_acl_tcam_vchunk_migrate_one+0x16b/0x270 mlxsw_sp_acl_tcam_vregion_rehash_work+0xbe/0x510 Process_one_work+0x151/0x370 trabajador_thread+0x2cb/0x3e0 kthread+0xd0/0x100 x34/0x50 ret_from_fork_asm+0x1a/0x30

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: kvm: s390: Rechazar operaciones de región de memoria para VM de ucontrol Este cambio rechaza los ioctls KVM_SET_USER_MEMORY_REGION y KVM_SET_USER_MEMORY_REGION2 cuando se llama en una VM de ucontrol. Esto es necesario ya que las máquinas virtuales ucontrol tienen kvm->arch.gmap establecido en 0 y, por lo tanto, daría como resultado una desreferencia de puntero nulo más adelante. La administración de la memoria debe realizarse en el espacio de usuario y utilizando los ioctls KVM_S390_UCAS_MAP y KVM_S390_UCAS_UNMAP. Mejore también la documentación específica de s390 para KVM_SET_USER_MEMORY_REGION y KVM_SET_USER_MEMORY_REGION2. [frankja@linux.ibm.com: confirmación de corrección ortográfica del mensaje, corrección del prefijo del asunto]

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: dm-raid: corrige la verificación WARN_ON_ONCE para sync_thread en raid_resume Los dispositivos rm-raid ocasionalmente activarán la siguiente advertencia cuando se reanude después de una carga de tabla porque DM_RECOVERY_RUNNING está configurado: ADVERTENCIA: CPU: 7 PID: 5660 en drivers/md/dm-raid.c:4105 raid_resume+0xee/0x100 [dm_raid] La verificación fallida es: WARN_ON_ONCE(test_bit(MD_RECOVERY_RUNNING, &mddev->recovery)); Esta verificación está manipulada para garantizar que el hilo de sincronización no esté registrado, pero md_check_recovery puede configurar MD_RECOVERY_RUNNING sin que sync_thread se registre. En lugar de verificar si MD_RECOVERY_RUNNING está configurado, verifique si sync_thread no es NULL.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: scsi: lpfc: corrige una posible desreferencia de puntero nulo En la función lpfc_xcvr_data_show, la asignación de memoria con kmalloc podría fallar, convirtiendo así a rdp_context en un puntero nulo. En el siguiente contexto y funciones que utilizan este puntero, hay operaciones de desreferenciación que conducen a una desreferencia del puntero nulo. Para solucionar este problema, se debe agregar una verificación de puntero nulo. Si es nulo, use scnprintf para notificar al usuario y devolver len.

En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: ASoc: PCM6240: Retorno directamente después de un devm_kzalloc() fallido en pcmdevice_i2c_probe() Se asignó el valor “-ENOMEM” a la variable local “ret” en una rama if después de un devm_kzalloc () la llamada falló al principio. Este código de error activará una llamada pcmdevice_remove() con un puntero nulo pasado, de modo que se realizará una desreferencia no deseada. Por lo tanto, devuelva el código de error apropiado directamente.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: PCI: endpoint: pci-epf-test: utilice 'epc_features' en caché en pci_epf_test_core_init() En lugar de obtener epc_features de la API pci_epc_get_features(), utilice pci_epf_test en caché:: Valor epc_features para evitar la verificación NULL. Dado que la verificación NULL ya se realiza en pci_epf_test_bind(), tener una verificación más en pci_epf_test_core_init() es redundante y no es posible alcanzar la desreferencia del puntero NULL. Además, con el commit a01e7214bef9 ("PCI: endpoint: Remove "core_init_notifier" flag"), se eliminó la referencia a 'epc_features' sin la verificación NULL, lo que generó la siguiente advertencia de falso positivo Smatch: drivers/pci/endpoint/functions/pci-epf-test .c:784 Error de pci_epf_test_core_init(): anteriormente asumimos que 'epc_features' podría ser nulo (consulte la línea 747). Por lo tanto, elimine la verificación NULL redundante y también use los indicadores epc_features:: {msix_capable/msi_capable} directamente para evitar variables locales. [kwilczynski: registro de confirmación]

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: iio: corrigió la funcionalidad de clasificación en iio_gts_build_avail_time_table La clasificación en iio_gts_build_avail_time_table no funciona según lo previsto. Podría resultar en un acceso fuera de los límites cuando el tiempo sea cero. Aquí hay más detalles: 1. Cuando gts->itime_table[i].time_us es cero, por ejemplo, la secuencia de tiempo es `3, 0, 1`, el bucle for interno no terminará y funcionará fuera de límite. Esto se debe a que una vez `times[j] > new`, el valor `new` se agregará en la posición actual y `times[j]` se moverá a la posición `j+1`, lo que hace que la condición if aguanta siempre. Mientras tanto, se agregará uno a idx, lo que hará que el bucle siga ejecutándose sin terminación ni escritura fuera de los límites. 2. Si ninguno de los gts->itime_table[i].time_us es cero, los elementos simplemente se copiarán sin ordenarse como se describe en el comentario "Ordenar tiempos de todas las tablas a una y eliminar duplicados". Para obtener más detalles, consulte https://lore.kernel.org/all/6dd0d822-046c-4dd2-9532-79d7ab96ec05@gmail.com.