Vulnerabilidades

En el núcleo de Linux, se ha resuelto la siguiente vulnerabilidad: can: m_can: m_can_tx_handler(): se corrige el use after free skb can_put_echo_skb() clonará skb y luego lo liberará. Mueva can_put_echo_skb() para la versión 3.0.x de m_can directamente antes del inicio de la transmisión en el hardware, de manera similar a la rama 3.1.x.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: jffs2: corregir pérdida de memoria en jffs2_scan_medium Si se devuelve un error en jffs2_scan_eraseblock() y se ha añadido algo de memoria a los *s de jffs2_summary, podemos observar el siguiente informe de kmemleak: -------------------------------------------- unreferenced object 0xffff88812b889c40 (size 64): comm "mount", pid 692, jiffies 4294838325 (age 34.288s) hex dump (first 32 bytes): 40 48 b5 14 81 88 ff ff 01 e0 31 00 00 00 50 00 @H........1...P. 00 00 01 00 00 00 01 00 00 00 02 00 00 00 09 08 ................ seguimiento inverso:[] __kmalloc+0x613/0x910 [] jffs2_sum_add_dirent_mem+0x5c/0xa0 [] jffs2_scan_medium.cold+0x36e5/0x4794 [] jffs2_do_mount_fs.cold+0xa7/0x2267 [] jffs2_do_fill_super+0x383/0xc30 [] jffs2_fill_super+0x2ea/0x4c0 [] mtd_get_sb+0x254/0x400 [] mtd_get_sb_by_nr+0x4f/0xd0 [] get_tree_mtd+0x498/0x840 [] jffs2_get_tree+0x25/0x30 [] vfs_get_tree+0x8d/0x2e0 [] path_mount+0x50f/0x1e50 [] do_mount+0x107/0x130 [] __se_sys_mount+0x1c5/0x2f0 [] __x64_sys_mount+0xc7/0x160 [] do_syscall_64+0x45/0x70 objeto sin referencia 0xffff888114b54840 (tamaño 32): comm "mount", pid 692, jiffies 4294838325 (antigüedad 34.288s) volcado hexadecimal (primeros 32 bytes): c0 75 b5 14 81 88 ff ff 02 e0 02 00 00 00 02 00 .u.............. 00 00 84 00 00 00 44 00 00 00 6b 6b 6b 6b 6b a5 ......D...kkkkk. backtrace: [] kmem_cache_alloc_trace+0x584/0x880 [] jffs2_sum_add_inode_mem+0x54/0x90 [] jffs2_scan_medium.cold+0x4481/0x4794 [...] objeto sin referencia 0xffff888114b57280 (tamaño 32): comm "mount", pid 692, jiffies 4294838393 (edad 34.357s) volcado hexadecimal (primeros 32 bytes): 10 d5 6c 11 81 88 ff ff 08 e0 05 00 00 00 01 00 ..l............. 00 00 38 02 00 00 28 00 00 00 6b 6b 6b 6b 6b a5 ..8...(...kkkkk. seguimiento inverso: [] kmem_cache_alloc_trace+0x584/0x880 [] jffs2_sum_add_xattr_mem+0x54/0x90 [] jffs2_scan_medium.cold+0x298c/0x4794 [...] objeto sin referencia 0xffff8881116cd510 (tamaño 16): comm "mount", pid 692, jiffies 4294838395 (edad 34.355s) volcado hexadecimal (primeros 16 bytes): 00 00 00 00 00 00 00 00 09 e0 60 02 00 00 6b a5 ..........`...k. backtrace: [] kmem_cache_alloc_trace+0x584/0x880 [] jffs2_sum_add_xref_mem+0x54/0x90 [] jffs2_scan_medium.cold+0x3a20/0x4794 [...] -------------------------------------------- Por lo tanto, debemos llamar a jffs2_sum_reset_collected(s) al salir para liberar la memoria agregada en s. Además, se agrega una nueva etiqueta "out_buf" para evitar la referencia de puntero NULL causada por s que es NULL. (gracias a Zhang Yi por este análisis)

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: jffs2: se corrige la pérdida de memoria en jffs2_do_mount_fs Si jffs2_build_filesystem() en jffs2_do_mount_fs() devuelve un error, podemos observar el siguiente informe de kmemleak: -------------------------------------------- objeto sin referencia 0xffff88811b25a640 (tamaño 64): comm "mount", pid 691, jiffies 4294957728 (edad 71,952 s) volcado hexadecimal (primeros 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ seguimiento inverso: [] kmem_cache_alloc_trace+0x584/0x880 [] jffs2_sum_init+0x86/0x130 [] jffs2_do_mount_fs+0x798/0xac0 [] jffs2_do_fill_super+0x383/0xc30 [] jffs2_fill_super+0x2ea/0x4c0 [...] objeto sin referencia 0xffff88812c760000 (tamaño 65536): comm "montar", pid 691, jiffies 4294957728 (edad 71,952 s) volcado hexadecimal (primeros 32 bytes): bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb ................ bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb ................ seguimiento inverso: [] __kmalloc+0x6b9/0x910 [] jffs2_sum_init+0xd7/0x130 [] jffs2_do_mount_fs+0x798/0xac0 [] jffs2_do_fill_super+0x383/0xc30 [] jffs2_fill_super+0x2ea/0x4c0 [...] -------------------------------------------- Esto se debe a que los recursos asignados en jffs2_sum_init() no se liberan. Llame a jffs2_sum_exit() para liberar estos recursos y resolver el problema.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: remoteproc: Se corrige la comprobación de recuento en rproc_coredump_write(). Se comprueba que el recuento sea 0 para evitar un posible desbordamiento. Se hace que la comprobación sea la misma que en rproc_recovery_write().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: NFSD: evitar el desbordamiento de enteros en sistemas de 32 bits. En un sistema de 32 bits, la operación "len * sizeof(*p)" puede tener un desbordamiento de enteros.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: cifs: fix handlecache y multiuser En multiuser, cada usuario individual tiene su propia estructura tcon para el recurso compartido y, por lo tanto, su propio identificador para un directorio en caché. Cuando desmontamos un recurso compartido de este tipo, debemos asegurarnos de liberar la entrada dentry fijada para cada uno de esos tcon y no solo el tcon maestro. De lo contrario, recibiremos advertencias desagradables al desmontar que indican que las dentry aún están en uso: [ 3459.590047] ERROR: Dentry 00000000115c6f41{i=12000000019d95,n=/} aún en uso\ (2) [desmontaje de cifs cifs] ... [ 3459.590492] Seguimiento de llamadas: [ 3459.590500] d_walk+0x61/0x2a0 [ 3459.590518] ? shrink_lock_dentry.part.0+0xe0/0xe0 [ 3459.590526] shrink_dcache_for_umount+0x49/0x110 [ 3459.590535] generic_shutdown_super+0x1a/0x110 [ 3459.590542] kill_anon_super+0x14/0x30 [ 3459.590549] cifs_kill_sb+0xf5/0x104 [cifs] [ 3459.590773] deactivate_locked_super+0x36/0xa0 [ 3459.590782] cleanup_mnt+0x131/0x190 [ 3459.590789] task_work_run+0x5c/0x90 [ 3459.590798] exit_to_user_mode_loop+0x151/0x160 [ 3459.590809] exit_to_user_mode_prepare+0x83/0xd0 [ 3459.590818] syscall_exit_to_user_mode+0x12/0x30 [ 3459.590828] do_syscall_64+0x48/0x90 [ 3459.590833] entry_SYSCALL_64_after_hwframe+0x44/0xae

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: NFSD: evitar desbordamiento en nfssvc_decode_writeargs() Smatch se queja: fs/nfsd/nfsxdr.c:341 nfssvc_decode_writeargs() advierte: no hay límite inferior en 'args->len' Cambie el tipo a sin signo para evitar este problema.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/i915/gem: agregar comprobación de los límites faltante en vm_access Una comprobación de los límites faltante en vm_access() puede provocar una lectura o escritura fuera de los límites en el área de memoria adyacente, ya que el atributo len no se valida antes de memcpy más adelante en la función, lo que potencialmente afecta a: [ 183.637831] ERROR: no se puede manejar la falla de página para la dirección: ffffc90000c86000 [ 183.637934] #PF: acceso de lectura de supervisor en modo kernel [ 183.637997] #PF: error_code(0x0000) - página no presente [ 183.638059] PGD 100000067 P4D 100000067 PUD 100258067 PMD 106341067 PTE 0 [ 183.638144] Oops: 0000 [#2] PREEMPT SMP NOPTI [ 183.638201] CPU: 3 PID: 1790 Comm: poc Contaminado: GD 5.17.0-rc6-ci-drm-11296+ #1 [ 183.638298] Nombre del hardware: Intel Corporation CoffeeLake Client Platform/CoffeeLake H DDR4 RVP, BIOS CNLSFWR1.R00.X208.B00.1905301319 30/05/2019 [ 183.638430] RIP: 0010:memcpy_erms+0x6/0x10 [ 183.640213] RSP: 0018:ffffc90001763d48 EFLAGS: 00010246 [ 183.641117] RAX: ffff888109c14000 RBX: ffff888111bece40 RCX: 0000000000000ffc [ 183.642029] RDX: 0000000000001000 RSI: ffffc90000c86000 RDI: ffff888109c14004 [ 183.642946] RBP: 0000000000000ffc R08: 800000000000016b R09: 0000000000000000 [ 183.643848] R10: ffffc90000c85000 R11: 0000000000000048 R12: 00000000000001000 [ 183.644742] R13: ffff888111bed190 R14: ffff888109c14000 R15: 0000000000001000 [ 183.645653] FS: 00007fe5ef807540(0000) GS:ffff88845b380000(0000) knlGS:0000000000000000 [ 183.646570] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 183.647481] CR2: ffffc90000c86000 CR3: 000000010ff02006 CR4: 00000000003706e0 [ 183.648384] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 000000000000000 [ 183.649271] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 183.650142] Seguimiento de llamadas: [ 183.650988] [ 183.651793] vm_access+0x1f0/0x2a0 [i915] [ 183.652726] __access_remote_vm+0x224/0x380 [ 183.653561] mem_rw.isra.0+0xf9/0x190 [ 183.654402] vfs_read+0x9d/0x1b0 [ 183.655238] ksys_read+0x63/0xe0 [ 183.656065] do_syscall_64+0x38/0xc0 [ 183.656882] entry_SYSCALL_64_after_hwframe+0x44/0xae [ 183.657663] RIP: 0033:0x7fe5ef725142 [ 183.659351] RSP: 002b:00007ffe1e81c7e8 EFLAGS: 00000246 ORIG_RAX: 000000000000000 [ 183.660227] RAX: ffffffffffffffda RBX: 0000557055dfb780 RCX: 00007fe5ef725142 [ 183.661104] RDX: 0000000000001000 RSI: 00007ffe1e81d880 RDI: 000000000000005 [ 183.661972] RBP: 00007ffe1e81e890 R08: 0000000000000030 R09: 0000000000000046 [ 183.662832] R10: 0000557055dfc2e0 R11: 0000000000000246 R12: 0000557055dfb1c0 [ 183.663691] R13: 00007ffe1e81e980 R14: 000000000000000 R15: 000000000000000 Cambios desde v1: - Condición if actualizada con range_overflows_t [Chris Wilson] [mauld: ordena el mensaje de confirmación y agrega Cc: estable] (seleccionado de el commit 661412e301e2ca86799aa4f400d1cf0bd38c57c6)

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: crypto: octeontx2 - eliminar la comprobación CONFIG_DM_CRYPT No se encontraron problemas al usar el controlador con dm-crypt habilitado. Por lo tanto, se puede eliminar la comprobación CONFIG_DM_CRYPT en el controlador. Esto también corrige la desreferencia del puntero NULL en la versión del controlador si CONFIG_DM_CRYPT está habilitado. ... No se puede manejar la desreferencia del puntero NULL del kernel en la dirección virtual 0000000000000008 ... Rastreo de llamadas: crypto_unregister_alg+0x68/0xfc crypto_unregister_skciphers+0x44/0x60 otx2_cpt_crypto_exit+0x100/0x1a0 otx2_cptvf_remove+0xf8/0x200 pci_device_remove+0x3c/0xd4 __device_release_driver+0x188/0x234 device_release_driver+0x2c/0x4c ...

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.