Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: smb: cliente: corregir UAF en descifrado asincrónico Al realizar un descifrado asincrónico (lectura grande), se produce un bloqueo con un método slab-use-after-free en la API de cifrado. Reproductor: # mount.cifs -o ...,seal,esize=1 //srv/share /mnt # dd if=/mnt/largefile of=/dev/null ... [ 194.196391] ===================================================================== [ 194.196844] ERROR: KASAN: slab-use-after-free en gf128mul_4k_lle+0xc1/0x110 [ 194.197269] Lectura de tamaño 8 en la dirección ffff888112bd0448 por la tarea kworker/u77:2/899 [ 194.197707] [ 194.197818] CPU: 12 UID: 0 PID: 899 Comm: kworker/u77:2 No contaminado 6.11.0-lku-00028-gfca3ca14a17a-dirty #43 [ 194.198400] Nombre del hardware: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.2-3-gd478f380-prebuilt.qemu.org 04/01/2014 [ 194.199046] Cola de trabajo: smb3decryptd smb2_decrypt_offload [cifs] [ 194.200032] Seguimiento de llamadas: [ 194.200191] [ [194.200327] dump_stack_lvl+0x4e/0x70 [194.200558] ? gf128mul_4k_lle+0xc1/0x110 [194.200809] print_report+0x174/0x505 [194.201040] ? __pfx__raw_spin_lock_irqsave+0x10/0x10 [194.201352] ? srso_return_thunk+0x5/0x5f [194.201604] ? __virt_addr_valid+0xdf/0x1c0 [194.201868] ? gf128mul_4k_lle+0xc1/0x110 [ 194.202128] kasan_report+0xc8/0x150 [ 194.202361] ? gf128mul_4k_lle+0xc1/0x110 [ 194.202616] gf128mul_4k_lle+0xc1/0x110 [ 194.202863] ghash_update+0x184/0x210 [ 194.203103] shash_ahash_update+0x184/0x2a0 [ 194.203377] ? __pfx_shash_ahash_update+0x10/0x10 [ 194.203651] ? srso_return_thunk+0x5/0x5f [ 194.203877] ? crypto_gcm_init_common+0x1ba/0x340 [ 194.204142] gcm_hash_assoc_remain_continue+0x10a/0x140 [ 194.204434] crypt_message+0xec1/0x10a0 [cifs] [ 194.206489] ? __pfx_crypt_message+0x10/0x10 [cifs] [ 194.208507] ? srso_return_thunk+0x5/0x5f [ 194.209205] ? srso_return_thunk+0x5/0x5f [ 194.209925] ? srso_return_thunk+0x5/0x5f [ 194.210443] ? srso_return_thunk+0x5/0x5f [ 194.211037] decrypt_raw_data+0x15f/0x250 [cifs] [ 194.212906] ? __pfx_decrypt_raw_data+0x10/0x10 [cifs] [ 194.214670] ? srso_return_thunk+0x5/0x5f [ 194.215193] smb2_decrypt_offload+0x12a/0x6c0 [cifs] Esto se debe a que TFM se está utilizando en paralelo. Solucione esto asignando un nuevo TFM AEAD para el descifrado asincrónico, pero conserve el existente para los casos de LECTURA sincrónica (similar a lo que se hace en smb3_calc_signature()). También elimine las llamadas a aead_request_set_callback() y crypto_wait_req() ya que siempre será una operación sincrónica.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: usb: gadget: uvc: Corrige la desreferenciación de ERR_PTR en uvc_v4l2.c Corrige la posible desreferenciación de ERR_PTR() en find_format_by_pix() y uvc_v4l2_enum_format(). Corrige los siguientes errores de coincidencia: drivers/usb/gadget/function/uvc_v4l2.c:124 find_format_by_pix() error: posible desreferenciación de 'fmtdesc' a ERR_PTR() drivers/usb/gadget/function/uvc_v4l2.c:392 uvc_v4l2_enum_format() error: posible desreferenciación de 'fmtdesc' a ERR_PTR() Además, corrige un problema similar en uvc_v4l2_try_format() para una posible desreferenciación de ERR_PTR().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: igb: No encender el dispositivo después de un error no fatal el commit 004d25060c78 ("igb: Reparar igb_down colgado en eliminación sorpresa") cambió igb_io_error_detected() para ignorar los errores pcie no fatales con el fin de evitar que la tarea se cuelgue que puede suceder cuando se llama a igb_down() varias veces. Esto causó un problema al procesar errores transitorios no fatales. igb_io_resume(), que se llama después de igb_io_error_detected(), asume que el dispositivo es derribado por igb_io_error_detected() si la interfaz está activa. Esto resultó en un pánico con el seguimiento de pila a continuación. [ T3256] igb 0000:09:00.0 haeth0: igb: el enlace NIC haeth0 está inactivo [ T292] pcieport 0000:00:1c.5: AER: Error no corregido (no fatal) recibido: 0000:09:00.0 [ T292] igb 0000:09:00.0: Error de bus PCIe: gravedad=No corregido (no fatal), tipo=Capa de transacción, (ID del solicitante) [ T292] igb 0000:09:00.0: dispositivo [8086:1537] estado/máscara de error=00004000/00000000 [ T292] igb 0000:09:00.0: [14] CmpltTO [ 200.105524,009][ T292] igb 0000:09:00.0: AER: Encabezado TLP: 00000000 00000000 00000000 00000000 [ T292] pcieport 0000:00:1c.5: AER: mensaje de transmisión error_detected [ T292] igb 0000:09:00.0: Se informó un error no fatal y no corregible. [ T292] pcieport 0000:00:1c.5: AER: mensaje de transmisión mmio_enabled [ T292] pcieport 0000:00:1c.5: AER: mensaje de transmisión de reanudación [ T292] ------------[ cortar aquí ]------------ [ T292] ¡ERROR del kernel en net/core/dev.c:6539! [ T292] código de operación no válido: 0000 [#1] PREEMPT SMP [ T292] RIP: 0010:napi_enable+0x37/0x40 [ T292] Seguimiento de llamadas: [ T292] [ T292] ? die+0x33/0x90 [ T292] ? do_trap+0xdc/0x110 [ T292] ? napi_enable+0x37/0x40 [ T292] ? napi_enable+0x37/0x40 [ T292] ? napi_enable+0x37/0x40 [ T292] ? exc_invalid_op+0x4e/0x70 [ T292] ? napi_enable+0x37/0x40 [ T292] ? asm_exc_invalid_op+0x16/0x20 [ T292] ? napi_enable+0x37/0x40 [ T292] ? igb_up+0x41/0x150 [ T292] igb_io_resume+0x25/0x70 [ T292] report_resume+0x54/0x70 [ T292] ? informe_congelado_detectado+0x20/0x20 [ T292] pci_walk_bus+0x6c/0x90 [ T292] ? aer_print_port_info+0xa0/0xa0 [ T292] pcie_do_recovery+0x22f/0x380 [ T292] aer_process_err_devices+0x110/0x160 [ T292] aer_isr+0x1c1/0x1e0 [ T292] ? deshabilitar_irq_nosync+0x10/0x10 [ T292] irq_thread_fn+0x1a/0x60 [ T292] irq_thread+0xe3/0x1a0 [ T292] ? Para solucionar este problema, igb_io_resume() verifica si la interfaz está ejecutándose y si el dispositivo no está inactivo, esto significa que igb_io_error_detected() no inactivó el dispositivo y no es necesario activarlo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: i40e: Corregir pérdida de macvlan sincronizando el acceso a mac_filter_hash Este parche soluciona un problema de pérdida de macvlan en el controlador i40e causado por el acceso simultáneo a vsi->mac_filter_hash. La pérdida se produce cuando varios subprocesos intentan modificar mac_filter_hash simultáneamente, lo que genera un estado inconsistente y posibles pérdidas de memoria. Para solucionar esto, ahora envolvemos las llamadas a i40e_del_mac_filter() y ponemos a cero vf->default_lan_addr.addr con spin_lock/unlock_bh(&vsi->mac_filter_hash_lock), lo que garantiza operaciones atómicas y evita el acceso simultáneo. Además, agregamos lockdep_assert_held(&vsi->mac_filter_hash_lock) en i40e_add_mac_filter() para ayudar a detectar problemas similares en el futuro. Pasos de reproducción: 1. Genere VFs y configure el puerto VLAN en ellos. 2. Active operaciones MACVLAN simultáneas (por ejemplo, agregar y eliminar filtros MAC o PortVLAN). 3. Observe la posible pérdida de memoria y el estado inconsistente en el hash de filtro MAC. Esta sincronización garantiza la integridad del hash de filtro MAC y evita la pérdida descrita.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: Bluetooth: RFCOMM: CORREGIR posible bloqueo en rfcomm_sk_state_change rfcomm_sk_state_change intenta usar sock_lock, por lo que nunca se debe llamar con él bloqueado, pero rfcomm_sock_ioctl siempre intenta bloquearlo, lo que provoca el siguiente rastro: ======================================================= ADVERTENCIA: se ha detectado una posible dependencia de bloqueo circular 6.8.0-syzkaller-08951-gfe46a7dd189e #0 No contaminado ------------------------------------------------------ syz-executor386/5093 está intentando adquirir el bloqueo: ffff88807c396258 (sk_lock-AF_BLUETOOTH-BTPROTO_RFCOMM){+.+.}-{0:0}, en: lock_sock include/net/sock.h:1671 [en línea] ffff88807c396258 (sk_lock-AF_BLUETOOTH-BTPROTO_RFCOMM){+.+.}-{0:0}, en: rfcomm_sk_state_change+0x5b/0x310 net/bluetooth/rfcomm/sock.c:73 pero la tarea ya tiene el bloqueo: ffff88807badfd28 (&d->lock){+.+.}-{3:3}, en: __rfcomm_dlc_close+0x226/0x6a0 net/bluetooth/rfcomm/core.c:491

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: netfilter: br_netfilter: fix panic with metadata_dst skb Corrige un pánico del kernel en el módulo br_netfilter al enviar tráfico sin etiquetar a través de un dispositivo VxLAN. Esto sucede durante la comprobación de fragmentación en br_nf_dev_queue_xmit. Depende de: 1) que se esté cargando el módulo br_netfilter; 2) que net.bridge.bridge-nf-call-iptables esté establecido en 1; 3) que haya un puente con un netdevice VxLAN (single-vxlan-device) como puerto de puente; 4) que se hayan reenviado o inundado tramas sin etiquetar con un tamaño superior a la MTU de VxLAN. Al reenviar el paquete sin etiquetar al puerto de puente VxLAN, antes de que se llamen los ganchos de netfilter, se llama a br_handle_egress_vlan_tunnel y cambia skb_dst al dst del túnel. tunnel_dst es un tipo de metadatos de dst, es decir, skb_valid_dst(skb) es falso y metadata->dst.dev es NULL. Luego, en los ganchos br_netfilter, en br_nf_dev_queue_xmit, hay una verificación de tramas que necesitan fragmentarse: las tramas con una MTU más alta que el dispositivo VxLAN terminan llamando a br_nf_ip_fragment, que a su vez llama a ip_skb_dst_mtu. ip_dst_mtu intenta usar skb_dst(skb) como si fuera un dst válido con dst->dev válido, de ahí el bloqueo. Este caso nunca fue compatible en primer lugar, por lo que descarta el paquete en su lugar. PING 10.0.0.2 (10.0.0.2) desde 0.0.0.0 h1-eth0: 2000(2028) bytes de datos. [ 176.291791] No se puede manejar la desreferencia del puntero NULL del núcleo en la dirección virtual 0000000000000110 [ 176.292101] Información de aborto de memoria: [ 176.292184] ESR = 0x0000000096000004 [ 176.292322] EC = 0x25: DABT (EL actual), IL = 32 bits [ 176.292530] SET = 0, FnV = 0 [ 176.292709] EA = 0, S1PTW = 0 [ 176.292862] FSC = 0x04: error de traducción de nivel 0 [ 176.293013] Información de aborto de datos: [ 176.293104] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 [ 176.293488] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 176.293787] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 176.293995] pgtable del usuario: páginas de 4k, VA de 48 bits, pgdp=0000000043ef5000 [ 176.294166] [0000000000000110] pgd=000000000000000, p4d=0000000000000000 [ 176.294827] Error interno: Oops: 0000000096000004 [#1] PREEMPT SMP [ 176.295252] Módulos vinculados: vxlan ip6_udp_tunnel udp_tunnel veth br_netfilter bridge stp llc ipv6 crct10dif_ce [ 176.295923] CPU: 0 PID: 188 Comm: ping No contaminado 6.8.0-rc3-g5b3fbd61b9d1 #2 [ 176.296314] Nombre del hardware: linux,dummy-virt (DT) [ 176.296535] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 176.296808] pc : br_nf_dev_queue_xmit+0x390/0x4ec [br_netfilter] [ 176.297382] lr : br_nf_dev_queue_xmit+0x2ac/0x4ec [br_netfilter] [ 176.297636] sp : ffff800080003630 [ 176.297743] x29: ffff800080003630 x28: 0000000000000008 x27: ffff6828c49ad9f8 [ 176.298093] x26: ffff6828c49ad000 x25: 0000000000000000 x24: 00000000000003e8 [ 176.298430] x23: 0000000000000000 x22: ffff6828c4960b40 x21: ffff6828c3b16d28 [ 176.298652] x20: ffff6828c3167048 x19: ffff6828c3b16d00 x18: 0000000000000014 [ 176.298926] x17: ffffb0476322f000 x16: ffffb7e164023730 x15: 0000000095744632 [ 176.299296] x14: ffff6828c3f1c880 x13: 0000000000000002 x12: ffffb7e137926a70 [ 176.299574] x11: 000000000000001 x10: ffff6828c3f1c898 x9: 0000000000000000 [ 176.300049] x8: ffff6828c49bf070 x7: 0008460f18d5f20e x6: f20e0100bebafeca [ 176.300302] x5 : ffff6828c7f918fe x4 : ffff6828c49bf070 x3 : 0000000000000000 [ 176.300586] x2 : 0000000000000000 x1 : ffff6828c3c7ad00 x0 : ffff6828c7f918f0 [ 176.300889] Rastreo de llamadas: [ 176.301123] br_nf_dev_queue_xmit+0x390/0x4ec [br_netfilter] [ 176.301411] br_nf_post_routing+0x2a8/0x3e4 [br_netfilter] [ 176.301703] br_nf_hook_slow+0x48/0x124 [ 176.302060] br_forward_finish+0xc8/0xe8 [puente] [ 176.302371] br_nf_hook_thresh+0x124/0x134 [br_filtro de red] [ 176.302605] br_nf_forward_finish+0x118/0x22c [br_filtro de red] [ 176.302824] br_nf_forward_ip.part.0+0x264/0x290 [br_filtro de red] [ 176.303136 ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: NFSv4: Evitar la desreferencia de puntero NULL en nfs42_complete_copies() En el nodo de un cliente NFS, algunos archivos guardados en el punto de montaje del servidor NFS se copiaron a otra ubicación del mismo servidor NFS. Accidentalmente, nfs42_complete_copies() tuvo un fallo por desreferencia de puntero NULL con el siguiente syslog: [232064.838881] NFSv4: la recuperación de estado falló para el archivo abierto nfs/pvc-12b5200d-cd0f-46a3-b9f0-af8f4fe0ef64.qcow2, error = -116 [232064.839360] NFSv4: la recuperación de estado falló para el archivo abierto nfs/pvc-12b5200d-cd0f-46a3-b9f0-af8f4fe0ef64.qcow2, error = -116 [232066.588183] No se puede manejar la desreferencia de puntero NULL del kernel en la dirección virtual 0000000000000058 [232066.588586] Información de cancelación de memoria: [232066.588701] ESR = 0x0000000096000007 [232066.588862] EC = 0x25: DABT (EL actual), IL = 32 bits [232066.589084] SET = 0, FnV = 0 [232066.589216] EA = 0, S1PTW = 0 [232066.589340] FSC = 0x07: error de traducción de nivel 3 [232066.589559] Información de cancelación de datos: [232066.589683] ISV = 0, ISS = 0x00000007 [232066.589842] CM = 0, WnR = 0 [232066.589967] usuario pgtable: 64k páginas, VA de 48 bits, pgdp=00002000956ff400 [232066.590231] [0000000000000058] pgd=08001100ae100003, p4d=08001100ae100003, pud=08001100ae100003, pmd=08001100b3c00003, pte=000000000000000 [232066.590757] Error interno: Oops: 96000007 [#1] SMP [232066.590958] Módulos vinculados en: rpcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver nfs lockd grace fscache netfs ocfs2_dlmfs ocfs2_stack_o2cb ocfs2_dlm vhost_net vhost vhost_iotlb tap tun ipt_rpfilter xt_multiport ip_set_hash_ip ip_set_hash_net xfrm_interface xfrm6_tunnel tunnel4 tunnel6 esp4 ah4 wireguard libcurve25519_generic veth xt_addrtype xt_set nf_conntrack_netlink ip_set_hash_ipportnet ip_set_hash_ipportip ip_set_bitmap_port ip_set_hash_ipport conjunto de ip ficticio ip_vs_sh ip_vs_wrr ip_vs_rr ip_vs iptable_filter sch_ingress nfnetlink_cttimeout vport_gre ip_gre ip_tunnel gre vport_geneve geneve vport_vxlan vxlan ip6_udp_tunnel udp_tunnel openvswitch nf_conncount dm_round_robin dm_service_time dm_multipath xt_nat xt_MASQUERADE nft_chain_nat nf_nat xt_mark xt_conntrack xt_comment nft_compat nft_counter nf_tables nfnetlink ocfs2 ocfs2_nodemanager ocfs2_stackglue iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi ipmi_ssif nbd overlay 8021q garp mrp enlace tls rfkill sunrpc ext4 mbcache jbd2 [232066.591052] vfat fat cas_cache cas_disk ses enclosure scsi_transport_sas sg acpi_ipmi ipmi_si ipmi_devintf ipmi_msghandler ip_tables vfio_pci vfio_pci_core vfio_virqfd vfio_iommu_type1 vfio dm_mirror dm_region_hash dm_log dm_mod nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 br_netfilter puente stp llc fuse xfs libcrc32c ast drm_vram_helper qla2xxx drm_kms_helper syscopyarea crct10dif_ce sysfillrect ghash_ce sysimgblt sha2_ce fb_sys_fops cec sha256_arm64 sha1_ce drm_ttm_helper ttm nvme_fc igb sbsa_gwdt nvme_fabrics drm nvme_core i2c_algo_bit i40e scsi_transport_fc megaraid_sas aes_neon_bs [232066.596953] CPU: 6 PID: 4124696 Comm: 10.253.166.125- Kdump: cargado No contaminado 5.15.131-9.cl9_ocfs2.aarch64 #1 [232066.597356] Nombre del hardware: Great Wall .\x93\x8e...RF6260 V5/GWMSSE2GL1T, BIOS T656FBE_V3.0.18 2024-01-06 [232066.597721] estado de la página: 20400009 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [232066.598034] equipo: nfs4_reclaim_open_state+0x220/0x800 [nfsv4] [232066.598327] estado de la página: nfs4_reclaim_open_state+0x12c/0x800 [nfsv4] [232066.598595] servidor de arranque: ffff8000f568fc70 [232066.598731] x29: ffff8000f568fc70 x28: 0000000000001000 x27: ffff21003db33000 [232066.599030] x26: ffff800005521ae0 x25: 0 x24: 0000000000000001 [232066.599319] x23: ffff800009920008 x22: ffff21003db33040 x21: ffff21003db33050 [232066.599628] x20: ffff410172fe9e40 x19: ffff410172fe9e00 x18: 0000000000000000 [232066.599914] x17: 0000000000000000 x16: 0000000000000004 x15: 0000000000000000 [232066.6001---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: fbcon: soluciona un problema de desreferencia de puntero NULL en fbcon_putcs syzbot ha encontrado un error de desreferencia de puntero NULL en fbcon. Aquí está el reproductor C simplificado: struct param { uint8_t type; struct tiocl_selection ts; }; int main() { struct fb_con2fbmap con2fb; struct param param; int fd = open("/dev/fb1", 0, 0); con2fb.console = 0x19; con2fb.framebuffer = 0; ioctl(fd, FBIOPUT_CON2FBMAP, &con2fb); param.type = 2; param.ts.xs = 0; param.ts.ys = 0; param.ts.xe = 0; param.ts.ye = 0; param.ts.sel_mode = 0; int fd1 = open("/dev/tty1", O_RDWR, 0); ioctl(fd1, TIOCLINUX, &param); con2fb.console = 1; con2fb.framebuffer = 0; ioctl(fd, FBIOPUT_CON2FBMAP, &con2fb); devolver 0; } Después de llamar a ioctl(fd1, TIOCLINUX, &param), el ioctl(fd, FBIOPUT_CON2FBMAP, &con2fb) subsiguiente hace que el núcleo siga una ruta de ejecución diferente: set_con2fb_map -> con2fb_init_display -> fbcon_set_disp -> redraw_screen -> hide_cursor -> clear_selection -> highlight -> invert_screen -> do_update_region -> fbcon_putcs -> ops->putcs Dado que ops->putcs es un puntero NULL, esto lleva a un pánico del núcleo. Para evitar esto, necesitamos llamar a set_blitting_type() dentro de set_con2fb_map() para inicializar correctamente ops->putcs.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/display: Verificar puntero nulo antes de desreferenciar se [QUÉ Y CÓMO] se verificó como nulo previamente en la misma función, lo que indica que podría ser nulo; por lo tanto, se debe verificar cuando se vuelva a utilizar. Esto soluciona 1 problema FORWARD_NULL informado por Coverity.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: serial: proteger uart_port_dtr_rts() en uart_shutdown() también El commit af224ca2df29 (serial: core: Prevenir el acceso inseguro al puerto uart, parte 3) agregó algunas comprobaciones uport == NULL. Agregó una a uart_shutdown(), por lo que el commit asume que uport puede ser NULL allí. Pero justo después de esa protección, hay una llamada "uart_port_dtr_rts(uport, false);" sin protección. Eso se invoca solo si HUPCL está configurado, por lo que supongo que esa es la razón por la que no vemos muchos de estos informes. O no puede ser NULL en este punto en absoluto por alguna razón :P. Hasta que se investigue lo anterior, manténgase del lado seguro y mueva esta desreferencia al if también. Obtuve esta inconsistencia de Coverity bajo CID 1585130. Gracias.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: thermal: core: copia libre de tzp junto con la zona térmica. Aún se puede acceder al objeto al que apunta tz->tzp después de liberarlo en thermal_zone_device_unregister(), por lo que debe mover su liberación al punto después de que se haya completado la eliminación en el que ya no se pueda acceder a él.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: thermal: core: recuento de referencia de la zona en thermal_zone_get_by_id() Hay lugares en el código de netlink térmico donde nada impide que el objeto de zona térmica desaparezca mientras se accede a él después de que thermal_zone_get_by_id() lo haya devuelto. Para solucionar esto, haga que thermal_zone_get_by_id() obtenga una referencia en el objeto de dispositivo de zona térmica que se devolverá con la ayuda de get_device(), bajo thermal_list_lock, y ajuste todos sus llamadores a este cambio con la ayuda de la infraestructura cleanup.h.