Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/display: Agregar verificación de puntero NULL para kzalloc [Por qué y cómo] Verifique el puntero de retorno de kzalloc antes de usarlo.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: LED: mlxreg: use devm_mutex_init() para la inicialización mutex. En este controlador, los LED se registran usando devm_led_classdev_register(), por lo que se cancelan automáticamente el registro después de que se realiza la eliminación() del módulo. led_classdev_unregister() llama a led_set_brightness() del módulo para apagar los LED y esa devolución de llamada usa mutex que ya fue destruido en remove() del módulo, así que use la API devm en su lugar.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: drm/amd/display: omite la búsqueda de audio gratuito para motor_id desconocido [POR QUÉ] ENGINE_ID_UNKNOWN = -1 y no se puede utilizar como índice de matriz. Además, también significa que no está inicializado y no necesita audio gratuito. [CÓMO] Saltar y devolver NULL. Esto soluciona 2 problemas de OVERRUN informados por Coverity.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/display: verifique el desplazamiento de la tubería antes de configurar vblank pipe_ctx tiene un tamaño de MAX_PIPES, por lo que debe verificar su índice antes de acceder a la matriz. Esto soluciona un problema de OVERRUN informado por Coverity.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/display: Verifique el índice msg_id antes de leer o escribir [QUÉ] msg_id se usa como índice de matriz y no puede ser un valor negativo y, por lo tanto, no puede ser igual a MOD_HDCP_MESSAGE_ID_INVALID (-1). [CÓMO] Verifique si msg_id es válido antes de leer y configurar. Esto soluciona 4 problemas de OVERRUN informados por Coverity.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: scsi: qedf: Hacer que qedf_execute_tmf() no sea preferible Dejar de llamar a smp_processor_id() desde código preferente en qedf_execute_tmf90. Esto da como resultado BUG_ON() cuando se ejecuta un kernel RT. [659.343280] ERROR: uso de smp_processor_id() en código interrumpible [00000000]: sg_reset/3646 [659.343282] la persona que llama es qedf_execute_tmf+0x8b/0x360 [qedf]

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: powerpc: Evite nmi_enter/nmi_exit en interrupción en modo real. nmi_enter()/nmi_exit() toca variables por CPU que pueden provocar un fallo del kernel cuando se invoca durante el manejo de interrupciones en modo real (por ejemplo, el controlador de interrupciones HMI/MCE temprano) si la asignación de percpu proviene del área vmalloc. Los primeros controladores HMI/MCE se llaman a través del contenedor DEFINE_INTERRUPT_HANDLER_NMI() que invoca llamadas nmi_enter/nmi_exit. No vemos ningún problema cuando la asignación de percpu proviene del primer fragmento integrado. Sin embargo, con CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK habilitado, hay posibilidades de que la asignación de percpu pueda provenir del área vmalloc. Con la línea de comando del kernel "percpu_alloc=page" podemos forzar que la asignación de percpu provenga del área vmalloc y podemos ver el fallo del kernel en machine_check_early: [1.215714] NIP [c000000000e49eb4] rcu_nmi_enter+0x24/0x110 [1.215717] LR [c0000000000461a0] check_early+0xf0/ 0x2c0 [1.215719] --- interrupción: 200 [ 1.215720] [c000000fffd73180] [0000000000000000] 0x0 (no confiable) [ 1.215722] [c000000fffd731b0] 000] 0x0 [ 1.215724] [c000000fffd73210] [c000000000008364] machine_check_early_common+0x134/0x1f8 Solucionar esto mediante evitando el uso de nmi_enter()/nmi_exit() en modo real si el primer fragmento de percpu no está incrustado.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/lima: arregla el manejo de irq compartido en el controlador elimina lima usa una interrupción compartida, por lo que los controladores de interrupciones deben estar preparados para ser llamados en cualquier momento. En el momento de la eliminación del controlador, los relojes se desactivan antes de tiempo y las interrupciones permanecen registradas hasta el final del proceso de eliminación debido al uso del devm. Esto es potencialmente un error ya que las interrupciones acceden a los registros del dispositivo, lo que supone que los relojes están habilitados. Se puede provocar un bloqueo eliminando el controlador en un kernel con CONFIG_DEBUG_SHIRQ habilitado. Este parche libera las interrupciones en cada dispositivo Lima que finaliza la devolución de llamada para que los controladores ya estén dados de baja cuando deshabilitemos completamente los relojes.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ice: no procesar extts si PTP está deshabilitado. La función ice_ptp_extts_event() puede competir con ice_ptp_release() y provocar una desreferencia del puntero NULL que provoca un pánico en el kernel. El pánico ocurre porque la función ice_ptp_extts_event() llama a ptp_clock_event() con un puntero NULL. El controlador de hielo ya ha liberado el reloj PTP cuando ocurre la interrupción para el siguiente evento de marca de tiempo externo. Para solucionar este problema, modifique la función ice_ptp_extts_event() para verificar el estado de PTP y salir temprano si PTP no está listo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: rswitch: Evite el use after free en rswitch_poll() El use after free está en realidad en rswitch_tx_free(), que está incluido en rswitch_poll(). Dado que `skb` y `gq->skbs[gq->dirty]` son de hecho el mismo puntero, el skb primero se libera usando dev_kfree_skb_any(), luego el valor en skb->len se usa para actualizar las estadísticas de la interfaz. Avancemos por las instrucciones para usar skb->len antes de liberar el skb. Este error es trivial de reproducir usando KFENCE. Activará un sonido cada pocos paquetes. Una simple solicitud ARP o una solicitud de eco ICMP es suficiente.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: btrfs: siempre haga las comprobaciones básicas de la estructura btrfs_qgroup_inherit [ERROR] Syzbot informa la siguiente regresión detectada por KASAN: ERROR: KASAN: slab-out-of-bounds in btrfs_qgroup_inherit+0x42e/ 0x2e20 fs/btrfs/qgroup.c:3277 Lectura de tamaño 8 en la dirección ffff88814628ca50 por tarea syz-executor318/5171 CPU: 0 PID: 5171 Comm: syz-executor318 No contaminado 6.10.0-rc2-syzkaller-00010-g2ab7951410 95 #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/04/2024 Seguimiento de llamadas: __dump_stack lib/dump_stack.c:88 [en línea] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114 print_address_description mm /kasan/report.c:377 [en línea] print_report+0x169/0x550 mm/kasan/report.c:488 kasan_report+0x143/0x180 mm/kasan/report.c:601 btrfs_qgroup_inherit+0x42e/0x2e20 fs/btrfs/qgroup. c:3277 create_pending_snapshot+0x1359/0x29b0 fs/btrfs/transaction.c:1854 create_pending_snapshots+0x195/0x1d0 fs/btrfs/transaction.c:1922 btrfs_commit_transaction+0xf20/0x3740 fs/btrfs/transaction.c:23 82 create_snapshot+0x6a1/0x9e0 fs/btrfs/ioctl.c:875 btrfs_mksubvol+0x58f/0x710 fs/btrfs/ioctl.c:1029 btrfs_mksnapshot+0xb5/0xf0 fs/btrfs/ioctl.c:1075 __btrfs_ioctl_snap_create+0x387/0x4b0 fs/btrfs/ioctl.c: 1340 btrfs_ioctl_snap_create_v2+0x1f2/0x3a0 fs/btrfs/ioctl.c:1422 btrfs_ioctl+0x99e/0xc60 vfs_ioctl fs/ioctl.c:51 [en línea] __do_sys_ioctl fs/ioctl.c:907 [en línea] __se_sys_ioctl+0xfc/0x170 fs/ioctl .c:893 do_syscall_x64 arch/x86/entry/common.c:52 [en línea] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 Entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fcbf1992509 RSP: 002b:00007fcbf1928218 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 00007fcbf1a1f618 RCX: 00007fcbf1992509 RDX: 0000000020000280 RSI: 0000000050 009417 RDI: 0000000000000003 RBP: 00007fcbf1a1f610 R08: 00007ffea1298e97 R09: 00000000000000000 R10: 0000000000000000 R11: 00000000000000 246 R12: 00007fcbf19eb660 R13: 00000000200002b8 R14: 00007fcbf19e60c0 R15: 0030656c69662f2e Y también lo fijó para confirmar b5357cb268c4 ("btrfs: qgroup: no marque la herencia de qgroup si qgroup está deshabilitado"). [CAUSA] Esa confirmación infractora omite toda la verificación de herencia de qgroup si qgroup no está habilitado. Pero eso también omite las comprobaciones más básicas como num_ref_copies/num_excl_copies y las comprobaciones del tamaño de la estructura. Es decir, si se produce una carrera de habilitación/deshabilitación de qgroup en segundo plano y pasamos una estructura btrfs_qgroup_inherit cuando qgroup está deshabilitado, la verificación se omitirá por completo. Luego, en el momento del compromiso de la transacción, qgroup se vuelve a habilitar y btrfs_qgroup_inherit() utilizará la estructura incorrecta y provocará el error KASAN anterior. [FIX] Haga que btrfs_qgroup_check_inherit() solo omita las comprobaciones de qgroup de origen. De modo que incluso si se pasa una estructura btrfs_qgroup_inherit no válida, aún podemos rechazar las no válidas sin importar si qgroup está habilitado o no. Además, ya tenemos una seguridad adicional dentro de btrfs_qgroup_inherit(), que simplemente ignoraría las fuentes de qgroup no válidas, por lo que incluso si solo nos saltamos la verificación de la fuente de qgroup, todavía estamos a salvo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: txgbe: recursos isb libres en el momento adecuado Cuando se utiliza la interrupción MSI/INTx, las interrupciones compartidas todavía se manejan en la rutina de eliminación del dispositivo, antes de las IRQ libres. Por lo tanto, la memoria isb todavía se lee después de liberarla. Por lo tanto, mueva wx_free_isb_resources() de txgbe_close() a txgbe_remove(). Y corrija la acción gratuita de isb incorrecta en la ruta de manejo de errores txgbe_open().