Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: smb/client: evitar posible desreferencia NULL en cifs_free_subrequest() Advertencia del verificador estático de Clang (scan-build): cifsglob.h:línea 890, columna 3 El acceso al campo 'ops' da como resultado una desreferencia de un puntero nulo. El commit 519be989717c ("cifs: Agregar un punto de seguimiento para rastrear créditos involucrados en solicitudes R/W") agrega una verificación para 'rdata->server' y permite que clang lance esta advertencia sobre la desreferencia NULL. Cuando sucede 'rdata->credits.value != 0 && rdata->server == NULL', add_credits_and_wake_if() llamará a rdata->server->ops->add_credits(). Esto causará un problema de desreferencia NULL. Agregue una verificación para 'rdata->server' para evitar la desreferencia NULL.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/v3d: Corregir lectura fuera de los límites en `v3d_csd_job_run()` Al habilitar UBSAN en Raspberry Pi 5, obtenemos la siguiente advertencia: [ 387.894977] UBSAN: array-index-out-of-bounds en drivers/gpu/drm/v3d/v3d_sched.c:320:3 [ 387.903868] el índice 7 está fuera de rango para el tipo '__u32 [7]' [ 387.909692] CPU: 0 PID: 1207 Comm: kworker/u16:2 Tainted: G WC 6.10.3-v8-16k-numa #151 [ 387.919166] Nombre del hardware: Raspberry Pi 5 Model B Rev 1.0 (DT) [ 387.925961] Cola de trabajo: v3d_csd drm_sched_run_job_work [gpu_sched] [ 387.932525] Rastreo de llamadas: [ 387.935296] dump_backtrace+0x170/0x1b8 [ 387.939403] show_stack+0x20/0x38 [ 387.942907] dump_stack_lvl+0x90/0xd0 [ 387.946785] dump_stack+0x18/0x28 [ 387.950301] __ubsan_handle_out_of_bounds+0x98/0xd0 [ 387.955383] v3d_csd_job_run+0x3a8/0x438 [v3d] [ 387.960707] drm_sched_run_job_work+0x520/0x6d0 [gpu_sched] [ 387.966862] process_one_work+0x62c/0xb48 [ 387.971296] worker_thread+0x468/0x5b0 [ 387.975317] kthread+0x1c4/0x1e0 [ 387.978818] ret_from_fork+0x10/0x20 [ 387.983014] ---[ fin del seguimiento ]--- Esto sucede porque la UAPI proporciona solo siete registros de configuración y estamos leyendo la octava posición de esta matriz u32. Por lo tanto, solucione la lectura fuera de los límites en `v3d_csd_job_run()` accediendo solo a siete posiciones en la matriz '__u32 [7]'. El octavo registro existe de hecho en V3D 7.1, pero no se utiliza actualmente. Siendo así, garanticemos que permanezca sin uso y agreguemos una nota que indique que podría configurarse en un parche futuro.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: iommu: Restaurar retorno perdido en iommu_report_device_fault() Cuando se llama a iommu_report_device_fault con un error parcial, se supone que debe recopilar el error en el grupo y luego regresar. En cambio, el retorno se eliminó accidentalmente, lo que da como resultado el intento de procesar el error y un bloqueo final. Eliminar el retorno fue un error tipográfico, vuelva a colocarlo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: vsock: corregir llamadas recursivas ->recvmsg Después de que se ha añadido un socket vsock a un sockmap BPF, su prot->recvmsg se ha reemplazado por vsock_bpf_recvmsg(). Por lo tanto, podría ocurrir la siguiente recursión: vsock_bpf_recvmsg() -> __vsock_recvmsg() -> vsock_connectible_recvmsg() -> prot->recvmsg() -> vsock_bpf_recvmsg() de nuevo Necesitamos solucionarlo llamando al ->recvmsg() original sin ninguna lógica sockmap BPF en __vsock_recvmsg().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: ethernet: mtk_wed: arregla el pánico de use after free en mtk_wed_setup_tc_block_cb() Cuando hay múltiples interfaces de punto de acceso en una banda y con WED activado, desactivar la interfaz provocará un pánico de kernel en MT798X. Anteriormente, cb_priv se liberaba en mtk_wed_setup_tc_block() sin marcar NULL, y mtk_wed_setup_tc_block_cb() tampoco verificaba el valor. Asigna NULL después de liberar cb_priv en mtk_wed_setup_tc_block() y marca NULL en mtk_wed_setup_tc_block_cb(). ---------- No se puede manejar la solicitud de paginación del núcleo en la dirección virtual 0072460bca32b4f5 Seguimiento de llamadas: mtk_wed_setup_tc_block_cb+0x4/0x38 0xffffffc0794084bc tcf_block_playback_offloads+0x70/0x1e8 tcf_block_unbind+0x6c/0xc8 ... ---------

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: KEYS: trusted: dcp: fix leak of blob encrypted key Las claves confiables abren el blob de la clave al cargar, pero mantienen la carga sellada en el campo blob para que cada lectura posterior (exportación) simplemente convierta este campo a hexadecimal y lo envíe al espacio de usuario. Con claves confiables basadas en DCP, desciframos la clave de cifrado de blob (BEK) en el kernel debido a limitaciones de hardware y luego desciframos el payload del blob. El descifrado de BEK se realiza en el lugar, lo que significa que el campo blob de la clave confiable se modifica y, en consecuencia, contiene la BEK en texto plano. Cada lectura posterior de esa clave envía la BEK en texto plano en lugar de la BEK cifrada al espacio de usuario. Este problema solo ocurre cuando se importa una clave confiable basada en DCP y luego se vuelve a exportar. Esto rara vez debería suceder, ya que los casos de uso comunes son crear una nueva clave confiable y exportarla, o importar un blob de clave y luego simplemente usarlo sin exportarlo nuevamente. Solucione este problema realizando el descifrado y cifrado de BEK en un búfer dedicado. Además, borre siempre el búfer de BEK de texto plano para evitar la fuga de la clave a través de la memoria no inicializada.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: KVM: s390: soluciona el problema de intercepción de validez cuando gisa está desactivado Podemos encontrarnos con una validez de SIE si gisa se ha deshabilitado mediante el uso del parámetro del kernel "kvm.use_gisa=0" o configurando el atributo sysfs relacionado en N (echo N >/sys/module/kvm/parameters/use_gisa). La validez es causada por un valor no válido en la designación gisa del bloque de control SIE. Esto sucede porque pasamos el origen gisa no inicializado a virt_to_phys() antes de escribirlo en la designación gisa. Para solucionar esto, devolvemos 0 en kvm_s390_get_gisa_desc() si el origen es 0. kvm_s390_get_gisa_desc() se utiliza para determinar qué designación gisa establecer en el bloque de control SIE. Un valor de 0 en la designación gisa deshabilita el uso de gisa. El problema aparece en el kernel del host con el siguiente mensaje del kernel tan pronto como se intenta iniciar un nuevo invitado kvm. kvm: interceptación de validez no controlada 0x1011 WARNING: CPU: 0 PID: 781237 at arch/s390/kvm/intercept.c:101 kvm_handle_sie_intercept+0x42e/0x4d0 [kvm] Modules linked in: vhost_net tap tun xt_CHECKSUM xt_MASQUERADE xt_conntrack ipt_REJECT xt_tcpudp nft_compat x_tables nf_nat_tftp nf_conntrack_tftp vfio_pci_core irqbypass vhost_vsock vmw_vsock_virtio_transport_common vsock vhost vhost_iotlb kvm nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip_set nf_tables sunrpc mlx5_ib ib_uverbs ib_core mlx5_core uvdevice s390_trng eadm_sch vfio_ccw zcrypt_cex4 mdev vfio_iommu_type1 vfio sch_fq_codel drm i2c_core loop drm_panel_orientation_quirks configfs nfnetlink lcs ctcm fsm dm_service_time ghash_s390 prng chacha_s390 libchacha aes_s390 des_s390 libdes sha3_512_s390 sha3_256_s390 sha512_s390 sha256_s390 sha1_s390 sha_common dm_mirror dm_region_hash dm_log zfcp scsi_transport_fc scsi_dh_rdac scsi_dh_emc scsi_dh_alua pkey zcrypt dm_multipath rng_core autofs4 [last unloaded: vfio_pci] CPU: 0 PID: 781237 Comm: CPU 0/KVM Not tainted 6.10.0-08682-gcad9f11498ea #6 Hardware name: IBM 3931 A01 701 (LPAR) Krnl PSW : 0704c00180000000 000003d93deb0122 (kvm_handle_sie_intercept+0x432/0x4d0 [kvm]) R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:0 PM:0 RI:0 EA:3 Krnl GPRS: 000003d900000027 000003d900000023 0000000000000028 000002cd00000000 000002d063a00900 00000359c6daf708 00000000000bebb5 0000000000001eff 000002cfd82e9000 000002cfd80bc000 0000000000001011 000003d93deda412 000003ff8962df98 000003d93de77ce0 000003d93deb011e 00000359c6daf960 Krnl Code: 000003d93deb0112: c020fffe7259 larl %r2,000003d93de7e5c4 000003d93deb0118: c0e53fa8beac brasl %r14,000003d9bd3c7e70 #000003d93deb011e: af000000 mc 0,0 >000003d93deb0122: a728ffea lhi %r2,-22 000003d93deb0126: a7f4fe24 brc 15,000003d93deafd6e 000003d93deb012a: 9101f0b0 tm 176(%r15),1 000003d93deb012e: a774fe48 brc 7,000003d93deafdbe 000003d93deb0132: 40a0f0ae sth %r10,174(%r15) Call Trace: [<000003d93deb0122>] kvm_handle_sie_intercept+0x432/0x4d0 [kvm] ([<000003d93deb011e>] kvm_handle_sie_intercept+0x42e/0x4d0 [kvm]) [<000003d93deacc10>] vcpu_post_run+0x1d0/0x3b0 [kvm] [<000003d93deaceda>] __vcpu_run+0xea/0x2d0 [kvm] [<000003d93dead9da>] kvm_arch_vcpu_ioctl_run+0x16a/0x430 [kvm] [<000003d93de93ee0>] kvm_vcpu_ioctl+0x190/0x7c0 [kvm] [<000003d9bd728b4e>] vfs_ioctl+0x2e/0x70 [<000003d9bd72a092>] __s390x_sys_ioctl+0xc2/0xd0 [<000003d9be0e9222>] __do_syscall+0x1f2/0x2e0 [<000003d9be0f9a90>] system_call+0x70/0x98 Last Breaking-Event-Address: [<000003d9bd3c7f58>] __warn_printk+0xe8/0xf0

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: mana: Fix RX buf alloc_size adjustment and atomic op panic El búfer RX alloc_size del controlador MANA se pasa a napi_build_skb() para crear SKB. skb_shinfo(skb) se encuentra al final de skb, y su alineación se ve afectada por el alloc_size pasado a napi_build_skb(). El tamaño debe estar alineado correctamente para un mejor rendimiento y operaciones atómicas. De lo contrario, en la CPU ARM64, para ciertas configuraciones de MTU como 4000, las operaciones atómicas pueden entrar en pánico en skb_shinfo(skb)->dataref debido a un error de alineación. Para corregir este error, agregue la alineación adecuada al cálculo alloc_size. Información de pánico de muestra: [253.298819] No se puede manejar la solicitud de paginación del núcleo en la dirección virtual ffff000129ba5cce [253.300900] Información de aborto de memoria: [253.301760] ESR = 0x0000000096000021 [253.302825] EC = 0x25: DABT (EL actual), IL = 32 bits [253.304268] SET = 0, FnV = 0 [253.305172] EA = 0, S1PTW = 0 [253.306103] FSC = 0x21: error de alineación Rastreo de llamada: __skb_clone+0xfc/0x198 skb_clone+0x78/0xe0 raw6_local_deliver+0xfc/0x228 ip6_protocol_deliver_rcu+0x80/0x500 ip6_input_finish+0x48/0x80 ip6_input+0x48/0xc0 ip6_sublist_rcv_finish+0x50/0x78 ip6_sublist_rcv+0x1cc/0x2b8 ipv6_list_rcv+0x100/0x150 __netif_receive_skb_list_core+0x180/0x220 netif_receive_skb_list_internal+0x198/0x2a8 __napi_poll+0x138/0x250 net_rx_action+0x148/0x330 manejar_softirqs+0x12c/0x3a0

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bonding: fix xfrm real_dev null pointer dereference No deberíamos establecer real_dev en NULL porque los paquetes pueden estar en tránsito y xfrm podría llamar a xdo_dev_offload_ok() en paralelo. Todas las devoluciones de llamadas suponen que real_dev está establecido. Ejemplo de seguimiento: kernel: BUG: no se puede manejar el error de página para la dirección: 0000000000001030 kernel: bond0: (esclavo eni0np1): haciendo que la interfaz sea la nueva activa kernel: #PF: acceso de escritura del supervisor en modo kernel kernel: #PF: error_code(0x0002) - página no presente kernel: PGD 0 P4D 0 kernel: Oops: 0002 [#1] PREEMPT SMP kernel: CPU: 4 PID: 2237 Comm: ping No contaminado 6.7.7+ #12 kernel: Nombre del hardware: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014 kernel: RIP: 0010:nsim_ipsec_offload_ok+0xc/0x20 [netdevsim] kernel: bond0: (esclavo eni0np1): bond_ipsec_add_sa_all: no se pudo agregar el kernel SA: Código: e0 0f 0b 48 83 7f 38 00 74 de 0f 0b 48 8b 47 08 48 8b 37 48 8b 78 40 e9 b2 e5 9a d7 66 90 0f 1f 44 00 00 48 8b 86 80 02 00 00 <83> 80 30 10 00 00 01 b8 01 00 00 00 c3 0f 1f 80 00 00 00 00 0f 1f kernel: bond0: (esclavo eni0np1): haciendo que la interfaz sea la nueva activa kernel: RSP: 0018:ffffabde81553b98 EFLAGS: 00010246 kernel: bond0: (esclavo eni0np1): bond_ipsec_add_sa_all: no se pudo agregar SA kernel: kernel: RAX: 0000000000000000 RBX: ffff9eb404e74900 RCX: ffff9eb403d97c60 kernel: RDX: ffffffffc090de10 RSI: ffff9eb404e74900 RDI: ffff9eb3c5de9e00 kernel: RBP: ffff9eb3c0a42000 R08: 000000000000010 R09: 0000000000000014 kernel: R10: 797420303030303030 R11: 3030303030303030 R12: 0000000000000000 núcleo: R13: ffff9eb3c5de9e00 R14: ffffabde81553cc8 R15: ffff9eb404c53000 núcleo: FS: 00007f2a77a3ad00(0000) GS:ffff9eb43bd00000(0000) knlGS:0000000000000000 núcleo: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 núcleo: CR2: 0000000000001030 CR3: 00000001122ab000 CR4: 0000000000350ef0 kernel: bond0: (esclavo eni0np1): haciendo que la interfaz sea la nueva activa kernel: Seguimiento de llamadas: kernel: kernel: ? __die+0x1f/0x60 kernel: bond0: (esclavo eni0np1): bond_ipsec_add_sa_all: error al agregar SA kernel: ? page_fault_oops+0x142/0x4c0 kernel: ? do_user_addr_fault+0x65/0x670 kernel: ? kvm_read_and_reset_apf_flags+0x3b/0x50 kernel: bond0: (esclavo eni0np1): haciendo que la interfaz sea la nueva activa kernel: ? exc_page_fault+0x7b/0x180 kernel: ? asm_exc_page_fault+0x22/0x30 kernel: ? nsim_bpf_uninit+0x50/0x50 [netdevsim] kernel: bond0: (esclavo eni0np1): bond_ipsec_add_sa_all: no se pudo agregar SA kernel: ? nsim_ipsec_offload_ok+0xc/0x20 [netdevsim] kernel: bond0: (esclavo eni0np1): haciendo que la interfaz sea la nueva activa kernel: bond_ipsec_offload_ok+0x7b/0x90 [vinculación] kernel: xfrm_output+0x61/0x3b0 kernel: bond0: (esclavo eni0np1): bond_ipsec_add_sa_all: no se pudo agregar SA kernel: ip_push_pending_frames+0x56/0x80

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bonding: corregir desreferenciación de puntero nulo en bond_ipsec_offload_ok Debemos comprobar si hay un esclavo activo antes de desreferenciar el puntero.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: tcp: evitar la ejecución concurrente de tcp_sk_exit_batch Es posible que dos subprocesos llamen a tcp_sk_exit_batch() simultáneamente, una vez desde la cola de trabajo cleanup_net, otra desde una tarea que no pudo clonar una nueva netns. En el último caso, el desenrollado de errores llama a los controladores de salida en orden inverso para las netns "fallidas". tcp_sk_exit_batch() llama a tcp_twsk_purge(). El problema es que desde el commit b099ce2602d8 ("net: Batch inet_twsk_purge"), esta función recoge twsk en cualquier netn moribundo, no solo en el que se pasa a través de la lista exit_batch. Esto significa que el desenrollado de errores de setup_net() puede "robar" y destruir los sockets timewait que pertenecen a las netns que salen. Esto permite que el trabajador de salida netns proceda a llamar a WARN_ON_ONCE(!refcount_dec_and_test(&net->ipv4.tcp_death_row.tw_refcount)); sin la transición esperada de 1 -> 0, que luego falla. Al mismo tiempo, la ruta de desenrollado de error que también está ejecutando inet_twsk_purge() también se mostrará: ADVERTENCIA: .. en lib/refcount.c:31 refcount_warn_saturate+0x1ed/0x210 ... refcount_dec include/linux/refcount.h:351 [en línea] inet_twsk_kill+0x758/0x9c0 net/ipv4/inet_timewait_sock.c:70 inet_twsk_deschedule_put net/ipv4/inet_timewait_sock.c:221 inet_twsk_purge+0x725/0x890 net/ipv4/inet_timewait_sock.c:304 tcp_sk_exit_batch+0x1c/0x170 net/ipv4/tcp_ipv4.c:3522 ops_exit_list+0x128/0x180 net/core/net_namespace.c:178 setup_net+0x714/0xb40 net/core/net_namespace.c:375 copy_net_ns+0x2f0/0x670 net/core/net_namespace.c:508 create_new_namespaces+0x3ea/0xb10 kernel/nsproxy.c:110 ... porque refcount_dec() de tw_refcount cayó inesperadamente a 0. Esto no parece un error real (no se perdieron sockets tw y no veo un use-after-free) sino un disparador erróneo de la comprobación de depuración. Agregue un mutex para forzar un orden estricto: la tarea que llama a tcp_twsk_purge() impide que otra tarea realice _dec_and_test final antes de que el propietario del mutex haya eliminado todos los sockets tw de los netn moribundos.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net:hns3: se corrige un problema de bloqueo cuando se configura TC durante el reinicio Cuando se configura TC durante el proceso de reinicio, puede causar un bloqueo, el flujo es el siguiente: pf reset start ? ? ...... setup tc ? ? ? ? DOWN: napi_disable() napi_disable()(skip) ? ? ? ? ? ...... ...... ? ? ? ? napi_enable() ? ? UINIT: netif_napi_del() ? ? ...... ? ? INIT: netif_napi_add() ? ? ...... global reset start ? ? ? ? UP: napi_enable()(skip) ...... ? ? ? ? ...... napi_disable() En el proceso de reinicio, el controlador DESACTIVARÁ el puerto y luego UINIT; en este caso, el proceso de configuración tc DESACTIVARÁ el puerto antes de UINIT, lo que provocará el problema. Agrega un proceso DESACTIVADO en UINIT para solucionarlo.