Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: NFSv4: Se corrige el error nfs4_label no inicializado en la búsqueda de referencias. Se envía el fattr ya asignado junto con nfs4_fs_locations y se elimina el memcpy de fattr. Terminamos aumentando dos asignaciones más, pero esto soluciona un fallo como: PID: 790 TAREA: ffff88811b43c000 CPU: 0 COMANDO: "ls" #0 [ffffc90000857920] panic en ffffffff81b9bfde #1 [ffffc900008579c0] do_trap en ffffffff81023a9b #2 [ffffc90000857a10] do_error_trap en ffffffff81023b78 #3 [ffffc90000857a58] exc_stack_segment en ffffffff81be1f45 #4 [ffffc90000857a80] asm_exc_stack_segment en ffffffff81c009de #5 [ffffc90000857b08] nfs_lookup en ffffffffa0302322 [nfs] #6 [ffffc90000857b70] __lookup_slow en ffffffff813a4a5f #7 [ffffc90000857c60] walk_component en ffffffff813a86c4 #8 [ffffc90000857cb8] path_lookupat en ffffffff813a9553 #9 [ffffc90000857cf0] filename_lookup en ffffffff813ab86b

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bfq: Actualizar la información del cgroup antes de fusionar bio Cuando el proceso se migra a un cgroup diferente (o en caso de escritura diferida simplemente comienza a enviar bios asociados con un cgroup diferente) bfq_merge_bio() puede operar con información de cgroup obsoleta en bic. Por lo tanto, la bio se puede fusionar con una solicitud de un cgroup diferente o puede resultar en la fusión de bfqqs para diferentes cgroups o bfqqs de cgroups ya inactivos y causar posibles problemas de use-after-free. Solucione el problema actualizando la información del cgroup en bfq_merge_bio().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bfq: Asegúrese de que bfqg para el que estamos poniendo en cola las solicitudes esté en línea. Las BIOS en cola en el programador de E/S de BFQ se pueden asociar con un cgroup que ya estaba fuera de línea. Esto puede provocar la inserción de este bfq_group en un árbol de servicios. Pero este bfq_group se liberará tan pronto como se complete la última bio asociada con él, lo que genera problemas de use-after-free para los usuarios del árbol de servicios. Solucione el problema asegurándose de que siempre operamos en bfq_group en línea. Si el bfq_group asociado con la bio no está en línea, elegimos el primer padre en línea.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: staging: r8188eu: prevenir ->Ssid overflow en rtw_wx_set_scan() Este código tiene una verificación para prevenir el desbordamiento de lectura, pero necesita otra verificación para prevenir la escritura más allá del final de la matriz ->Ssid[].

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: dlm: fix plock invalid read Este parche corrige una lectura no válida mostrada por KASAN. Un unlock asignará un "struct plock_op" y un send_op() seguido lo anexará a una estructura de datos global send_list. En algunos casos, un dev_read() seguido lo mueve a recv_list y dev_write() lo convertirá a "struct plock_xop" y accederá a campos que solo están disponibles en esas estructuras. En este punto, se produce una lectura no válida al acceder a esos campos. Para corregir este problema, el campo "callback" se mueve a "struct plock_op" para indicar que se permite una conversión a "plock_xop" y realiza la gestión adicional de "plock_xop" si está configurado. Ejemplo de la salida de KASAN que mostró la lectura no válida: [ 2064.296453] ================================================================== [ 2064.304852] BUG: KASAN: slab-out-of-bounds in dev_write+0x52b/0x5a0 [dlm] [ 2064.306491] Read of size 8 at addr ffff88800ef227d8 by task dlm_controld/7484 [ 2064.308168] [ 2064.308575] CPU: 0 PID: 7484 Comm: dlm_controld Kdump: loaded Not tainted 5.14.0+ #9 [ 2064.310292] Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011 [ 2064.311618] Call Trace: [ 2064.312218] dump_stack_lvl+0x56/0x7b [ 2064.313150] print_address_description.constprop.8+0x21/0x150 [ 2064.314578] ? dev_write+0x52b/0x5a0 [dlm] [ 2064.315610] ? dev_write+0x52b/0x5a0 [dlm] [ 2064.316595] kasan_report.cold.14+0x7f/0x11b [ 2064.317674] ? dev_write+0x52b/0x5a0 [dlm] [ 2064.318687] dev_write+0x52b/0x5a0 [dlm] [ 2064.319629] ? dev_read+0x4a0/0x4a0 [dlm] [ 2064.320713] ? bpf_lsm_kernfs_init_security+0x10/0x10 [ 2064.321926] vfs_write+0x17e/0x930 [ 2064.322769] ? __fget_light+0x1aa/0x220 [ 2064.323753] ksys_write+0xf1/0x1c0 [ 2064.324548] ? __ia32_sys_read+0xb0/0xb0 [ 2064.325464] do_syscall_64+0x3a/0x80 [ 2064.326387] entry_SYSCALL_64_after_hwframe+0x44/0xae [ 2064.327606] RIP: 0033:0x7f807e4ba96f [ 2064.328470] Code: 89 54 24 18 48 89 74 24 10 89 7c 24 08 e8 39 87 f8 ff 48 8b 54 24 18 48 8b 74 24 10 41 89 c0 8b 7c 24 08 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 31 44 89 c7 48 89 44 24 08 e8 7c 87 f8 ff 48 [ 2064.332902] RSP: 002b:00007ffd50cfe6e0 EFLAGS: 00000293 ORIG_RAX: 0000000000000001 [ 2064.334658] RAX: ffffffffffffffda RBX: 000055cc3886eb30 RCX: 00007f807e4ba96f [ 2064.336275] RDX: 0000000000000040 RSI: 00007ffd50cfe7e0 RDI: 0000000000000010 [ 2064.337980] RBP: 00007ffd50cfe7e0 R08: 0000000000000000 R09: 0000000000000001 [ 2064.339560] R10: 000055cc3886eb30 R11: 0000000000000293 R12: 000055cc3886eb80 [ 2064.341237] R13: 000055cc3886eb00 R14: 000055cc3886f590 R15: 0000000000000001 [ 2064.342857] [ 2064.343226] Allocated by task 12438: [ 2064.344057] kasan_save_stack+0x1c/0x40 [ 2064.345079] __kasan_kmalloc+0x84/0xa0 [ 2064.345933] kmem_cache_alloc_trace+0x13b/0x220 [ 2064.346953] dlm_posix_unlock+0xec/0x720 [dlm] [ 2064.348811] do_lock_file_wait.part.32+0xca/0x1d0 [ 2064.351070] fcntl_setlk+0x281/0xbc0 [ 2064.352879] do_fcntl+0x5e4/0xfe0 [ 2064.354657] __x64_sys_fcntl+0x11f/0x170 [ 2064.356550] do_syscall_64+0x3a/0x80 [ 2064.358259] entry_SYSCALL_64_after_hwframe+0x44/0xae [ 2064.360745] [ 2064.361511] Last potentially related work creation: [ 2064.363957] kasan_save_stack+0x1c/0x40 [ 2064.365811] __kasan_record_aux_stack+0xaf/0xc0 [ 2064.368100] call_rcu+0x11b/0xf70 [ 2064.369785] dlm_process_incoming_buffer+0x47d/0xfd0 [dlm] [ 2064.372404] receive_from_sock+0x290/0x770 [dlm] [ 2064.374607] process_recv_sockets+0x32/0x40 [dlm] [ 2064.377290] process_one_work+0x9a8/0x16e0 [ 2064.379357] worker_thread+0x87/0xbf0 [ 2064.381188] kthread+0x3ac/0x490 [ 2064.383460] ret_from_fork+0x22/0x30 [ 2064.385588] [ 2064.386518] Second to last potentially related work creation: [ 2064.389219] kasan_save_stack+0x1c/0x40 [ 2064.391043] __kasan_record_aux_stack+0xaf/0xc0 [ 2064.393303] call_rcu+0x11b/0xf70 [ 2064.394885] dlm_process_incoming_buffer+0x47d/0xfd0 [dlm] [ 2064.397694] receive_from_sock+0x290/0x770 ---truncated---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ext4: se corrige bug_on en __es_tree_search Hulk Robot informó un BUG_ON: ================================================================== kernel BUG at fs/ext4/extents_status.c:199! [...] RIP: 0010:ext4_es_end fs/ext4/extents_status.c:199 [inline] RIP: 0010:__es_tree_search+0x1e0/0x260 fs/ext4/extents_status.c:217 [...] Call Trace: ext4_es_cache_extent+0x109/0x340 fs/ext4/extents_status.c:766 ext4_cache_extents+0x239/0x2e0 fs/ext4/extents.c:561 ext4_find_extent+0x6b7/0xa20 fs/ext4/extents.c:964 ext4_ext_map_blocks+0x16b/0x4b70 fs/ext4/extents.c:4384 ext4_map_blocks+0xe26/0x19f0 fs/ext4/inode.c:567 ext4_getblk+0x320/0x4c0 fs/ext4/inode.c:980 ext4_bread+0x2d/0x170 fs/ext4/inode.c:1031 ext4_quota_read+0x248/0x320 fs/ext4/super.c:6257 v2_read_header+0x78/0x110 fs/quota/quota_v2.c:63 v2_check_quota_file+0x76/0x230 fs/quota/quota_v2.c:82 vfs_load_quota_inode+0x5d1/0x1530 fs/quota/dquot.c:2368 dquot_enable+0x28a/0x330 fs/quota/dquot.c:2490 ext4_quota_enable fs/ext4/super.c:6137 [inline] ext4_enable_quotas+0x5d7/0x960 fs/ext4/super.c:6163 ext4_fill_super+0xa7c9/0xdc00 fs/ext4/super.c:4754 mount_bdev+0x2e9/0x3b0 fs/super.c:1158 mount_fs+0x4b/0x1e4 fs/super.c:1261 [...] ================================================================== Above issue may happen as follows: ------------------------------------- ext4_fill_super ext4_enable_quotas ext4_quota_enable ext4_iget __ext4_iget ext4_ext_check_inode ext4_ext_check __ext4_ext_check ext4_valid_extent_entries Check for overlapping extents does't take effect dquot_enable vfs_load_quota_inode v2_check_quota_file v2_read_header ext4_quota_read ext4_bread ext4_getblk ext4_map_blocks ext4_ext_map_blocks ext4_find_extent ext4_cache_extents ext4_es_cache_extent ext4_es_cache_extent __es_tree_search ext4_es_end BUG_ON(es->es_lblk + es->es_len < es->es_lblk) The error ext4 extents is as follows: 0af3 0300 0400 0000 00000000 extent_header 00000000 0100 0000 12000000 extent1 00000000 0100 0000 18000000 extent2 02000000 0400 0000 14000000 extent3 In the ext4_valid_extent_entries function, if prev is 0, no error is returned even if lblock<=prev.. Esto tenía como objetivo omitir la comprobación de la primera extensión, pero en la imagen de error anterior, prev=0+1-1=0 al comprobar la segunda extensión, por lo que, aunque lblock<=prev, la función no devuelve un error. Como resultado, se produce bug_ON en __es_tree_search y el sistema entra en pánico. Para resolver este problema, solo necesitamos comprobar que: 1. El lblock de la primera extensión no sea menor que 0. 2. El lblock de la siguiente extensión no sea menor que el siguiente bloque de la extensión anterior. Lo mismo se aplica a extended_idx.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ipmi:ipmb: Se corrige la pérdida de recuento de referencias en ipmi_ipmb_probe. of_parse_phandle() devuelve un puntero de nodo con el recuento de referencias incrementado; cuando termine, debemos usar of_node_put() en él. Agregue el error of_node_put() faltante para evitar la pérdida de recuento de referencias.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: block: Fix potential deadlock in blk_ia_range_sysfs_show() Cuando se lee, un atributo sysfs ya está protegido contra la eliminación con el contador de referencia activo del nodo kobject. Como resultado, en blk_ia_range_sysfs_show(), no es necesario tomar el bloqueo sysfs de la cola al leer el valor de un atributo de rango. El uso del bloqueo de cola sysfs en esta función crea una posible situación de bloqueo con la eliminación del disco, algo que un lockdep señala con un splat cuando se elimina el dispositivo: [ 760.703551] Posible escenario de bloqueo inseguro: [ 760.703551] [ 760.703554] CPU0 CPU1 [ 760.703556] ---- ---- [ 760.703558] lock(&q->sysfs_lock); [ 760.703565] lock(kn->active#385); [ 760.703573] lock(&q->sysfs_lock); [ 760.703579] lock(kn->active#385); [ 760.703587] [ 760.703587] *** DEADLOCK *** Solve this by removing the mutex_lock()/mutex_unlock() calls from blk_ia_range_sysfs_show().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ext4: se corrige la pérdida de memoria en parse_apply_sb_mount_options() Si el procesamiento de las opciones de montaje en disco falla después de que se haya asignado memoria en ext4_fs_context, por ejemplo, s_qf_names, entonces se produce una pérdida de memoria. Corrija esto llamando a ext4_fc_free() en lugar de kfree() directamente. Reproductor: mkfs.ext4 -F /dev/vdc tune2fs /dev/vdc -E mount_opts=usrjquota=file echo clear > /sys/kernel/debug/kmemleak mount /dev/vdc /vdc echo scan > /sys/kernel/debug/kmemleak sleep 5 echo scan > /sys/kernel/debug/kmemleak cat /sys/kernel/debug/kmemleak

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: seguimiento: Se corrige la posible doble liberación en create_var_ref() En create_var_ref(), se llama a init_var_ref() para inicializar los campos de la variable ref_field, que se asigna en la llamada de función anterior a create_hist_field(). La función init_var_ref() asigna los campos correspondientes, como ref_field->system, pero libera estos campos cuando la función encuentra un error. El llamador luego llama a destroy_hist_field() para realizar la gestión de errores, que libera los campos y la variable misma. Esto da como resultado una doble liberación de los campos que ya están liberados en la función anterior. Corrija esto almacenando NULL en los campos correspondientes cuando se liberan en init_var_ref().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ext4: se corrige la condición de ejecución entre ext4_write y ext4_convert_inline_data Hulk Robot informó de un BUG_ON: ================================================================== EXT4-fs error (device loop3): ext4_mb_generate_buddy:805: group 0, block bitmap and bg descriptor inconsistent: 25 vs 31513 free clusters kernel BUG at fs/ext4/ext4_jbd2.c:53! invalid opcode: 0000 [#1] SMP KASAN PTI CPU: 0 PID: 25371 Comm: syz-executor.3 Not tainted 5.10.0+ #1 RIP: 0010:ext4_put_nojournal fs/ext4/ext4_jbd2.c:53 [inline] RIP: 0010:__ext4_journal_stop+0x10e/0x110 fs/ext4/ext4_jbd2.c:116 [...] Call Trace: ext4_write_inline_data_end+0x59a/0x730 fs/ext4/inline.c:795 generic_perform_write+0x279/0x3c0 mm/filemap.c:3344 ext4_buffered_write_iter+0x2e3/0x3d0 fs/ext4/file.c:270 ext4_file_write_iter+0x30a/0x11c0 fs/ext4/file.c:520 do_iter_readv_writev+0x339/0x3c0 fs/read_write.c:732 do_iter_write+0x107/0x430 fs/read_write.c:861 vfs_writev fs/read_write.c:934 [inline] do_pwritev+0x1e5/0x380 fs/read_write.c:1031 [...] ================================================================== Above issue may happen as follows: cpu1 cpu2 __________________________|__________________________ do_pwritev vfs_writev do_iter_write ext4_file_write_iter ext4_buffered_write_iter generic_perform_write ext4_da_write_begin vfs_fallocate ext4_fallocate ext4_convert_inline_data ext4_convert_inline_data_nolock ext4_destroy_inline_data_nolock clear EXT4_STATE_MAY_INLINE_DATA ext4_map_blocks ext4_ext_map_blocks ext4_mb_new_blocks ext4_mb_regular_allocator ext4_mb_good_group_nolock ext4_mb_init_group ext4_mb_init_cache ext4_mb_generate_buddy --> error ext4_test_inode_state(inode, EXT4_STATE_MAY_INLINE_DATA) ext4_restore_inline_data set EXT4_STATE_MAY_INLINE_DATA ext4_block_write_begin ext4_da_write_end ext4_test_inode_state(inode, EXT4_STATE_MAY_INLINE_DATA) ext4_write_inline_data_end handle=NULL ext4_journal_stop(handle) __ext4_journal_stop ext4_put_nojournal(handle) ref_cnt = (unsigned long)handle BUG_ON(ref_cnt == 0) ---> BUG_ON The lock held by ext4_convert_inline_data is xattr_sem, but the lock held by generic_perform_write is i_rwsem. Therefore, the two locks can be concurrent. To solve above issue, we add inode_lock() for ext4_convert_inline_data(). At the same time, move ext4_convert_inline_data() in front of ext4_punch_hole(), remove similar handling from ext4_punch_hole().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bfq: evitar la fusión de colas con diferentes padres Puede suceder que el padre de un bfqq cambie entre el momento en que decidimos que vale la pena fusionar dos colas (y establecemos bic->stable_merge_bfqq) y el momento en que se llama a bfq_setup_merge(). Esto puede suceder, por ejemplo, porque el proceso envió IO para un cgroup diferente y, por lo tanto, bfqq se volvió a asignar como padre. Incluso puede suceder que el bfqq con el que estamos fusionando tenga un cgroup padre que ya está fuera de línea y se va a destruir, en cuyo caso la fusión puede provocar problemas de use-after-free, como: ERROR: KASAN: use-after-free in __bfq_deactivate_entity+0x9cb/0xa50 Read of size 8 at addr ffff88800693c0c0 by task runc:[2:INIT]/10544 CPU: 0 PID: 10544 Comm: runc:[2:INIT] Tainted: G E 5.15.2-0.g5fb85fd-default #1 openSUSE Tumbleweed (unreleased) f1f3b891c72369aebecd2e43e4641a6358867c70 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a-rebuilt.opensuse.org 04/01/2014 Call Trace: dump_stack_lvl+0x46/0x5a print_address_description.constprop.0+0x1f/0x140 ? __bfq_deactivate_entity+0x9cb/0xa50 kasan_report.cold+0x7f/0x11b ? __bfq_deactivate_entity+0x9cb/0xa50 __bfq_deactivate_entity+0x9cb/0xa50 ? update_curr+0x32f/0x5d0 bfq_deactivate_entity+0xa0/0x1d0 bfq_del_bfqq_busy+0x28a/0x420 ? resched_curr+0x116/0x1d0 ? bfq_requeue_bfqq+0x70/0x70 ? check_preempt_wakeup+0x52b/0xbc0 __bfq_bfqq_expire+0x1a2/0x270 bfq_bfqq_expire+0xd16/0x2160 ? try_to_wake_up+0x4ee/0x1260 ? bfq_end_wr_async_queues+0xe0/0xe0 ? _raw_write_unlock_bh+0x60/0x60 ? _raw_spin_lock_irq+0x81/0xe0 bfq_idle_slice_timer+0x109/0x280 ? bfq_dispatch_request+0x4870/0x4870 __hrtimer_run_queues+0x37d/0x700 ? enqueue_hrtimer+0x1b0/0x1b0 ? kvm_clock_get_cycles+0xd/0x10 ? ktime_get_update_offsets_now+0x6f/0x280 hrtimer_interrupt+0x2c8/0x740 Solucione el problema comprobando que el padre de los dos bfqqs que estamos fusionando en bfq_setup_merge() sea el mismo.