Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: RISC-V: se corrige la toma de text_mutex dos veces durante la corrección de erratas de SiFive. Chris señaló que un imbécil, *ejem* yo *ejem*, añadió dos mutex_locks() a la corrección de erratas de SiFive. El segundo debía ser un mutex_unlock(). Esto genera errores como No se puede manejar la desreferencia del puntero NULL del núcleo en la dirección virtual 0000000000000030 Ups [#1] Módulos vinculados: CPU: 0 PID: 0 Comm: swapper No contaminado 6.2.0-rc1-starlight-00079-g9493e6f3ce02 #229 Nombre del hardware: BeagleV Starlight Beta (DT) epc: __schedule+0x42/0x500 ra: schedule+0x46/0xce epc: ffffffff8065957c ra: ffffffff80659a80 sp: ffffffff81203c80 gp: ffffffff812d50a0 tp: ffffffff8120db40 t0: ffffffff81203d68 t1: 0000000000000001 t2: 4c45203a76637369 s0: ffffffff81203cf0 s1: ffffffff8120db40 a0: 0000000000000000 a1: ffffffff81213958 a2: ffffffff81213958 a3: 0000000000000000 a4: 0000000000000000 a5: ffffffff80a1bd00 a6: 0000000000000000 a7: 0000000052464e43 s2: ffffffff8120db41 s3: ffffffff80a1ad00 s4: 0000000000000000 s5: 0000000000000002 s6: ffffffff81213938 s7: 0000000000000000 s8: 0000000000000000 s9: 0000000000000001 s10: ffffffff812d7204 s11: ffffffff80d3c920 t3: 0000000000000001 t4: ffffffff812e6dd7 t5: ffffffff812e6dd8 t6: ffffffff81203bb8 estado: 0000000200000100 dirección incorrecta: 0000000000000030 causa: 000000000000000d [] programación+0x46/0xce [] programación_preempt_disabled+0x16/0x28 [] __mutex_lock.constprop.0+0x3fe/0x652 [] __mutex_lock_slowpath+0xe/0x16 [] mutex_lock+0x42/0x4c [] sifive_errata_patch_func+0xf6/0x18c [] _apply_alternatives+0x74/0x76 [] apply_boot_alternatives+0x3c/0xfa [] setup_arch+0x60c/0x640 [] start_kernel+0x8e/0x99c ---[ fin de seguimiento 0000000000000000 ]--- [Palmer: consulta el informe de error de Geert en el hilo]

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ext4: Se corrige el bloqueo al renombrar un directorio. Como advierte lockdep, no se debe bloquear i_rwsem mientras se inician transacciones, ya que el orden de bloqueo correcto para todas las operaciones de gestión de directorios es i_rwsem -> inicio de transacción. Corrija el orden de bloqueo desplazando el bloqueo del directorio hacia una etapa anterior en ext4_rename().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bloque: corregir el modo incorrecto para blkdev_put() desde disk_scan_partitions(). Si se llama a disk_scan_partitions() con 'FMODE_EXCL', blkdev_get_by_dev() se llamará sin 'FMODE_EXCL'. Sin embargo, blkdev_put() se seguirá llamando con 'FMODE_EXCL', lo que provocará una fuga del contador 'bd_holders'. Solucione el problema usando el modo correcto para blkdev_put().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: scsi: mpi3mr: Se corrige la pérdida de memoria de throttle_groups. Se agrega un kfree() faltante.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: scsi: mpi3mr: Se corrige la pérdida del nodo expansor en mpi3mr_remove(). Se agrega una limpieza de recursos faltantes en .remove.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: scsi: mpi3mr: corrige la pérdida de memoria sas_hba.phy en mpi3mr_remove() Libera mrioc->sas_hba.phy en .remove.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: usb: smsc75xx: Limitar la longitud del paquete a skb->len. La longitud del paquete recuperada de los datos de skb puede ser mayor que la longitud real del búfer del socket (hasta 9026 bytes). En tal caso, el skb clonado que se pasa a la pila de red filtrará el contenido de la memoria del kernel.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: scsi: mpt3sas: Se corrige el acceso a puntero nulo en mpt3sas_transport_port_add(). El puerto se asigna mediante sas_port_alloc_num() y el rphy se asigna mediante sas_end_device_alloc() o sas_expander_alloc(), lo que puede devolver un valor nulo. Por lo tanto, es necesario comprobar el rphy para evitar un posible acceso a puntero nulo. Si sas_rphy_add() falla, el rphy se establece en nulo. Accederíamos al rphy en las siguientes líneas, lo que también resultaría en un acceso a puntero nulo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: PCI: s390: Se corrige el problema de use-after-free de recursos PCI con la conexión en caliente por función. En s390, las funciones PCI pueden conectarse en caliente individualmente, incluso si pertenecen a un dispositivo multifunción. En particular, en un dispositivo SR-IOV, las funciones virtuales (VF) pueden eliminarse y volver a añadirse posteriormente. Sin embargo, en el commit a50297cf8235 ("s390/pci: separar la creación de zbus del escaneo") se omitió que la lista de recursos de struct pci_bus y struct zpci_bus conservaba una referencia a los recursos MMIO de las funciones PCI, incluso si estos recursos se liberan al desconectar en caliente. Estos recursos obsoletos pueden reclamarse posteriormente cuando la función PCI reaparece, lo que resulta en un problema de use-after-free. Una idea para corregir este problema de use-after-free en el código específico de s390 que se investigó fue simplemente mantener los recursos desde el momento en que aparece una función PCI hasta que desaparece todo el bus PCI virtual creado para un dispositivo multifunción. El problema con esto, sin embargo, es que debido al requisito de direcciones MMIO artificiales (cookies de dirección), se necesita lógica adicional para mantener las cookies de dirección compatibles al volver a conectar. Al mismo tiempo, los recursos MMIO pertenecen semánticamente a la función PCI, por lo que vincular su ciclo de vida a la función parece más lógico. En cambio, un enfoque más simple es eliminar los recursos de una función PCI individualmente desconectada en caliente de la lista de recursos del bus PCI, mientras que se mantienen intactos los recursos de otras funciones PCI en el bus PCI. Esto se hace introduciendo pci_bus_remove_resource() para eliminar un recurso individual. De manera similar, el recurso también debe eliminarse de la lista de recursos de struct zpci_bus. Sin embargo, resulta que realmente no hay necesidad de agregar los recursos MMIO a la lista de recursos de struct zpci_bus en absoluto y, en su lugar, podemos simplemente usar el puntero de recursos de zpci_bar_struct directamente.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: tcp: tcp_make_synack() se puede llamar desde el contexto del proceso. tcp_rtx_synack() ahora se puede llamar en el contexto del proceso como se explica en 0a375c822497 ("tcp: tcp_rtx_synack() se puede llamar desde el contexto del proceso"). tcp_rtx_synack() podría llamar a tcp_make_synack(), que tocará las variables por CPU con la preempción habilitada. Esto provoca el siguiente ERROR: ERROR: uso de __this_cpu_add() en código preemptible [00000000]: El llamador de ThriftIO1/5464 es tcp_make_synack+0x841/0xac0 Rastreo de llamadas: dump_stack_lvl+0x10d/0x1a0 check_preemption_disabled+0x104/0x110 tcp_make_synack+0x841/0xac0 tcp_v6_send_synack+0x5c/0x450 tcp_rtx_synack+0xeb/0x1f0 inet_rtx_syn_ack+0x34/0x60 tcp_check_req+0x3af/0x9e0 tcp_rcv_state_process+0x59b/0x2030 tcp_v6_do_rcv+0x5f5/0x700 release_sock+0x3a/0xf0 tcp_sendmsg+0x33/0x40 ____sys_sendmsg+0x2f2/0x490 __sys_sendmsg+0x184/0x230 do_syscall_64+0x3d/0x90 Evite llamar a __TCP_INC_STATS(), ya que afectará las variables por CPU. Use TCP_INC_STATS(), que se puede llamar de forma segura desde un cambio de contexto.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: scsi: mpi3mr: Se corrige la pérdida de memoria DMA en la página de configuración. Una solución para: DMA-API: pci 0000:83:00.0: el controlador del dispositivo tiene asignaciones DMA pendientes mientras se libera del dispositivo [count=1]

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nfc: pn533: inicializar correctamente la estructura pn533_out_arg. La estructura pn533_out_arg, utilizada como contexto temporal para out_urb, no se inicializa correctamente. Su campo "phy" no inicializado puede desreferenciarse en casos de error dentro de la función de devolución de llamada pn533_out_complete(). Provoca el siguiente error: fallo de protección general, probablemente para la dirección no canónica 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN KASAN: null-ptr-deref en el rango [0x0000000000000000-0x0000000000000007] CPU: 1 PID: 0 Comm: swapper/1 No contaminado 6.2.0-rc3-next-20230110-syzkaller #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 26/10/2022 RIP: 0010:pn533_out_complete.cold+0x15/0x44 drivers/nfc/pn533/usb.c:441 Rastreo de llamadas: __usb_hcd_giveback_urb+0x2b6/0x5c0 drivers/usb/core/hcd.c:1671 usb_hcd_giveback_urb+0x384/0x430 drivers/usb/core/hcd.c:1754 dummy_timer+0x1203/0x32d0 drivers/usb/gadget/udc/dummy_hcd.c:1988 call_timer_fn+0x1da/0x800 kernel/time/timer.c:1700 expire_timers+0x234/0x330 kernel/time/timer.c:1751 __run_timers kernel/time/timer.c:2022 [inline] __run_timers kernel/time/timer.c:1995 [inline] run_timer_softirq+0x326/0x910 kernel/time/timer.c:2035 __do_softirq+0x1fb/0xaf6 kernel/softirq.c:571 invoke_softirq kernel/softirq.c:445 [inline] __irq_exit_rcu+0x123/0x180 kernel/softirq.c:650 irq_exit_rcu+0x9/0x20 kernel/softirq.c:662 sysvec_apic_timer_interrupt+0x97/0xc0 arch/x86/kernel/apic/apic.c:1107 Inicializa el campo con el pn533_usb_phy utilizado actualmente. Encontrado por el Centro de Verificación de Linux (linuxtesting.org) con Syzkaller.