Vulnerabilidades

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: 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: 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.

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: bpf, sockmap: Se corrige más mensajes sin cargar mientras msg tiene more_data En tcp_bpf_send_verdict(), si msg tiene más datos después de tcp_bpf_sendmsg_redir(): tcp_bpf_send_verdict() tosend = msg->sg.size //msg->sg.size = 22220 caso __SK_REDIRECT: sk_msg_return() //mensaje sin cargar->sg.size(22220) sk->sk_forward_alloc tcp_bpf_sendmsg_redir() //después de tcp_bpf_sendmsg_redir, msg->sg.size=11000 goto more_data; tosend = msg->sg.size //msg->sg.size = 11000 caso __SK_REDIRECT: sk_msg_return() //msg->sg.size(11000) no cargado a sk->sk_forward_alloc El msg->sg.size(11000) se ha descargado dos veces, para solucionarlo podemos cargar el msg->sg.size restante antes de ir a más datos. Este problema puede generar la siguiente información: ADVERTENCIA: CPU: 0 PID: 9860 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 ? vfs_write+0x237/0x290 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: 0 PID: 2136 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 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: bpf, sockmap: Se corrige la doble descarga de la memoria de sk_msg. Si tcp_bpf_sendmsg se está ejecutando durante una operación de desmantelamiento, psock puede liberarse. tcp_bpf_sendmsg() tcp_bpf_send_verdict() sk_msg_return() tcp_bpf_sendmsg_redir() Unlikely(!psock)) sk_msg_free() La memoria de msg ha sido descargada en tcp_bpf_send_verdict() por sk_msg_return(), y sería descargada nuevamente por sk_msg_free(). Cuando psock es nulo, podemos simplemente devolver un código de error, esto activaría sk_msg_free_nocharge en la ruta de error de __SK_REDIRECT y tendría el efecto secundario de arrojar un error al espacio del usuario. Esto sería un ligero cambio en el comportamiento del lado del usuario, pero se vería igual que un error si la redirección en el socket arrojara un error. Este problema puede causar la siguiente información: ADVERTENCIA: CPU: 0 PID: 2136 en net/ipv4/af_inet.c:155 inet_sock_destruct+0x13c/0x260 Seguimiento de llamadas: __sk_destruct+0x24/0x1f0 sk_psock_destroy+0x19b/0x1c0 process_one_work+0x1b3/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: 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/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: mxser: se corrige la fuga de xmit_buf en activate cuando LSR == 0xff Cuando LSR es 0xff en ->activate() (bastante diferente), devolvemos un error. Siempre que no se llame a ->shutdown() cuando ->activate() falla, en realidad nada libera el búfer en este caso. Corrija esto liberando correctamente el búfer en una etiqueta designada. Saltamos allí también desde "!info->type" if now también.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drivers: ethernet: cpsw: fix panic when interrumpe coaleceing is seted via ethtool cpsw_ethtool_begin directamente devuelve el resultado de pm_runtime_get_sync cuando es exitoso. pm_runtime_get_sync devuelve el código de error en caso de fallo y 0 en caso de reanudación exitosa, pero también 1 cuando el dispositivo ya está activo. Por lo tanto, el caso común para cpsw_ethtool_begin es devolver 1. Eso lleva a llamadas inconsistentes a pm_runtime_put en la cadena de llamadas, de modo que pm_runtime_put se llama una vez de más y, como resultado, deja suspendido el cpsw dev. El cpsw dev suspendido lleva a una violación de acceso más adelante por diferentes partes del controlador cpsw. Solucione esto llamando a la función pm_runtime_resume_and_get, que es amigable con los retornos.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ice: fix 'scheduling while atomic' on aux critical err interrupción Hay un ERROR del kernel en el procesamiento de interrupciones de error crítico auxiliar en ice_misc_intr(): [ 2100.917085] ERROR: scheduling while atomic: swapper/15/0/0x00010000 ... [ 2101.060770] Seguimiento de llamadas: [ 2101.063229] [ 2101.065252] dump_stack+0x41/0x60 [ 2101.068587] __schedule_bug.cold.100+0x4c/0x58 [ 2101.073060] __schedule+0x6a4/0x830 [ [2101.076570] schedule+0x35/0xa0 [2101.079727] schedule_preempt_disabled+0xa/0x10 [2101.084284] __mutex_lock.isra.7+0x310/0x420 [2101.088580] ? ice_misc_intr+0x201/0x2e0 [hielo] [ 2101.093078] ice_send_event_to_aux+0x25/0x70 [hielo] [ 2101.097921] ice_misc_intr+0x220/0x2e0 [hielo] [ 2101.102232] __handle_irq_event_percpu+0x40/0x180 [ 2101.106965] handle_irq_event_percpu+0x30/0x80 [ 2101.111434] handle_irq_event+0x36/0x53 [ 2101.115292] handle_edge_irq+0x82/0x190 [ 2101.119148] handle_irq+0x1c/0x30 [ 2101.122480] do_IRQ+0x49/0xd0 [ 2101.125465] common_interrupt+0xf/0xf [ 2101.129146] ... Como Andrew mencionó correctamente anteriormente[0], ocurre la siguiente escalera de llamadas: ice_misc_intr() <- hardirq ice_send_event_to_aux() device_lock() mutex_lock() might_sleep() might_resched() <- oops Agregue un nuevo bit de estado de PF que indique que ocurrió un error crítico auxiliar y sirvalo en ice_service_task() en el contexto del proceso. El nuevo ice_pf::oicr_err_reg es de lectura y escritura tanto en contextos de hardirq como de proceso, pero solo 3 bits de datos no críticos probablemente no merezcan una sincronización explícita (e incluso están en el mismo byte [31:24]). [0] https://lore.kernel.org/all/YeSRUVmrdmlUXHDn@lunn.ch