Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: MIPS: pgalloc: reparar pérdida de memoria causada por pgd_free() La página pgd es liberada por la implementación genérica pgd_free() desde el commit f9cb654cb550 ("asm-generic: pgalloc: proporcionar pgd_free() genérico"), sin embargo, hay escenarios en los que el sistema usa más de una página como la tabla pgd, en tales casos la implementación genérica pgd_free() ya no será aplicable. Por ejemplo, cuando PAGE_SIZE_4KB está habilitado y MIPS_VA_BITS_48 no está habilitado en un sistema de 64 bits, la macro "PGD_ORDER" se establecerá como "1", lo que provocará la asignación de dos páginas como la tabla pgd. Bueno, al mismo tiempo, la implementación genérica pgd_free() solo libera una página pgd, lo que provocará la pérdida de memoria. La pérdida de memoria se puede detectar fácilmente ejecutando el comando de shell: "while true; do ls > /dev/null; grep MemFree /proc/meminfo; done"

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf, sockmap: Se corrige la pérdida de memoria en tcp_bpf_sendmsg mientras sk msg está lleno Si tcp_bpf_sendmsg() se está ejecutando mientras sk msg está lleno. Cuando sk_msg_alloc() devuelve el error -ENOMEM, tcp_bpf_sendmsg() va a wait_for_memory. Si sk_msg_alloc() ha asignado memoria parcial, es decir, msg_tx->sg.size es mayor que osize después de sk_msg_alloc(), se produce una pérdida de memoria. Para solucionarlo, utilizamos sk_msg_trim() para liberar la memoria asignada y luego vamos a esperar memoria. Otras rutas de llamada de sk_msg_alloc() tienen un problema similar, como tls_sw_sendmsg(), así que maneje la lógica de sk_msg_trim dentro de sk_msg_alloc(), como sugirió Cong Wang. Este problema puede generar la siguiente información: ADVERTENCIA: CPU: 3 PID: 7950 en net/core/stream.c:208 sk_stream_kill_queues+0xd4/0x1a0 Seguimiento de llamadas: inet_csk_destroy_sock+0x55/0x110 __tcp_close+0x279/0x470 tcp_close+0x1f/0x60 inet_release+0x3f/0x80 __sock_release+0x3d/0xb0 sock_close+0x11/0x20 __fput+0x92/0x250 task_work_run+0x6a/0xa0 do_exit+0x33b/0xb60 do_group_exit+0x2f/0xa0 get_signal+0xb6/0x950 arch_do_signal_or_restart+0xac/0x2a0 exit_to_user_mode_prepare+0xa9/0x200 syscall_exit_to_user_mode+0x12/0x30 do_syscall_64+0x46/0x80 entry_SYSCALL_64_after_hwframe+0x44/0xae ADVERTENCIA: CPU: 3 PID: 2094 en net/ipv4/af_inet.c:155 inet_sock_destruct+0x13c/0x260 Rastreo de llamadas: __sk_destruct+0x24/0x1f0 sk_psock_destroy+0x19b/0x1c0 process_one_work+0x1b3/0x3c0 kthread+0xe6/0x110 ret_from_fork+0x22/0x30

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: powerpc/64s: No usar DSISR para fallas SLB Desde el commit 46ddcb3950a2 ("powerpc/mm: Mostrar si un fallo de página incorrecta en los datos es de lectura o escritura") usamos page_fault_is_write(regs->dsisr) en __bad_page_fault() para determinar si el fallo es de lectura o escritura y cambiar el mensaje impreso en consecuencia. Pero las fallas SLB, también conocidas como interrupciones de segmento de datos, no establecen DSISR (registro de estado de interrupción de almacenamiento de datos) en un valor útil. Todas las versiones de ISA desde la v2.03 hasta la v3.1 especifican que la interrupción de segmento de datos establece DSISR "en un valor indefinido". Hasta donde puedo ver, tampoco se menciona que los fallos SLB establezcan DSISR en ningún contenido de BookIV. Esto se manifiesta como accesos que deberían ser de lectura que se informan incorrectamente como escrituras, por ejemplo, al usar el comando "dump" de xmon: 0:mon> d 0x5deadbeef0000000 5deadbeef0000000 [359526.415354][ C6] ERROR: No se puede manejar el acceso a los datos del kernel en escritura en 0x5deadbeef0000000 [359526.415611][ C6] Dirección de instrucción con fallas: 0xc00000000010a300 cpu 0x6: Vector: 380 (Data SLB Access) en [c00000000ffbf400] pc: c00000000010a300: mread+0x90/0x190 Si desmontamos la PC, vemos una instrucción de carga: 0:mon> di c00000000010a300 c00000000010a300 89490000 lbz r10,0(r9) También podemos ver en exceptions-64s.S que el bloque data_access_slb no establece IDSISR=1, lo que significa que no carga DSISR en pt_regs. Por lo tanto, el valor que estamos usando para determinar si el error es de lectura/escritura es algún valor obsoleto en pt_regs de un error de página anterior. Reelabore la lógica de impresión para separar el caso de error de SLB y solo imprima lectura/escritura en los casos en los que podamos determinarlo. El resultado se parece a, por ejemplo: 0:mon> d 0x5deadbeef0000000 5deadbeef0000000 [ 721.779525][ C6] ERROR: No se puede manejar el acceso a los datos del kernel en 0x5deadbeef0000000 [ 721.779697][ C6] Dirección de instrucción con error: 0xc00000000014cbe0 cpu 0x6: Vector: 380 (Acceso a datos SLB) en [c00000000ffbf390] 0:mon> d 0 0000000000000000 [ 742.793242][ C6] ERROR: Desreferencia de puntero NULL del kernel en 0x00000000 [ 742.793316][ C6] Instrucción con error dirección: 0xc00000000014cbe0 cpu 0x6: Vector: 380 (Acceso a datos SLB) en [c00000000ffbf390]

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: scsi: pm8001: Se ha corregido la interrupción de todas las inicializaciones de tareas. En pm80xx_send_abort_all(), el campo n_elem del ccb utilizado no se inicializa a 0. Esta inicialización faltante a veces provoca que la ruta de finalización de la tarea vea el ccb con un n_elem distinto de cero, lo que da como resultado la ejecución de llamadas dma_unmap_sg() no válidas en pm8001_ccb_task_free(), lo que provoca un bloqueo como el siguiente: [ 197.676341] RIP: 0010:iommu_dma_unmap_sg+0x6d/0x280 [ 197.700204] RSP: 0018:ffff889bbcf89c88 EFLAGS: 00010012 [ 197.705485] RAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffffffff83d0bda0 [ 197.712687] RDX: 00000000000000002 RSI: 0000000000000000 RDI: ffff88810dffc0d0 [ 197.719887] RBP: 0000000000000000 R08: 0000000000000000 R09: ffff8881c790098b [ 197.727089] R10: ffffed1038f20131 R11: 0000000000000001 R12: 0000000000000000 [ 197.734296] R13: ffff88810dffc0d0 R14: 0000000000000010 R15: 0000000000000000 [ 197.741493] FS: 000000000000000(0000) GS:ffff889bbcf80000(0000) knlGS:0000000000000000 [ 197.749659] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 197.755459] CR2: 00007f16c1b42734 CR3: 0000000004814000 CR4: 0000000000350ee0 [ 197.762656] Rastreo de llamadas: [ 197.765127] [ 197.767162] pm8001_ccb_task_free+0x5f1/0x820 [pm80xx] [ 197.772364] ? do_raw_spin_unlock+0x54/0x220 [ 197.776680] pm8001_mpi_task_abort_resp+0x2ce/0x4f0 [pm80xx] [ 197.782406] process_oq+0xe85/0x7890 [pm80xx] [ 197.786817] ? lock_acquire+0x194/0x490 [ 197.790697] ? handle_irq_event+0x10e/0x1b0 [ 197.794920] ? mpi_sata_completion+0x2d70/0x2d70 [pm80xx] [ 197.800378] ? __wake_up_bit+0x100/0x100 [ 197.804340] ? lock_is_held_type+0x98/0x110 [ 197.808565] pm80xx_chip_isr+0x94/0x130 [pm80xx] [ 197.813243] tasklet_action_common.constprop.0+0x24b/0x2f0 [ 197.818785] __do_softirq+0x1b5/0x82d [ 197.822485] ? do_raw_spin_unlock+0x54/0x220 [ 197.826799] __irq_exit_rcu+0x17e/0x1e0 [ 197.830678] irq_exit_rcu+0xa/0x20 [ 197.834114] common_interrupt+0x78/0x90 [ 197.840051] [ 197.844236] [ 197.848397] asm_common_interrupt+0x1e/0x40 Evite este problema inicializando siempre el campo n_elem de ccb en 0 en pm8001_send_abort_all(), pm8001_send_read_log() y pm80xx_send_abort_all().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: vfio/pci: se corrige la pérdida de memoria durante la transición de D3hot a D0 Si se establece 'vfio_pci_core_device::needs_pm_restore' (el dispositivo PCI no tiene el bit No_Soft_Reset establecido en su registro de configuración PMCSR), entonces el estado PCI actual se guardará localmente en 'vfio_pci_core_device::pm_save' durante la transición de D0 a D3hot y el mismo se restaurará durante la transición de D3hot a D0. Para guardar el estado PCI localmente, se utiliza pci_store_saved_state() y pci_load_and_free_saved_state() liberará la memoria asignada. Pero para los IOCTL relacionados con el reinicio, el controlador vfio llama a las API relacionadas con el reinicio de PCI que cambiarán internamente el estado de energía de PCI a D0. Por lo tanto, cuando el invitado se reanude, obtendrá el estado actual como D0 y omitirá la llamada a vfio_pci_set_power_state() para cambiar el estado de energía a D0 explícitamente. En este caso, la memoria apuntada por 'pm_save' nunca se liberará. En una secuencia maliciosa, el cambio de estado a D3hot seguido de VFIO_DEVICE_RESET/VFIO_DEVICE_PCI_HOT_RESET se puede ejecutar en un bucle y puede causar una situación de OOM. Este parche libera primero la memoria asignada anteriormente antes de sobrescribir 'pm_save' para evitar la pérdida de memoria mencionada.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: RDMA/irdma: Evitar algunos desbordamientos de enteros Mi verificador estático se queja de que: drivers/infiniband/hw/irdma/ctrl.c:3605 irdma_sc_ceq_init() warn: can subtract underflow 'info->dev->hmc_fpm_misc.max_ceqs'? Parece que "info->dev->hmc_fpm_misc.max_ceqs" proviene del firmware en irdma_sc_parse_fpm_query_buf() así que, sí, existe la posibilidad de que sea cero. Incluso si confiamos en el firmware, es bastante fácil cambiar la condición como una medida de endurecimiento.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf, sockmap: Corregir pérdida de memoria en sk_psock_queue_msg Si tcp_bpf_sendmsg se está ejecutando durante una operación de desmontaje, podemos poner en cola datos en la cola de mensajes de entrada mientras el desmontaje intenta liberarlos. sk1 (redireccionar sk2) sk2 ------------------- --------------- tcp_bpf_sendmsg() tcp_bpf_send_verdict() tcp_bpf_sendmsg_redir() bpf_tcp_ingress() sock_map_close() lock_sock() lock_sock() ... bloqueando sk_psock_stop sk_psock_clear_state(psock, SK_PSOCK_TX_ENABLED); release_sock(sk); lock_sock() sk_mem_charge() get_page() sk_psock_queue_msg() sk_psock_test_state(psock, SK_PSOCK_TX_ENABLED); drop_sk_msg() release_sock() Mientras se usa drop_sk_msg(), el mensaje ha cargado la memoria del formulario sk mediante sk_mem_charge y tiene páginas sg que se deben colocar. Para solucionarlo, usamos sk_msg_free() y luego kfee() msg. Este problema puede causar la siguiente información: ADVERTENCIA: CPU: 0 PID: 9202 en net/core/stream.c:205 sk_stream_kill_queues+0xc8/0xe0 Rastreo de llamadas: inet_csk_destroy_sock+0x55/0x110 tcp_rcv_state_process+0xe5f/0xe90 ? sk_filter_trim_cap+0x10d/0x230 ? tcp_v4_do_rcv+0x161/0x250 tcp_v4_do_rcv+0x161/0x250 tcp_v4_rcv+0xc3a/0xce0 ip_protocol_deliver_rcu+0x3d/0x230 ip_local_deliver_finish+0x54/0x60 ip_local_deliver+0xfd/0x110 ? ip_protocol_deliver_rcu+0x230/0x230 ip_rcv+0xd6/0x100 ? ip_local_deliver+0x110/0x110 __netif_receive_skb_one_core+0x85/0xa0 process_backlog+0xa4/0x160 __napi_poll+0x29/0x1b0 net_rx_action+0x287/0x300 __do_softirq+0xff/0x2fc do_softirq+0x79/0x90 WARNING: CPU: 0 PID: 531 at net/ipv4/af_inet.c:154 inet_sock_destruct+0x175/0x1b0 Call Trace: __sk_destruct+0x24/0x1f0 sk_psock_destroy+0x19b/0x1c0 process_one_work+0x1b3/0x3c0 ? process_one_work+0x3c0/0x3c0 worker_thread+0x30/0x350 ? process_one_work+0x3c0/0x3c0 kthread+0xe6/0x110 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork+0x22/0x30

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: RDMA/mlx5: Se corrige la pérdida de memoria en el flujo de error para la rutina de evento de suscripción. En caso de que falle el segundo xa_insert(), no se libera el obj_event. Corrija el flujo de desenrollado de error para liberar esa memoria y evitar una pérdida de memoria.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/display: Arreglar doble liberación durante el reinicio de la GPU en flujos de DC [Por qué] El problema solo ocurre durante la ruta del código de reinicio de la GPU. Primero hacemos una copia de seguridad del estado actual antes de confirmar 0 flujos internamente desde DM a DC. Esta copia de seguridad del estado contiene asignaciones de codificador de enlace válidas. DC borrará las asignaciones de codificador de enlace como parte del estado actual (pero no la copia de seguridad, ya que se copió antes de el commit) y liberará la referencia de flujo adicional que tenía. DC requiere que las asignaciones de codificador de enlace permanezcan borradas/inválidas antes de el commit. Dado que la copia de seguridad aún tiene asignaciones válidas, llamamos a la interfaz post reset para borrarlas. Esta rutina también libera la referencia adicional que tenía la interfaz de codificador de enlace, lo que da como resultado una doble liberación (y eventualmente una desreferencia de puntero NULL). [Cómo] Tendremos que hacer una confirmación de DC completa de todos modos después de reiniciar la GPU porque el conteo de transmisiones anteriormente llegó a 0. No necesitamos conservar la asignación que habíamos respaldado, así que simplemente copiamos la asignación del estado actual ahora limpio después de que se haya producido el reinicio con la nueva interfaz link_enc_cfg_copy().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ibmvnic: se corrige la ejecución entre xmit y reset Existe una ejecución entre reset y las rutas de transmisión que puede provocar que ibmvnic_xmit() acceda a un scrq después de que se haya liberado en la ruta de reset. Puede provocar un bloqueo como: El kernel intentó leer la página del usuario (0): ¿intento de explotación? (uid: 0) ERROR: Desreferencia de puntero NULL del kernel en lectura en 0x00000000 Dirección de instrucción con error: 0xc0080000016189f8 Oops: Acceso del kernel al área defectuosa, sig: 11 [#1] ... NIP [c0080000016189f8] ibmvnic_xmit+0x60/0xb60 [ibmvnic] LR [c000000000c0046c] dev_hard_start_xmit+0x11c/0x280 Rastreo de llamadas: [c008000001618f08] ibmvnic_xmit+0x570/0xb60 [ibmvnic] (no confiable) [c000000000c0046c] dev_hard_start_xmit+0x11c/0x280 [c000000000c9cfcc] sch_direct_xmit+0xec/0x330 [c000000000bfe640] __dev_xmit_skb+0x3a0/0x9d0 [c000000000c00ad4] __dev_queue_xmit+0x394/0x730 [c008000002db813c] __bond_start_xmit+0x254/0x450 [enlace] [c008000002db8378] bond_start_xmit+0x40/0xc0 [enlace] [c000000000c0046c] dev_hard_start_xmit+0x11c/0x280 [c000000000c00ca4] __dev_queue_xmit+0x564/0x730 [c000000000cf97e0] neigh_hh_output+0xd0/0x180 [c000000000cfa69c] ip_finish_output2+0x31c/0x5c0 [c000000000cfd244] __ip_queue_xmit+0x194/0x4f0 [c000000000d2a3c4] __tcp_transmit_skb+0x434/0x9b0 [c000000000d2d1e0] __tcp_retransmit_skb+0x1d0/0x6a0 [c000000000d2d984] tcp_retransmit_skb+0x34/0x130 [c000000000d310e8] tcp_retransmit_timer+0x388/0x6d0 [c000000000d315ec] tcp_write_timer_handler+0x1bc/0x330 [c000000000d317bc] tcp_write_timer+0x5c/0x200 [c000000000243270] call_timer_fn+0x50/0x1c0 [c000000000243704] __run_timers.part.0+0x324/0x460 [c000000000243894] run_timer_softirq+0x54/0xa0 [c000000000ea713c] __do_softirq+0x15c/0x3e0 [c000000000166258] __irq_exit_rcu+0x158/0x190 [c000000000166420] irq_exit+0x20/0x40 [c00000000002853c] timer_interrupt+0x14c/0x2b0 [c000000000009a00] decrementer_common_virt+0x210/0x220 --- interrupción: 900 La causa inmediata del bloqueo es el acceso a tx_scrq en el siguiente fragmento durante un reinicio, donde tx_scrq puede ser NULL o una dirección que pronto será inválida: ibmvnic_xmit() { ... tx_scrq = adaptador->tx_scrq[queue_num]; txq = netdev_get_tx_queue(netdev, queue_num); ind_bufp = &tx_scrq->ind_buf; if (test_bit(0, &adapter->resetting)) { ... } Pero más allá de eso, la llamada a ibmvnic_xmit() en sí no es segura durante un reinicio y la ruta de reinicio intenta evitar esto deteniendo la cola en ibmvnic_cleanup(). Sin embargo, justo después de que se detuviera la cola, una ibmvnic_complete_tx() en curso podría haber reiniciado la cola incluso mientras el reinicio estaba en progreso. Dado que la cola se reinició, podríamos recibir una llamada a ibmvnic_xmit() que luego puede acceder al tx_scrq incorrecto (u otros campos). Sin embargo, no podemos simplemente hacer que ibmvnic_complete_tx() verifique el bit ->resetting y omita el inicio de la cola. Esto puede funcionar en el "back-end" de un reinicio correcto que simplemente reinició la cola pero aún no borró el bit ->resetting. Si omitimos el reinicio de la cola debido a que ->resetting es verdadero, la cola permanecería detenida indefinidamente, lo que podría provocar tiempos de espera de transmisión. IOW ->resetting es demasiado amplio para este propósito. En su lugar, use un nuevo indicador que indique si las colas están activas o no. Solo las rutas de apertura/reinicio controlan cuándo están activas las colas. ibmvnic_complete_tx() y otros activan la cola solo si la cola está marcada como activa. Por lo tanto, tendremos: A. restablecer/abrir subproceso en ibmvnic_cleanup() y __ibmvnic_open() ->resetting = true ->tx_queues_active = false deshabilitar colas de transmisión ... ->tx_queues_active = true iniciar colas de transmisión B. Interrupción de transmisión en ibmvnic_complete_tx(): if (->tx_queues_active) netif_wake_subqueue(); Para garantizar que ->tx_queues_active y el estado de las colas sean cons ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: Bluetooth: btmtksdio: Corrige los errores del kernel en btmtksdio_interrupt Corrige los siguientes errores del kernel en btmtksdio_interrrupt [ 14.339134] btmtksdio_interrupt+0x28/0x54 [ 14.339139] process_sdio_pending_irqs+0x68/0x1a0 [ 14.339144] sdio_irq_work+0x40/0x70 [ 14.339154] process_one_work+0x184/0x39c [ 14.339160] worker_thread+0x228/0x3e8 [ 14.339168] kthread+0x148/0x3ac [ 14.339176] ret_from_fork+0x10/0x30 Esto sucedió porque hdev->power_on ya se llama antes de que sdio_set_drvdata en el que se basa el controlador btmtksdio_interrupt no esté configurado correctamente. Los detalles se muestran a continuación: hci_register_dev ejecutaría queue_work(hdev->req_workqueue, &hdev->power_on) como WQ_HIGHPRI workqueue_struct para completar la secuencia de encendido y, por lo tanto, hci_power_on puede ejecutarse antes de que sdio_set_drvdata se complete en btmtksdio_probe. hci_dev_do_open en hci_power_on inicializaría el dispositivo y habilitaría la interrupción y, por lo tanto, es posible que btmtksdio_interrupt se llame justo antes de que se complete sdio_set_drvdata. Cuando se llama a btmtksdio_interrupt y no se completa sdio_set_drvdata, se producirá un error en el kernel porque btmtksdio_interrupt accede a un puntero no inicializado.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: Bluetooth: hci_uart: falta de comprobación NULL en h5_enqueue Syzbot encontró un fallo de protección general en __pm_runtime_resume(). El problema estaba en la falta de comprobación NULL. hu->serdev puede ser NULL y no deberíamos pasar ciegamente &serdev->dev en algún lugar, ya que provocará GPF.