Vulnerabilidades

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: sfc: corrige el desplazamiento del canal TX cuando se usan interrupciones heredadas En el modo de interrupción heredado, tx_channel_offset estaba codificado en 1, pero eso no es correcto si efx_sepparate_tx_channels es falso. En ese caso, el desplazamiento es 0 porque las colas de transmisión están en el único canal existente en el índice 0, junto con la cola de recepción. Sin esta solución, tan pronto como intenta enviar tráfico, intenta obtener las colas de transmisión de un canal no inicializado y obtiene estos errores: ADVERTENCIA: CPU: 1 PID: 0 en drivers/net/ethernet/sfc/tx.c: 540 efx_hard_start_xmit+0x12e/0x170 [sfc] [...] RIP: 0010:efx_hard_start_xmit+0x12e/0x170 [sfc] [...] Seguimiento de llamadas: dev_hard_start_xmit+0xd7/0x230 sch_direct_xmit+0x9f/0x360 +0x890 /0xa40 [...] ERROR: no se puede manejar la desreferencia del puntero NULL del kernel en 0000000000000020 [...] RIP: 0010:efx_hard_start_xmit+0x153/0x170 [sfc] [...] Seguimiento de llamadas: dev_hard_start_xmit+0xd7/ 0x230 sch_direct_xmit+0x9f/0x360 __dev_queue_xmit+0x890/0xa40 [...]

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: sfc: corrige la desreferencia del puntero nulo en efx_hard_start_xmit Intentar obtener el canal de la variable tx_queue aquí es incorrecto porque solo podemos estar aquí si tx_queue es NULL, por lo que no debemos desreferenciarlo. Como dice el comentario anterior en el código, es muy poco probable que esto suceda, pero de todos modos está mal, así que solucionémoslo. Encontré este problema debido a un error diferente que provocó que tx_queue fuera NULL. Si eso sucede, este es el mensaje de error que recibimos aquí: ERROR: no se puede manejar la desreferencia del puntero NULL del kernel en 0000000000000020 [...] RIP: 0010:efx_hard_start_xmit+0x153/0x170 [sfc]

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm/slab_common: corrección posible doble liberación de kmem_cache Al realizar la prueba slub_debug, el caso de prueba kunit 'test_memcache_typesafe_by_rcu' de kfence causa un error de use-after-free: ERROR: KASAN: uso después -free en kobject_del+0x14/0x30 Lectura de tamaño 8 en addr ffff888007679090 por tarea kunit_try_catch/261 CPU: 1 PID: 261 Comm: kunit_try_catch Contaminado: GBN 6.0.0-rc5-next-20220916 #17 Nombre de hardware: PC estándar QEMU ( I440FX+PIIX, 1996), BIOS 1.15.0-1 04/01/2014 TRACE DE LLAMADA: dump_stack_lvl+0x34/0x48 print_address_description.constprop.0+0x87/0x2a5 print_rePort+0x103/0x1ed kasan_report+0xb7/0x140/0x140/0x140+0xb7/0x140/0x140/0x140/0x14/0x140/0xil 0x14/0x30 kmem_cache_destroy+0x130/0x170 test_exit+0x1a/0x30 kunit_try_run_case+0xad/0xc0 kunit_generic_run_threadfn_adapter+0x26/0x50 kthread+0x17b/0x1b0 La causa está dentro de kmem_cache_destroy (): kmem_cache_destroy adquirir bloqueo/mutex Shutdown_cache Schedule_work(kmem_cache_release) (si el indicador RCU está establecido) liberar bloqueo/mutex kmem_cache_release (si el indicador RCU no está establecido) En un momento determinado, el trabajo programado podría ejecutarse antes de la siguiente verificación del indicador RCU, lo que luego puede obtener un valor incorrecto y provocar un doble kmem_cache_release() . Solucionarlo almacenando en caché la bandera RCU dentro del área protegida, como 'refcnt'

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: scsi: qla2xxx: Reparar pérdida de memoria en __qlt_24xx_handle_abts() el commit 8f394da36a36 ("scsi: qla2xxx: Drop TARGET_SCF_LOOKUP_LUN_FROM_TAG") hizo que la función __qlt_24xx_handle_abts() regresara antes si tcm_qla2xxx_find_cmd_by_tag() no lo hizo encontró un comando, pero no pudo limpiar la memoria asignada para el comando de administración.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ipvlan: corrige errores fuera de los límites causados por skb->mac_header no configurado si se usa un socket AF_PACKET para enviar paquetes a través de ipvlan y se cambia la función xmit predeterminada del socket AF_PACKET desde dev_queue_xmit() a paquete_direct_xmit() a través de setsockopt() con el nombre de opción PACKET_QDISC_BYPASS, es posible que skb->mac_header no se restablezca y permanezca en el valor inicial de 65535, esto puede desencadenar errores de losa fuera de los límites como se muestra a continuación : =================================================== ================ UG: KASAN: losa fuera de los límites en ipvlan_xmit_mode_l2+0xdb/0x330 [ipvlan] PU: 2 PID: 1768 Comm: raw_send Kdump: cargado No contaminado 6.0.0-rc4+ #6 nombre de hardware: PC estándar QEMU (i440FX + PIIX, 1996), BIOS 1.14.0-1.fc33 todo Seguimiento: print_address_description.constprop.0+0x1d/0x160 print_report.cold+0x4f/0x112 kasan_report+ 0xa3/0x130 ipvlan_xmit_mode_l2+0xdb/0x330 [ipvlan] ipvlan_start_xmit+0x29/0xa0 [ipvlan] __dev_direct_xmit+0x2e2/0x380 paquete_direct_xmit+0x22/0x60 paquete_snd+0x7c9/0xc40 0x9a/0xa0 __sys_sendto+0x18a/0x230 __x64_sys_sendto+0x74/0x90 do_syscall_64 +0x3b/0x90 Entry_SYSCALL_64_after_hwframe+0x63/0xcd La causa principal es: 1. paquete_snd() solo restablece skb->mac_header cuando sock->tipo es SOCK_RAW y skb->protocolo no se especifica como en paquete_parse_headers() 2. paquete_direct_xmit() no restablece skb->mac_header como dev_queue_xmit() En este caso, skb->mac_header es 65535 cuando se llama a ipvlan_xmit_mode_l2(). Entonces, cuando ipvlan_xmit_mode_l2() obtiene el encabezado mac con eth_hdr() que usa "skb->head + skb->mac_header", se produce un acceso fuera de los límites. Este parche reemplaza eth_hdr() con skb_eth_hdr() en ipvlan_xmit_mode_l2() y restablece el encabezado de mac en multidifusión para resolver este error fuera de los límites.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ice: se corrige el fallo manteniendo cfg antiguo cuando se actualizan TC más que colas. Hay problemas si se asignan colas con menos clases de tráfico. el commit a632b2a4c920 ("ice: ethtool: Prohibir configuración de canal incorrecta para DCB") ya no permite configurar menos colas que los TC. Otro caso es si primero configuramos menos colas y luego actualizamos más configuraciones de TC debido a LLDP, ice_vsi_cfg_tc() fallará pero dejará num_txq/rxq y tc_cfg sucios en vsi, lo que provocará un acceso al puntero no válido. [ 95.968089] ice 0000:3b:00.1: Más TC definidos que colas/anillos asignados. [ 95.968092] ice 0000:3b:00.1: ¡Intentando utilizar más colas de Rx (8) de las asignadas (1)! [ 95.968093] ice 0000:3b:00.1: Error al configurar TC para índice VSI: 0 [ 95.969621] falla de protección general: 0000 [#1] SMP NOPTI [ 95.969705] CPU: 1 PID: 58405 Comm: lldpad Kdump: cargado Contaminado: GUWO --------- -t - 4.18.0 #1 [ 95.969867] Nombre de hardware: OEM/BC11SPSCB10, BIOS 8.23 30/12/2021 [ 95.969992] RIP: 0010:devm_kmalloc+0xa/0x60 [ 95.970052] Código: 5c ff ff ff 31 c0 5b 5d 41 5c c3 b8 f4 ff ff ff eb f4 0f 1f 40 00 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 89 d1 <8b> 97 0 02 00 00 48 8d 7e 18 48 39 f7 72 3f 55 89 ce 53 48 8b 4c [ 95.970344] RSP: 0018:ffffc9003f553888 EFLAGS: 00010206 [ 95.970425] RAX: muerto0000000 00200 RBX: ffffea003c425b00 RCX: 00000000006080c0 [ 95.970536] RDX: 00000000006080c0 RSI: 0000000000000200 RDI: muerto000000000200 [ 95.970648] RBP: muerto000000000200 R08: 00000000000463c0 R09: ffff888ffa900000 [ 95.970760] R10: 0000000000000000 R11: 00000000000002 R12: ffff888ff6b40100 [ 95.970870] R13: ffff888ff6a55018 R14: 0000000000000000 R15: ffff888ff6a55460 [ 95.970981] FS: 1b7d24700(0000) GS: ffff88903ee80000(0000) knlGS:00000000000000000 [ 95.971108] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 95.971197] CR2: 10 CR3: 0000000f2c1de002 CR4: 00000000007606e0 [ 95.971309] DR0: 0000000000000000 DR1: 00000000000000000 DR2: 0000000000000000 [ 95.971419 ] DR3 : 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 95.971530] PKRU: 55555554 [ 95.971573] Seguimiento de llamadas: [ 95.971622] x110 [hielo] [ 95.971695] ice_vsi_setup_rx_rings+0x54/0x90 [hielo] [ 95.971774] ice_vsi_open+0x25/0x120 [hielo] [ 95.971843] ice_open_internal+0xb8/0x1f0 [hielo] [ 95.971919] ice_ena_vsi+0x4f/0xd0 [hielo] [ 95.971987] ice_dcb_ena_dis_vsi.constprop.5+0x29/0x90 [hielo] [ 95.972082] f_dcb_cfg+0x29a/0x380 [hielo ] [ 95.972154] ice_dcbnl_setets+0x174/0x1b0 [hielo] [ 95.972220] dcbnl_ieee_set+0x89/0x230 [ 95.972279] ? dcbnl_ieee_del+0x150/0x150 [ 95.972341] dcb_doit+0x124/0x1b0 [ 95.972392] rtnetlink_rcv_msg+0x243/0x2f0 [ 95.972457] ? dcb_doit+0x14d/0x1b0 [95.972510]? __kmalloc_node_track_caller+0x1d3/0x280 [95.972591]? rtnl_calcit.isra.31+0x100/0x100 [ 95.972661] netlink_rcv_skb+0xcf/0xf0 [ 95.972720] netlink_unicast+0x16d/0x220 [ 95.972781] netlink_sendmsg+0x2ba/0x3a0 [ 95.975 891] sock_sendmsg+0x4c/0x50 [ 95.979032] ___sys_sendmsg+0x2e4/0x300 [ 95.982147] ? kmem_cache_alloc+0x13e/0x190 [95.985242]? __wake_up_common_lock+0x79/0x90 [95.988338]? __check_object_size+0xac/0x1b0 [ 95.991440] ? _copiar_al_usuario+0x22/0x30 [ 95.994539] ? move_addr_to_user+0xbb/0xd0 [95.997619]? __sys_sendmsg+0x53/0x80 [ 96.000664] __sys_sendmsg+0x53/0x80 [ 96.003747] do_syscall_64+0x5b/0x1d0 [ 96.006862] Entry_SYSCALL_64_after_hwframe+0x65/0xca Solo actualización num_txq/rxq cuando se pasa la verificación y restaura tc_cfg si falla el mapa de cola de configuración.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: ice: no desconectar dos veces el auxiliar en el reinicio iniciado por el par. En la devolución de llamada de IDC a la que se accede cuando los controladores auxiliares solicitan un reinicio, se llama a la función para desconectar los dispositivos auxiliares. Esta función también se llama en la función ice_prepare_for_reset. Esta doble llamada está provocando un ERROR de "programación atómica". [662.676430] ice 0000:4c:00.0 rocep76s0: cqp opcode = 0x1 maj_err_code = 0xffff min_err_code = 0x8003 [662.676609] ice 0000:4c:00.0 rocep76s0: [Modificar error de comando QP][op_code=8] =-29 esperando=1 complete_err=1 maj=0xffff min=0x8003 [662.815006] ice 0000:4c:00.0 rocep76s0: Notificación de evento ICE OICR: oicr = 0x10000003 [662.815014] ice 0000:4c:00.0 rocep76s0: Error PE crítico, GLPE_CRITERR= 0x00011424 [662.815017] hielo 0000:4c:00.0 rocep76s0: Solicitando un reinicio [662.815475] ERROR: programación mientras atómico: swapper/37/0/0x00010002 [662.815475] ERROR: programación mientras atómico: swapper/37/0/0x00010002 [ 662.815477] Módulos vinculados en: rpcsec_gss_krb5 auténtico x86_pkg_temp_thermal intel_powerclamp coretemp target_core_mod snd_hda_intel ib_iser snd_intel_dspcfg libiscsi snd_intel_sdw_acpi scsi_transport_iscsi kvm_intel iTCO_wdt rdma_cm snd_hda_codec kvm iw_cm ipmi_ssif iTCO_vendor_support s nd_hda_core irqbypass crct10dif_pclmul crc32_pclmul ghash_clmulni_intel snd_hwdep snd_seq snd_seq_device rapl snd_pcm snd_timer isst_if_mbox_pci pcspkr isst_if_mmio irdma intel_uncore idxd acpi_ipmi joydev isst_if_common snd mei_me idxd_bus ipmi_si soundcore i2c_i801 mei i2c_smbus i2c_ismt ipmi_msghandler acpi_power_meter acpi_pad rv(OE) ib_uverbs ib_cm ib_core xfs libcrc32c ast i2c_algo_bit drm_vram_helper drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops drm_ttm_helpe r ttm [ 662.815546 ] nvme nvme_core ice drm crc32c_intel i40e t10_pi wmi pinctrl_emmitsburg dm_mirror dm_region_hash dm_log dm_mod fuse [ 662.815557] Preferencia deshabilitada en: [ 662.815558] [<0000000000000000>] 0x0 [ 6 62.815563] CPU: 37 PID: 0 Comunicaciones: intercambiador/37 Kdump: cargado Contaminado: GS OE 5.17.1 #2 [ 662.815566] Nombre del hardware: Intel Corporation D50DNP/D50DNP, BIOS SE5C6301.86B.6624.D18.2111021741 02/11/2021 [ 662.815568] Seguimiento de llamadas: [ 662.815572] [ 662 .815574] dump_stack_lvl +0x33/0x42 [ 662.815581] __schedule_bug.cold.147+0x7d/0x8a [ 662.815588] __schedule+0x798/0x990 [ 662.815595] horario+0x44/0xc0 [ 662.815597] +0x14/0x20 [ 662.815600] __mutex_lock.isra.11+0x46c /0x490 [662.815603] ? __ibdev_printk+0x76/0xc0 [ib_core] [ 662.815633] dispositivo_del+0x37/0x3d0 [ 662.815639] ice_unplug_aux_dev+0x1a/0x40 [ice] [ 662.815674] ice_schedule_reset+0x3c/0xd0 [ice] [ 2.815693] irdma_iidc_event_handler.cold.7+0xb6/0xd3 [irdma] [662.815712] ? bitmap_find_next_zero_area_off+0x45/0xa0 [ 662.815719] ice_send_event_to_aux+0x54/0x70 [ice] [ 662.815741] ice_misc_intr+0x21d/0x2d0 [ice] [ 662.815756] pu+0x4c/0x180 [ 662.815762] handle_irq_event_percpu+0xf/0x40 [ 662.815764] handle_irq_event+0x34/ 0x60 [ 662.815766] handle_edge_irq+0x9a/0x1c0 [ 662.815770] __common_interrupt+0x62/0x100 [ 662.815774] common_interrupt+0xb4/0xd0 [ 662.815779] [ 662.81578 0] [ 662.815780] asm_common_interrupt+0x1e/0x40 [ 662.815785] RIP : 0010:cpuidle_enter_state+0xd6/0x380 [ 662.815789] Código: 49 89 c4 0f 1f 44 00 00 31 ff e8 65 d7 95 ff 45 84 ff 74 12 9c 58 f6 c4 02 0f 85 64 02 00 31 ff e8 ae c5 9c ff fb 45 85 f6 <0f> 88 12 01 00 00 49 63 d6 4c 2b 24 24 48 8d 04 52 48 8d 04 82 49 [ 662.815791] RSP: 0018:ff2c2c4f18edbe80 EFLAGS: 0202 [662.815793] RAX: ff280805df140000 RBX: 0000000000000002 RCX : 000000000000001f [ 662.815795] RDX: 0000009a52da2d08 R ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: netfilter: nfnetlink_osf: corrige una posible coincidencia falsa en nf_osf_find() nf_osf_find() devuelve verdadero incorrectamente en caso de discrepancia, esto lleva a copiar el área de memoria no inicializada en nft_osf que puede usarse para filtrar el kernel obsoleto apilar datos en el espacio de usuario.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: firmware: arm_scmi: Refuerza los accesos a los dominios de reinicio. El acceso a los descriptores de dominios de reinicio por el índice ante las solicitudes de los controladores SCMI a través de la interfaz de operaciones de reinicio de SCMI puede conducir potencialmente a violaciones fuera de los límites. si el controlador SCMI se comporta mal. Agregue una verificación de coherencia interna antes de que se acceda a dichos descriptores de dominio.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: dmaengine: ti: k3-udma-private: corrige el error de fuga de recuento en of_xudma_dev_get() Deberíamos llamar a of_node_put() para la referencia devuelta por of_parse_phandle() en la ruta de error o cuando ya no se usa. Aquí solo necesitamos mover of_node_put() antes de la verificación.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: arm64: topología: corrige posible desbordamiento en amu_fie_setup() cpufreq_get_hw_max_freq() devuelve la frecuencia máxima en kHz como *unsigned int*, mientras que freq_inv_set_max_ratio() pasa esta frecuencia en Hz como 'u64 '. Multiplicar la frecuencia máxima por 1000 puede potencialmente resultar en un desbordamiento; multiplicar por 1000ULL debería evitar eso... Encontrado por el Centro de verificación de Linux (linuxtesting.org) con la herramienta de análisis estático SVACE.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm: slub: corrige las invocaciones de flu_cpu_slab()/__free_slab() en el contexto de la tarea. Commit 5a836bf6b09f ("mm: slub: mover invocaciones de flu_cpu_slab() invocaciones de __free_slab() fuera del contexto IRQ") movió todas las invocaciones de flu_cpu_slab() a la cola de trabajo global para evitar un problema relacionado con la llamada de desactivate_slab()/__free_slab() desde un Contexto IRQ en núcleos PREEMPT_RT. Cuando se llama a la función Flush_all_cpu_locked() desde un contexto de tarea, puede suceder que una cola de trabajo con el bit WQ_MEM_RECLAIM configurado termine vaciando la cola de trabajo global, esto causará un problema de dependencia. cola de trabajo: WQ_MEM_RECLAIM nvme-delete-wq:nvme_delete_ctrl_work [nvme_core] se está vaciando! Eventos WQ_MEM_RECLAIM:flush_cpu_slab ADVERTENCIA: CPU: 37 PID: 410 en kernel/workqueue.c:2637 check_flush_dependency+0x10a/0x120 Cola de trabajo: vme-delete-wq nvme_delete_ctrl_work [ nvme_core] RIP: 0010:check_flush_dependency+0x10a/0x120[ 453.262125] Seguimiento de llamadas: __flush_work.isra.0+0xbf/0x220? __queue_work+0x1dc/0x420 Flush_all_cpus_locked+0xfb/0x120 __kmem_cache_shutdown+0x2b/0x320 kmem_cache_destroy+0x49/0x100 bioset_exit+0x143/0x190 blk_release_queue+0xb9/0x100 kobject_cleanup+0 x37/0x130 nvme_fc_ctrl_free+0xc6/0x150 [nvme_fc] nvme_free_ctrl+0x1ac/0x2b0 [nvme_core ] Corrija este error creando una cola de trabajo para la operación de vaciado con el bit WQ_MEM_RECLAIM establecido.