Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad:<br /> <br /> net: phy: registrar los led_triggers del phy durante la sonda para evitar un interbloqueo AB-BA<br /> <br /> Existe un interbloqueo AB-BA cuando tanto LEDS_TRIGGER_NETDEV como LED_TRIGGER_PHY están habilitados:<br /> <br /> [ 1362.049207] [&amp;lt;8054e4b8&amp;gt;] led_trigger_register+0x5c/0x1fc &amp;lt;-- Intentando obtener el bloqueo &amp;#39;triggers_list_lock&amp;#39; a través de down_write(&amp;amp;triggers_list_lock);<br /> [ 1362.054536] [&amp;lt;80662830&amp;gt;] phy_led_triggers_register+0xd0/0x234<br /> [ 1362.060329] [&amp;lt;8065e200&amp;gt;] phy_attach_direct+0x33c/0x40c<br /> [ 1362.065489] [&amp;lt;80651fc4&amp;gt;] phylink_fwnode_phy_connect+0x15c/0x23c<br /> [ 1362.071480] [&amp;lt;8066ee18&amp;gt;] mtk_open+0x7c/0xba0<br /> [ 1362.075849] [&amp;lt;806d714c&amp;gt;] __dev_open+0x280/0x2b0<br /> [ 1362.080384] [&amp;lt;806d7668&amp;gt;] __dev_change_flags+0x244/0x24c<br /> [ 1362.085598] [&amp;lt;806d7698&amp;gt;] dev_change_flags+0x28/0x78<br /> [ 1362.090528] [&amp;lt;807150e4&amp;gt;] dev_ioctl+0x4c0/0x654 &amp;lt;-- Mantiene el bloqueo &amp;#39;rtnl_mutex&amp;#39; al llamar a rtnl_lock();<br /> [ 1362.094985] [&amp;lt;80694360&amp;gt;] sock_ioctl+0x2f4/0x4e0<br /> [ 1362.099567] [&amp;lt;802e9c4c&amp;gt;] sys_ioctl+0x32c/0xd8c<br /> [ 1362.104022] [&amp;lt;80014504&amp;gt;] syscall_common+0x34/0x58<br /> <br /> Aquí LED_TRIGGER_PHY está registrando los disparadores LED durante phy_attach mientras mantiene RTNL y luego toma triggers_list_lock.<br /> <br /> [ 1362.191101] [&amp;lt;806c2640&amp;gt;] register_netdevice_notifier+0x60/0x168 &amp;lt;-- Intentando obtener el bloqueo &amp;#39;rtnl_mutex&amp;#39; a través de rtnl_lock();<br /> [ 1362.197073] [&amp;lt;805504ac&amp;gt;] netdev_trig_activate+0x194/0x1e4<br /> [ 1362.202490] [&amp;lt;8054e28c&amp;gt;] led_trigger_set+0x1d4/0x360 &amp;lt;-- Mantiene el bloqueo &amp;#39;triggers_list_lock&amp;#39; mediante down_read(&amp;amp;triggers_list_lock);<br /> [ 1362.207511] [&amp;lt;8054eb38&amp;gt;] led_trigger_write+0xd8/0x14c<br /> [ 1362.212566] [&amp;lt;80381d98&amp;gt;] sysfs_kf_bin_write+0x80/0xbc<br /> [ 1362.217688] [&amp;lt;8037fcd8&amp;gt;] kernfs_fop_write_iter+0x17c/0x28c<br /> [ 1362.223174] [&amp;lt;802cbd70&amp;gt;] vfs_write+0x21c/0x3c4<br /> [ 1362.227712] [&amp;lt;802cc0c4&amp;gt;] ksys_write+0x78/0x12c<br /> [ 1362.232164] [&amp;lt;80014504&amp;gt;] syscall_common+0x34/0x58<br /> <br /> Aquí LEDS_TRIGGER_NETDEV está siendo habilitado en un LED. Primero toma triggers_list_lock y luego RTNL. Un interbloqueo AB-BA clásico.<br /> <br /> phy_led_triggers_registers() no requiere el RTNL, no realiza ninguna llamada a la pila de red que requiera protección. Tampoco existe el requisito de que el PHY haya sido conectado a un MAC, los disparadores solo hacen uso del estado de phydev. Esto permite que la llamada a phy_led_triggers_registers() se coloque en otro lugar. PHY probe() y release() no mantienen RTNL, resolviendo así el interbloqueo AB-BA.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> platform/x86: dell-wmi-sysman: No volcar en hexadecimal datos de contraseña en texto plano<br /> <br /> set_new_password() vuelca en hexadecimal el búfer completo, que contiene datos de contraseña en texto plano, incluyendo contraseñas actuales y nuevas. Eliminar el volcado en hexadecimal para evitar la fuga de credenciales.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> nfc: rawsock: cancelar tx_work antes del desmontaje del socket<br /> <br /> En rawsock_release(), cancelar cualquier tx_work pendiente y purgar la cola de escritura antes de dejar huérfano el socket. rawsock_tx_work se ejecuta en la cola de trabajo del sistema y llama a nfc_data_exchange, que desreferencia el dispositivo NCI. Sin sincronización, tx_work puede competir con el desmontaje del socket y del dispositivo cuando un proceso es terminado (p. ej., por SIGKILL), lo que lleva a uso después de liberación o referencias filtradas.<br /> <br /> Establecer SEND_SHUTDOWN primero para que si tx_work ya se está ejecutando, vea la bandera y omita la transmisión, luego usar cancel_work_sync para esperar a que finalice cualquier ejecución en curso, y finalmente purgar cualquier skbs en cola restante.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> ksmbd: Comparar MACs en tiempo constante<br /> <br /> Para prevenir ataques de temporización, las comparaciones de MAC necesitan ser de tiempo constante.<br /> Reemplazar memcmp() con la función correcta, crypto_memneq().

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> PCI: dwc: ep: Vaciar escritura MSI-X antes de desmapear su entrada ATU<br /> <br /> Los controladores de punto final usan dw_pcie_ep_raise_msix_irq() para generar una interrupción MSI-X al host usando un writel(), lo que genera una transacción de escritura publicada PCI. No hay finalización para las escrituras publicadas, por lo que el writel() puede regresar antes de que la escritura PCI se complete. dw_pcie_ep_raise_msix_irq() también desmapea la entrada ATU de salida usada para la escritura PCI, por lo que la escritura compite con el desmapeo.<br /> <br /> Si la escritura PCI pierde la carrera con el desmapeo ATU, la escritura puede corromper la memoria del host o causar errores de IOMMU, por ejemplo, estos al ejecutar fio con una profundidad de cola mayor contra nvmet-pci-epf:<br /> <br /> arm-smmu-v3 fc900000.iommu: 0x0000010000000010<br /> arm-smmu-v3 fc900000.iommu: 0x0000020000000000<br /> arm-smmu-v3 fc900000.iommu: 0x000000090000f040<br /> arm-smmu-v3 fc900000.iommu: 0x0000000000000000<br /> arm-smmu-v3 fc900000.iommu: event: F_TRANSLATION cliente: 0000:01:00.0 sid: 0x100 ssid: 0x0 iova: 0x90000f040 ipa: 0x0<br /> arm-smmu-v3 fc900000.iommu: unpriv data write s1 &amp;#39;Input address caused fault&amp;#39; stag: 0x0<br /> <br /> Vaciar la escritura realizando un readl() de la misma dirección para asegurar que la escritura ha alcanzado el destino antes de que la entrada ATU sea desmapeada.<br /> <br /> El mismo problema fue resuelto para dw_pcie_ep_raise_msi_irq() en el commit 8719c64e76bf (&amp;#39;PCI: dwc: ep: Cacheo de mapeo iATU de salida MSI&amp;#39;), pero allí fue resuelto dedicando un iATU de salida solo para MSI. No podemos hacer lo mismo para MSI-X porque cada vector puede tener una msg_addr diferente y la msg_addr puede ser cambiada mientras el vector está enmascarado.<br /> <br /> [bhelgaas: registro de commit]

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> wifi: mt76: mt7925: Corrige posible acceso fuera de límites en mt7925_mac_write_txwi_80211()<br /> <br /> Comprueba la longitud del frame antes de acceder a los campos mgmt en mt7925_mac_write_txwi_80211 para evitar un posible acceso fuera de límites.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> drm/cliente: No destruir modos NULL<br /> <br /> &amp;#39;modes&amp;#39; en drm_client_modeset_probe puede fallar al kcalloc. Si esto ocurre, saltamos a &amp;#39;out&amp;#39;, llamando a modes_destroy sobre él, lo que lo desreferencia. Esto puede resultar en una desreferencia de puntero NULL en el caso de error. Prevenir eso.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> can: bcm: corregir el bloqueo para las actualizaciones en tiempo de ejecución de bcm_op<br /> <br /> El commit c2aba69d0c36 (&amp;#39;can: bcm: añadir bloqueo para las actualizaciones en tiempo de ejecución de bcm_op&amp;#39;) añadió un bloqueo para algunas variables que pueden ser modificadas en tiempo de ejecución al actualizar el bcm_op de envío con un nuevo comando TX_SETUP en bcm_tx_setup().<br /> <br /> Normalmente, el RX_SETUP solo maneja y filtra el tráfico entrante con una excepción: Cuando la bandera RX_RTR_FRAME está establecida, se envía una trama CAN predefinida cuando se recibe una trama RTR específica. Por lo tanto, el bcm_op de rx usa bcm_can_tx() que usa el bcm_tx_lock que solo fue inicializado en bcm_tx_setup(). Añadir el spin_lock_init() faltante al asignar el bcm_op en bcm_rx_setup() para manejar el caso RTR correctamente.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> net: usb: kalmia: validar puntos finales USB<br /> <br /> El controlador kalmia debería validar que el dispositivo que está sondeando tiene el número y los tipos adecuados de puntos finales USB que espera antes de que se vincule a él. Si un dispositivo malicioso no tuviera los mismos urbs, el controlador fallará más tarde cuando acceda ciegamente a estos puntos finales.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> nvme: corrige la fuga de la cola de administración al reiniciar el controlador<br /> <br /> Cuando se llama a nvme_alloc_admin_tag_set() durante un reinicio del controlador, una cola de administración anterior aún puede existir. Libérela correctamente antes de asignar una nueva para evitar dejar huérfana la cola antigua.<br /> <br /> Esto corrige una regresión introducida por el commit 03b3bcd319b3 (&amp;#39;nvme: corrige la vida útil de request_queue de administración&amp;#39;).

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> ata: libata: cancelar trabajo pendiente después de limpiar deferred_qc<br /> <br /> Syzbot informó un WARN_ON() en ata_scsi_deferred_qc_work(), causado por ap-&amp;gt;ops-&amp;gt;qc_defer() que devolvía un valor distinto de cero antes de emitir el qc diferido.<br /> <br /> ata_scsi_schedule_deferred_qc() es llamada durante cada finalización de comando. Esta función verificará si hay un QC diferido, y si ap-&amp;gt;ops-&amp;gt;qc_defer() devuelve cero, lo que significa que es posible encolar el qc diferido en este momento (sin ser diferido), entonces encolará el trabajo que emitirá el qc diferido.<br /> <br /> Una vez que el trabajo se ejecuta, lo que potencialmente puede ser mucho tiempo después de que el trabajo fue programado, hay un WARN_ON() si ap-&amp;gt;ops-&amp;gt;qc_defer() devuelve un valor distinto de cero.<br /> <br /> Mientras mantenemos el ap-&amp;gt;lock tanto al asignar como al limpiar deferred_qc, y el trabajo en sí mantiene el ap-&amp;gt;lock, el código actualmente no cancela el trabajo después de limpiar el qc diferido.<br /> <br /> Esto significa que el siguiente escenario puede ocurrir:<br /> 1) Uno o varios comandos NCQ son encolados.<br /> 2) Un comando no-NCQ es encolado, se almacena en ap-&amp;gt;deferred_qc.<br /> 3) El último comando NCQ se completa, el trabajo es encolado para emitir el qc diferido.<br /> 4) Ocurre un tiempo de espera o un error, ap-&amp;gt;deferred_qc es limpiado. El trabajo encolado NO es cancelado actualmente.<br /> 5) El puerto es reiniciado.<br /> 6) Uno o varios comandos NCQ son encolados.<br /> 7) Un comando no-NCQ es encolado, se almacena en ap-&amp;gt;deferred_qc.<br /> 8) El trabajo finalmente se ejecuta. Sin embargo, en este momento, todavía hay comandos NCQ en curso.<br /> <br /> El trabajo en 8) realmente pertenece al comando no-NCQ en 2), no al comando no-NCQ en 7). La razón por la cual el trabajo se ejecuta cuando no se supone que debe hacerlo, es porque nunca fue cancelado cuando ap-&amp;gt;deferred_qc fue limpiado en 4). Por lo tanto, asegúrese de que siempre cancelemos el trabajo después de limpiar ap-&amp;gt;deferred_qc.<br /> <br /> Otra solución potencial habría sido dejar que ata_scsi_deferred_qc_work() no hiciera nada si ap-&amp;gt;ops-&amp;gt;qc_defer() devuelve un valor distinto de cero. Sin embargo, cancelar el trabajo al limpiar ap-&amp;gt;deferred_qc parece ligeramente más lógico, ya que mantenemos el ap-&amp;gt;lock al limpiar ap-&amp;gt;deferred_qc, por lo que sabemos que el trabajo no puede estar manteniendo el bloqueo. (La función podría estar esperando el bloqueo, pero eso está bien ya que no hará nada si ap-&amp;gt;deferred_qc no está configurado.)

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> drm/amdgpu: Corregir el manejo de errores en el reinicio de ranura<br /> <br /> Si el dispositivo no se ha recuperado después de que se llama al reinicio de ranura, va a la etiqueta out para el manejo de errores. Allí podría tomar una decisión basada en un puntero hive no inicializado y podría resultar en el acceso a una lista no inicializada.<br /> <br /> Inicializar la lista y hive correctamente para que maneje la situación de error y también libere el bloqueo del dominio de reinicio que se adquiere durante la llamada de retorno error_detected.<br /> <br /> (seleccionado de la confirmación bb71362182e59caa227e4192da5a612b09349696)