Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: sparx5: switchdev: se corrige la posible desreferencia de puntero NULL. Como es posible que la asignación falle, devm_kzalloc() puede devolver un puntero NULL. Por lo tanto, es mejor comprobar la 'db' para evitar la desreferencia de puntero NULL.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: pinctrl: nomadik: se agrega la función of_node_put() faltante en nmk_pinctrl_probe. Este puntero de nodo es devuelto por of_parse_phandle() con refcount incrementado en esta función. Se llama a of_node_put() para evitar la fuga de refcount.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: clk: visconti: evitar desbordamiento de matriz en visconti_clk_register_gates() Este código usaba -1 para representar que no había una función de reinicio. Desafortunadamente, el -1 se almacenaba en u8, por lo que la condición if (clks[i].rs_id >= 0) siempre era verdadera. Esto provocó un acceso fuera de los límites en visconti_clk_register_gates().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: clk: Arreglar clk_hw_get_clk() cuando dev es NULL Cualquier estructura clk_core registrada puede tener un puntero NULL en su campo dev. Si bien nunca se documentó realmente, esto se evidencia por el amplio uso de clk_register y clk_hw_register con un puntero de dispositivo NULL, y el hecho de que la función principal of_clk_hw_register() también pasa un puntero de dispositivo NULL. Una llamada a clk_hw_get_clk() en una estructura clk_hw cuyo clk_core está en ese caso dará como resultado una desreferencia de puntero NULL cuando llame a dev_name() en ese puntero de dispositivo NULL. Agregue una prueba para este caso y use NULL como dev_id si el puntero del dispositivo es NULL.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: remoteproc: qcom_q6v5_mss: Corrige algunas fugas en q6v5_alloc_memory_region El puntero device_node es devuelto por of_parse_phandle() o of_get_child_by_name() con refcount incrementado. Deberíamos usar of_node_put() en él cuando haya terminado. Esta función solo llama a of_node_put(node) cuando of_address_to_resource tiene éxito, omitiendo los casos de error.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: clk: qcom: clk-rcg2: Actualizar la lógica para calcular el valor D para RCG El reloj de píxeles de la pantalla tiene un requisito en ciertas plataformas más nuevas para admitir M/N como (2/3) y el valor D final calculado da como resultado errores de desbordamiento. Como la implementación actual no verifica que el valor D esté dentro del rango aceptado para un valor M & N dado. Actualice la lógica para calcular el valor D final según el rango.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: f2fs: usar spin_lock para evitar que se cuelgue [14696.634553] task:cat state:D stack: 0 pid:1613738 ppid:1613735 flags:0x00000004 [14696.638285] Seguimiento de llamadas: [14696.639038] [14696.640032] __schedule+0x302/0x930 [14696.640969] schedule+0x58/0xd0 [14696.641799] schedule_preempt_disabled+0x18/0x30 [14696.642890] __mutex_lock.constprop.0+0x2fb/0x4f0 [14696.644035] ? mod_objcg_state+0x10c/0x310 [14696.645040] ? obj_cgroup_charge+0xe1/0x170 [14696.646067] __mutex_lock_slowpath+0x13/0x20 [14696.647126] mutex_lock+0x34/0x40 [14696.648070] stat_show+0x25/0x17c0 [f2fs] [14696.649218] seq_read_iter+0x120/0x4b0 [14696.650289] ? aa_file_perm+0x12a/0x500 [14696.651357] ? lru_cache_add+0x1c/0x20 [14696.652470] seq_read+0xfd/0x140 [14696.653445] full_proxy_read+0x5c/0x80 [14696.654535] vfs_read+0xa0/0x1a0 [14696.655497] ksys_read+0x67/0xe0 [14696.656502] __x64_sys_read+0x1a/0x20 [14696.657580] do_syscall_64+0x3b/0xc0 [14696.658671] entry_SYSCALL_64_after_hwframe+0x44/0xae [14696.660068] RIP: 0033:0x7efe39df1cb2 [14696.661133] RSP: 002b:00007ffc8badd948 EFLAGS: 00000246 ORIG_RAX: 000000000000000 [14696.662958] RAX: ffffffffffffffda RBX: 0000000000020000 RCX: 00007efe39df1cb2 [14696.664757] RDX: 0000000000020000 RSI: 00007efe399df000 RDI: 0000000000000003 [14696.666542] RBP: 00007efe399df000 R08: 00007efe399de010 R09: 00007efe399de010 [14696.668363] R10: 0000000000000022 R11: 0000000000000246 R12: 0000000000000000 [14696.670155] R13: 000000000000003 R14: 0000000000020000 R15: 0000000000020000 [14696.671965] [14696.672826] tarea: desmontaje estado: D pila: 0 pid: 1614985 ppid: 1614984 indicadores: 0x00004000 [14696.674930] Seguimiento de llamadas: [14696.675903] [14696.676780] __schedule+0x302/0x930 [14696.677927] schedule+0x58/0xd0 [14696.679019] schedule_preempt_disabled+0x18/0x30 [14696.680412] __mutex_lock.constprop.0+0x2fb/0x4f0 [14696.681783] ? destroy_inode+0x65/0x80 [14696.683006] __mutex_lock_slowpath+0x13/0x20 [14696.684305] mutex_lock+0x34/0x40 [14696.685442] f2fs_destroy_stats+0x1e/0x60 [f2fs] [14696.686803] f2fs_put_super+0x158/0x390 [f2fs] [14696.688238] generic_shutdown_super+0x7a/0x120 [14696.689621] kill_block_super+0x27/0x50 [14696.690894] kill_f2fs_super+0x7f/0x100 [f2fs] [14696.692311] deactivate_locked_super+0x35/0xa0 [14696.693698] deactivate_super+0x40/0x50 [14696.694985] cleanup_mnt+0x139/0x190 [14696.696209] __cleanup_mnt+0x12/0x20 [14696.697390] task_work_run+0x64/0xa0 [14696.698587] exit_to_user_mode_prepare+0x1b7/0x1c0 [14696.700053] syscall_exit_to_user_mode+0x27/0x50 [14696.701418] do_syscall_64+0x48/0xc0 [14696.702630] entry_SYSCALL_64_after_hwframe+0x44/0xae

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: f2fs: corrección para realizar una comprobación de cordura en curseg->alloc_type Como informó Wenqing Liu en bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=215657 - Descripción general UBSAN: array-index-out-of-bounds en fs/f2fs/segment.c:3460:2 cuando se monta y opera una imagen dañada - Reproducir probado en kernel 5.17-rc4, 5.17-rc6 1. mkdir test_crash 2. cd test_crash 3. unzip tmp2.zip 4. mkdir mnt 5. ./single_test.sh f2fs 2 - Volcado de kernel [ 46.434454] loop0: se detectó un cambio de capacidad de 0 a 131072 [ 46.529839] F2FS-fs (loop0): montado con la versión de punto de control = 7548c2d9 [ 46.738319] ===================================================================================== [ 46.738412] UBSAN: índice de matriz fuera de los límites en fs/f2fs/segment.c:3460:2 [ 46.738475] el índice 231 está fuera de rango para el tipo 'unsigned int [2]' [ 46.738539] CPU: 2 PID: 939 Comm: umount No contaminado 5.17.0-rc6 #1 [ [46.738547] Nombre del hardware: PC estándar QEMU (Q35 + ICH9, 2009), BIOS 1.13.0-1ubuntu1.1 01/04/2014 [ 46.738551] Seguimiento de llamadas: [ 46.738556] [ 46.738563] dump_stack_lvl+0x47/0x5c [ 46.738581] ubsan_epilogue+0x5/0x50 [ 46.738592] __ubsan_handle_out_of_bounds+0x68/0x80 [ 46.738604] f2fs_allocate_data_block+0xdff/0xe60 [f2fs] [ 46.738819] do_write_page+0xef/0x210 [f2fs] [ 46.738934] f2fs_do_write_node_page+0x3f/0x80 [f2fs] [ 46.739038] __write_node_page+0x2b7/0x920 [f2fs] [ 46.739162] f2fs_sync_node_pages+0x943/0xb00 [f2fs] [ 46.739293] f2fs_write_checkpoint+0x7bb/0x1030 [f2fs] [ 46.739405] kill_f2fs_super+0x125/0x150 [f2fs] [ 46.739507] deactivate_locked_super+0x60/0xc0 [ 46.739517] deactivate_super+0x70/0xb0 [ 46.739524] cleanup_mnt+0x11a/0x200 [ 46.739532] __cleanup_mnt+0x16/0x20 [ 46.739538] task_work_run+0x67/0xa0 [ 46.739547] exit_to_user_mode_prepare+0x18c/0x1a0 [ 46.739559] syscall_exit_to_user_mode+0x26/0x40 [ 46.739568] do_syscall_64+0x46/0xb0 [ 46.739584] entry_SYSCALL_64_after_hwframe+0x44/0xae La causa raíz es que olvidamos realizar una verificación de integridad en curseg->alloc_type, lo que da como resultado un acceso fuera de los límites en la matriz sbi->block_count[], corríjalo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ext4: no generar ERRORES si alguien ensucia páginas sin preguntar primero a ext4 [un]pin_user_pages_remote está ensuciando páginas sin advertir adecuadamente al sistema de archivos con anticipación. Jan Kara notó una ejecución relacionada en 2018[1]; sin embargo, más recientemente, en lugar de ser una ejecución muy difícil de alcanzar, podría ser activada de manera confiable por process_vm_writev(2) que fue descubierto por Syzbot[2]. Técnicamente, esto es un error en mm/gup.c, pero podría decirse que ext4 es frágil en el sentido de que si algún otro subsistema del kernel ensucia páginas sin notificar adecuadamente al sistema de archivos usando page_mkwrite(), ext4 generará ERRORES, mientras que otros sistemas de archivos no generarán ERRORES (aunque aún se perderán datos). Entonces, en lugar de bloquearse con un ERROR, emita una advertencia (ya que puede haber una posible pérdida de datos) y simplemente marque la página como limpia para evitar ataques de denegación de servicio sin privilegios hasta que el problema pueda solucionarse correctamente. Se puede encontrar más discusión y antecedentes en el hilo que comienza en [2]. [1] https://lore.kernel.org/linux-mm/20180103100430.GE4911@quack2.suse.cz [2] https://lore.kernel.org/r/Yg0m6IjcNmfaSokM@google.com

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: parisc: Se corrigen los fallos de vaciado de caché TLB de datos sin acceso Cuando una página no está presente, obtenemos fallos de TLB de datos sin acceso de las instrucciones fdc y fic en flush_user_dcache_range_asm y flush_user_icache_range_asm. Cuando esto ocurre, la línea de caché no se invalida y potencialmente obtenemos corrupción de memoria. El problema estaba oculto por la anulación de las instrucciones de vaciado. Estos fallos también afectan el rendimiento. Con los procesadores pa8800/pa8900, habrá 32 fallos por página de 4 KB ya que la línea de caché es de 128 bytes. Habrá más fallos con procesadores anteriores. El problema se soluciona utilizando flush_cache_pages(). Realiza el vaciado utilizando una asignación de alias tmp. La llamada flush_cache_pages() en flush_cache_range() vació un rango demasiado grande. V2: Eliminar las llamadas preempt_disable() y preempt_enable() innecesarias.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: spi: fsi: Implementar un tiempo de espera para sondear el estado Las rutinas de transferencia de datos deben sondear el registro de estado para determinar cuándo se pueden introducir o sacar más datos. Si el hardware entra en un mal estado, estos bucles de sondeo pueden no salir nunca. Evite esto devolviendo un error si se excede un tiempo de espera.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ext4: reparar ext4_mb_mark_bb() con flex_bg con fast_commit En el caso de la característica flex_bg (que está habilitada por defecto), las extensiones para cualquier inodo dado pueden abarcar bloques de dos grupos de bloques diferentes. ext4_mb_mark_bb() solo lee el buffer_head del mapa de bits del bloque una vez para el grupo de bloques de inicio, pero no puede leerlo de nuevo cuando el límite de longitud de la extensión se desborda a otro grupo de bloques. Luego, en este bucle a continuación, accede a la memoria más allá del mapa de bits del grupo de bloques buffer_head y da como resultado una interrupción de datos. for (i = 0; i < clen; i++) if (!mb_test_bit(blkoff + i, bitmap_bh->b_data) == !state) Already++; Este parche agrega esta funcionalidad para verificar el límite del grupo de bloques en ext4_mb_mark_bb() y actualizar el buffer_head(bitmap_bh) para cada grupo de bloques diferente. Sin este parche, pude lograr fácilmente un aborto de acceso a datos usando la plataforma Power. <...> [ 74.327662] Error EXT4-fs (dispositivo loop3): ext4_mb_generate_buddy:1141: grupo 11, mapa de bits de bloque y descriptor de fondo inconsistentes: 21248 vs 23294 clústeres libres [ 74.533214] EXT4-fs (loop3): apagado solicitado (2) [ 74.536705] Abortando diario en dispositivo loop3-8. [ 74.702705] ERROR: No se puede manejar el acceso a los datos del núcleo en lectura en 0xc00000005e980000 [ 74.703727] Dirección de instrucción con fallo: 0xc0000000007bffb8 cpu 0xd: Vector: 300 (Acceso a datos) en [c000000015db7060] pc: c0000000007bffb8: ext4_mb_mark_bb+0x198/0x5a0 lr: c0000000007bfeec: ext4_mb_mark_bb+0xcc/0x5a0 sp: c000000015db7300 msr: 800000000280b033 dar: c00000005e980000 dsisr: 40000000 actual = 0xc000000027af6880 paca = 0xc00000003ffd5200 irqmask: 0x03 irq_happened: 0x01 pid = 5167, comm = mount <...> ingresar ? para ayuda [c000000015db7380] c000000000782708 ext4_ext_clear_bb+0x378/0x410 [c000000015db7400] c000000000813f14 ext4_fc_replay+0x1794/0x2000 [c000000015db7580] c000000000833f7c do_one_pass+0xe9c/0x12a0 [c000000015db7710] c000000000834504 jbd2_journal_recover+0x184/0x2d0 [c000000015db77c0] c000000000841398 jbd2_journal_load+0x188/0x4a0 [c000000015db7880] c000000000804de8 ext4_fill_super+0x2638/0x3e10 [c000000015db7a40] c0000000005f8404 get_tree_bdev+0x2b4/0x350 [c000000015db7ae0] c0000000007ef058 ext4_get_tree+0x28/0x40 [c000000015db7b00] c0000000005f6344 vfs_get_tree+0x44/0x100 [c000000015db7b70] c00000000063c408 path_mount+0xdd8/0xe70 [c000000015db7c40] c00000000063c8f0 sys_mount+0x450/0x550 [c000000015db7d50] c000000000035770 system_call_exception+0x4a0/0x4e0 [c000000015db7e10] c00000000000c74c system_call_common+0xec/0x250