Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: brcmfmac: pcie: Liberar firmwares en la ruta de error brcmf_pcie_setup Esto evita la pérdida de memoria si falla brcmf_chip_get_raminfo. Tenga en cuenta que el blob CLM se libera en la ruta de eliminación del dispositivo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: exec: Forzar una sola cadena vacía cuando argv está vacío Citando[1] a Ariadne Conill: "En varios otros sistemas operativos, es un requisito estricto que el segundo argumento de execve(2) sea el nombre de un programa, lo que prohíbe un escenario donde argc < 1. POSIX 2017 también recomienda este comportamiento, pero no es un requisito explícito[2]: el argumento arg0 debe apuntar a una cadena de nombre de archivo que esté asociada con el proceso que inicia una de las funciones exec. ... Curiosamente, Michael Kerrisk abrió un problema sobre esto en 2008[3], pero no hubo consenso para apoyar la solución de este problema en ese momento. Con suerte, ahora que CVE-2021-4034 muestra un uso explotador práctico[4] de este error en un shellcode, podemos reconsiderarlo. Este problema se está rastreando en el rastreador de problemas de KSPP[5]". Si bien las búsquedas de código iniciales[6][7] dieron como resultado lo que parecían ser principalmente pruebas de casos extremos, intentar simplemente rechazar argv == NULL (o una lista de punteros terminada inmediatamente) rápidamente comenzó a hacer tropezar[8] a los programas de espacio de usuario existentes. El siguiente mejor enfoque es forzar una sola cadena vacía en argv y ajustar argc para que coincida. La cantidad de programas que dependen de argc == 0 parece un conjunto más pequeño que los que llaman a execve con un argv NULL. Tenga en cuenta el espacio de pila adicional en bprm_stack_limits(). Inyecte una cadena vacía cuando argc == 0 (y establezca argc = 1). Advertir sobre el caso para que el espacio de usuario tenga algún aviso sobre el cambio: proceso './argc0' lanzado './argc0' con argv NULL: cadena vacía agregada Además, WARN() y rechace el uso de argv NULL para subprocesos del kernel. [1] https://lore.kernel.org/lkml/20220127000724.15106-1-ariadne@dereferenced.org/ [2] https://pubs.opengroup.org/onlinepubs/9699919799/functions/exec.html [3] https://bugzilla.kernel.org/show_bug.cgi?id=8408 [4] https://www.qualys.com/2022/01/25/cve-2021-4034/pwnkit.txt [5] https://github.com/KSPP/linux/issues/176 [6] https://codesearch.debian.net/search?q=execve%5C+*%5C%28%5B%5E%2C%5D%2B%2C+*NULL&literal=0 [7] https://codesearch.debian.net/search?q=execlp%3F%5Cs*%5C%28%5B%5E%2C%5D%2B%2C%5Cs*NULL&literal=0 [8] https://lore.kernel.org/lkml/20220131144352.GE16385@xsang-OptiPlex-9020/

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: PM: dominios: Se corrige el error sleep-in-atomic causado por genpd_debug_remove() Cuando se elimina un genpd con GENPD_FLAG_IRQ_SAFE, se verá el siguiente error sleep-in-atomic, ya que se llamará a genpd_debug_remove() con un spinlock retenido. [ 0.029183] ERROR: función inactiva llamada desde un contexto no válido en kernel/locking/rwsem.c:1460 [ 0.029204] in_atomic(): 1, irqs_disabled(): 128, non_block: 0, pid: 1, name: swapper/0 [ 0.029219] preempt_count: 1, expected: 0 [ 0.029230] CPU: 1 PID: 1 Comm: swapper/0 No contaminado 5.17.0-rc4+ #489 [ 0.029245] Nombre del hardware: Thundercomm TurboX CM2290 (DT) [ 0.029256] Rastreo de llamadas: [ 0.029265] dump_backtrace.part.0+0xbc/0xd0 [ 0.029285] show_stack+0x3c/0xa0 [ 0.029298] dump_stack_lvl+0x7c/0xa0 [ 0.029311] dump_stack+0x18/0x34 [ 0.029323] __might_resched+0x10c/0x13c [ 0.029338] __might_sleep+0x4c/0x80 [ 0.029351] down_read+0x24/0xd0 [ 0.029363] lookup_one_len_unlocked+0x9c/0xcc [ 0.029379] lookup_positive_unlocked+0x10/0x50 [ 0.029392] debugfs_lookup+0x68/0xac [ 0.029406] genpd_remove.part.0+0x12c/0x1b4 [ 0.029419] of_genpd_remove_last+0xa8/0xd4 [ 0.029434] psci_cpuidle_domain_probe+0x174/0x53c [ 0.029449] platform_probe+0x68/0xe0 [ 0.029462] really_probe+0x190/0x430 [ 0.029473] __driver_probe_device+0x90/0x18c [ 0.029485] driver_probe_device+0x40/0xe0 [ 0.029497] __driver_attach+0xf4/0x1d0 [ 0.029508] bus_for_each_dev+0x70/0xd0 [ 0.029523] driver_attach+0x24/0x30 [ 0.029534] bus_add_driver+0x164/0x22c [ 0.029545] driver_register+0x78/0x130 [ 0.029556] __platform_driver_register+0x28/0x34 [ 0.029569] psci_idle_init_domains+0x1c/0x28 [ 0.029583] do_one_initcall+0x50/0x1b0 [ 0.029595] kernel_init_freeable+0x214/0x280 [ 0.029609] kernel_init+0x2c/0x13c [ 0.029622] ret_from_fork+0x10/0x200 No parece necesario llamar a genpd_debug_remove() con el bloqueo, así que sáquelo del bloqueo para solucionar el problema.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: block: fix rq-qos breakage from skipping rq_qos_done_bio() a647a524a467 ("block: don't call rq_qos_ops->done_bio if the bio isn't tracked") hizo que bio_endio() saltara rq_qos_done_bio() si BIO_TRACKED no está configurado. Si bien esto solucionó un posible error, también rompió blk-iocost al saltarse la devolución de llamada done_bio para bios fusionados. Antes, ya sea que una bio pase por rq_qos_throttle() o rq_qos_merge(), rq_qos_done_bio() se llamaría en la bio al completarse con BIO_TRACKED distinguiendo la primera de la segunda. rq_qos_done_bio() no se llama para bios que pasaron por rq_qos_merge(). Esto confunde mucho a blk-iocost, ya que las bios fusionadas nunca terminan y se consideran en constante funcionamiento. Un modo de falla reproducible de manera confiable es un cgroup intermedio que se queda bloqueado en modo activo, lo que impide que sus hijos se activen debido a la regla de solo hojas, lo que lleva a la pérdida de control. Lo siguiente es del escenario de protección de resctl-bench que emula el aislamiento de una carga de trabajo similar a la de un servidor web de una bomba de memoria ejecutada en una configuración de iocost que debería producir un nivel razonable de protección. # cat /sys/block/nvme2n1/device/model Samsung SSD 970 PRO 512GB # cat /sys/fs/cgroup/io.cost.model 259:0 ctrl=usuario model=linear rbps=834913556 rseqiops=93622 rrandiops=102913 wbps=618985353 wseqiops=72325 wrandiops=71025 # cat /sys/fs/cgroup/io.cost.qos 259:0 enable=1 ctrl=usuario rpct=95.00 rlat=18776 wpct=95.00 wlat=8897 mín=60.00 máx=100.00 # resctl-bench -m 29.6G -r out.json ejecutar protection::scenario=mem-hog,loops=1 ... Resumen de acaparadores de memoria ================== Latencia de E/S: R p50=242u:336u/2,5 m p90=794u:1,4 m/7,5 m p99=2,7 m:8,0 m/62,5 m máx.=8,0 m:36,4 m/350 m W p50=221u:323u/1,5 m p90=709u:1,2 m/5,5 m p99=1,5 m:2,5 m/9,5 m máx.=6,9 m:35,9 m/350 m Distribuciones del impacto de latencia de solicitud y aislamiento: mín. p01 p05 p10 p25 p50 p75 p90 p95 p99 máx. media desviación estándar isol% 15,90 15,90 15,90 40,05 57,24 59,07 60,01 74,63 74,63 90,35 90,35 58,12 15,82 lat-imp% 0 0 0 0 0 4,55 14,68 15,54 233,5 548,1 548,1 53,88 143,6 Resultado: isol=58,12:15,82% lat_imp=53,88%:143,6 work_csv=100,0% missing=3,96% El resultado de aislamiento de 58,12% es cercano a lo que este dispositivo mostraría sin ningún control de E/S. Arréglelo introduciendo una nueva bandera BIO_QOS_MERGED para marcar las bios fusionadas y llamando a rq_qos_done_bio() en ellas también. Para mayor coherencia y claridad, cambie el nombre de BIO_TRACKED a BIO_QOS_THROTTLED. Las comprobaciones de banderas se mueven a rq_qos_done_bio() para que estén junto a las rutas de código que establecen las banderas. Con el parche aplicado, el mismo punto de referencia anterior muestra: # resctl-bench -m 29.6G -r out.json run protection::scenario=mem-hog,loops=1 ... Resumen de acaparamiento de memoria ================== Latencia de E/S: R p50=123u:84.4u/985u p90=322u:256u/2.5m p99=1.6m:1.4m/9.5m máx.=11.1m:36.0m/350m W p50=429u:274u/995u p90=1.7m:1.3m/4.5m p99=3.4m:2.7m/11.5m máx.=7.9m:5.9m/26.5m Distribuciones de impacto de latencia de solicitud y aislamiento: min p01 p05 p10 p25 p50 p75 p90 p95 p99 media máxima desviación estándar isol% 84,91 84,91 89,51 90,73 92,31 94,49 96,36 98,04 98,71 100,0 100,0 94,42 2,81 lat-imp% 0 0 0 0 0 2,81 5,73 11,11 13,92 17,53 22,61 4,10 4,68 Resultado: isol=94,42:2,81% lat_imp=4,10%:4,68 work_csv=58,34% missing=0%

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ASoC: SOF: Intel: Se corrige la desreferencia de puntero NULL cuando ENOMEM No llame a snd_dma_free_pages() cuando snd_dma_alloc_pages() devuelve -ENOMEM porque conduce a un error de desreferencia de puntero NULL. El dmesg dice: [ T1387] sof-audio-pci-intel-tgl 0000:00:1f.3: error: falla de asignación de memoria: -12 [ T1387] ERROR: desreferencia de puntero NULL del kernel, dirección: 0000000000000000 [ T1387] #PF: acceso de lectura del supervisor en modo kernel [ T1387] #PF: error_code(0x0000) - página no presente [ T1387] PGD 0 P4D 0 [ T1387] Oops: 0000 [#1] PREEMPT SMP NOPTI [ T1387] CPU: 6 PID: 1387 Comm: alsa-sink-HDA A Tainted: GW 5.17.0-rc4-superb-owl-00055-g80d47f5de5e3 [ T1387] Nombre del hardware: HP HP Laptop 14s-dq2xxx/87FD, BIOS F.15 15/09/2021 [ T1387] RIP: 0010:dma_free_noncontiguous+0x37/0x80 [ T1387] Código: [... fragmento ...] [ T1387] RSP: 0000:ffffc90002b87770 EFLAGS: 00010246 [ T1387] RAX: 000000000000000 RBX: 0000000000000000 RCX: 0000000000000000 [ T1387] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff888101db30d0 [ T1387] RBP: 00000000ffffff4 R08: 000000000000000 R09: 000000000000000 [ T1387] R10: 000000000000000 R11: ffffc90002b874d0 R12: 000000000000001 [ T1387] R13: 0000000000058000 R14: ffff888105260c68 R15: ffff888105260828 [ T1387] FS: 00007f42e2ffd640(0000) GS:ffff888466b80000(0000) knlGS:0000000000000000 [ T1387] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ T1387] CR2: 0000000000000000 CR3: 000000014acf0003 CR4: 0000000000770ee0 [ T1387] PKRU: 55555554 [ T1387] Rastreo de llamadas: [ T1387] [ T1387] cl_stream_prepare+0x10a/0x120 [snd_sof_intel_hda_common 146addf995b9279ae7f509621078cccbe4f875e1] [... recorte ...] [ T1387]

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: can: isotp: sanitize CAN ID checks in isotp_bind() Syzbot creó un entorno que condujo a un estado de máquina de estados al que no se puede acceder con una configuración de dirección CAN ID compatible. La información de dirección proporcionada consistía en CAN ID 0x6000001 y 0xC28001, que se reducen a 11 bits CAN ID 0x001 en envío y recepción. Sanitize los valores SFF/EFF CAN ID antes de realizar las comprobaciones de dirección.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: dm: se corrige el use-after-free en dm_cleanup_zoned_dev() dm_cleanup_zoned_dev() usa cola, por lo que debe llamarse antes de que blk_cleanup_disk() comience su eliminación: blk_cleanup_disk->blk_cleanup_queue()->kobject_put()->blk_release_queue()-> ->...RCU...->blk_free_queue_rcu()->kmem_cache_free() De lo contrario, la devolución de llamada RCU se puede ejecutar primero y dm_cleanup_zoned_dev() tocará la memoria liberada: ERROR: KASAN: use-after-free en dm_cleanup_zoned_dev+0x33/0xd0 Lectura de tamaño 8 en la dirección ffff88805ac6e430 por la tarea dmsetup/681 CPU: 4 PID: 681 Comm: dmsetup No contaminado 5.17.0-rc2+ #6 Nombre del hardware: PC estándar QEMU (i440FX + PIIX, 1996), BIOS 1.14.0-2 01/04/2014 Seguimiento de llamadas: dump_stack_lvl+0x57/0x7d print_address_description.constprop.0+0x1f/0x150 ? dm_cleanup_zoned_dev+0x33/0xd0 kasan_report.cold+0x7f/0x11b ? dm_cleanup_zoned_dev+0x33/0xd0 dm_cleanup_zoned_dev+0x33/0xd0 __dm_destroy+0x26a/0x400 ? dm_blk_ioctl+0x230/0x230 ? up_write+0xd8/0x270 dev_remove+0x156/0x1d0 ctl_ioctl+0x269/0x530 ? table_clear+0x140/0x140 ? lock_release+0xb2/0x750 ? remove_all+0x40/0x40 ? rcu_read_lock_sched_held+0x12/0x70 ? lock_downgrade+0x3c0/0x3c0 ? rcu_read_lock_sched_held+0x12/0x70 dm_ctl_ioctl+0xa/0x10 __x64_sys_ioctl+0xb9/0xf0 do_syscall_64+0x3b/0x90 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7fb6dfa95c27

En el núcleo de Linux, se ha resuelto la siguiente vulnerabilidad: mmc: core: use sysfs_emit() en lugar de sprintf() sprintf() (que todavía se usa en el núcleo de MMC para la salida de sysfs) es vulnerable al desbordamiento del búfer. Use el nuevo sysfs_emit() en su lugar. Encontrado por Linux Verification Center (linuxtesting.org) con la herramienta de análisis estático SVACE.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ASoC: codecs: va-macro: se corrige el acceso a una matriz fuera de los límites para el tipo de enumeración. Acceder a enumeraciones usando números enteros daría como resultado un acceso a una matriz fuera de los límites en plataformas como aarch64, donde sizeof(long) es 8 en comparación con el tamaño de la enumeración, que es de 4 bytes.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ASoC: codecs: rx-macro: se corrige el acceso a una matriz fuera de los límites para el tipo de enumeración. Acceder a enumeraciones usando números enteros daría como resultado un acceso a una matriz fuera de los límites en plataformas como aarch64, donde sizeof(long) es 8 en comparación con el tamaño de la enumeración, que es de 4 bytes.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: media: usb: go7007: s2250-board: corrección de fuga en probe() Llamada a i2c_unregister_device(audio) en esta ruta de error.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: media: ti-vpe: cal: Se corrige una desreferencia de puntero NULL en cal_ctx_v4l2_init_formats() En cal_ctx_v4l2_init_formats(), devm_kzalloc() se asigna a ctx->active_fmt y hay una desreferencia de este después de eso, lo que podría provocar una desreferencia de puntero NULL en caso de fallo de devm_kzalloc(). Corrija este error agregando una comprobación NULL de ctx->active_fmt. Este error fue encontrado por un analizador estático. Las compilaciones con 'make allyesconfig' no muestran nuevas advertencias y nuestro analizador estático ya no advierte sobre este código.