Vulnerabilidades

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: drm/tegra: Se corrige la pérdida de referencia en tegra_dsi_ganged_probe La referencia tomada por 'of_find_device_by_node()' debe liberarse cuando ya no se necesita. Agregue la llamada put_device() para corregir esto.

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: drm/dp: Se corrige la lectura OOB al manejar el registro Post Cursor2 La matriz link_status no era lo suficientemente grande para leer el registro Post Cursor2 de solicitud de ajuste, por lo que se debe eliminar la función auxiliar común para evitar una lectura OOB, que se encontró con una compilación -Warray-bounds: drivers/gpu/drm/drm_dp_helper.c: En la función 'drm_dp_get_adjust_request_post_cursor': drivers/gpu/drm/drm_dp_helper.c:59:27: error: el subíndice 10 de la matriz está fuera de los límites de la matriz 'const u8[6]' {también conocido como 'const unsigned char[6]'} [-Werror=array-bounds] 59 | ~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~ drivers/gpu/drm/drm_dp_helper.c:147:51: nota: al hacer referencia a 'link_status' 147 | u8 drm_dp_get_adjust_request_post_cursor(const u8 link_status[DP_LINK_STATUS_SIZE], | ~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Reemplace el único usuario del ayudante con una búsqueda y decodificación de código abierto, similar a drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c.

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: xsk: Corregir ejecución en el desmontaje del socket Corrige una ejecución en el código de desmontaje del socket xsk que puede provocar un splat de desreferencia de puntero NULL. El código de desvinculación xsk actual en xsk_unbind_dev() comienza estableciendo xs->state en XSK_UNBOUND, establece xs->dev en NULL y luego espera a que finalice cualquier procesamiento NAPI utilizandosynchronous_net(). Después de eso, el código de lanzamiento comienza a desmantelar el estado del socket y a liberar la memoria asignada. ERROR: desreferencia de puntero NULL del núcleo, dirección: 00000000000000c0 PGD 8000000932469067 P4D 8000000932469067 PUD 0 Oops: 0000 [#1] PREEMPT SMP PTI CPU: 25 PID: 69132 Comm: grpcpp_sync_ser Contaminado: GI 5.16.0+ #2 Nombre del hardware: Dell Inc. PowerEdge R730/0599V5, BIOS 1.2.10 09/03/2015 RIP: 0010:__xsk_sendmsg+0x2c/0x690 [...] RSP: 0018:ffffa2348bd13d50 EFLAGS: 00010246 RAX: 00000000000000000 RBX: 00000000000000040 RCX: ffff8d5fc632d258 RDX: 0000000000400000 RSI: ffffa2348bd13e10 RDI: ffff8d5fc5489800 RBP: ffffa2348bd13db0 R08: 000000000000000 R09: 00007ffffffff000 R10: 0000000000000000 R11: 0000000000000000 R12: ffff8d5fc5489800 R13: ffff8d5fcb0f5140 R14: ffff8d5fcb0f5140 R15: 0000000000000000 FS: 00007f991cff9400(0000) GS:ffff8d6f1f700000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000c0 CR3: 0000000114888005 CR4: 00000000001706e0 Seguimiento de llamadas: ? aa_sk_perm+0x43/0x1b0 xsk_sendmsg+0xf0/0x110 sock_sendmsg+0x65/0x70 __sys_sendto+0x113/0x190 ? debug_smp_processor_id+0x17/0x20 ? fpregs_assert_state_consistent+0x23/0x50 ? exit_to_user_mode_prepare+0xa5/0x1d0 __x64_sys_sendto+0x29/0x30 do_syscall_64+0x3b/0xc0 entry_SYSCALL_64_after_hwframe+0x44/0xae Hay dos problemas con el código actual. Primero, establecer xs->dev en NULL antes de esperar a que todos los usuarios dejen de usar el socket no es correcto. La entrada a las funciones del plano de datos xsk_poll(), xsk_sendmsg() y xsk_recvmsg() están todas protegidas por una prueba de que xs->state está en el estado XSK_BOUND y, si no, regresa de inmediato. Pero un proceso podría haber pasado esta prueba pero aún no haber llegado al punto en el que usa xs->dev en el código. Mientras tanto, un segundo proceso que ejecuta xsk_unbind_dev() podría haber establecido xs->dev en NULL, lo que provocará un bloqueo para el primer proceso. La solución aquí es simplemente deshacerse de esta asignación NULL ya que ya no se usa. Antes de el commit 42fddcc7c64b ("xsk: usar miembro de estado para sincronización de socket"), xs->dev era el guardián para admitir procesos en las funciones del plano de datos, pero fue reemplazado por la variable de estado xs->state en el commit mencionada anteriormente. El segundo problema es quesynchronous_net() no espera a que se complete ningún proceso en xsk_poll(), xsk_sendmsg() o xsk_recvmsg(), lo que significa que el estado en el que se basan podría limpiarse prematuramente. Esto puede suceder cuando se llama al notificador (por ejemplo, al descargar el controlador) ya que utiliza xsk_unbind_dev(). Resuelva esto extendiendo la región crítica de RCU desde solo ndo_xsk_wakeup a todas las funciones mencionadas anteriormente, de modo que tanto la prueba de xs->state == XSK_BOUND como el último uso de cualquier miembro de xs estén cubiertos por la sección crítica de RCU. Esto garantizará que cuando se completesynchronous_net(), no habrá procesos restantes ejecutando xsk_poll(), xsk_sendmsg() o xsk_recvmsg() y el estado se puede limpiar de forma segura. Tenga en cuenta que debemos eliminar el bloqueo de RCU para la ruta de transmisión de skb, ya que utiliza funciones que podrían estar inactivas. Debido a esto, tenemos que volver a probar xs->state después de obtener el mutex que protege el código xmit de skb de, entre varias cosas, un xsk_unbind_dev() que se ejecuta desde el notificador al mismo tiempo.

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.

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