Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: dmaengine: Corrección del doble incremento de client_count en dma_chan_get() La primera vez que se llama a dma_chan_get() para un canal, el canal client_count se incrementa incorrectamente dos veces para los canales públicos, primero en balance_ref_count() y nuevamente antes de regresar. Esto da como resultado un recuento de clientes incorrecto que provocará que los recursos del canal no se liberen cuando deberían. Una prueba simple de carga y descarga repetida del módulo async_tx en un Dell Power Edge R7425 también muestra que esto da como resultado una advertencia de desbordamiento por debajo de kref. [ 124.329662] async_tx: api inicializada (async) [ 129.000627] async_tx: api inicializada (async) [ 130.047839] ------------[ cortar aquí ]------------ [ 130.052472] refcount_t: desbordamiento; uso después de la liberación. [ 130.057279] ADVERTENCIA: CPU: 3 PID: 19364 en lib/refcount.c:28 refcount_warn_saturate+0xba/0x110 [ 130.065811] Módulos vinculados: async_tx(-) rfkill intel_rapl_msr intel_rapl_common amd64_edac edac_mce_amd ipmi_ssif kvm_amd dcdbas kvm mgag200 drm_shmem_helper acpi_ipmi irqbypass drm_kms_helper ipmi_si syscopyarea sysfillrect rapl pcspkr ipmi_devintf sysimgblt fb_sys_fops k10temp i2c_piix4 ipmi_msghandler acpi_power_meter acpi_cpufreq vfat fat drm fuse xfs libcrc32c sd_mod t10_pi sg ahci crct10dif_pclmul libahci crc32_pclmul crc32c_intel ghash_clmulni_intel igb megaraid_sas i40e libata i2c_algo_bit ccp sp5100_tco dca dm_mirror dm_region_hash dm_log dm_mod [última descarga: async_tx] [130.117361] CPU: 3 PID: 19364 Comm: modprobe Kdump: cargado No contaminado 5.14.0-185.el9.x86_64 #1 [130.126091] Nombre del hardware: Dell Inc. PowerEdge R7425/02MJ3T, BIOS 1.18.0 17/01/2022 [ 130.133806] RIP: 0010:refcount_warn_saturate+0xba/0x110 [ 130.139041] Código: 01 01 e8 6d bd 55 00 0f 0b e9 72 9d 8a 00 80 3d 26 18 9c 01 00 75 85 48 c7 c7 f8 a3 03 9d c6 05 16 18 9c 01 01 e8 4a bd 55 00 <0f> 0b e9 4f 9d 8a 00 80 3d 01 18 9c 01 00 0f 85 5e ff ff ff 48 c7 [ 130.157807] RSP: 0018:ffffbf98898afe68 EFLAGS: 00010286 [ 130.163036] RAX: 000000000000000 RBX: ffff9da06028e598 RCX: 0000000000000000 [ 130.170172] RDX: ffff9daf9de26480 RSI: ffff9daf9de198a0 RDI: ffff9daf9de198a0 [ 130.177316] RBP: ffff9da7cddf3970 R08: 0000000000000000 R09: 00000000ffff7fff [ 130.184459] R10: ffffbf98898afd00 R11: ffffffff9d9e8c28 R12: ffff9da7cddf1970 [ 130.191596] R13: 000000000000000 R14: 000000000000000 R15: 000000000000000 [ 130.198739] FS: 00007f646435c740(0000) GS:ffff9daf9de00000(0000) knlGS:0000000000000000 [ 130.206832] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 130.212586] CR2: 00007f6463b214f0 CR3: 00000008ab98c000 CR4: 00000000003506e0 [ 130.219729] Rastreo de llamadas: [ 130.222192] [ 130.224305] dma_chan_put+0x10d/0x110 [ 130.227988] dmaengine_put+0x7a/0xa0 [ [130.231575] __do_sys_delete_module.constprop.0+0x178/0x280 [ 130.237157] ? syscall_trace_enter.constprop.0+0x145/0x1d0 [ 130.242652] do_syscall_64+0x5c/0x90 [ 130.246240] ? exc_page_fault+0x62/0x150 [ 130.250178] entry_SYSCALL_64_after_hwframe+0x63/0xcd [ 130.255243] RIP: 0033:0x7f6463a3f5ab [ 130.258830] Código: 73 01 c3 48 8b 0d 75 a8 1b 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa b8 b0 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 45 a8 1b 00 f7 d8 64 89 01 48 [ 130.277591] RSP: 002b:00007fff22f972c8 EFLAGS: 00000206 ORIG_RAX: 00000000000000b0 [ 130.285164] RAX: ffffffffffffffda RBX: 000055b6786edd40 RCX: 00007f6463a3f5ab [ 130.292303] RDX: 000000000000000 RSI: 0000000000000800 RDI: 000055b6786edda8 [ 130.299443] RBP: 000055b6786edd40 R08: 0000000000000000 R09: 0000000000000000 [ 130.306584] R10: 00007f6463b9eac0 R11: 0000000000000206 R12: 000055b6786edda8 [ 130.313731] R13: 000000000000000 R14: 000055b6786edda8 R15: 00007fff22f995f8 [ 130.320875] [ 130.323081] ---[ fin del seguimiento eff7156d56b5cf25 ]--- cat /sys/class/dma/dma0chan*/in_use obtendría un resultado incorrecto. ----truncada----

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: EDAC/highbank: Se corrige la pérdida de memoria en highbank_mc_probe(). Cuando devres_open_group() falla, devuelve -ENOMEM sin liberar la memoria asignada por edac_mc_alloc(). Se llama a edac_mc_free() en la ruta de gestión de errores para evitar una pérdida de memoria. [bp: Mensaje de confirmación de Modificación].

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm/uffd: corrección del marcador pte cuando fork() no tiene evento fork. Serie de parches "mm: Correcciones en marcadores pte". El parche 1 resuelve el informe de syzkiller de Pengfei. El parche 2 refuerza aún más los marcadores pte cuando se usan con los recientes marcadores de error de intercambio. El caso principal es que debemos conservar un marcador de error de intercambio después de fork(), para que el elemento secundario no lea una página dañada. Este parche (de 2): Al ejecutar fork(), no se garantiza que dst_vma tenga VM_UFFD_WP, incluso si src lo tiene y tiene instalado el marcador pte. La advertencia y el comentario son incorrectos. Lo correcto es heredar el marcador pte cuando sea necesario o dejar vacío el marcador pte de dst. Una vaga suposición es que esto ocurrió accidentalmente durante el parche anterior para introducir src/dst vma en este ayudante durante el desarrollo de la función uffd-wp, y probablemente cometí un error al rebasar, ya que si reemplazamos dst_vma con src_vma, la advertencia y el comentario también cobran sentido. Hugetlb hizo exactamente lo correcto aquí (copy_hugetlb_page_range()). Corrija la ruta general. Reproductor: https://github.com/xupengfe/syzkaller_logs/blob/main/221208_115556_copy_page_range/repro.c. Informe de Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=216808

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: fpga: m10bmc-sec: Corregir reversión de errores de sonda gestionar adecuadamente las reversiones de errores de sonda para evitar fugas.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: dmaengine: imx-sdma: Se corrige una posible fuga de memoria en sdma_transfer_init. Si la función sdma_load_context() falla, se libera sdma_desc, pero se olvida liberar el desc->bd asignado. Ya se ha detectado el fallo de sdma_load_context() y el registro es el siguiente: [450.699064] imx-sdma 30bd0000.dma-controller: Tiempo de espera agotado para que CH0 esté listo... En este caso, el desc->bd no se liberará sin este cambio.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: erofs/zmap.c: Se corrigió el cálculo incorrecto del desplazamiento. El desplazamiento efectivo para añadir a length se calculaba incorrectamente, lo que provocaba que iomap->length se estableciera en 0, lo que activaba un WARN_ON en iomap_iter_done(). Se corrigió y se describió en los comentarios. syzbot reportó esto como un fallo en un problema relacionado con una advertencia encontrada en iomap_iter_done(), pero no relacionada con erofs. Reproductor C: https://syzkaller.appspot.com/text?tag=ReproC&x=1037a6b2880000 Configuración del kernel: https://syzkaller.appspot.com/text?tag=KernelConfig&x=e2021a61197ebe02 Enlace del panel: https://syzkaller.appspot.com/bug?extid=a8e049cd3abd342936b6

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: perf/x86/amd: se corrige un posible desbordamiento de enteros al desplazar un entero. El desplazamiento a la izquierda de la constante entera de 32 bits 1 se evalúa mediante aritmética de 32 bits y se pasa como argumento de función de 64 bits. Si i es 32 o más, esto puede provocar un desbordamiento. Para evitarlo, utilice la macro BIT_ULL para desplazar.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: i2c: designware: usar la conversión de u64 en la multiplicación de reloj para evitar el desbordamiento. Las funciones i2c_dw_scl_lcnt() e i2c_dw_scl_hcnt() pueden experimentar un desbordamiento al depender de los valores de los parámetros dados, incluido ic_clk. Por ejemplo, en nuestro caso práctico, donde ic_clk es mayor que un millón, la multiplicación de ic_clk * 4700 resultará en un desbordamiento de 32 bits. Añada la conversión de u64 al cálculo para evitar el desbordamiento de la multiplicación y utilice la definición correspondiente para la división.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: cpufreq: CPPC: Añadir conversiones u64 para evitar desbordamientos. Los campos del objeto _CPC son valores de 32 bits sin signo. Para evitar desbordamientos al usar los valores de _CPC, añadir conversiones 'u64'.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: w1: corregir ADVERTENCIA después de llamar a w1_process() Recibí el siguiente mensaje de ADVERTENCIA al eliminar el controlador (ds2482): ------------[ cortar aquí ]------------ no llamar a operaciones de bloqueo cuando !TASK_RUNNING; estado=1 establecido en [<000000002d50bfb6>] w1_process+0x9e/0x1d0 [wire] ADVERTENCIA: CPU: 0 PID: 262 en kernel/sched/core.c:9817 __might_sleep+0x98/0xa0 CPU: 0 PID: 262 Comm: w1_bus_master1 Contaminado: GN 6.1.0-rc3+ #307 RIP: 0010:__might_sleep+0x98/0xa0 Rastreo de llamadas: exit_signals+0x6c/0x550 do_exit+0x2b4/0x17e0 kthread_exit+0x52/0x60 kthread+0x16d/0x1e0 ret_from_fork+0x1f/0x30 El estado de la tarea está establecido en TASK_INTERRUPTIBLE en bucle en w1_process(), configúrelo en TASK_RUNNING cuando salga del bucle para evitar la advertencia.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: f2fs: corrección para realizar una comprobación de cordura en i_extra_isize en is_alive() syzbot encontró un error de f2fs: ERROR: KASAN: slab-out-of-bounds en data_blkaddr fs/f2fs/f2fs.h:2891 [en línea] ERROR: KASAN: slab-out-of-bounds en is_alive fs/f2fs/gc.c:1117 [en línea] ERROR: KASAN: slab-out-of-bounds en gc_data_segment fs/f2fs/gc.c:1520 [en línea] ERROR: KASAN: slab-out-of-bounds en do_garbage_collect+0x386a/0x3df0 fs/f2fs/gc.c:1734 Lectura de tamaño 4 en la dirección ffff888076557568 por la tarea kworker/u4:3/52 CPU: 1 PID: 52 Comm: kworker/u4:3 No contaminado 6.1.0-rc4-syzkaller-00362-gfef7fd48922d #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 26/10/2022 Cola de trabajo: escritura diferida wb_workfn (flush-7:0) Rastreo de llamadas: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106 print_address_description mm/kasan/report.c:284 [inline] print_report+0x15e/0x45d mm/kasan/report.c:395 kasan_report+0xbb/0x1f0 mm/kasan/report.c:495 data_blkaddr fs/f2fs/f2fs.h:2891 [inline] is_alive fs/f2fs/gc.c:1117 [inline] gc_data_segment fs/f2fs/gc.c:1520 [inline] do_garbage_collect+0x386a/0x3df0 fs/f2fs/gc.c:1734 f2fs_gc+0x88c/0x20a0 fs/f2fs/gc.c:1831 f2fs_balance_fs+0x544/0x6b0 fs/f2fs/segment.c:410 f2fs_write_inode+0x57e/0xe20 fs/f2fs/inode.c:753 write_inode fs/fs-writeback.c:1440 [inline] __writeback_single_inode+0xcfc/0x1440 fs/fs-writeback.c:1652 writeback_sb_inodes+0x54d/0xf90 fs/fs-writeback.c:1870 wb_writeback+0x2c5/0xd70 fs/fs-writeback.c:2044 wb_do_writeback fs/fs-writeback.c:2187 [inline] wb_workfn+0x2dc/0x12f0 fs/fs-writeback.c:2227 process_one_work+0x9bf/0x1710 kernel/workqueue.c:2289 worker_thread+0x665/0x1080 kernel/workqueue.c:2436 kthread+0x2e4/0x3a0 kernel/kthread.c:376 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:306 La causa raíz es que olvidamos hacer una comprobación de cordura en .i_extra_isize en la siguiente ruta, lo que da como resultado el acceso a una dirección no válida más tarde, corríjalo. - gc_data_segment - is_alive - data_blkaddr - offset_in_addr

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: gfs2: Comprobar siempre el tamaño de los inodos en línea. Se comprueba si el tamaño de los inodos rellenos (en línea) está dentro del rango permitido al leer inodos del disco (gfs2_dinode_in()). Esto evita la corrupción en disco. Las dos comprobaciones en stuffed_readpage() y gfs2_unstuffer_page(), que simplemente truncan los datos en línea al tamaño máximo permitido, no tienen sentido y también se pueden eliminar.