Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: block, bfq: don't move oom_bfqq Nuestro informe de prueba es un UAF: [ 2073.019181] ======================================================================= [ 2073.019188] ERROR: KASAN: use-after-free en __bfq_put_async_bfqq+0xa0/0x168 [ 2073.019191] Escritura de tamaño 8 en la dirección ffff8000ccf64128 por la tarea rmmod/72584 [ 2073.019192] [ 2073.019196] CPU: 0 PID: 72584 Comm: rmmod Kdump: cargado No contaminado 4.19.90-yk #5 [ 2073.019198] Nombre del hardware: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015 [ 2073.019200] Rastreo de llamadas: [ 2073.019203] dump_backtrace+0x0/0x310 [ 2073.019206] show_stack+0x28/0x38 [ 2073.019210] dump_stack+0xec/0x15c [ 2073.019216] print_address_description+0x68/0x2d0 [ 2073.019220] kasan_report+0x238/0x2f0 [ 2073.019224] __asan_store8+0x88/0xb0 [ 2073.019229] __bfq_put_async_bfqq+0xa0/0x168 [ 2073.019233] bfq_put_async_queues+0xbc/0x208 [ 2073.019236] bfq_pd_offline+0x178/0x238 [ 2073.019240] blkcg_deactivate_policy+0x1f0/0x420 [ 2073.019244] bfq_exit_queue+0x128/0x178 [ 2073.019249] blk_mq_exit_sched+0x12c/0x160 [ 2073.019252] elevator_exit+0xc8/0xd0 [ 2073.019256] blk_exit_queue+0x50/0x88 [ 2073.019259] blk_cleanup_queue+0x228/0x3d8 [ 2073.019267] null_del_dev+0xfc/0x1e0 [null_blk] [ 2073.019274] null_exit+0x90/0x114 [null_blk] [ 2073.019278] __arm64_sys_delete_module+0x358/0x5a0 [ 2073.019282] el0_svc_common+0xc8/0x320 [ 2073.019287] el0_svc_handler+0xf8/0x160 [ 2073.019290] el0_svc+0x10/0x218 [ 2073.019291] [ 2073.019294] Asignado por la tarea 14163: [ 2073.019301] kasan_kmalloc+0xe0/0x190 [ 2073.019305] kmem_cache_alloc_node_trace+0x1cc/0x418 [ 2073.019308] bfq_pd_alloc+0x54/0x118 [ 2073.019313] blkcg_activate_policy+0x250/0x460 [ 2073.019317] bfq_create_group_hierarchy+0x38/0x110 [ 2073.019321] bfq_init_queue+0x6d0/0x948 [ 2073.019325] blk_mq_init_sched+0x1d8/0x390 [ 2073.019330] elevator_switch_mq+0x88/0x170 [ 2073.019334] elevator_switch+0x140/0x270 [ 2073.019338] elv_iosched_store+0x1a4/0x2a0 [ 2073.019342] queue_attr_store+0x90/0xe0 [ 2073.019348] sysfs_kf_write+0xa8/0xe8 [ 2073.019351] kernfs_fop_write+0x1f8/0x378 [ 2073.019359] __vfs_write+0xe0/0x360 [ 2073.019363] vfs_write+0xf0/0x270 [ 2073.019367] ksys_write+0xdc/0x1b8 [ 2073.019371] __arm64_sys_write+0x50/0x60 [ 2073.019375] el0_svc_common+0xc8/0x320 [ 2073.019380] el0_svc_handler+0xf8/0x160 [ 2073.019383] el0_svc+0x10/0x218 [ 2073.019385] [ 2073.019387] Liberado por la tarea 72584: [ 2073.019391] __kasan_slab_free+0x120/0x228 [ 2073.019394] kasan_slab_free+0x10/0x18 [ 2073.019397] kfree+0x94/0x368 [ 2073.019400] bfqg_put+0x64/0xb0 [ 2073.019404] bfqg_and_blkg_put+0x90/0xb0 [ 2073.019408] bfq_put_queue+0x220/0x228 [ 2073.019413] __bfq_put_async_bfqq+0x98/0x168 [ 2073.019416] bfq_put_async_queues+0xbc/0x208 [ 2073.019420] bfq_pd_offline+0x178/0x238 [ 2073.019424] blkcg_deactivate_policy+0x1f0/0x420 [ 2073.019429] bfq_exit_queue+0x128/0x178 [ 2073.019433] blk_mq_exit_sched+0x12c/0x160 [ 2073.019437] elevator_exit+0xc8/0xd0 [ 2073.019440] blk_exit_queue+0x50/0x88 [ 2073.019443] blk_cleanup_queue+0x228/0x3d8 [ 2073.019451] null_del_dev+0xfc/0x1e0 [null_blk] [ 2073.019459] null_exit+0x90/0x114 [null_blk] [ 2073.019462] __arm64_sys_delete_module+0x358/0x5a0 [ 2073.019467] el0_svc_common+0xc8/0x320 [ 2073.019471] el0_svc_handler+0xf8/0x160 [ 2073.019474] el0_svc+0x10/0x218 [ 2073.019475] [ 2073.019479] La dirección con errores pertenece al objeto en ffff8000ccf63f00 que pertenece al caché kmalloc-1024 de tamaño 1024 [ 2073.019484] La dirección con errores se encuentra 552 bytes dentro de la región de 1024 bytes [ffff8000ccf63f00, ffff8000ccf64300) [ 2073.019486] La dirección con errores pertenece a la página: [ 2073.019492] page:ffff7e000333d800 count:1 mapcount:0 mapping:ffff8000c0003a00 index:0x0 Compound_mapcount: 0 [ 2073.020123] flags: 0x7ffff0000008100(slab|head) [ 2073.020403] raw: 07ffff0000008100 ffff7e0003334c08 ffff7e00001f5a08 ffff8000c0003a00 [ 2073.020409] ra ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: LSM: error de protección general en legacy_parse_param El esquema habitual de gancho LSM "bail on fail" no funciona para los casos en los que un módulo de seguridad puede devolver un código de error que indica que no reconoce una entrada. En este caso particular, Smack ve una opción de montaje que reconoce y devuelve 0. Sigue una llamada a un gancho BPF, que devuelve -ENOPARAM, lo que confunde al llamador porque Smack ha procesado sus datos. El gancho SELinux devuelve incorrectamente 1 en caso de éxito. Hubo un momento en que esto era correcto, sin embargo, la expectativa actual es que devuelva 0 en caso de éxito. Esto se ha reparado.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: hns3: agregar bloqueo de lista de VLAN para proteger la lista de VLAN Al agregar una VLAN base de puerto, la VLAN de VF debe eliminarse de HW y modificar el estado de VLAN en la lista de VLAN de VF como falso. Si la tarea de periodicidad está liberando el mismo nodo, puede causar un error de "use-after-free". Este parche agrega un bloqueo de lista de VLAN para proteger la lista de VLAN.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/sched: act_ct: se corrige la fuga de referencia al cambiar de zona Al cambiar de zona o de espacio de nombres de red sin hacer una limpieza de ct en el medio, ahora se filtra una referencia a la entrada ct anterior. Esto se debe a que tcf_ct_skb_nfct_cached() devuelve falso y tcf_ct_flow_table_lookup() puede simplemente sobrescribirlo. La solución es, como la entrada ct no es reutilizable, liberarla ya en tcf_ct_skb_nfct_cached().

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.