Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: rastreo/histograma: corrige una posible pérdida de memoria para kstrdup(). Falta kfree() en una ruta de error para liberar la memoria asignada por kstrdup(): p = param = kstrdup( datos->params[i], GFP_KERNEL); Por eso es mejor liberarlo mediante kfree(p).

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: efi: runtime: evite los servicios de tiempo de ejecución EFIv2 en máquinas Apple x86 Aditya informa [0] que su reciente MacbookPro falla en el firmware cuando usa los servicios variables en tiempo de ejecución. El culpable parece ser una llamada a QueryVariableInfo(), que no utilizamos para llamar a máquinas Apple x86 en el pasado, ya que recientemente se actualizaron del firmware EFI v1.10 al firmware EFI v2.40, y QueryVariableInfo() (junto con con UpdateCapsule() et al) se agregó en EFI v2.00. El único servicio de tiempo de ejecución introducido en EFI v2.00 que realmente usamos en Linux es QueryVariableInfo(), ya que los basados en cápsulas son opcionales y generalmente no se usan en tiempo de ejecución (toda la infraestructura de actualización de firmware LVFS/fwupd utiliza programas EFI auxiliares que invocan la cápsula). actualizar en el momento del arranque, no en el tiempo de ejecución) y, en primer lugar, no lo implementan las máquinas Apple. QueryVariableInfo() se utiliza para establecer variables de forma "segura", es decir, sólo cuando hay suficiente espacio. Esto evita que las máquinas con firmwares defectuosos dañen sus NVRAM cuando se quedan sin espacio. Dado que las máquinas Apple han estado usando los servicios EFI v1.10 solo durante más tiempo (la especificación EFI v2.0 se lanzó en 2006 y el soporte de Linux para los servicios de ejecución recientemente introducidos se agregó en 2011, pero el MacbookPro12,1 se lanzó en 2015 todavía afirma ser solo EFI v1.10), evitemos los EFI v2.0 en todas las máquinas Apple x86. [0] https://lore.kernel.org/all/6D757C75-65B1-468B-842D-10410081A8E4@live.com/

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf: protección contra el acceso a pt_regs NULL en bpf_get_task_stack() task_pt_regs() puede devolver NULL en powerpc para subprocesos del kernel. Luego, esto se usa en __bpf_get_stack() para verificar el modo de usuario, lo que genera un kernel ups. Protéjase contra esto verificando el valor de retorno de task_pt_regs() antes de intentar obtener la cadena de llamadas.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: net: bridge: vlan: corrige la pérdida de memoria en __allowed_ingress Cuando se usa el estado por VLAN, si la vigilancia de VLAN y las estadísticas están deshabilitadas, el marco de ingreso sin etiquetar o con etiqueta de prioridad irá a verificar pvid estado. Si el estado del puerto está reenviando y el estado del pvid no está aprendiendo/reenviando, se descartará la trama sin etiquetar o con etiqueta de prioridad, pero no se liberará la memoria skb. Debería liberar skb cuando __allowed_ingress devuelva falso.

En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: drm/msm/dpu: comprobación de parámetro no válido en dpu_setup_dspp_pcc La función realiza una comprobación del parámetro de entrada "ctx", sin embargo, se utiliza antes de la comprobación. Inicialice la variable "base" después de la verificación de cordura para evitar una posible desreferencia del puntero NULL. Direcciones-Coverity-ID: 1493866 ("Desreferencia de puntero nulo")

En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: hwmon: (nct6775) ¿Reparar fallo en clear_caseopen Pawe? Marciniak informa del siguiente accidente, observado al borrar la alarma de intrusión en el chasis. ERROR: desreferencia del puntero NULL del kernel, dirección: 00000000000000028 PGD 0 P4D 0 Ups: 0000 [#1] PREEMPT SMP PTI CPU: 3 PID: 4815 Comm: bash Contaminado: GS 5.16.2-200.fc35.x86_64 #1 Nombre de hardware: Para ser completado por OEM Para ser completado por OEM/Z97 Extreme4, BIOS P2.60A 03/05/2018 RIP: 0010:clear_caseopen+0x5a/0x120 [nct6775] Código: 68 70 e8 e9 32 b1 e3 85 c0 0f 85 d2 00 00 00 48 83 7c 24 ... RSP: 0018:ffffabcb02803dd8 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 00000000000000002 RCX: 0000000000000000 RDX: 8808192880 RSI: 0000000000000000 RDI: ffff8e87c7509a68 RBP: 0000000000000000 R08: 0000000000000001 R09: 000000000000000a R10: 000000a R11: f000000000000000 R12: 000000000000001f R13: ffff8e87c7509828 R14: ffff8e87c7509a68 R15: ffff8e88494527a0 FS: 00007f4db9151740(0000) GS:ffff8e8ebfec0000(0000) nlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000028 CR3: 0000000166b66001 CR4: 00000000001706e0 : kernfs_fop_write_iter+0x11c/0x1b0 new_sync_write+0x10b/0x180 vfs_write+0x209/0x2a0 ksys_write+0x4f/0xc0 do_syscall_64+0x3b/0x90 Entry_SYSCALL_64_after_hwframe+0x44/0xae El problema es que el dispositivo pasado a clear_caseopen() es el dispositivo hwmon, no el dispositivo de plataforma y los datos de la plataforma no están configurados en el dispositivo hwmon. Guarde el puntero a sio_data en la estructura nct6775_data y obtengalo desde allí si es necesario.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: net/smc: solución transitoria para el problema de ejecución de clcsock Encontramos un bloqueo en smc_setsockopt() y se debe al acceso a smc->clcsock después de que se lanzó clcsock. ERROR: desreferencia del puntero NULL del kernel, dirección: 0000000000000020 #PF: acceso de lectura del supervisor en modo kernel #PF: código_error(0x0000) - página no presente PGD 0 P4D 0 Ups: 0000 [#1] PREEMPT SMP PTI CPU: 1 PID: 50309 Comm: nginx Kdump: cargado Contaminado: GE 5.16.0-rc4+ #53 RIP: 0010:smc_setsockopt+0x59/0x280 [smc] Seguimiento de llamadas: __sys_setsockopt+0xfc/0x190 __x64_sys_setsockopt+0x20/0x30 do_syscall_64+0x34/0x90 Entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7f16ba83918e Este parche intenta solucionarlo manteniendo presionado clcsock_release_lock y verificando si clcsock ya se ha liberado antes del acceso. En caso de que ocurra una falla por el mismo motivo en smc_getsockopt() o smc_switch_to_fallback(), este parche también verifica smc->clcsock en ellos. Y la persona que llama a smc_switch_to_fallback() identificará si el respaldo tiene éxito de acuerdo con el valor de retorno.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: powerpc/perf: corrija power_pmu_disable para llamar a clear_pmi_irq_pending solo si PMI está pendiente Ejecutando la autoprueba con CONFIG_PPC_IRQ_SOFT_MASK_DEBUG habilitado en el kernel activado a continuación: [172.851380] ---------- --[ cortar aquí ]------------ [ 172.851391] ADVERTENCIA: CPU: 8 PID: 2901 en arch/powerpc/include/asm/hw_irq.h:246 power_pmu_disable+0x270/0x280 [ 172.851402 ] Módulos vinculados en: dm_mod bonding nft_ct nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip_set nf_tables rfkill nfnetlink sunrpc xfs libcrc32c pseries_rng xts vmx_crypto uio_pdrv_genirq uio sch_fq_codel ip_tables ext4 mbcache j bd2 sd_mod t10_pi sg ibmvscsi ibmveth scsi_transport_srp fusible [172.851442] CPU: 8 PID: 2901 Comm: lost_exception_ No contaminado 5.16 .0-rc5-03218-g798527287598 #2 [ 172.851451] NIP: c00000000013d600 LR: c00000000013d5a4 CTR: c00000000013b180 [ 172.851458] REGS: 7687860 TRAMPA: 0700 No contaminado (5.16.0-rc5-03218-g798527287598) [ 172.851465] MSR: 8000000000029033 CR: 48004884 XER: 20040000 [ 172.851482] CFAR: c00000000013d5b4 IRQMASK: 1 [ 172.851482] GPR00: c00000000013d5a4 c00000001768 7b00 c000000002a10600 0000000000000004 [ 172.851482] GPR04: 0000000082004000 c0000008ba08f0a8 0000000000000000 00000008b7ed0000 [ 17 2.851482 ] GPR08: 00000000446194f6 0000000000008000 c00000000013b118 c000000000d58e68 [ 172.851482] GPR12: c00000000013d390 c00000001ec54a80 0000000000000000 0000000000000000 [ 172.851482] GPR16: 0000000000000000 0000000000000000 c000000015d5c708 c0000000025396d0 [ 172.8 51482] GPR20: 0000000000000000 0000000000000000 c00000000a3bbf40 0000000000000003 [ 172.851482] GPR24: 0000000000000000 c0000008ba097 400 c0000000161e0d00 c00000000a3bb600 [ 172.851482] GPR28: c000000015d5c700 0000000000000001 0000000082384090 c0000008ba0020d8 [ 172.851549] NIP [c00000000013d600] power_pmu_disable+0x270/0x280 [ 172.851557] LR [c00000000013d5a4] able+0x214/0x280 [ 172.851565] Seguimiento de llamadas: [ 172.851568] [c000000017687b00] [c00000000013d5a4] power_pmu_disable+0x214/0x280 (no confiable) [ 172.851579] [c000000017687b40] [c0000000003403ac] perf_pmu_disable+0x4c/0x60 [ 172.851588] [c000000017687b60] [c0000000003445e4] k_sched_out+0x1d4/0x660 [ 172.851596] [c000000017687c50] [c000000000d1175c] __schedule+0xbcc/0x12a0 [ 172.851602] [c000000017687d60] 00d11ea8] programación+0x78/0x140 [ 172.851608] [c000000017687d90] [c0000000001a8080] sys_sched_yield+0x20/0x40 [ 172.851615] [c000000017687db0] 34dc] system_call_exception+0x18c/0x380 [ 172.851622] [c000000017687e10] [c00000000000c74c] system_call_common+0xec/0x268 La advertencia indica que MSR_EE se configuró (interrupción habilitada) cuando se detectó un PMC desbordado. Esto podría suceder en power_pmu_disable ya que se ejecuta bajo la condición de desactivación suave de interrupción ( local_irq_save ) y no con interrupciones desactivadas por completo. commit 2c9ac51b850d ("powerpc/perf: Fix devoluciones de llamada de PMU para borrar el PMI pendiente antes de restablecer un PMC desbordado") destinado a borrar el bit pendiente de PMI en Paca al deshabilitar la PMU. Podría suceder que PMC se desborde mientras el código está en la función de devolución de llamada power_pmu_disable. Por lo tanto, agregue una verificación para ver si el bit pendiente de PMI está configurado en Paca antes de borrarlo a través de clear_pmi_pending.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bloque: corrige la pérdida de memoria en disk_register_independent_access_ranges kobject_init_and_add() toma referencia incluso cuando falla. Según el documento de kobject_init_and_add() Si esta función devuelve un error, se debe llamar a kobject_put() para limpiar adecuadamente la memoria asociada con el objeto. Solucione este problema agregando kobject_put(). La función de devolución de llamada blk_ia_ranges_sysfs_release() en kobject_put() puede manejar el puntero "iars" correctamente.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: phylib: corrige el posible use-after-free. Commit bafbdd527d56 ("phylib: agregue soporte GPIO para restablecer el dispositivo") se agregó una llamada a phy_device_reset(phydev) después de la llamada put_device() en phy_detach( ). El comentario antes de la llamada put_device() dice que phydev podría desaparecer con put_device(). Solucione el posible use-after-free llamando a phy_device_reset() antes de put_device().

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: powerpc64/bpf: Limite 'ldbrx' a procesadores compatibles con ISA v2.06 Johan informó el siguiente fallo con test_bpf en ppc64 e5500: test_bpf: #296 ALU_END_FROM_LE 64: 0x0123456789abcdef -> 0x67452301 jited:1 Ups: Excepción en modo kernel, sign: 4 [#1] BE PAGE_SIZE=4K SMP NR_CPUS=24 Módulos QEMU e500 vinculados en: test_bpf(+) CPU: 0 PID: 76 Comm: insmod Not tainted 5.14.0- 03771-g98c2059e008a-dirty #1 NIP: 8000000000061c3c LR: 80000000006dea64 CTR: 8000000000061c18 REGS: c0000000032d3420 TRAP: 0700 No contaminado (5.14.0-0 3771-g98c2059e008a-dirty) MSR: 0000000080089000 CR: 88002822 XER: 20000000 IRQMASK : 0 <...> NIP [8000000000061c3c] 0x8000000000061c3c LR [80000000006dea64] .__run_one+0x104/0x17c [test_bpf] Seguimiento de llamadas: .__run_one+0x60/0x17c [test_bpf] (no confiable). test_bpf_init+0x6a8/0xdc8 [test_bpf] . do_one_initcall+0x6c/0x28c .do_init_module+0x68/0x28c .load_module+0x2460/0x2abc .__do_sys_init_module+0x120/0x18c .system_call_exception+0x110/0x1b8 system_call_common+0xf0/0x210 --- interrupción : c00 en 0x101d0acc <...> --- [ end trace 47b2bf19090bb3d0 ]--- Instrucción ilegal La instrucción ilegal resultó ser 'ldbrx' emitida para BPF_FROM_[L|B]E, que solo se introdujo en ISA v2.06. Proteger el uso de los mismos e implementar un enfoque alternativo para procesadores más antiguos.

En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: drm/msm/dsi: comprobación de parámetro no válido en msm_dsi_phy_enable La función realiza una comprobación del parámetro de entrada "phy", sin embargo, se utiliza antes de la comprobación. Inicialice la variable "dev" después de la verificación de cordura para evitar una posible desreferencia del puntero NULL. Direcciones-Coverity-ID: 1493860 ("Desreferencia de puntero nulo")