Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/etnaviv: comprobar mapeo cosechado en etnaviv_iommu_unmap_gem Cuando el mapeo ya fue cosechado, anular el mapeo debe ser una operación nula, ya que de lo contrario intentaríamos eliminar el mapeo dos veces, corrompiendo las estructuras de datos involucradas.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ocfs2: dlmfs: se corrige la gestión de errores de user_dlm_destroy_lock Cuando user_dlm_destroy_lock fallaba, no limpiaba las banderas que establecía antes de salir. Para USER_LOCK_IN_TEARDOWN, si esta función falla debido a que el bloqueo aún está en uso, la próxima vez que unlink invoque esta función, devolverá éxito y luego unlink eliminará el inodo y la dentry si el bloqueo no está en uso (archivo cerrado), pero el bloqueo dlm aún está vinculado en el recurso de bloqueo dlm, luego cuando bast ingrese, activará un pánico debido a use after free. Vea el siguiente seguimiento de llamada de pánico. Para solucionar esto, USER_LOCK_IN_TEARDOWN debe revertirse si falla. Y también debe devolverse un error si USER_LOCK_IN_TEARDOWN está configurado para informar al usuario que unlink falló. En el caso de que falle ocfs2_dlm_unlock, además de USER_LOCK_IN_TEARDOWN, también se requiere borrar USER_LOCK_BUSY. Aunque se libere el bloqueo de giro en el medio, pero USER_LOCK_IN_TEARDOWN aún esté configurado, para USER_LOCK_BUSY, si antes de cada lugar que espera en este indicador, se marca USER_LOCK_IN_TEARDOWN para que se libere, eso asegurará que ningún flujo espere en el indicador de ocupado establecido por user_dlm_destroy_lock(), entonces podemos simplemente revertir USER_LOCK_BUSY cuando falla ocfs2_dlm_unlock. Corrija user_dlm_cluster_lock(), que es la única función que no sigue esto. [ 941.336392] (python,26174,16):dlmfs_unlink:562 ERROR: desvincular 004fb0000060000b5a90b8c847b72e1, error -16 de la destrucción [ 989.757536] ------------[ cortar aquí ]------------ [ 989.757709] ¡ERROR del kernel en fs/ocfs2/dlmfs/userdlm.c:173! [ 989.757876] código de operación no válido: 0000 [#1] SMP [ 989.758027] Módulos vinculados en: ksplice_2zhuk2jr_ib_ipoib_new(O) ksplice_2zhuk2jr(O) mptctl mptbase xen_netback xen_blkback xen_gntalloc xen_gntdev xen_evtchn cdc_ether usbnet mii ocfs2 jbd2 rpcsec_gss_krb5 auth_rpcgss nfsv4 nfsv3 nfs_acl nfs fscache lockd grace ocfs2_dlmfs ocfs2_stack_o2cb ocfs2_dlm ocfs2_nodemanager ocfs2_stackglue configfs bnx2fc fcoe libfcoe libfc scsi_transport_fc sunrpc ipmi_devintf puente stp llc rds_rdma enlace rds ib_sdp ib_ipoib rdma_ucm ib_ucm ib_uverbs ib_umad rdma_cm ib_cm iw_cm falcon_lsm_serviceable(PE) falcon_nf_netcontain(PE) mlx4_vnic falcon_kal(E) falcon_lsm_pinned_13402(E) mlx4_ib ib_sa ib_mad ib_core ib_addr xenfs xen_privcmd dm_multipath iTCO_wdt soporte de proveedor de iTCO pcspkr sb_edac edac_core i2c_i801 lpc_ich mfd_core ipmi_ssif i2c_core ipmi_si ipmi_msghandler [ 989.760686] ioatdma sg ext3 jbd mbcache sd_mod ahci libahci ixgbe dca ptp pps_core vxlan udp_tunnel ip6_udp_tunnel megaraid_sas mlx4_core crc32c_intel be2iscsi bnx2i cnic uio cxgb4i cxgb4 cxgb3i libcxgbi ipv6 cxgb3 mdio libiscsi_tcp qla4xxx iscsi_boot_sysfs libiscsi scsi_transport_iscsi wmi dm_mirror dm_region_hash dm_log dm_mod [última descarga: ksplice_2zhuk2jr_ib_ipoib_old] [ 989.761987] CPU: 10 PID: 19102 Comm: dlm_thread Contaminado: P OE 4.1.12-124.57.1.el6uek.x86_64 #2 [ 989.762290] Nombre del hardware: Oracle Corporation ORACLE SERVER X5-2/ASM,MOTHERBOARD,1U, BIOS 30350100 17/06/2021 [ 989.762599] tarea: ffff880178af6200 ti: ffff88017f7c8000 task.ti: ffff88017f7c8000 [ 989.762848] RIP: e030:[] [] __user_dlm_queue_lockres.part.4+0x76/0x80 [ocfs2_dlmfs] [ 989.763185] RSP: e02b:ffff88017f7cbcb8 EFLAGS: 00010246 [ 989.763353] RAX: 0000000000000000 RBX: ffff880174d48008 RCX: 0000000000000003 [ 989.763565] RDX: 0000000000120012 RSI: 0000000000000003 RDI: ffff880174d48170 [ 989.763778] RBP: R08: ffff88021f4293b0 R09: 0000000000000000 [ 989.763991] R10: ffff880179c8c000 R11: 0000000000000003 R12: ffff880174d48008 [ 989.764204] R13: 0000000000000003 R14: ffff880179c8c000 R15: ffff88021db7a000 [ 989.764422] FS: 0000000000000000(0000) GS:ffff880247480000(0000) knlGS:ffff880247480000 [ 989.764685] CS: e033 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 989.764865] CR2: ffff8000007f6800 CR3: ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ip_gre: prueba csum_start en lugar del encabezado de transporte GRE con TUNNEL_CSUM aplicará la descarga de suma de comprobación local en los paquetes CHECKSUM_PARTIAL. ipgre_xmit debe validar csum_start después de un skb_pull opcional, de lo contrario lco_csum puede provocar un desbordamiento. La comprobación original era if (csum && skb_checksum_start(skb) < skb->data) return -EINVAL; Esto tenía falsos positivos cuando skb_checksum_start no está definido: cuando ip_summed no es CHECKSUM_PARTIAL. Una mejora discutida fue sencilla if (csum && skb->ip_summed == CHECKSUM_PARTIAL && skb_checksum_start(skb) < skb->data) return -EINVAL; Pero finalmente se revisó más a fondo: - restringir la verificación a la única rama donde sea necesario, en una ruta GRE poco común que usa header_ops y llama a skb_pull. - probar skb_transport_header, que se establece junto con csum_start en skb_partial_csum_set en la ruta de datos header_ops normal. Resulta que skbs puede llegar a esta rama sin el encabezado de transporte establecido, por ejemplo, a través de la redirección BPF. Revise la verificación nuevamente para verificar csum_start directamente, y solo si CHECKSUM_PARTIAL. Deje la verificación en la ubicación actualizada. Verifique el campo independientemente de si TUNNEL_CSUM está configurado.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: Seguimiento: se corrige la función inactiva llamada desde un contexto no válido en el kernel RT Al configurar bootparams="trace_event=initcall:initcall_start tp_printk=1" en la línea de comandos, se llamó a output_printk() y a spin_lock_irqsave() en la adecuación del contexto de interrupción atómica y deshabilitada de irq. En el kernel PREEMPT_RT, estos bloqueos se reemplazan con rt-spinlock sleepable, por lo que se activará la llamada de pila trace. Corríjalo con raw_spin_lock_irqsave cuando PREEMPT_RT y "trace_event=initcall:initcall_start tp_printk=1" estén habilitados. ERROR: función de suspensión llamada desde un contexto no válido en kernel/locking/spinlock_rt.c:46 in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 1, name: swapper/0 preempt_count: 2, expected: 0 Profundidad de anidamiento de RCU: 0, expected: 0 Preempción deshabilitada en: [] try_to_wake_up+0x7e/0xba0 CPU: 0 PID: 1 Comm: swapper/0 No contaminado 5.17.1-rt17+ #19 34c5812404187a875f32bee7977f7367f9679ea7 Nombre del hardware: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-2 01/04/2014 Seguimiento de llamadas: dump_stack_lvl+0x60/0x8c dump_stack+0x10/0x12 __might_resched.cold+0x11d/0x155 rt_spin_lock+0x40/0x70 trace_event_buffer_commit+0x2fa/0x4c0 ? map_vsyscall+0x93/0x93 trace_event_raw_event_initcall_start+0xbe/0x110 ? perf_trace_initcall_finish+0x210/0x210 ? probe_sched_wakeup+0x34/0x40 ? ttwu_do_wakeup+0xda/0x310 ? trace_hardirqs_on+0x35/0x170 ? map_vsyscall+0x93/0x93 do_one_initcall+0x217/0x3c0 ? trace_event_raw_event_initcall_level+0x170/0x170 ? push_cpu_stop+0x400/0x400 ? cblist_init_generic+0x241/0x290 kernel_init_freeable+0x1ac/0x347 ? _raw_spin_unlock_irq+0x65/0x80 ? rest_init+0xf0/0xf0 kernel_init+0x1e/0x150 ret_from_fork+0x22/0x30

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: iommu/arm-smmu: se corrige la posible eliminación de referencias PTR nulas en arm_smmu_device_probe(). Esto provocará una eliminación de referencias PTR nulas al usar 'res', si platform_get_resource() devuelve NULL, por lo que se pasa a usar 'res' después de devm_ioremap_resource() que lo comprobará para evitar la eliminación de referencias PTR nulas. Y se usa devm_platform_get_and_ioremap_resource() para simplificar el código.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mips: cpc: Se corrige la pérdida de recuento de referencias en mips_cpc_default_phys_base. Agregue of_node_put() faltante para liberar el recuento de referencias incrementado por of_find_compatible_node().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: rtl818x: Evitar el uso de colas no inicializadas El uso de colas no existentes puede provocar un pánico en el kernel con tarjetas rtl8180/rtl8185. Ignore la prioridad skb para esas tarjetas, solo tienen una cola tx. Pierre Asselin (pa@panix.com) informó sobre el fallo del kernel en el foro de Gentoo: https://forums.gentoo.org/viewtopic-t-1147832-postdays-0-postorder-asc-start-25.html También confirmó que este parche soluciona el problema. En resumen, esto sucedió: Después de actualizar wpa_supplicant de 2.9 a 2.10, el kernel se bloqueó con un "error de división: 0000" al conectarse a un AP. El puerto de control tx ahora intenta usar IEEE80211_AC_VO para la prioridad, que wpa_supplicants comienza a usar en 2.10. Como solo la parte rtl8187se del controlador admite QoS, la prioridad del skb se establece en IEEE80211_AC_BE (2) por mac80211 para las tarjetas rtl8180/rtl8185. Luego, rtl8180 lee incondicionalmente la prioridad y finalmente se bloquea en la línea 544 de drivers/net/wireless/realtek/rtl818x/rtl8180/dev.c sin este parche: idx = (ring->idx + skb_queue_len(&ring->queue)) % ring->entries "ring->entries" es cero para las tarjetas rtl8180/rtl8185, tx_ring[2] nunca se inicializó.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bcache: evitar el bloqueo por falta de espacio en el diario reservando 1 depósito de diario El bloqueo por falta de espacio en el diario se informó de vez en cuando. Tal bloqueo puede ocurrir en la siguiente situación. Cuando todos los depósitos de diario están completamente llenos por jset activo con una carga de E/S de escritura pesada, el registro del conjunto de caché (después de un reinicio) cargará todos los jsets activos y los insertará en el btree nuevamente (lo que se llama reproducción del diario). Si una bkey registrada en el diario se inserta en un nodo btree y da como resultado la división del nodo btree, se puede activar una nueva solicitud de diario. Por ejemplo, el btree crece un nivel más después de la división del nodo, entonces el registro del nodo raíz en el superbloque del dispositivo de caché se actualizará mediante bch_journal_meta() desde bch_btree_set_root(). Pero no hay espacio en los depósitos de diario, la reproducción del diario tiene que esperar a que se recupere un nuevo depósito de diario después de reproducir al menos un depósito de diario. Este es un ejemplo de cómo ocurre el bloqueo por falta de espacio en el diario. La solución para evitar el bloqueo es reservar 1 depósito de diario en tiempo de ejecución y solo permitir que el depósito de diario reservado se use durante el procedimiento de registro del conjunto de caché para cosas como la reproducción del diario. Entonces, el espacio del diario nunca se llenará por completo, ya no hay posibilidad de que se produzca un bloqueo por falta de espacio en el diario. Este parche agrega un nuevo miembro "bool do_reserve" en struct journal, se inicializa a 0 (falso) cuando se asigna struct journal y se establece en 1 (verdadero) por bch_journal_space_reserve() cuando se realiza toda la inicialización en run_cache_set(). En el tiempo de ejecución, cuando journal_reclaim() intenta asignar un nuevo depósito de diario, se llama a free_journal_buckets() para verificar si hay suficientes depósitos de diario libres para usar. Si solo hay 1 depósito de diario libre y journal->do_reserve es 1 (verdadero), el último depósito está reservado y free_journal_buckets() devolverá 0 para indicar que no hay ningún depósito de diario libre. Luego, journal_reclaim() se dará por vencido y la próxima vez intentará ver si hay un depósito de diario libre para asignar. Con este método, siempre hay un depósito de diario reservado en tiempo de ejecución. Durante el registro del conjunto de caché, journal->do_reserve es 0 (falso), por lo que el depósito de diario reservado se puede utilizar para evitar el bloqueo por falta de espacio.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: vduse: corrige la desreferencia de puntero NULL en el acceso a sysfs El dispositivo de control no tiene drvdata. Por lo tanto, obtendremos una desreferencia de puntero NULL al acceder al atributo msg_timeout del dispositivo de control a través de sysfs: [ 132.841881][ T3644] ERROR: desreferencia de puntero NULL del kernel, dirección: 00000000000000f8 [ 132.850619][ T3644] RIP: 0010:msg_timeout_show (drivers/vdpa/vdpa_user/vduse_dev.c:1271) [ 132.869447][ T3644] dev_attr_show (drivers/base/core.c:2094) [ 132.870215][ T3644] sysfs_kf_seq_show (fs/sysfs/file.c:59) [ 132.871164][ T3644] ? archivo_bin_de_eliminación_de_dispositivo (drivers/base/core.c:2088) [ 132.872082][ T3644] kernfs_seq_show (fs/kernfs/file.c:164) [ 132.872838][ T3644] seq_read_iter (fs/seq_file.c:230) [ 132.873578][ T3644] ? __vmalloc_area_node (mm/vmalloc.c:3041) [ 132.874532][ T3644] kernfs_fop_read_iter (fs/kernfs/file.c:238) [ 132.875513][ T3644] __kernel_read (fs/read_write.c:440 (discriminador 1)) [ 132.876319][ T3644] kernel_read (fs/read_write.c:459) [ 132.877129][ T3644] kernel_read_file (fs/kernel_read_file.c:94) [ 132.877978][ T3644] kernel_read_file_from_fd (include/linux/file.h:45 fs/kernel_read_file.c:186) [ 132.879019][ T3644] __do_sys_finit_module (kernel/module.c:4207) [ 132.879930][ T3644] __ia32_sys_finit_module (kernel/module.c:4189) [ 132.880930][ T3644] do_int80_syscall_32 (arch/x86/entry/common.c:112 arch/x86/entry/common.c:132) [ 132.881847][ T3644] entry_INT80_compat (arch/x86/entry/entry_64_compat.S:419) Para solucionarlo, no cree el atributo innecesario para el dispositivo de control. ya no.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nfc: st21nfca: se corrigen las fugas de memoria en la gestión de EVT_TRANSACTION. Las rutas de error no liberan la memoria asignada previamente. Agregue devm_kfree() a esas rutas de error.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: scsi: lpfc: Desreferencia de puntero NULL de dirección después de starget_to_rport() Las llamadas a starget_to_rport() pueden devolver NULL. Agregue una comprobación de rport NULL antes de la desreferencia.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: tcp: agregar descriptores de acceso para leer/establecer tp->snd_cwnd Tuvimos varios errores a lo largo de los años con código que rompía la suposición de que tp->snd_cwnd es mayor que cero. Últimamente, syzbot informó que se puede activar WARN_ON_ONCE(!tp->prior_cwnd) agregado en el commit 8b8a321ff72c ("tcp: corregir cwnd cero en tcp_cwnd_reduction"), y sin una reproducción tendríamos que dedicar un tiempo considerable a encontrar el error. En lugar de quejarnos demasiado tarde, queremos detectar dónde y cuándo tp->snd_cwnd se establece en un valor ilegal.