Vulnerabilidades

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: 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.

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: 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: 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: 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: um: Se corrige la lectura fuera de los límites en la configuración de LDT syscall_stub_data() espera que el parámetro data_count sea el número de longs, no bytes. ===================================================================== ERROR: KASAN: stack-out-of-bounds in syscall_stub_data+0x70/0xe0 Read of size 128 at addr 000000006411f6f0 by task swapper/1 CPU: 0 PID: 1 Comm: swapper Not tainted 5.18.0+ #18 Call Trace: show_stack.cold+0x166/0x2a7 __dump_stack+0x3a/0x43 dump_stack_lvl+0x1f/0x27 print_report.cold+0xdb/0xf81 kasan_report+0x119/0x1f0 kasan_check_range+0x3a3/0x440 memcpy+0x52/0x140 syscall_stub_data+0x70/0xe0 write_ldt_entry+0xac/0x190 init_new_ldt+0x515/0x960 init_new_context+0x2c4/0x4d0 mm_init.constprop.0+0x5ed/0x760 mm_alloc+0x118/0x170 0x60033f48 do_one_initcall+0x1d7/0x860 0x60003e7b kernel_init+0x6e/0x3d4 new_thread_handler+0x1e7/0x2c0 The buggy address belongs to stack of task swapper/1 and is located at offset 64 in frame: init_new_ldt+0x0/0x960 This frame has 2 objects: [32, 40) 'addr' [64, 80) 'desc' ==================================================================

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: phy: qcom-qmp: se corrige la pérdida del controlador de reinicio en los errores de sondeo Asegúrese de liberar el controlador de reinicio de carril en caso de un error de sondeo tardío (por ejemplo, aplazamiento de sondeo). Tenga en cuenta que debido a que el controlador de reinicio se define en devicetree en los nodos secundarios "lane", devm_reset_control_get_exclusive() no se puede usar directamente.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: phy: qcom-qmp: corrige pérdida de struct clk en errores de sonda Asegúrese de liberar la referencia del reloj de la tubería en caso de un error de sonda tardío (por ejemplo, aplazamiento de la sonda).

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: usb: dwc3: gadget: Reemplazar list_for_each_entry_safe() si se usa giveback La macro list_for_each_entry_safe() guarda el elemento actual (n) y el elemento posterior (n+1), de modo que n se pueda eliminar de forma segura sin dañar la lista. Sin embargo, al recorrer la lista y eliminar elementos usando gadget giveback, el bloqueo DWC3 se libera brevemente, lo que permite que se ejecuten otras rutinas. Existe una situación en la que, mientras se eliminan elementos de la lista cancelada usando dwc3_gadget_ep_cleanup_cancelled_requests(), la rutina de desactivación de pullup se ejecuta en paralelo (debido a la desvinculación de UDC). A medida que la rutina de limpieza elimina n, y la desactivación de pullup elimina n+1, una vez que la limpieza retoma el bloqueo DWC3, hace referencia a una solicitud que ya fue eliminada/gestionada. Con la depuración de lista habilitada, esto genera un pánico. Asegúrese de que todas las instancias de la macro se reemplacen donde se use la devolución de gadgets. Ejemplo de pila de llamadas: Thread#1: __dwc3_gadget_ep_set_halt() - CLEAR HALT -> dwc3_gadget_ep_cleanup_cancelled_requests() ->list_for_each_entry_safe() ->dwc3_gadget_giveback(n) ->dwc3_gadget_del_and_unmap_request()- n deleted[cancelled_list] ->spin_unlock ->Thread#2 executes ... ->dwc3_gadget_giveback(n+1) ->Already removed! Thread#2: dwc3_gadget_pullup() ->waiting for dwc3 spin_lock ... ->Thread#1 released lock ->dwc3_stop_active_transfers() ->dwc3_remove_requests() ->fetches n+1 item from cancelled_list (n removed by Thread#1) ->dwc3_gadget_giveback() ->dwc3_gadget_del_and_unmap_request()- n+1 deleted[cancelled_list] ->spin_unlock

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: tty: goldfish: Use tty_port_destroy() para destruir el puerto En goldfish_tty_probe(), el puerto inicializado a través de tty_port_init() debe destruirse en las rutas de error. En goldfish_tty_remove(), qtty->port también debe destruirse o, de lo contrario, podría perder recursos. Corrija lo anterior llamando a tty_port_destroy().