Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: iommu/omap: Se corrige la regresión en la sonda para la desreferencia de puntero NULL. el commit 3f6634d997db ("iommu: Use la forma correcta de recuperar iommu_ops") comenzó a activar una desreferencia de puntero NULL para algunas variantes de omap: __iommu_probe_device de probe_iommu_group+0x2c/0x38 probe_iommu_group de bus_for_each_dev+0x74/0xbc bus_for_each_dev de bus_iommu_probe+0x34/0x2e8 bus_iommu_probe de bus_set_iommu+0x80/0xc8 bus_set_iommu de omap_iommu_init+0x88/0xcc omap_iommu_init de do_one_initcall+0x44/0x24 Esto se debe a que la sonda omap iommu devuelve 0 en lugar de ERR_PTR(-ENODEV), como lo señaló Jason Gunthorpe . Parece que la regresión ya ocurrió con una confirmación anterior 6785eb9105e3 ("iommu/omap: Convertir a devoluciones de llamada de probe/release_device()") que cambió el tipo de retorno de la función y no realizó la conversión en un lugar.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: qede: confirmar que skb está asignado antes de usar qede_build_skb() supone que build_skb() siempre funciona y pasa directamente a skb_reserve(). Sin embargo, build_skb() puede fallar bajo presión de memoria. Esto da como resultado un pánico del kernel porque el skb a reservar es NULL. Agregue una verificación en caso de que build_skb() no pueda asignar y devuelva NULL. El retorno NULL se maneja correctamente en los llamadores a qede_build_skb().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drbd: Arregla cinco errores de use-after-free en get_initial_state En get_initial_state, llama a notify_initial_state_done(skb,..) si cb->args[5]==1. Si genlmsg_put() falló en notify_initial_state_done(), el skb será liberado por nlmsg_free(skb). Entonces get_initial_state saldrá y el skb liberado será utilizado por el valor de retorno skb->len, que es un error de uaf. Lo que es peor, el mismo problema va aún más allá: skb también se puede liberar en las llamadas notify_*_state_change -> notify_*_state a continuación. Por lo tanto, ocurrieron 4 errores de uaf adicionales. Mi parche permite que las funciones llamadas al problema: notify_initial_state_done y notify_*_state_change devuelvan un código de error si ocurren errores. Para que los códigos de error se puedan propagar y los errores de uaf se puedan evitar, la v2 informa una advertencia de compilación. Esta v3 corrigió esta advertencia y se compiló correctamente en mi entorno local sin advertencias adicionales. v2: https://lore.kernel.org/patchwork/patch/1435218/

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: openvswitch: fix leak of nested shares Mientras analiza acciones proporcionadas por el usuario, el módulo openvswitch puede asignar memoria dinámicamente y almacenar punteros en la copia interna de las acciones. Por lo tanto, esta memoria debe liberarse mientras se destruyen las acciones. Actualmente solo hay dos acciones de este tipo: ct() y set(). Sin embargo, hay muchas acciones que pueden contener listas anidadas de acciones y ovs_nla_free_flow_actions() simplemente las salta, perdiendo la memoria. Por ejemplo, la eliminación del flujo con las siguientes acciones provocará una pérdida de la memoria asignada por nf_ct_tmpl_alloc(): shares:clone(ct(commit),0) La acción set() no liberada también puede perder la estructura 'dst' para la información del túnel, incluidas las referencias del dispositivo. Bajo ciertas condiciones con una alta tasa de rotación del flujo, esto puede causar un problema de pérdida de memoria significativo (2 MB por segundo en el caso del reportero). El problema también es difícil de mitigar, porque el usuario no tiene control directo sobre los flujos de rutas de datos generados por OVS. Solucione eso iterando sobre todas las acciones anidadas y liberando todo lo que se necesite liberar de forma recursiva. La nueva afirmación de tiempo de compilación debería protegernos de este problema si se agregan nuevas acciones en el futuro. Desafortunadamente, el módulo openvswitch no usa NLA_F_NESTED, por lo que todos los atributos deben verificarse explícitamente. Las acciones sample() y clone() mezclan atributos adicionales en la lista de acciones proporcionada por el usuario. Eso también evita cierta generalización del código.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: lz4: arreglar LZ4_decompress_safe_partial lectura fuera de límite Cuando se realiza una descodificación parcial, es EOF si hemos llenado el búfer de salida o no podemos continuar con la lectura de un desplazamiento para la siguiente coincidencia. En algunos casos extremos, cuando los datos comprimidos están adecuadamente dañados, se producirá UAF. Como informó KASAN [1], LZ4_decompress_safe_partial puede provocar un problema de lectura fuera de límite durante la descodificación. lz4 upstream lo ha solucionado [2] y este problema se ha discutido aquí [3] anteriormente. La rutina de descompresión actual se trasladó de lz4 v1.8.3, actualizar lib/lz4 a v1.9.+ es sin duda un gran trabajo por hacer más adelante, así que será mejor que lo solucionemos primero. [1] https://lore.kernel.org/all/000000000000830d1205cf7f0477@google.com/ [2] https://github.com/lz4/lz4/commit/c5d6f8a8be3927c0bec91bcc58667a6cfad244ad# [3] https://lore.kernel.org/all/CC666AE8-4CA4-4951-B6FB-A2EFDE3AC03B@fb.com/

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: btrfs: libera la cantidad correcta de delalloc en la ruta de escritura de E/S directa. La ejecución de generic/406 provoca la siguiente ADVERTENCIA en btrfs_destroy_inode() que indica que quedan extensiones pendientes. En btrfs_get_blocks_direct_write(), reservamos extensiones pendientes temporalmente con btrfs_delalloc_reserve_metadata() (o indirectamente desde btrfs_delalloc_reserve_space()). Luego, liberamos las extensiones pendientes con btrfs_delalloc_release_extents(). Sin embargo, la "longitud" se puede modificar en el caso de COW, que libera menos extensiones pendientes de lo esperado. Arréglelo llamando a btrfs_delalloc_release_extents() para la longitud original. Para reproducir la advertencia, el sistema de archivos debe ser de 1 GiB. Está activando una escritura corta, debido a que no se puede asignar una extensión grande y, en su lugar, se asigna una más pequeña. ADVERTENCIA: CPU: 0 PID: 757 en fs/btrfs/inode.c:8848 btrfs_destroy_inode+0x1e6/0x210 [btrfs] Módulos vinculados en: btrfs blake2b_generic xor lzo_compress lzo_decompress raid6_pq zstd zstd_decompress zstd_compress xxhash zram zsmalloc CPU: 0 PID: 757 Comm: umount No contaminado 5.17.0-rc8+ #101 Nombre del hardware: PC estándar QEMU (i440FX + PIIX, 1996), BIOS d55cb5a 01/04/2014 RIP: 0010:btrfs_destroy_inode+0x1e6/0x210 [btrfs] RSP: 0018:ffffc9000327bda8 EFLAGS: 00010206 RAX: 000000000000000 RBX: ffff888100548b78 RCX: 0000000000000000 RDX: 0000000000026900 RSI: 0000000000000000 RDI: ffff888100548b78 RBP: ffff888100548940 R08: 0000000000000000 R09: ffff88810b48aba8 R10: 0000000000000001 R11: ffff8881004eb240 R12: ffff88810b48a800 R13: ffff88810b48ec08 R14: ffff88810b48ed00 R15: ffff888100490c68 FS: 00007f8549ea0b80(0000) GS:ffff888237c00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f854a09e733 CR3: 000000010a2e9003 CR4: 0000000000370eb0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 00000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Seguimiento de llamadas: destroy_inode+0x33/0x70 dispose_list+0x43/0x60 evict_inodes+0x161/0x1b0 generic_shutdown_super+0x2d/0x110 kill_anon_super+0xf/0x20 btrfs_kill_super+0xd/0x20 [btrfs] deactivate_locked_super+0x27/0x90 cleanup_mnt+0x12c/0x180 task_work_run+0x54/0x80 exit_to_user_mode_prepare+0x152/0x160 syscall_exit_to_user_mode+0x12/0x30 do_syscall_64+0x42/0x80 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7f854a000fb7

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/display: Se solucionó agregando protección FPU para dcn30_internal_validate_bw [Por qué] Se observó una falla de protección general cuando WebGL Aquarium se ejecuta durante un período prolongado. Si los registros de depuración de drm están habilitados y configurados en 0x1f, el problema se observa dentro de los 10 minutos posteriores a la ejecución. [ 100.717056] Fallo de protección general, probablemente para la dirección no canónica 0x2d33302d32323032: 0000 [#1] PREEMPT SMP NOPTI [ 100.727921] CPU: 3 PID: 1906 Comm: DrmThread Tainted: GW 5.15.30 #12 d726c6a2d6ebe5cf9223931cbca6892f916fe18b [ 100.754419] RIP: 0010:CalculateSwathWidth+0x1f7/0x44f [ 100.767109] Código: 00 00 00 f2 42 0f 11 04 f0 48 8b 85 88 00 00 00 f2 42 0f 10 04 f0 48 8b 85 98 00 00 00 f2 42 0f 11 04 f0 48 8b 45 10 0f 57 c0 42 0f 2a 04 b0 0f 57 c9 f3 43 0f 2a 0c b4 e8 8c e2 f3 ff 48 8b [ 100.781269] RSP: 0018:ffffa9230079eeb0 EFLAGS: 00010246 [ 100.812528] RAX: 2d33302d32323032 RBX: 0000000000000500RCX: 00000000000000000 [ 100.819656] RDX: 00000000000000001 RSI: ffff99deb712c49c RDI: 0000000000000000 [ 100.826781] RBP: ffffa9230079ef50 R08: ffff99deb712460c R09: ffff99deb712462c [ 100.833907] R10: ffff99deb7124940 R11: ffff99deb7124d70 R12: ffff99deb712ae44 [ 100.841033] R13: 00000000000000001 R14: 00000000000000000 R15: ffffa9230079f0a0 [ 100.848159] FS: 00007af121212640(0000) GS:ffff99deba780000(0000) knlGS:0000000000000000 [ 100.856240] CS: 0010 DS: 0000 ES: 0000 CR0: 000000080050033 [ 100.861980] CR2: 0000209000fe1000 CR3: 000000011b18c000 CR4: 0000000000350ee0 [ 100.869106] Seguimiento de llamadas: [ 100.871555] [ 100.873655] ? asm_sysvec_reschedule_ipi+0x12/0x20 [ 100.878449] CalculateSwathAndDETConfiguration+0x1a3/0x6dd [ 100.883937] dml31_ModeSupportAndSystemConfigurationFull+0x2ce4/0x76da [ 100.890467] ? kallsyms_lookup_buildid+0xc8/0x163 [ 100.895173] ? kallsyms_lookup_buildid+0xc8/0x163 [ 100.899874] ? __sprint_symbol+0x80/0x135 [ 100.903883] ? dm_update_plane_state+0x3f9/0x4d2 [ 100.908500] ? symbol_string+0xb7/0xde [ 100.912250] ? number+0x145/0x29b [ 100.915566] ? vsnprintf+0x341/0x5ff [ 100.919141] ? desc_read_finalized_seq+0x39/0x87 [ 100.923755] ? update_load_avg+0x1b9/0x607 [ 100.927849] ? compute_mst_dsc_configs_for_state+0x7d/0xd5b [ 100.933416] ? fetch_pipe_params+0xa4d/0xd0c [ 100.937686] ? dc_fpu_end+0x3d/0xa8 [ 100.941175] dml_get_voltage_level+0x16b/0x180 [ 100.945619] dcn30_internal_validate_bw+0x10e/0x89b [ 100.950495] ? dcn31_validate_bandwidth+0x68/0x1fc [ 100.955285] ? resource_build_scaling_params+0x98b/0xb8c [ 100.960595] ? dcn31_validate_bandwidth+0x68/0x1fc [ 100.965384] dcn31_validate_bandwidth+0x9a/0x1fc [ 100.970001] dc_validate_global_state+0x238/0x295 [ 100.974703] amdgpu_dm_atomic_check+0x9c1/0xbce [ 100.979235] ? _printk+0x59/0x73 [ 100.982467] drm_atomic_check_only+0x403/0x78b [ 100.986912] drm_mode_atomic_ioctl+0x49b/0x546 [ 100.991358] ? drm_ioctl+0x1c1/0x3b3 [ 100.994936] ? drm_atomic_set_property+0x92a/0x92a [ 100.999725] drm_ioctl_kernel+0xdc/0x149 [ 101.003648] drm_ioctl+0x27f/0x3b3 [ 101.007051] ? drm_atomic_set_property+0x92a/0x92a [ 101.011842] amdgpu_drm_ioctl+0x49/0x7d [ 101.015679] __se_sys_ioctl+0x7c/0xb8 [ 101.015685] do_syscall_64+0x5f/0xb8 [ 101.015690] ? __irq_exit_rcu+0x34/0x96 [Cómo] Se llama populate_dml_pipes, que utiliza dobles para inicializar. Agregar protección FPU evita el cambio de contexto y la probable pérdida del contexto de VBA, ya que existe una posible contención mientras los registros de depuración de DRM están habilitados.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: fbdev: Se corrige la anulación del registro de los framebuffers sin dispositivo. Los framebuffers OF no tienen un dispositivo subyacente en la jerarquía de dispositivos de Linux. Se realiza una llamada de anulación del registro normal en lugar de desconectar en caliente un dispositivo inexistente. Se corrige una desreferencia NULL. A continuación se muestra un mensaje de error de ejemplo en ppc64le. ERROR: Desreferencia de puntero NULL del kernel en lectura en 0x00000060 Dirección de instrucción con error: 0xc00000000080dfa4 Oops: Acceso del kernel al área defectuosa, firma: 11 [#1] LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA pSeries [...] CPU: 2 PID: 139 Comm: systemd-udevd No contaminado 5.17.0-ae085d7f9365 #1 NIP: c00000000080dfa4 LR: c00000000080df9c CTR: c000000000797430 REGS: c000000004132fe0 TRAP: 0300 No contaminado (5.17.0-ae085d7f9365) MSR: 8000000002009033 CR: 28228282 XER: 20000000 CFAR: c00000000000c80c DAR: 0000000000000060 DSISR: 40000000 IRQMASK: 0 GPR00: c00000000080df9c c000000004133280 c00000000169d200 0000000000000029 GPR04: 00000000fffffff c000000004132f90 c000000004132f88 00000000000000000 GPR08: c0000000015658f8 c0000000015cd200 c0000000014f57d0 0000000048228283 GPR12: 000000000000000 c0000003fffe300 000000002000000 000000000000000 GPR16: 000000000000000 0000000113fc4a40 000000000000005 0000000113fcfb80 GPR20: 000001000f7283b0 0000000000000000 c000000000e4a588 c000000000e4a5b0 GPR24: 0000000000000001 00000000000a000 c008000000db0168 c0000000021f6ec0 GPR28: c0000000016d65a8 c000000004b36460 000000000000000 c0000000016d64b0 PIP [c00000000080dfa4] do_remove_conflicting_framebuffers+0x184/0x1d0 [c000000004133280] [c00000000080df9c] do_remove_conflicting_framebuffers+0x17c/0x1d0 (no confiable) [c000000004133350] [c00000000080e4d0] remove_conflicting_framebuffers+0x60/0x150 [c0000000041333a0] [c00000000080e6f4] remove_conflicting_pci_framebuffers+0x134/0x1b0 [c000000004133450] [c008000000e70438] drm_aperture_remove_conflicting_pci_framebuffers+0x90/0x100 [drm] [c000000004133490] [c008000000da0ce4] bochs_pci_probe+0x6c/0xa64 [bochs] [...] [c000000004133db0] [c00000000002aaa0] system_call_exception+0x170/0x2d0 [c000000004133e10] [c00000000000c3cc] system_call_common+0xec/0x250 El error [1] fue introducido por el commit 27599aacbaef ("fbdev: Desconexión en caliente dispositivos fb de firmware en caso de eliminación forzada"). La mayoría de los framebuffers de firmware tienen un dispositivo de plataforma subyacente, que se puede desconectar en caliente antes de cargar el controlador de gráficos nativo. Los framebuffers de OF no tienen (todavía) ese dispositivo. Corrija el código anulando el registro del framebuffer como antes sin una desconexión en caliente. Probado con 5.17 en emulación qemu ppc64le.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/panel: ili9341: se corrige la gestión del regulador opcional. Si la búsqueda del regulador opcional falla, restablece el puntero a NULL. Otras funciones como mipi_dbi_poweron_reset_conditional() solo realizan una verificación del puntero NULL y, de lo contrario, desreferenciarán el puntero de error.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: gpio: Restringir el uso de los miembros IRQ del chip GPIO antes de la inicialización Los miembros IRQ del chip GPIO quedan expuestos antes de que se puedan inicializar por completo y esto genera condiciones de ejecución. Se observó un problema de este tipo para la variable gc->irq.domain, a la que se accedía a través de la interfaz I2C en gpiochip_to_irq() antes de que pudiera inicializarse mediante gpiochip_add_irqchip(). Esto provocaba la desreferencia del puntero NULL del kernel. A continuación se muestran los registros de referencia: kernel: Seguimiento de llamadas: kernel: gpiod_to_irq+0x53/0x70 kernel: acpi_dev_gpio_irq_get_by+0x113/0x1f0 kernel: i2c_acpi_get_irq+0xc0/0xd0 kernel: i2c_device_probe+0x28a/0x2a0 kernel: really_probe+0xf2/0x460 kernel: RIP: 0010:gpiochip_to_irq+0x47/0xc0 Para evitar tales escenarios, restrinja el uso de los miembros irq del chip GPIO antes de que se inicialicen por completo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ata: sata_dwc_460ex: Se corrige un fallo debido a que el controlador usa valores de "etiqueta" de libata en varias matrices debido a que la corrección mencionada aumentó ATA_TAG_INTERNAL a 32. Por lo tanto, el valor de SATA_DWC_QCMD_MAX debe tenerlo en cuenta. De lo contrario, el uso de ATA_TAG_INTERNAL causa fallos similares a este, según lo informado por Tice Rex en el foro OpenWrt y reproducido (con símbolos) aquí: | ERROR: Desreferencia de puntero NULL del kernel en 0x00000000 | Dirección de instrucción con error: 0xc03ed4b8 | Vaya: Acceso del kernel a un área incorrecta, firma: 11 [#1] | BE PAGE_SIZE=4K PowerPC 44x Platform | CPU: 0 PID: 362 Comm: scsi_eh_1 No contaminado 5.4.163 #0 | NIP: c03ed4b8 LR: c03d27e8 CTR: c03ed36c | REGS: cfa59950 TRAP: 0300 No contaminado (5.4.163) | MSR: 00021000 CR: 42000222 XER: 00000000 | DEAR: 00000000 ESR: 00000000 | GPR00: c03d27e8 cfa59a08 cfa55fe0 00000000 0fa46bc0 [...] | [..] | Rastreo de llamadas: | [cfa59a08] [c003f4e0] __cancel_work_timer+0x124/0x194 (no confiable) | [cfa59a78] [c03d27e8] ata_qc_issue+0x1c8/0x2dc | [cfa59a98] [c03d2b3c] ata_exec_internal_sg+0x240/0x524 | [cfa59b08] [c03d2e98] ata_exec_internal+0x78/0xe0 | [cfa59b58] [c03d30fc] ata_read_log_page.part.38+0x1dc/0x204 | [cfa59bc8] [c03d324c] ata_identify_page_supported+0x68/0x130 | [...] Esto se debe a que sata_dwc_dma_xfer_complete() convierte en NULL el próximo vecino "chan" de dma_pending (una estructura *dma_chan) en este caso '32' aquí mismo (línea ~735): > hsdevp->dma_pending[tag] = SATA_DWC_DMA_PENDING_NONE; Luego, la próxima vez que se emite un dma; dma_dwc_xfer_setup() pasa el hsdevp->chan convertido en NULL a dmaengine_slave_config() que luego causa el bloqueo. Con este parche, SATA_DWC_QCMD_MAX ahora está configurado en ATA_MAX_QUEUE + 1. Esto evita el OOB. Pero tenga en cuenta que hubo una discusión valiosa sobre qué son ATA_TAG_INTERNAL y ATA_MAX_QUEUE. Y por qué no debería haber un tamaño de cola "falso" de 33 comandos. Idealmente, el controlador dw debería tener en cuenta ATA_TAG_INTERNAL. En palabras de Damien Le Moal: "... después de observar el controlador, es un cambio más grande que simplemente falsificar una "etiqueta" número 33 que, de hecho, no es una etiqueta de comando en absoluto". Enlace de error: https://github.com/openwrt/openwrt/issues/9505

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: irqchip/gic-v3: Corregir sondeo de GICR_CTLR.RWP Resulta que nuestro sondeo de RWP es totalmente erróneo al comprobarlo en los redistribuidores, ya que probamos el índice de bits del *distribuidor*, mientras que es un número de bit diferente en los RD... Uy, buu. Esto es vergonzoso. No solo porque es incorrecto, sino también porque tardaron *8 años* en darse cuenta del error... Simplemente arreglen la maldita cosa.