Vulnerabilidades

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: ssb: corrige la posible desreferencia del puntero NULL en ssb_device_uevent() La función ssb_device_uevent() primero intenta convertir el puntero 'dev' en 'struct ssb_device *'. Sin embargo, por error elimina la referencia a 'dev' antes de realizar la comprobación NULL, lo que podría provocar una desreferencia del puntero NULL si 'dev' es NULL. Para solucionar este problema, mueva la marca NULL antes de eliminar la referencia al puntero 'dev', asegurándose de que el puntero sea válido antes de intentar usarlo. Encontrado por el Centro de verificación de Linux (linuxtesting.org) con SVACE.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/lima: enmascara irqs en la ruta de tiempo de espera antes del restablecimiento completo. Existe una condición de ejecución en la que un trabajo de renderizado puede tardar el tiempo suficiente para activar el controlador de tiempo de espera del trabajo programado drm, pero también completar antes de que el controlador de tiempo de espera realice el restablecimiento completo. Esto se encuentra con condiciones de ejecución que el controlador de tiempo de espera no esperaba. En algunos casos muy específicos, actualmente puede resultar en un desequilibrio de recuento en lima_pm_idle, con un volcado de pila como: [10136.669170] ADVERTENCIA: CPU: 0 PID: 0 en drivers/gpu/drm/lima/lima_devfreq.c:205 lima_devfreq_record_idle+ 0xa0/0xb0... [10136.669459] pc: lima_devfreq_record_idle+0xa0/0xb0... [10136.669628] Rastreo de llamadas: [10136.669634] lima_devfreq_record_idle+0xa0/0xb0 [10136.669646] lima_sched_pipe_tas k_done+0x5c/0xb0 [10136.669656] lima_gp_irq_handler+0xa8/0x120 [ 10136.669666] __handle_irq_event_percpu+0x48/0x160 [10136.669679] handle_irq_event+0x4c/0xc0 Podemos evitar esa condición de ejecución por completo enmascarando los irqs al comienzo del controlador de tiempo de espera, momento en el cual renunciamos a esperar por ese trabajo por completo. Los irqs se habilitarán nuevamente en el próximo restablecimiento completo, que ya se realiza como recuperación mediante el controlador de tiempo de espera.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: mt76: mt7921s: soluciona posibles tareas bloqueadas durante la recuperación del chip Durante la recuperación del chip (por ejemplo, reinicio del chip), existe una posible situación en la que el trabajador del kernel reset_work esté manteniendo el bloqueo y esperando. El hilo del kernel stat_worker se estacionará, mientras stat_worker está esperando la liberación del mismo bloqueo. Provoca un punto muerto que resulta en el volcado de mensajes de tareas colgadas y un posible reinicio del dispositivo. Este parche evita la ejecución de stat_worker durante la recuperación del chip.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: scsi: qedi: soluciona el fallo al leer el atributo debugfs La función qedi_dbg_do_not_recover_cmd_read() invoca sprintf() directamente en un puntero __user, lo que provoca el fallo. Para solucionar este problema, use un pequeño búfer de pila local para sprintf() y luego llame a simple_read_from_buffer(), que a su vez realiza la llamada copy_to_user(). ERROR: no se puede manejar el error de página para la dirección: 00007f4801111000 PGD 8000000864df6067 P4D 8000000864df6067 PUD 864df7067 PMD 846028067 PTE 0 Ups: 0002 [#1] PREEMPT SMP PTI Nombre de hardware: HPE ProLi hormiga DL380 Gen10/ProLiant DL380 Gen10, BIOS U30 15/06/2023 RIP: 0010:memcpy_orig+0xcd/0x130 RSP: 0018:ffffb7a18c3ffc40 EFLAGS: 00010202 RAX: 00007f4801111000 RBX: 00007f4801111000 RCX: 000000000000000f RDX: 000000000000000f RSI: ffffffffc0bfd7a0 RDI: 00007f4801111000 RBP: ffffffffc0bfd7a0 R08: 725f746f6e5f6f64 R09: 3d7265766f636572 R10: 18c3ffd08 R11: 0000000000000000 R12: 00007f4881110fff R13: 000000007ffffff R14: ffffb7a18c3ffca0 R15: ffffffffc0bfd7af FS: 00007f480118a740(0000) GS:ffff98e38af00000(0000) 0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f4801111000 CR3: 0000000864b8e001 CR4: 000000000007706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffe0ff0 DR7: 0000000000000400 PKRU: 5554 Seguimiento de llamadas: ? __die_body+0x1a/0x60 ? page_fault_oops+0x183/0x510? exc_page_fault+0x69/0x150? asm_exc_page_fault+0x22/0x30? memcpy_orig+0xcd/0x130 vsnprintf+0x102/0x4c0 sprintf+0x51/0x80 qedi_dbg_do_not_recover_cmd_read+0x2f/0x50 [qedi 6bcfdeeecdea037da47069eca2ba717c84a77324] 0x80 vfs_read+0xa5/0x2e0? folio_add_new_anon_rmap+0x44/0xa0 ? set_pte_at+0x15/0x30? do_pte_missing+0x426/0x7f0 ksys_read+0xa5/0xe0 do_syscall_64+0x58/0x80 ? __count_memcg_events+0x46/0x90? count_memcg_event_mm+0x3d/0x60? handle_mm_fault+0x196/0x2f0? do_user_addr_fault+0x267/0x890? exc_page_fault+0x69/0x150 Entry_SYSCALL_64_after_hwframe+0x72/0xdc RIP: 0033:0x7f4800f20b4d

En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: drop_monitor: reemplaza spin_lock por raw_spin_lock Se llama a trace_drop_common() con la preferencia deshabilitada y adquiere un spin_lock. Esto es problemático para los kernels RT porque los spin_locks son bloqueos inactivos en esta configuración, lo que provoca el siguiente símbolo: ERROR: función inactiva llamada desde un contexto no válido en kernel/locking/spinlock_rt.c:48 in_atomic(): 1, irqs_disabled(): 1 , non_block: 0, pid: 449, nombre: rcuc/47 preempt_count: 1, esperado: 0 Profundidad del nido de RCU: 2, esperado: 2 5 bloqueos retenidos por rcuc/47/449: #0: ff1100086ec30a60 ((softirq_ctrl.lock) ){+.+.}-{2:2}, en: __local_bh_disable_ip+0x105/0x210 #1: fffffffffb394a280 (rcu_read_lock){....}-{1:2}, en: rt_spin_lock+0xbf/0x130 #2 : ffffffffb394a280 (rcu_read_lock){....}-{1:2}, en: __local_bh_disable_ip+0x11c/0x210 #3: ffffffffb394a160 (rcu_callback){....}-{0:0}, en: rcu_do_batch+0x360 /0xc70 #4: ff1100086ee07520 (&data->lock){+.+.}-{2:2}, en: trace_drop_common.constprop.0+0xb5/0x290 sello de evento irq: 139909 hardirqs habilitado por última vez en (139908): [ ] _raw_spin_unlock_irqrestore+0x63/0x80 hardirqs deshabilitado por última vez en (139909): [] trace_drop_common.constprop.0+0x26d/0x290 softirqs habilitado por última vez en (139892): [ ] __local_bh_enable_ip+0x103/0x170 softirqs últimamente deshabilitado en (139898): [] rcu_cpu_kthread+0x93/0x1f0 Prelación deshabilitada en: [] rt_mutex_slowunlock+0xab/0x2e0 CPU: 47 PID: 449 Comm: rcuc/47 No contaminado 6.9.0-rc2 - rt1+ #7 Nombre del hardware: Dell Inc. PowerEdge R650/0Y2G81, BIOS 1.6.5 15/04/2022 Seguimiento de llamadas: dump_stack_lvl+0x8c/0xd0 dump_stack+0x14/0x20 __might_resched+0x21e/0x2f0 rt_spin_lock+0x5e/0x130 ? trace_drop_common.constprop.0+0xb5/0x290? skb_queue_purge_reason.part.0+0x1bf/0x230 trace_drop_common.constprop.0+0xb5/0x290 ? preempt_count_sub+0x1c/0xd0? _raw_spin_unlock_irqrestore+0x4a/0x80? __pfx_trace_drop_common.constprop.0+0x10/0x10? rt_mutex_slowunlock+0x26a/0x2e0? skb_queue_purge_reason.part.0+0x1bf/0x230? __pfx_rt_mutex_slowunlock+0x10/0x10? skb_queue_purge_reason.part.0+0x1bf/0x230 trace_kfree_skb_hit+0x15/0x20 trace_kfree_skb+0xe9/0x150 kfree_skb_reason+0x7b/0x110 skb_queue_purge_reason.part.0+0x1bf/0x230 ? __pfx_skb_queue_purge_reason.part.0+0x10/0x10 ? mark_lock.part.0+0x8a/0x520 ... trace_drop_common() también desactiva las interrupciones, pero este es un problema menor porque podríamos reemplazarlo fácilmente con local_lock. Reemplace spin_lock con raw_spin_lock para evitar dormir en un contexto atómico.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: batman-adv: evita depósitos vacíos en batadv_purge_orig_ref() Muchos informes de syzbot apuntan a bloqueos suaves en batadv_purge_orig_ref() [1] Se desconoce la causa raíz, pero podemos evitar gastar demasiado pasar tiempo allí y tal vez obtener informes más interesantes. [1] perro guardián: ERROR: bloqueo suave - ¡CPU#0 bloqueada durante 27 segundos! [kworker/u4:6:621] Módulos vinculados en: sello de evento irq: 6182794 hardirqs habilitados por última vez en (6182793): [] __local_bh_enable_ip+0x224/0x44c kernel/softirq.c:386 hardirqs deshabilitados por última vez en (6182794) : [] __el1_irq arch/arm64/kernel/entry-common.c:533 [inline] hardirqs deshabilitado por última vez en (6182794): [] el1_interrupt+0x24/0x68 arch/arm64/kernel/entry-common .c:551 softirqs habilitado por última vez en (6182792): [] spin_unlock_bh include/linux/spinlock.h:396 [inline] softirqs habilitado por última vez en (6182792): [] batadv_purge_orig_ref+0x114c/0x122 8 netos/ batman-adv/originator.c:1287 softirqs deshabilitados por última vez en (6182790): [] spin_lock_bh include/linux/spinlock.h:356 [inline] softirqs deshabilitados por última vez en (6182790): [] batadv_purge_orig_ref+ 0x164/0x1228 net/batman-adv/originator.c:1271 CPU: 0 PID: 621 Comm: kworker/u4:6 No contaminado 6.8.0-rc7-syzkaller-g707081b61156 #0 Nombre de hardware: Google Google Compute Engine/Google Compute Motor, BIOS Google 29/02/2024 Cola de trabajo: bat_events batadv_purge_orig pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc: debería_resched arch/arm64/include/asm/preempt.h:79 [en línea] pc: __local_bh_enable_ip+0x228/0x44c kernel/softirq.c:388 lr: __local_bh_enable_ip+0x224/0x44c kernel/softirq.c:386 sp: ffff800099007970 x29: ffff800099007980 x28: 018fce1bd x27: dfff800000000000 x26: ffff0000d2620008 x25: ffff0000c7e70de8 x24 : 0000000000000001 x23: 1fffe00018e57781 x22: dfff800000000000 x21: ffff80008aab71c4 x20: ffff0001b40136c0 x19: ffff0000c72bbc08 x18: a817bb0 x17: ffff800125414000 x16: ffff80008032116c x15: 0000000000000001 x14: 1fffe0001ee9d610 x13: 0000000000000000 x12: 0000000000000000 3 x11: 0000000000000000 x10: 0000000000ff0100 x9: 0000000000000000 x8: 00000000005e5789 x7: ffff80008aab61dc x6: 0000000000000000 x5: 0000000000000000 x4: 0000000000000001 x3: 00000000000000000 x2: 0000000000000006 x1: 00000000000080 x0: ffff800125414000 Rastreo de llamadas: __daif_local_irq_enable arch/arm64/include/asm/irqflags.h:27 [en línea] arch_local_irq_enable arch/arm64/include /asm/irqflags.h:49 [en línea] __local_bh_enable_ip+0x228/0x44c kernel/softirq.c: 386 __raw_spin_unlock_bh include/linux/spinlock_api_smp.h: 167 [en línea] 210 spin_unlock_bh include/linux/spinlock.h:396 [en línea] batadv_purge_orig_ref+0x114c/0x1228 net/batman-adv/originator.c:1287 batadv_purge_orig+0x20/0x70 net/batman-adv/originator.c:1300 Process_one_work+0x694/0x120 4 kernel/workqueue.c:2633 Process_scheduled_works kernel/workqueue.c:2706 [en línea] trabajador_thread+0x938/0xef4 kernel/workqueue.c:2787 kthread+0x288/0x310 kernel/kthread.c:388 ret_from_fork+0x10/0x20 arch/arm64 /kernel/entry.S:860 Envío de NMI desde la CPU 0 a las CPU 1: rastreo de NMI para la CPU 1 CPU: 1 PID: 0 Comm: swapper/1 No contaminado 6.8.0-rc7-syzkaller-g707081b61156 #0 Nombre de hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 29/02/2024 pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc: arch_local_irq_enable+0x8/0xc arch/arm64/include/asm /irqflags.h:51 lr: default_idle_call+0xf8/0x128 kernel/sched/idle.c:103 sp: ffff800093a17d30 x29: ffff800093a17d30 x28: dfff800000000000 x27: 1ffff00012742fb4 x26: ffff80008ec9d000 x25: 0000000000000000 x24: 0000000000000002 x23: 1ffff00011d93a74 x22:---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: tipc: forzar un refcount dst antes de realizar el descifrado como dice en el commit 3bc07321ccc2 ("xfrm: forzar un refcount dst antes de ingresar los controladores de tipo xfrm"): "Las solicitudes criptográficas pueden regresar asíncronas En este caso, salimos de la región protegida de rcu, así que fuercemos un recuento en la entrada de destino del skb antes de ingresar los controladores de entrada/salida de tipo xfrm. En la ruta de descifrado TIPC tiene el mismo problema, y se debe llamar a skb_dst_force() antes de realizar el descifrado para evitar un posible bloqueo. Shuang informó este problema cuando se activa esta advertencia: [] ADVERTENCIA: include/net/dst.h:337 tipc_sk_rcv+0x1055/0x1ea0 [tipc] [] Kdump: cargado Contaminado: GW --------- - - 4.18.0-496.el8.x86_64+debug [] Cola de trabajo: crypto cryptd_queue_worker [] RIP: 0010:tipc_sk_rcv+0x1055/0x1ea0 [tipc] [] Seguimiento de llamadas: [] tipc_sk_mcast_rcv+0x548/0xea0 [tipc] [] tipc_rcv+ 0xcf5/0x1060 [tipc] [] tipc_aead_decrypt_done+0x215/0x2e0 [tipc] [] cryptd_aead_crypt+0xdb/0x190 [] cryptd_queue_worker+0xed/0x190 [] Process_one_work+0x93d/0x17e0

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: ACPICA: Revertir "ACPICA: evitar Información: mapeo de múltiples BAR. Su kernel está bien". Deshaga las modificaciones realizadas en el commit d410ee5109a1 ("ACPICA: evite "Información: mapeo de varias BAR. Su kernel está bien.""). El propósito inicial de esté commit fue evitar que las asignaciones de memoria para regiones de operación se superpongan en los límites de las páginas, ya que puede generar advertencias si hay diferentes atributos de página presentes. Sin embargo, se descubrió que cuando surge esta situación, el mapeo continúa hasta el final del límite, pero todavía hay un intento de leer/escribir en toda la longitud del mapa, lo que lleva a una deferencia del puntero NULL. Por ejemplo, si se realiza una solicitud de asignación de cuatro bytes pero solo se asigna un byte porque llega al final del límite de la página actual, aún se realiza un intento de lectura/escritura de cuatro bytes, lo que resulta en una deferencia de puntero NULL. En su lugar, asigne toda la longitud, ya que la especificación ACPI no exige que deba estar dentro del mismo límite de página. Está permitido mapearlo en diferentes regiones.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: btrfs: zonificado: asigna sumas de verificación ficticias para zonas zonificadas NODATASUM escribe Shin'ichiro informó que cuando ejecuta el caso de prueba btrfs/167 de fstests en dispositivos zonificados emulados, ve el siguiente puntero NULL desreferencia en 'btrfs_zone_finish_endio()': Vaya: error de protección general, probablemente para la dirección no canónica 0xdffffc0000000011: 0000 [#1] PREEMPT SMP KASAN NOPTI KASAN: null-ptr-deref en el rango [0x0000000000000088-0x00000000000000 8f] CPU: 4 PID: 2332440 Comm: kworker/u80:15 Contaminado: GW 6.10.0-rc2-kts+ #4 Nombre de hardware: Supermicro Super Server/X11SPi-TF, BIOS 3.3 21/02/2020 Cola de trabajo: btrfs-endio-write btrfs_work_helper [btrfs] RIP : 0010:btrfs_zone_finish_endio.part.0+0x34/0x160 [btrfs] RSP: 0018:ffff88867f107a90 EFLAGS: 00010206 RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 893e5534 RDX: 0000000000000011 RSI: 0000000000000004 RDI: 0000000000000088 RBP: 0000000000000002 R08: 0000000000000001 R09: 6028 R10: ffff88840b4b0143 R11: ffff88834dfff600 R12: ffff88840b4b0000 R13: 0000000000020000 R14: 00000000000000000 R15: ffff888530ad5210 FS: 0000000000000(0000) GS:ffff888e3f800000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f87223fff38 CR3 : 00000007a7c6a002 CR4: 00000000007706f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 00000000000000000 DR3: 0000000000000000 DR6: 000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Seguimiento de llamadas: ? __die_body.cold+0x19/0x27 ? die_addr+0x46/0x70? exc_general_protection+0x14f/0x250? asm_exc_general_protection+0x26/0x30? do_raw_read_unlock+0x44/0x70? btrfs_zone_finish_endio.part.0+0x34/0x160 [btrfs] btrfs_finish_one_ordered+0x5d9/0x19a0 [btrfs] ? __pfx_lock_release+0x10/0x10? do_raw_write_lock+0x90/0x260? __pfx_do_raw_write_lock+0x10/0x10? __pfx_btrfs_finish_one_ordered+0x10/0x10 [btrfs]? _raw_write_unlock+0x23/0x40? btrfs_finish_ordered_zoned+0x5a9/0x850 [btrfs]? lock_acquire+0x435/0x500 btrfs_work_helper+0x1b1/0xa70 [btrfs]? __programar+0x10a8/0x60b0? __pfx___might_resched+0x10/0x10 proceso_one_work+0x862/0x1410 ? __pfx_lock_acquire+0x10/0x10? __pfx_process_one_work+0x10/0x10? asignar_trabajo+0x16c/0x240 trabajador_hilo+0x5e6/0x1010? __pfx_worker_thread+0x10/0x10 kthread+0x2c3/0x3a0 ? trace_irq_enable.constprop.0+0xce/0x110? __pfx_kthread+0x10/0x10 ret_from_fork+0x31/0x70 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 Al habilitar CONFIG_BTRFS_ASSERT se reveló la siguiente aserción para activar: aserción fallida: !list_empty(&ordered->list), en fs/btrfs/zoned.c:1815 Esto indica que Falta la lista de sumas de verificación en la extensión_ordenada. Como btrfs/167 está escribiendo NOCOW, esto es de esperarse. Un análisis más detallado con drgn confirmó la suposición: >>> inode = prog.crashed_thread().stack_trace()[11]['ordered'].inode >>> btrfs_inode = drgn.container_of(inode, "struct btrfs_inode", \ " vfs_inode") >>> print(btrfs_inode.flags) (u32)1 Como el modo de emulación de zonas simula zonas convencionales en dispositivos normales, no podemos usar Zone-Append para escribir. Pero solo adjuntamos sumas de verificación ficticias si realizamos una escritura de adición de zona. Entonces, para las escrituras de datos de zonas NOCOW en zonas convencionales, adjunte también una suma de verificación ficticia.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ALSA: hda: cs35l41: Posible desreferencia del puntero nulo en cs35l41_hda_unbind() La función cs35l41_hda_unbind() borra la entrada hda_component que coincide con su índice y luego desreferencia el puntero del códec contenido en el primer elemento de la matriz hda_component, esto es un problema cuando el índice del dispositivo era 0. En su lugar, utilice el puntero del códec escondido en la estructura cs35l41_hda, ya que seguirá siendo válido.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: i2c: lpi2c: evite llamar a clk_get_rate durante la transferencia. En lugar de llamar repetidamente a clk_get_rate para cada transferencia, bloquee la velocidad del reloj y almacene en caché el valor. Se ha observado un punto muerto al agregar el códec de audio tlv320aic32x4 al sistema. Cuando este proveedor de reloj agrega su reloj, el mutex clk ya está bloqueado, necesita acceder a i2c, que a cambio también necesita el mutex para clk_get_rate.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: f2fs: no configure RO al apagar f2fs El apagado no verifica el error de thaw_super debido a solo lectura, lo que causa un punto muerto como el que se muestra a continuación. f2fs_ioc_shutdown(F2FS_GOING_DOWN_FULLSYNC) issues_discard_thread - bdev_freeze - frozen_super - f2fs_stop_checkpoint() - f2fs_handle_critical_error - sb_start_write - establecer RO - esperando - bdev_thaw - thaw_super_locked - devolver -EINVAL, si sb_rdonly() - card_thread -> esperar kthread_stop(discard_thread);