Vulnerabilidades

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: RDMA/mlx5: Agregar verificación para el atributo srq max_sge El usuario pasa el atributo max_sge, se inserta y se usa sin marcar, así que verifique que el valor no exceda el valor máximo permitido antes usándolo.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: netfilter: ipset: corrige rcu_dereference_protected() sospechoso Al destruir todos los conjuntos, estamos en la fase de salida de pernet o estamos ejecutando un "comando de destruir todos los conjuntos" desde el espacio de usuario. Este último se tuvo en cuenta en ip_set_dereference() (se mantiene el mutex de nfnetlink), pero el primero no. El parche agrega la verificación requerida a rcu_dereference_protected() en ip_set_dereference().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ptp: corrige el desbordamiento de enteros en max_vclocks_store En sistemas de 32 bits, la multiplicación "4 * max" puede desbordarse. Utilice kcalloc() para realizar la asignación y evitar esto.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/sched: act_api: corrige posible bucle infinito en tcf_idr_check_alloc() syzbot encontró tareas pendientes esperando en rtnl_lock [1] Hay un reproductor disponible en el error syzbot. Cuando se envía una solicitud para agregar varias acciones con el mismo índice, la segunda solicitud se bloqueará para siempre en la primera solicitud. Esto retiene rtnl_lock y hace que las tareas se bloqueen. Devuelve -EAGAIN para evitar bucles infinitos y al mismo tiempo mantener el comportamiento documentado. [1] INFORMACIÓN: tarea kworker/1:0:5088 bloqueada durante más de 143 segundos. No contaminado 6.9.0-rc4-syzkaller-00173-g3cdb45594619 #0 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" desactiva este mensaje. tarea:kworker/1:0 estado:D pila:23744 pid:5088 tgid:5088 ppid:2 banderas:0x00004000 Cola de trabajo: events_power_ficient reg_check_chans_work Seguimiento de llamadas: context_switch kernel/sched/core.c:5409 [en línea] __schedule+ 0xf15/0x5d00 kernel/sched/core.c:6746 __schedule_loop kernel/sched/core.c:6823 programación [en línea]+0xe7/0x350 kernel/sched/core.c:6838 Schedule_preempt_disabled+0x13/0x30 kernel/sched/core. c:6895 __mutex_lock_common kernel/locking/mutex.c:684 [en línea] __mutex_lock+0x5b8/0x9c0 kernel/locking/mutex.c:752 wiphy_lock include/net/cfg80211.h:5953 [en línea] reg_leave_invalid_chans net/wireless/reg. c:2466 [en línea] reg_check_chans_work+0x10a/0x10e0 net/wireless/reg.c:2481

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: bpf: evitar splat en pskb_pull_reason compilaciones de syzkaller (CONFIG_DEBUG_NET=y) frecuentemente activa una sugerencia de depuración en pskb_may_pull. Nos gustaría conservar esta verificación de depuración porque podría indicar desbordamientos de enteros y otros problemas (el código del kernel debe extraer encabezados, no valores enormes). En el caso de bpf, este símbolo no es nada interesante: estos programas bpf (sin sentido) normalmente son generados por un fuzzer de todos modos. Haga lo que Eric sugirió y suprima esa advertencia. Para CONFIG_DEBUG_NET=n no necesitamos la verificación adicional porque pskb_may_pull hará lo correcto: devolver un error sin el rastreo WARN().

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: plataforma/x86: x86-android-tablets: cancelar el registro de dispositivos en orden inverso. No todos los subsistemas admiten la eliminación de un dispositivo mientras todavía hay consumidores del dispositivo con una referencia al dispositivo. Un ejemplo de esto es el subsistema regulador. Si un regulador se da de baja mientras todavía hay controladores que tienen una referencia, se activa WARN() en drivers/regulator/core.c:5829, por ejemplo: ADVERTENCIA: CPU: 1 PID: 1587 en drivers/regulator/core.c:5829 regulator_unregister Nombre del hardware: Intel Corp. VALLEYVIEW C0 PLATFORM/BYT-T FFD8, BIOS BLADE_21.X64.0005.R00.1504101516 FFD8_X64_R_2015_04_10_1516 10/04/2015 RIP: 0010:regulator_unregister Seguimiento de llamada: regulator_unregister i2c_device_remove devres_release_group device_release_driver_internal device_del device_unregister x86_android_tablet_remove En la serie Lenovo Yoga Tablet 2, el chip del cargador bq24190 también proporciona una salida de convertidor elevador de 5 V para alimentar dispositivos USB conectados al puerto micro USB; el controlador del cargador bq24190 lo exporta como un regulador Vbus. En los modelos 830 (8") y 1050 ("10"), este regulador está controlado por un platform_device y x86_android_tablet_remove() elimina platform_device-s antes que i2c_clients para que el consumidor se elimine primero. Pero en el modelo 1380 (13") hay un interruptor micro-USB lc824206xa conectado a través de I2C y el controlador externo que controla el regulador. El cliente i2c bq24190 *debe* registrarse primero, porque eso crea el regulador con el lc824206xa listado como su consumidor. Si el regulador aún no se ha registrado, el controlador lc824206xa terminará obteniendo un regulador ficticio. Dado que en este caso tanto el proveedor del regulador como el consumidor son dispositivos I2C, la única forma de garantizar que el consumidor cancele el registro primero es cancelar el registro de los dispositivos I2C en el orden inverso al que fueron creados. Para mantener la coherencia y evitar problemas similares en el futuro, cambie x86_android_tablet_remove() para cancelar el registro de todos los tipos de dispositivos en orden inverso.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: ath12k: soluciona el fallo del kernel durante la reanudación Actualmente, durante la reanudación, la memoria de destino de QMI no se maneja adecuadamente, lo que provoca un fallo del kernel en caso de que no se admita la reasignación de DMA: ERROR: Estado incorrecto de la página en proceso kworker/u16:54 pfn:36e80 página: refcount:1 mapcount:0 mapeo:0000000000000000 index:0x0 pfn:0x36e80 página descargada porque: distinto de cero _refcount Rastreo de llamadas: bad_page free_page_is_bad_report __free_pages_ok __free_pages dma_direct_free dma_free_attrs a th12k_qmi_free_target_mem_chunk ath12k_qmi_msg_mem_request_cb El motivo es: Una vez ath12k El módulo está cargado, el firmware envía la solicitud de memoria al host. En caso de que no se admita la reasignación de DMA, ath12k rechaza la primera solicitud debido a un error en la asignación con un tamaño de segmento grande: ath12k_pci 0000:04:00.0: solicitud de firmware qmi solicitud de memoria ath12k_pci 0000:04:00.0: qmi mem seg tipo 1 tamaño 7077888 ath12k_pci 0000 :04:00.0: qmi mem seg tipo 4 tamaño 8454144 ath12k_pci 0000:04:00.0: falla en la asignación de qmi dma (7077888 B tipo 1), lo intentaré más tarde con un tamaño pequeño ath12k_pci 0000:04:00.0: qmi retrasa mem_request 2 ath12k_pci 0000: 04:00.0: solicitud de memoria de solicitud de firmware qmi El firmware posterior regresa con más segmentos, pero pequeños, y la asignación se realiza correctamente: ath12k_pci 0000:04:00.0: qmi mem seg tipo 1 tamaño 524288 ath12k_pci 0000:04:00.0: qmi mem seg tipo 1 tamaño 524288 ath12k_pci 0000:04:00.0: qmi mem seg tipo 1 tamaño 524288 ath12k_pci 0000:04:00.0: qmi mem seg tipo 1 tamaño 524288 ath12k_pci 0000:04:00.0: qmi mem seg tipo 1 tamaño 524288 pci 0000:04:00.0:qmi mem seg tipo 1 tamaño 524288 ath12k_pci 0000:04:00.0: qmi mem seg tipo 1 tamaño 524288 ath12k_pci 0000:04:00.0: qmi mem seg tipo 1 tamaño 262144 ath12k_pci 0000:04:00.0: qmi mem seg tipo 1 tamaño 524288 ath12k_pci 0000 :04:00.0: qmi mem seg tipo 1 tamaño 524288 ath12k_pci 0000:04:00.0: qmi mem seg tipo 1 tamaño 524288 ath12k_pci 0000:04:00.0: qmi mem seg tipo 1 tamaño 524288 ath12k_pci 0000:04:00 .0: segmento de memoria qmi tipo 1 tamaño 524288 ath12k_pci 0000:04:00.0: qmi mem seg tipo 4 tamaño 524288 ath12k_pci 0000:04:00.0: qmi mem seg tipo 4 tamaño 524288 ath12k_pci 0000:04:00.0: qmi mem seg tipo 4 tamaño 24288 ath12k_pci 0000:04 :00.0: qmi mem seg tipo 4 tamaño 524288 ath12k_pci 0000:04:00.0: qmi mem seg tipo 4 tamaño 524288 ath12k_pci 0000:04:00.0: qmi mem seg tipo 4 tamaño 524288 ath12k_pci 0000:04:00.0: qmi mem seg tipo 4 tamaño 524288 ath12k_pci 0000:04:00.0: qmi mem seg tipo 4 tamaño 524288 ath12k_pci 0000:04:00.0: qmi mem seg tipo 4 tamaño 524288 ath12k_pci 0000:04:00.0: qmi mem seg tipo 4 tamaño 5242 88 ath12k_pci 0000:04:00.0 : qmi mem seg tipo 4 tamaño 524288 ath12k_pci 0000:04:00.0: qmi mem seg tipo 4 tamaño 524288 ath12k_pci 0000:04:00.0: qmi mem seg tipo 4 tamaño 524288 ath12k_pci 0000:04:00.0: qmi mem se g tipo 4 tamaño 524288 ath12k_pci 0000:04:00.0: qmi mem seg tipo 4 tamaño 524288 ath12k_pci 0000:04:00.0: qmi mem seg tipo 4 tamaño 524288 ath12k_pci 0000:04:00.0: qmi mem seg tipo 4 tamaño 65536 ci 0000:04:00.0: qmi mem seg tipo 1 tamaño 524288 Ahora ath12k está funcionando. Si se activa la suspensión, el firmware se recargará durante la reanudación. Al igual que antes, el firmware solicita dos segmentos grandes al principio. En ath12k_qmi_msg_mem_request_cb() se asigna el recuento y el tamaño del segmento: ab->qmi.mem_seg_count == 2 ab->qmi.target_mem[0].size == 7077888 ab->qmi.target_mem[1].size == 8454144 Luego, la asignación falló como antes y se llama a ath12k_qmi_free_target_mem_chunk() para liberar todos los segmentos asignados. ---truncado---

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.