Vulnerabilidades

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: 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: 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: 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: 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: 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: 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: drm/i915/sseu: fix max_subslices array-index-out-of-bounds access Parece que el commit bc3c5e0809ae ("drm/i915/sseu: No intente almacenar la máscara EU internamente en formato UAPI") expuso un posible acceso fuera de los límites, informado por UBSAN de la siguiente manera en una computadora portátil con una tarjeta i915 gen 11: UBSAN: array-index-out-of-bounds en drivers/gpu/drm/i915/gt/intel_sseu.c:65:27 el índice 6 está fuera de rango para el tipo 'u16 [6]' CPU: 2 PID: 165 Comm: systemd-udevd No contaminado 6.2.0-9-generic #9-Ubuntu Nombre del hardware: Dell Inc. XPS 13 9300/077Y9N, BIOS 1.11.0 22/03/2022 Seguimiento de llamadas: show_stack+0x4e/0x61 dump_stack_lvl+0x4a/0x6f dump_stack+0x10/0x18 ubsan_epilogue+0x9/0x3a __ubsan_handle_out_of_bounds.cold+0x42/0x47 gen11_compute_sseu_info+0x121/0x130 [i915] intel_sseu_info_init+0x15d/0x2b0 [i915] intel_gt_init_mmio+0x23/0x40 [i915] i915_driver_mmio_probe+0x129/0x400 [i915] ? intel_gt_probe_all+0x91/0x2e0 [i915] i915_driver_probe+0xe1/0x3f0 [i915] ? drm_privacy_screen_get+0x16d/0x190 [drm] ? acpi_dev_found+0x64/0x80 i915_pci_probe+0xac/0x1b0 [i915] ... Según la definición de sseu_dev_info, eu_mask->hsw está limitado a un máximo de GEN_MAX_SS_PER_HSW_SLICE (6) subsecciones, pero gen11_sseu_info_init() puede establecer potencialmente 8 subsecciones, en el caso de !IS_JSL_EHL(gt->i915). Para solucionar esto, reserve hasta 8 espacios para max_subslices en la estructura eu_mask. (Seleccionado de la confirmación 3cba09a6ac86ea1d456909626eb2685596c07822)

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: nl80211: se corrige la deref NULL-ptr en la comprobación offchan. Si, por ejemplo, en modo AP, el enlace ya fue creado por el espacio de usuario, pero aún no se activó, tiene una definición de canal (chandef), pero esta no es válida y no tiene canal. Verifique esto e ignore este enlace.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: i40e: Se soluciona el fallo del kernel durante el reinicio cuando el adaptador está en modo de recuperación Si el controlador detecta durante el sondeo que el firmware está en modo de recuperación, se llama a i40e_init_recovery_mode() y se omite el resto de la función del sondeo, incluido pci_set_drvdata(). La llamada posterior a i40e_shutdown() durante el apagado/reinicio desreferencia el puntero NULL, ya que pci_get_drvdata() devuelve NULL. Para solucionarlo, llame también a pci_set_drvdata() durante el ingreso al modo de recuperación. Reproductor: 1) Tengamos la NIC i40e con el firmware en modo de recuperación 2) Ejecute el reinicio Resultado: [ 139.084698] i40e: Controlador de red Intel(R) Ethernet Connection XL710 [ 139.090959] i40e: Copyright (c) 2013 - 2019 Intel Corporation. [ 139.108438] i40e 0000:02:00.0: Se detectó el modo de recuperación de firmware. Funcionalidad limitada. [ 139.116439] i40e 0000:02:00.0: Consulte la Guía del usuario de adaptadores y dispositivos Intel(R) Ethernet para obtener más información sobre el modo de recuperación de firmware. [ 139.129499] i40e 0000:02:00.0: fw 8.3.64775 api 1.13 nvm 8.30 0x8000b78d 1.3106.0 [8086:1583] [15d9:084a] [ 139.215932] i40e 0000:02:00.0 enp2s0f0: renombrado de eth0 [ 139.223292] i40e 0000:02:00.1: Se detectó modo de recuperación de firmware. Funcionalidad limitada. [ 139.231292] i40e 0000:02:00.1: Consulte la Guía del usuario de adaptadores y dispositivos Intel(R) Ethernet para obtener más información sobre el modo de recuperación de firmware. [ 139.244406] i40e 0000:02:00.1: fw 8.3.64775 api 1.13 nvm 8.30 0x8000b78d 1.3106.0 [8086:1583] [15d9:084a] [ 139.329209] i40e 0000:02:00.1 enp2s0f1: renombrado de eth0 ... [ 156.311376] ERROR: desreferencia de puntero NULL del kernel, dirección: 00000000000006c2 [ 156.318330] #PF: acceso de escritura del supervisor en modo kernel [ 156.323546] #PF: error_code(0x0002) - no presente página [ 156.328679] PGD 0 P4D 0 [ 156.331210] Oops: 0002 [#1] PREEMPT SMP NOPTI [ 156.335567] CPU: 26 PID: 15119 Comm: reboot Tainted: GE 6.2.0+ #1 [ 156.343126] Nombre del hardware: Abacus electric, s.r.o. - servis@abacus.cz Super Server/H12SSW-iN, BIOS 2.4 04/13/2022 [ 156.353369] RIP: 0010:i40e_shutdown+0x15/0x130 [i40e] [ 156.358430] Code: c1 fc ff ff 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 0f 1f 44 00 00 55 48 89 fd 53 48 8b 9f 48 01 00 00 80 8b c2 06 00 00 04 f0 80 8b c0 06 00 00 08 48 8d bb 08 08 00 [ 156.377168] RSP: 0018:ffffb223c8447d90 EFLAGS: 00010282 [ 156.382384] RAX: ffffffffc073ee70 RBX: 0000000000000000 RCX: 0000000000000001 [ 156.389510] RDX: 0000000080000001 RSI: 0000000000000246 RDI: ffff95db49988000 [ 156.396634] RBP: ffff95db49988000 R08: ffffffffffffffff R09: ffffffff8bd17d40 [ 156.403759] R10: 0000000000000001 R11: ffffffff8a5e3d28 R12: ffff95db49988000 [ 156.410882] R13: ffffffff89a6fe17 R14: ffff95db49988150 R15: 0000000000000000 [ 156.418007] FS: 00007fe7c0cc3980(0000) GS:ffff95ea8ee80000(0000) knlGS:0000000000000000 [ 156.426083] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 156.431819] CR2: 00000000000006c2 CR3: 00000003092fc005 CR4: 0000000000770ee0 [ 156.438944] PKRU: 55555554 [ 156.441647] Call Trace: [ 156.444096] [ 156.446199] pci_device_shutdown+0x38/0x60 [ 156.450297] device_shutdown+0x163/0x210 [ 156.454215] kernel_restart+0x12/0x70 [ 156.457872] __do_sys_reboot+0x1ab/0x230 [ 156.461789] ? vfs_writev+0xa6/0x1a0 [ 156.465362] ? __pfx_file_free_rcu+0x10/0x10 [ 156.469635] ? __call_rcu_common.constprop.85+0x109/0x5a0 [ 156.475034] do_syscall_64+0x3e/0x90 [ 156.478611] entry_SYSCALL_64_after_hwframe+0x72/0xdc [ 156.483658] RIP: 0033:0x7fe7bff37ab7