Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: dsa: corrige un bloqueo si ->get_sset_count() falla. Si ds->ops->get_sset_count() falla, entonces "count" es un código de error negativo como - EOPNOTSUPP. Debido a que "i" es un int sin signo, el código de error negativo se promociona a un valor muy alto y el bucle corromperá la memoria hasta que el sistema falle. Solucione este problema buscando códigos de error y cambiando el tipo de "i" a solo int.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: net: dsa: mt7530: corregir fugas de tráfico de VLAN El campo PCR_MATRIX se configuró en todos 1 cuando el filtrado de VLAN está habilitado, pero no se restableció cuando está deshabilitado, lo que puede causar fugas de tráfico: enlace ip agregar puente tipo br0 vlan_filtering 1 enlace ip agregar puente tipo br1 vlan_filtering 1 conjunto de enlaces ip swp0 master br0 conjunto de enlaces ip swp1 maestro br1 conjunto de enlaces ip br0 puente tipo vlan_filtering 0 conjunto de enlaces ip br1 tipo puente vlan_filtering 0 # tráfico en br0 y br1 comenzarán a filtrarse entre sí. Como port_bridge_{add,del} ha configurado PCR_MATRIX correctamente, elimine la escritura PCR_MATRIX de mt7530_port_set_vlan_aware.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: spi: spi-fsl-dspi: reparar una fuga de recursos en una ruta de manejo de errores 'dspi_request_dma()' debe deshacerse mediante una llamada 'dspi_release_dma()' en la ruta de manejo de errores de la función de sonda, como ya se hizo en la función de eliminación

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: tipc: skb_linearize el skb principal al volver a ensamblar mensajes No es una buena idea agregar el frag skb a la frag_list de un skb si la frag_list ya tiene skbs de otro lugar, como por ejemplo este skb fue creado por pskb_copy() donde se clonó frag_list (todos los skbs que contenía fueron skb_get'ed) y se compartió con varios skbs. Sin embargo, el nuevo fragmento skb adjunto solo debería haber sido visto por el skb actual. De lo contrario, causará uso después de fallas gratuitas, ya que varios skbs ven este fragmento skb agregado, pero solo se llamó a skb_get una vez. Lo mismo sucede con un skb actualizado por pskb_may_pull() con un skb skb_cloned. Li Shuang ha informado de bastantes fallos causados por esto al realizar pruebas en dispositivos macvlan: [] ¡ERROR del kernel en net/core/skbuff.c:1970! [] Seguimiento de llamadas: [] skb_clone+0x4d/0xb0 [] macvlan_broadcast+0xd8/0x160 [macvlan] [] macvlan_process_broadcast+0x148/0x150 [macvlan] [] Process_one_work+0x1a7/0x360 [] trabajador_thread+0x30/0x390 [] ERROR del kernel en mm/usercopy.c:102! [] Seguimiento de llamadas: [] __check_heap_object+0xd3/0x100 [] __check_object_size+0xff/0x16b [] simple_copy_to_iter+0x1c/0x30 [] __skb_datagram_iter+0x7d/0x310 [] __skb_datagram_iter+0x2a5/0x310 [] skb_copy_datagram _iter+0x3b/0x90 [] tipc_recvmsg +0x14a/0x3a0 [tipc] [] ____sys_recvmsg+0x91/0x150 [] ___sys_recvmsg+0x7b/0xc0 [] ¡ERROR del kernel en mm/slub.c:305! [] Seguimiento de llamadas: [] [] kmem_cache_free+0x3ff/0x400 [] __netif_receive_skb_core+0x12c/0xc40 [] ? kmem_cache_alloc+0x12e/0x270 [] netif_receive_skb_internal+0x3d/0xb0 [] ? get_rx_page_info+0x8e/0xa0 [be2net] [] be_poll+0x6ef/0xd00 [be2net] [] ? irq_exit+0x4f/0x100 [] net_rx_action+0x149/0x3b0 ... Este parche es para solucionarlo linealizando el skb principal si tiene frag_list configurado en tipc_buf_append(). Tenga en cuenta que elegimos hacer esto antes de llamar a skb_unshare(), ya que __skb_linearize() evitará skb_copy(). Además, tampoco podemos simplemente eliminar frag_list desde el principio.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: tipc: espere y salga hasta que todas las colas de trabajo estén terminadas. En algunos hosts, se podría desencadenar un bloqueo simplemente repitiendo estos comandos varias veces: # modprobe tipc # tipc portador habilitar media udp nombre UDP1 localip 127.0.0.1 # rmmod tipc [] ERROR: no se puede manejar la solicitud de paginación del kernel en ffffffffc096bb00 [] Cola de trabajo: eventos 0xffffffffc096bb00 [] Seguimiento de llamadas: []? proceso_one_work+0x1a7/0x360 []? hilo_trabajador+0x30/0x390 []? crear_trabajador+0x1a0/0x1a0 []? kthread+0x116/0x130 []? kthread_flush_work_fn+0x10/0x10 []? ret_from_fork+0x35/0x40 Al retirar el módulo TIPC, el calcetín del túnel UDP se retrasará para liberarse en una cola de trabajo, ya que sock_release() no se puede realizar en rtnl_lock(). Si la cola de trabajo está programada para ejecutarse después de eliminar el módulo TIPC, el kernel fallará porque el código de la función de cola de trabajo cleanup_beareri() ya no existe al intentar invocarlo. Para solucionarlo, este parche introduce un miembro wq_count en tipc_net para rastrear el número de colas de trabajo programadas y esperar y salir hasta que todas las colas de trabajo estén terminadas en tipc_exit_net().

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: net/mlx5e: corrigió el deref nulo al acceder a lag dev. Podría ser que el lag dev sea nulo, así que deje de procesar el evento. En bond_enslave(), el esclavo activo/de respaldo se configura antes de configurar el desarrollo superior, por lo que el primer evento es sin un desarrollo superior. Después de configurar el desarrollo superior con bond_master_upper_dev_link() hay un segundo evento y en ese evento tenemos un desarrollo superior.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: drm/meson: corrige el fallo de apagado cuando el componente no se prueba Cuando el componente principal no se prueba, por ejemplo, cuando el módulo dw-hdmi aún no está cargado o en el aplazamiento de la prueba, se produce el siguiente fallo aparece al apagar: No se puede manejar la desreferencia del puntero NULL del kernel en la dirección virtual 0000000000000038... pc: meson_drv_shutdown+0x24/0x50 lr: platform_drv_shutdown+0x20/0x30... Rastreo de llamadas: meson_drv_shutdown+0x24/0x50 platform_drv_shutdown+0x20/0x3 0 dispositivo_apagado+ 0x158/0x360 kernel_restart_prepare+0x38/0x48 kernel_restart+0x18/0x68 __do_sys_reboot+0x224/0x250 __arm64_sys_reboot+0x24/0x30... Simplemente verifique si la estructura priv se ha asignado antes de usarla.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: NFS: no corrompa el valor de pg_bytes_writing en nfs_do_recoalesce() El valor de mirror->pg_bytes_write solo debe actualizarse después de un intento exitoso de eliminar las solicitudes de la lista.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: NFS: corrija una condición de Oopsable en __nfs_pageio_add_request() Asegúrese de que nfs_pageio_error_cleanup() restablezca el contenido de la matriz reflejada, de modo que la estructura refleje el hecho de que ahora está vacía. También cambie la prueba en nfs_pageio_do_add_request() para que sea más sólida verificando si la lista está vacía o no en lugar de confiar en el valor de pg_count.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: NFS: corrige un límite incorrecto en filelayout_decode_layout() El "sizeof(struct nfs_fh)" es dos bytes demasiado grande y podría provocar daños en la memoria. Debería ser NFS_MAXFHSIZE porque ese es el tamaño del búfer ->datos[]. Invertí el tamaño de los argumentos para poner la variable a la izquierda.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: serial: rp2: use 'request_firmware' en lugar de 'request_firmware_nowait' En 'rp2_probe', el controlador registra 'rp2_uart_interrupt' y luego llama a 'rp2_fw_cb' a través de 'request_firmware_nowait'. En 'rp2_fw_cb', si el firmware no existe, la función simplemente regresa sin inicializar los puertos de 'rp2_card'. Pero ahora la función de manejo de interrupciones ha sido registrada, y cuando llega una interrupción, 'rp2_uart_interrupt' puede acceder a esos puertos y causar desreferencia al puntero NULL u otros errores. Debido a que el controlador realiza algún trabajo de inicialización en 'rp2_fw_cb', para que el controlador esté listo para manejar interrupciones, se debe usar 'request_firmware' en lugar de 'request_firmware_nowait' asíncrono. Este informe lo revela: INFORMACIÓN: intentando registrar una clave no estática. el código está bien pero necesita una anotación de bloqueo. apagando el validador de corrección de bloqueo. CPU: 2 PID: 0 Comunicaciones: swapper/2 No contaminado 4.19.177-gdba4159c14ef-dirty #45 Nombre del hardware: PC estándar QEMU (Q35 + ICH9, 2009), BIOS rel-1.12.0-59- gc9ba5276e321-prebuilt.qemu .org 01/04/2014 Seguimiento de llamadas: __dump_stack lib/dump_stack.c:77 [en línea] dump_stack+0xec/0x156 lib/dump_stack.c:118 asignar_lock_key kernel/locking/lockdep.c:727 [en línea] Register_lock_class +0x14e5/0x1ba0 kernel/locking/lockdep.c:753 __lock_acquire+0x187/0x3750 kernel/locking/lockdep.c:3303 lock_acquire+0x124/0x340 kernel/locking/lockdep.c:3907 __raw_spin_lock include/linux/spinlock_api_smp.h: 142 [en línea] _raw_spin_lock+0x32/0x50 kernel/locking/spinlock.c:144 spin_lock include/linux/spinlock.h:329 [en línea] rp2_ch_interrupt drivers/tty/serial/rp2.c:466 [en línea] rp2_asic_interrupt.isra. 9+0x15d/0x990 controladores/tty/serial/rp2.c:493 rp2_uart_interrupt+0x49/0xe0 controladores/tty/serial/rp2.c:504 __handle_irq_event_percpu+0xfb/0x770 kernel/irq/handle.c:149 handle_irq_event_percpu+0x79/ 0x150 kernel/irq/handle.c:189 handle_irq_event+0xac/0x140 kernel/irq/handle.c:206 handle_fasteoi_irq+0x232/0x5c0 kernel/irq/chip.c:725 generic_handle_irq_desc include/linux/irqdesc.h:155 [en línea ] handle_irq+0x230/0x3a0 arch/x86/kernel/irq_64.c:87 do_IRQ+0xa7/0x1e0 arch/x86/kernel/irq.c:247 common_interrupt+0xf/0xf arch/x86/entry/entry_64.S:670 < /IRQ> RIP: 0010:native_safe_halt+0x28/0x30 arch/x86/include/asm/irqflags.h:61 Código: 00 00 55 be 04 00 00 00 48 c7 c7 00 c2 2f 8c 48 89 e5 e8 fb 31 e7 f8 8b 05 75 af 8d 03 85 c0 7e 07 0f 00 2d 8a 61 65 00 fb f4 <5d> c3 90 90 90 90 90 90 0f 1f 44 00 00 55 48 89 e5 41 57 41 56 41 RSP: 00 18:ffff88806b71fcc8 EF BANDERAS: 00000246 ORIG_RAX: ffffffffffffffde RAX: 0000000000000000 RBX: ffffffff8bde7e48 RCX: ffffffff88a21285 RDX: 00000000000000000 RSI: 00000000000000004 RDI: ffffff ff8c2fc200 RBP: ffff88806b71fcc8 R08: ffffbfff185f840 R09: ffffbfff185f840 R10: 00000000000000001 R11: ffffbfff185f840 R12: 0000000000000002 R13: ff ffffff8bea18a0 R14: 0000000000000000 R15: 0000000000000000 arch_safe_halt arch/x86/include/asm/paravirt.h:94 [en línea] default_idle+0x6f/0x360 arch/x86/kernel/process.c:557 arch_cpu_idle+0xf/0x20 arch/x86/kernel/process.c:548 default_idle_call+ 0x3b/0x60 kernel/sched/idle.c:93 cpuidle_idle_call kernel/sched/idle.c:153 [en línea] do_idle+0x2ab/0x3c0 kernel/sched/idle.c:263 cpu_startup_entry+0xcb/0xe0 kernel/sched/idle. c:369 start_secondary+0x3b8/0x4e0 arch/x86/kernel/smpboot.c:271 second_startup_64+0xa4/0xb0 arch/x86/kernel/head_64.S:243 ERROR: no se puede manejar la desreferencia del puntero NULL del kernel en 00000000000000010 PGD 8000000056d270 67 P4D 8000000056d27067 PUD 56d28067 PMD 0 Ups: 0000 [#1] PREEMPT SMP KASAN PTI CPU: 2 PID: 0 Comm: swapper/2 No contaminado 4.19.177-gdba4159c14ef-dirty #45 Nombre de hardware: PC estándar QEMU (Q35 + ICH9, 2009) , BIOS rel-1.12.0-59- gc9ba5276e321-prebuilt.qemu.org 01/04/2014 ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: USB: usbfs: No ADVERTIR sobre asignaciones de memoria excesivamente grandes. Syzbot descubrió que el kernel genera una ADVERTENCIA si el usuario intenta enviar una transferencia masiva a través de usbfs con un búfer demasiado grande. Esto no es un error en el kernel; es simplemente una solicitud no válida del usuario y el código usbfs la maneja correctamente. En teoría, lo mismo puede suceder con las transferencias asíncronas o con la tabla de descriptores de paquetes para transferencias isócronas. Para evitar que el subsistema MM se queje de estas solicitudes de asignación incorrectas, agregue el indicador __GFP_NOWARN a las llamadas kmalloc para estos búferes.