Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: openvswitch: corrige la lectura OOB de la pila al fragmentar paquetes IPv4 al ejecutar openvswitch en kernels creados con KASAN, es posible ver el siguiente símbolo al probar la fragmentación de paquetes IPv4: ERROR: KASAN: stack- fuera de los límites en ip_do_fragment+0x1b03/0x1f60 Lectura de tamaño 1 en la dirección ffff888112fc713c por task handler2/1367 CPU: 0 PID: 1367 Comm: handler2 Not tainted 5.12.0-rc6+ #418 Nombre de hardware: Red Hat KVM, BIOS 1.11 .1-4.module+el8.1.0+4066+0f1aadab 01/04/2014 Seguimiento de llamadas: dump_stack+0x92/0xc1 print_address_description.constprop.7+0x1a/0x150 kasan_report.cold.13+0x7f/0x111 ip_do_fragment+0x1b03/0x1f60 ovs_fragment+0x5bf/0x840 [openvswitch] do_execute_actions+0x1bd5/0x2400 [openvswitch] ovs_execute_actions+0xc8/0x3d0 [openvswitch] ovs_packet_cmd_execute+0xa39/0x1150 [openvswitch] genl_family_rcv_msg_do it.isra.15+0x227/0x2d0 genl_rcv_msg+0x287/0x490 netlink_rcv_skb+0x120/ 0x380 genl_rcv+0x24/0x40 netlink_unicast+0x439/0x630 netlink_sendmsg+0x719/0xbf0 sock_sendmsg+0xe2/0x110 ____sys_sendmsg+0x5ba/0x890 ___sys_sendmsg+0xe9/0x160 __sy s_sendmsg+0xd3/0x170 do_syscall_64+0x33/0x40 Entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033: 0x7f957079db07 Código: c3 66 90 41 54 41 89 d4 55 48 89 f5 53 89 fb 48 83 ec 10 e8 eb ec ff ff 44 89 e2 48 89 ee 89 df 41 89 c0 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 35 44 89 c7 48 89 44 24 08 e8 24 ed ff ff 48 RSP: 002b:00007f956ce35a50 EFLAGS: 00000293 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RB X: 0000000000000019 RCX: 00007f957079db07 RDX: 0000000000000000 RSI: 00007f956ce35ae0 RDI: 0000000000000019 RBP: 00007f956ce35ae0 R08: 00000000000000000 R09: 00007f9558006730 R10: 0000000000000000 R11: 00000000000000293 R12: 0000000000000000 R13: 00007f956ce37308 R14: 00007f956ce35f80 R15: 00007f956ce35ae0 La dirección del error pertenece a la página: página:00000000af2a1d93 refcount:0 mapcount:0 mapeo:00000000000000000 index:0x0 pfn: 0x112fc7 banderas: 0x17ffffc0000000() sin formato: 0017ffffc0000000 0000000000000000 muerto000000000122 00000000000000000 sin formato: 0000000000000000 000000000000 0000 00000000ffffffff 0000000000000000 página volcada porque: kasan: mal acceso detectado addr ffff888112fc713c está ubicado en la pila del controlador de tareas 2/1367 en el desplazamiento 180 en el framework: ovs_fragment+0x0/0x840 [ openvswitch] este framework tiene 2 objetos: [32, 144) 'ovs_dst' [192, 424) 'ovs_rt' Estado de la memoria alrededor de la dirección del error: ffff888112fc7000: f3 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffff88811 2fc7080 : 00 f1 f1 f1 f1 00 00 00 00 00 00 00 00 00 00 00 >ffff888112fc7100: 00 00 00 f2 f2 f2 f2 f2 f2 00 00 00 00 00 00 00 ^ ffff888112fc7180: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffff888112fc7200: 00 00 00 00 00 00 f2 f2 f2 00 00 00 00 00 00 00 para paquetes IPv4, ovs_fragment() utiliza una estructura temporal dst_entry. Luego, en el siguiente gráfico de llamadas: ip_do_fragment() ip_skb_dst_mtu() ip_dst_mtu_maybe_forward() ip_mtu_locked() el puntero a struct dst_entry se usa como puntero a struct rtable: esto convierte el acceso a miembros de estructura como rt_mtu_locked en una lectura OOB en la pila. Solucione este problema cambiando la variable temporal utilizada para los paquetes IPv4 en ovs_fragment(), de manera similar a lo que se hace para IPv6 unas líneas más abajo.

En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: virtiofs: corrige pérdida de memoria en virtio_fs_probe() Al pasar accidentalmente dos veces la misma etiqueta a qemu, kmemleak terminó reportando una pérdida de memoria en virtiofs. Además, mirando el registro vi el siguiente error (fue entonces cuando me di cuenta de la etiqueta duplicada): virtiofs: la sonda de virtio5 falló con el error -17 Aquí está el registro kmemleak como referencia: objeto sin referencia 0xffff888103d47800 (tamaño 1024): comm "systemd- udevd", pid 118, jiffies 4294893780 (edad 18.340 s) volcado hexadecimal (primeros 32 bytes): 00 00 00 00 ad 4e ad de ff ff ff ff 00 00 00 00 ......N....... ... ff ff ff ff ff ff ff ff 80 90 02 a0 ff ff ff ff ................ rastreo: [<000000000ebb87c1>] virtio_fs_probe+0x171/0x7ae [virtiofs] [<00000000f8aca419>] virtio_dev_probe+0x15f/0x210 [<000000004d6baf3c>] very_probe+0xea/0x430 [<00000000a6ceeac8>] device_driver_attach+0xa8/0xb0 [<00000000196f47a7 >] __driver_attach+0x98/0x140 [<000000000b20601d>] bus_for_each_dev+0x7b/0xc0 [<00000000399c7b7f>] bus_add_driver+0x11b/0x1f0 [<0000000032b09ba7>] driver_register+0x8f/0xe0 [<00000000cdd55998>] 0xffffffffa002c013 [<000000000ea196a2> ] do_one_initcall+0x64/0x2e0 [<0000000008f727ce>] do_init_module+0x5c/0x260 [<000000003cdedab6> ] __do_sys_finit_module+0xb5/0x120 [<00000000ad2f48c6>] do_syscall_64+0x33/0x40 [<00000000809526b5>] Entry_SYSCALL_64_after_hwframe+0x44/0xae

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: riscv/kprobe: corrige el pánico del kernel al invocar sys_read rastreado por kprobe La ejecución de sys_read termina con un BUG_ON() en __find_get_block después de instalar kprobe en sys_read, el mensaje de ERROR es como el siguiente : [65.708663] ------------[ cortar aquí ]------------ [ 65.709987] ¡ERROR del kernel en fs/buffer.c:1251! [65.711283] ERROR del kernel [#1] [65.712032] Módulos vinculados en: [65.712925] CPU: 0 PID: 51 Comm: sh No contaminado 5.12.0-rc4 #1 [65.714407] Nombre de hardware: riscv-virtio,qemu (DT ) [ 65.715696] epc : __find_get_block+0x218/0x2c8 [ 65.716835] ra : __getblk_gfp+0x1c/0x4a [ 65.717831] epc : ffffffe00019f11e ra : ffffffe00019f56a sp : ffffffe00243 7930 [65.719553] gp: ffffffe000f06030 tp: ffffffe0015abc00 t0: ffffffe00191e038 [65.721290] t1: ffffffe00191e038 t2: 000000000000000a s0: ffffffe002437960 [65.723051] s1: ffffffe00160ad00 a0: ffffffe00160ad00 a1: 000000000000012a [65.724772 ] a2 : 0000000000000400 a3 : 0000000000000008 a4 : 0000000000000040 [ 65.726545] a5 : 00000000000000000 a6 : ffffffe00191e000 a7 : 0000000000000 0000 [65.728308] s2: 000000000000012a s3 : 0000000000000400 s4 : 0000000000000008 [ 65.730049] s5 : 000000000000006c s6 : ffffffe00240f800 s7 : ffffffe000f080a8 [ 65.731802] s8 : 0 000000000000001 s9: 000000000000012a s10: 0000000000000008 [65.733516] s11: 00000000000000008 t3: 00000000000003ff t4: 0000000000 00000f [65.734434] t5: 00000000000003ff t6: 0000000000040000 [65.734613] estado: 0000000000000100 badaddr: 00000000000000000 causa: 0000000000000003 [65.734901] Seguimiento de llamadas: [65.735076] [] __find_get_block+ 0x218/0x2c8 [ 65.735417] [] __ext4_get_inode_loc+0xb2/0x2f6 [ 65.735618] [] ext4_get_inode_loc+0x3a/0x8a [ 65.735802] [] ext4_reserve_inode_write+0x2e/0x8c [ 65.735999] [] __ext4_mark_inode_dirty+0x4c/0x18e [ 65.736208] [] ext4_dirty_inode+0x46/0x66 [ 65.736387] [ ] __mark_inode_dirty+0x12c/0x3da [ 65.736576] [] touch_atime+0x146/0x150 [ 65.736748] [] filemap_read+0x234/0x246 [ 65.736920] [] generic_file_read_iter+0xc0/0x114 [ 65.737114 ] [] ext4_file_read_iter+0x42/0xea [ 65.737310] [] new_sync_read+0xe2/0x15a [ 65.737483] [] vfs_read+0xca/0xf2 [ 65.737641] [] ksys_read+0x5e/0xc8 [ 65.737816] [] sys_read+0xe/0x16 [ 65.737973] [] ret_from_syscall+0x0/0x2 [ 65.738858] ---[ end trace fe93f985456c935d ]--- A El reproductor simple se ve así: echo 'p: myprobe sys_read fd=%a0 buf=%a1 count=%a2' > /sys/kernel/debug/tracing/kprobe_events echo 1 > /sys/kernel/debug/tracing/events/kprobes/myprobe/enable cat /sys/kernel /debug/tracing/trace Esto es lo que sucede cuando se activa ese BUG_ON(): 1) Después de instalar kprobe en la entrada de sys_read, la primera instrucción se reemplaza por la instrucción 'ebreak' en la plataforma riscv64. 2) Una vez que el kernel alcanza la instrucción 'ebreak' en la entrada de sys_read, entra en el controlador de punto de interrupción riscv, donde hace algo para configurar la siguiente instrucción de origen de un solo paso, incluida una copia de seguridad del 'sstatus' en pt_regs, seguido de deshabilite la interrupción durante un solo paso mediante el bit 'SIE' claro de 'sstatus' en pt_regs. 3) Luego, la restauración del kernel en la ranura de instrucciones contiene dos instrucciones, una es la instrucción original en la entrada de sys_read y la otra es 'ebreak'. Aquí se activa una excepción de 'Error en la página de instrucciones' (el valor en 'scause' es '0xc'), si el PF aún no se ha completado en PageTabe para ese espacio.---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: btrfs: corrige la ejecución entre transacciones abortadas y fsyncs que conducen a use-after-free. Hay una carrera entre una tarea que aborta una transacción durante un commit, una tarea que realiza una fsync y la transacción. kthread, lo que conduce a un use-after-free del árbol raíz del registro. Cuando esto sucede, se genera un seguimiento de pila como el siguiente: Información BTRFS (dispositivo dm-0): solo lectura forzada Advertencia BTRFS (dispositivo dm-0): omitir confirmación de transacción abortada. BTRFS: error (dispositivo dm-0) en cleanup_transaction:1958: errno=-5 falla de IO Advertencia de BTRFS (dispositivo dm-0): escritura de página perdida debido a un error de IO en /dev/mapper/error-test (-5) BTRFS Advertencia (dispositivo dm-0): omitir confirmación de transacción abortada. Advertencia BTRFS (dispositivo dm-0): IO directa falló en 261 rw 0,0 sector 0xa4e8 len 4096 err no 10 Error BTRFS (dispositivo dm-0): error al escribir el superbloque primario en el dispositivo 1 Advertencia BTRFS (dispositivo dm-0) : error de IO directo ino 261 rw 0,0 sector 0x12e000 len 4096 err no 10 advertencia BTRFS (dispositivo dm-0): error de IO directo ino 261 rw 0,0 sector 0x12e008 len 4096 error no 10 advertencia BTRFS (dispositivo dm-0) : error de IO directo ino 261 rw 0,0 sector 0x12e010 len 4096 error no 10 BTRFS: error (dispositivo dm-0) en write_all_supers:4110: errno=-5 error de IO (1 error al escribir supers) BTRFS: error (dispositivo dm -0) en btrfs_sync_log:3308: errno=-5 Fallo de E/S Fallo de protección general, probablemente para la dirección no canónica 0x6b6b6b6b6b6b6b68: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC PTI CPU: 2 PID: 2458471 Comm: fsstress Not tainted 5.12.0- rc5-btrfs-next-84 #1 Nombre del hardware: PC estándar QEMU (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 01/04/2014 RIP: 0010:__mutex_lock+ 0x139/0xa40 Código: c0 74 19 (...) RSP: 0018:ffff9f18830d7b00 EFLAGS: 00010202 RAX: 6b6b6b6b6b6b6b68 RBX: 0000000000000001 RCX: 00000000000000002 RD X: ffffffffb9c54d13 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffff9f18830d7bc0 R08: 00000000000000000 R09: 0000000000000000 R10: ffff9f18830d7be0 R11: 0000000000000001 R12: ffff8c6cd199c040 R13: ffff8c6c95821358 R14: 00000000fffffffb R15: ffff8c6cbcf01358 FS: 00007fa9140c2b 80(0000) GS:ffff8c6fac600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fa913d52000 CR3: 000000013d2 b4003 CR4 : 0000000000370ee0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 00000000000000000 DR6: 00000000fffe0ff0 DR7: 000000 0000000400 Rastreo de llamadas: ? __btrfs_handle_fs_error+0xde/0x146 [btrfs] ? btrfs_sync_log+0x7c1/0xf20 [btrfs]? btrfs_sync_log+0x7c1/0xf20 [btrfs] btrfs_sync_log+0x7c1/0xf20 [btrfs] btrfs_sync_file+0x40c/0x580 [btrfs] do_fsync+0x38/0x70 __x64_sys_fsync+0x10/0x20 do_syscall_64+ 0x33/0x80 Entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7fa9142a55c3 Código : 8b 15 09 (...) RSP: 002b:00007fff26278d48 EFLAGS: 00000246 ORIG_RAX: 000000000000004a RAX: ffffffffffffffda RBX: 0000563c83cb4560 RCX: 00007fa9142a55c 3 RDX: 00007fff26278cb0 RSI: 00007fff26278cb0 RDI: 0000000000000005 RBP: 0000000000000005 R08: 000000000000000001 R09: 00007fff26278d5c R10: 0 000000000000000 R11: 0000000000000246 R12: 0000000000000340 R13: 00007fff26278de0 R14: 00007fff26278d96 R15: 0000563c83ca57c0 Módulos vinculados en: btrfs dm_zero dm_snapshot dm _thin_pool (...) ---[ end trace ee2f1b19327d791d ]--- Los pasos que conducen a este bloqueo son los siguientes: 1) Estamos en la transacción N; 2) Tenemos dos tareas con un identificador de transacción adjunto a la transacción N. Tarea A y Tarea B. La tarea B está realizando una sincronización f; 3) La tarea B está en btrfs_sync_log() y ha guardado fs_info->log_root_tree en una variable local llamada 'log_root_tree' en la parte superior de btrfs_sync_log().---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: cifs: devuelve el código de error correcto de smb2_get_enc_key Evite una advertencia si el error se repite: [440700.376476] CIFS VFS: \\otters.example.com crypt_message: no se pudo obtener la clave de cifrado [440700.386947] ------------[ cortar aquí ]------------ [440700.386948] err = 1 [440700.386977] ADVERTENCIA: CPU: 11 PID: 2733 en / build/linux-hwe-5.4-p6lk6L/linux-hwe-5.4-5.4.0/lib/errseq.c:74 errseq_set+0x5c/0x70 ... [440700.397304] CPU: 11 PID: 2733 Comm: tar Contaminado: G OE 5.4.0-70-generic #78~18.04.1-Ubuntu... [440700.397334] Seguimiento de llamadas: [440700.397346] __filemap_set_wb_err+0x1a/0x70 [440700.397419] cifs_writepages+0x9c7/0xb30 [cifs ] [440700.397426] do_writepages+0x4b /0xe0 [440700.397444] __filemap_fdatawrite_range+0xcb/0x100 [440700.397455] filemap_write_and_wait+0x42/0xa0 [440700.397486] cifs_setattr+0x68b/0xf30 [cifs] [440700.39749 3] notify_change+0x358/0x4a0 [440700.397500] utimes_common+0xe9/0x1c0 [440700.397510] do_utimes+ 0xc5/0x150 [440700.397520] __x64_sys_utimensat+0x88/0xd0

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: irqchip/gic-v3: no habilitar irqs cuando se manejan interrupciones espurias. Activamos el siguiente error al ejecutar nuestro kernel 4.19 con los parches pseudo-NMI respaldados: [14.816231] - -----------[ cortar aquí ]------------ ¡ERROR del kernel [14.816231] en irq.c:99! [14.816232] Error interno: Ups - ERROR: 0 [#1] SMP [14.816232] Intercambiador de procesos/0 (pid: 0, límite de pila = 0x(____ptrval____)) [14.816233] CPU: 0 PID: 0 Comunicaciones: intercambiador/0 Contaminado: GO 4.19.95.aarch64 #14 [ 14.816233] Nombre de hardware: evb (DT) [ 14.816234] pstate: 80400085 (Nzcv daIf +PAN -UAO) [ 14.816234] pc : asm_nmi_enter+0x94/0x98 [ 14.816235] lr : asm_nmi_enter +0x18/0x98 [ 14.816235] sp : ffff000008003c50 [ 14.816235] pmr_save: 00000070 [ 14.816237] x29: ffff000008003c50 x28: ffff0000095f56c0 [ 14.816 238] x27: 0000000000000000 x26: ffff000008004000 [ 14.816239] x25: 00000000015e0000 x24: ffff8008fb916000 [ 14.816240] x23: 000000002040 0005x22 : ffff0000080817cc [ 14.816241] x21: ffff000008003da0 x20: 0000000000000060 [ 14.816242] x19: 00000000000003ff x18: ffffffffffffffff [ 14.816243] x 17: 0000000000000008 x16: 003d090000000000 [ 14.816244] x15: ffff0000095ea6c8 x14: ffff8008fff5ab40 [ 14.816244] x13: ffff8008fff58b9d x12: 00 00000000000000 [14.816245] x11: ffff000008c8a200 x10: 000000008e31fca5 [ 14.816246] x9 : ffff000008c8a208 x8 : 0000000000000000f [ 14.816247] x7 : 0000000000000004 x6 : ffff8008fff58b9e [ 14.816248] x5 : 00000000000000000 x4 : 0000000080000000 [ 14.816249] x3 : 00000000000000000 x2 : 0000000080000000 [ 14.81 6250] x1: 0000000000120000 x0: ffff0000095f56c0 [ 14.816251] Rastreo de llamadas: [ 14.816251] asm_nmi_enter+0x94/0x98 [ 14.816251] el1_irq+0x8c/0x180 (IRQ C) [ 14.816252] gic_handle_irq+0xbc/0x2e4 [ 14.816252] el1_irq+0xcc/0x180 (IRQ B) [ 14.816253] arch_timer_handler_virt+0x38/0x58 [ 14.816253] handle_percpu_devid_irq+0x90/0x240 [ 14.816253] generic_handle_irq+0x34/0x50 [ 14.816254] __handle_domain_irq+0x68/0xc0 [ 14.81625 4] gic_handle_irq+0xf8/0x2e4 [ 14.816255] el1_irq+0xcc/0x180 (IRQ A) [ 14.816255] arch_cpu_idle+0x34/0x1c8 [ 14.816255] default_idle_call+0x24/0x44 [ 14.816256] do_idle+0x1d0/0x2c8 [ 14.816256] cpu_startup_entry+0x28/0x30 [ 14.8162 56] rest_init+0xb8/0xc8 [ 14.816257] start_kernel+0x4c8/0x4f4 [ 14.816257] Código: 940587f1 d5384100 b9401001 36a7fd01 (d4210000) [14.816258] Módulos vinculados en: start_dp(O) smeth(O) [15.103092] ---[ end trace 701753956cb14aa8 ]--- [ 15.1030 93] Pánico en el kernel: no se sincroniza: excepción fatal en interrupción [15.103099] SMP: deteniendo CPU secundarias [15.103100] Desplazamiento del kernel: deshabilitado [15.103100] Características de la CPU: 0x36,a2400218 [15.103100] Límite de memoria: ninguno causado por un 'BUG_ON(in_nmi())' en nmi_enter(). Desde el seguimiento de la llamada, podemos encontrar tres interrupciones (anotadas A, B, C arriba): la interrupción (A) es reemplazada por (B), que es interrumpida aún más por (C). Investigaciones posteriores muestran que (B) da como resultado que se llame a nmi_enter(), pero que en realidad es una interrupción espuria. Además, las interrupciones se vuelven a habilitar en el contexto de incendios (B) y (C) con prioridad NMI. Terminamos con una situación de NMI anidada, algo que definitivamente no queremos (y no podemos) manejar. El error aquí es que las interrupciones espurias nunca deberían dar lugar a ningún cambio de estado y simplemente deberíamos volver al contexto interrumpido. Mover el manejo de interrupciones espurias lo antes posible en el controlador GICv3 soluciona este problema. [maz: reescribí el mensaje de confirmación, corregido Correcciones: etiqueta]

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mmc: uniphier-sd: corrige una fuga de recursos en la función de eliminación Falta una llamada 'tmio_mmc_host_free()' en la función de eliminación, para equilibrar un 'tmio_mmc_host_alloc()' llamar a la sonda. Esto se hace en la ruta de manejo de errores de la sonda, pero no en la función de eliminación. Agrega la llamada faltante.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: Thermal/drivers/cpufreq_cooling: solucionar el problema de Slab OOB El problema de Slab OOB es escaneado por KASAN en cpu_power_to_freq(). Si la potencia se limita por debajo de la potencia de OPP0 en la tabla EM, provocará un problema de losa fuera de los límites con un índice de matriz negativo. Devuelve la frecuencia más baja si la potencia limitada no puede encontrar un OPP adecuado en la tabla EM para solucionar este problema. Seguimiento inverso: [] die+0x104/0x5ac [] bug_handler+0x64/0xd0 [] brk_handler+0x160/0x258 [] do_debug_exception+0x 248/0x3f0 [] el1_dbg+0x14 /0xbc [] __kasan_report+0x1dc/0x1e0 [] kasan_report+0x10/0x20 [] __asan_report_load8_noabort+0x18/0x28 [] cpufreq_power2state+0x180/0x43c [] power_actor_set_power+0x114 /0x1d4 [] allocate_power+0xaec/0xde0 [] power_allocator_throttle+0x3ec/0x5a4 [] handle_thermal_trip+0x160/0x294 [] térmico _zone_device_check+0xe4/0x154 [] proceso_one_work+0x5e4 /0xe28 [] work_thread+0xa4c/0xfac [] kthread+0x33c/0x358 [] ret_from_fork+0xc/0x18

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: medios: dvbdev: corrige la pérdida de memoria en dvb_media_device_free() dvb_media_device_free() está perdiendo memoria. Libere `dvbdev->adapter->conn` antes de configurarlo en NULL, como se documenta en include/media/media-device.h: "La instancia media_entity debe ser liberada explícitamente por el controlador si es necesario".

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: dm rq: corrige la liberación doble de blk_mq_tag_set en dev y se elimina después de que falla la carga de la tabla Al cargar una tabla de mapeador de dispositivos para un dispositivo mapeado basado en solicitudes y la asignación/inicialización de blk_mq_tag_set Si el dispositivo falla, la siguiente eliminación del dispositivo provocará una doble liberación. Por ejemplo, (dmesg): mapeador de dispositivos: núcleo: no se puede inicializar la cola para el dispositivo asignado dm-mq basado en solicitudes mapeador de dispositivos: ioctl: no se puede configurar la cola de dispositivos para una nueva tabla. No se puede manejar la desreferencia del puntero del kernel en el espacio de direcciones virtual del kernel Dirección fallida: 0305e098835de000 TEID: 0305e098835de803 Fallo en el modo de espacio de inicio mientras se usa el kernel ASCE. AS:000000025efe0007 R3:0000000000000024 Ups: 0038 ilc:3 [#1] Módulos SMP vinculados en: ... muchos módulos ... Compatible: Sí, CPU externa: 0 PID: 7348 Comm: multipathd Kdump: cargado Contaminado: GWX 5.3.18-53-default #1 SLE15-SP3 Nombre de hardware: IBM 8561 T01 7I2 (LPAR) Krnl PSW: 0704e00180000000 000000025e368eca (kfree+0x42/0x330) R:0 T:1 IO:1 EX:1 Clave:0 M :1 W:0 P:0 AS:3 CC:2 PM:0 RI:0 EA:3 Krnl GPRS: 000000000000004a 000000025efe5230 c1773200d779968d 00000000000000000 000000025e520270 000000025 e8d1b40 0000000000000003 00000007aae10000 000000025e5202a2 0000000000000001 c1773200d779968d 0305e098835de640 00000007a8170000 0 00003ff80138650 000000025e5202a2 000003e00396faa8 Código Krnl: 000000025e368eb8: c4180041e100 lgrl % r1,25eba50b8 000000025e368ebe: ecba06b93a55 risbg %r11,%r10,6,185,58 #000000025e368ec4: e3b010000008 ag %r11,0(%r1) >000000025e368eca: e310 b0080004 lg %r1,8(%r11) 000000025e368ed0: a7110001 tmll %r1,1 000000025e368ed4: a7740129 brc 7,25e369126 000000025e368ed8: e320b0080004 lg %r2,8(%r11) 000000025e368ede: b904001b lgr %r1,%r11 Seguimiento de llamadas: [<0 00000025e368eca>] kfree+0x42/0x330 [<000000025e5202a2>] blk_mq_free_tag_set+0x72/ 0xb8 [<000003ff801316a8>] dm_mq_cleanup_mapped_device+0x38/0x50 [dm_mod] [<000003ff80120082>] free_dev+0x52/0xd0 [dm_mod] [<000003ff801233f0>] __dm_destroy+0x1 50/0x1d0 [dm_mod] [<000003ff8012bb9a>] dev_remove+0x162/0x1c0 [dm_mod] [<000003ff8012a988>] ctl_ioctl+0x198/0x478 [dm_mod] [<000003ff8012ac8a>] dm_ctl_ioctl+0x22/0x38 [dm_mod] [<000000025e3b11ee>] ksys_ioctl+0xbe /0xe0 [<000000025e3b127a>] __s390x_sys_ioctl+0x2a/0x40 [ <000000025e8c15ac>] system_call+0xd8/0x2c8 Última dirección del evento de última hora: [<000000025e52029c>] blk_mq_free_tag_set+0x6c/0xb8 Pánico del kernel: no se sincroniza: excepción grave: pánico_on_oops Cuando la asignación/inicialización de blk_mq_tag_set falla en d m_mq_init_request_queue(), no está inicializado/liberado, pero el puntero no se restablece a NULL; entonces, cuando dev_remove() ingresa más tarde a dm_mq_cleanup_mapped_device(), ve el puntero e intenta desinicializarlo y liberarlo nuevamente. Solucione este problema estableciendo el puntero en NULL en el manejo de errores dm_mq_init_request_queue(). También configúrelo en NULL en dm_mq_cleanup_mapped_device().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: rastreo: reestructurar trace_clock_global() para no bloquear nunca. Se informó que una solución a la detección de recursividad del búfer circular provocaría que la máquina se bloqueara al realizar pruebas de suspensión/reanudación. El siguiente seguimiento se extrajo de la depuración de ese caso: Call Trace: trace_clock_global+0x91/0xa0 __rb_reserve_next+0x237/0x460 ring_buffer_lock_reserve+0x12a/0x3f0 trace_buffer_lock_reserve+0x10/0x50 __trace_graph_return+0x1f/0x80 trace_graph_return+0xb7 /0xf0? trace_clock_global+0x91/0xa0 ftrace_return_to_handler+0x8b/0xf0 ? pv_hash+0xa0/0xa0 return_to_handler+0x15/0x30 ? ftrace_graph_caller+0xa0/0xa0? trace_clock_global+0x91/0xa0? __rb_reserve_next+0x237/0x460? ring_buffer_lock_reserve+0x12a/0x3f0? trace_event_buffer_lock_reserve+0x3c/0x120? trace_event_buffer_reserve+0x6b/0xc0? trace_event_raw_event_device_pm_callback_start+0x125/0x2d0? dpm_run_callback+0x3b/0xc0? pm_ops_is_empty+0x50/0x50? platform_get_irq_byname_opcional+0x90/0x90? trace_device_pm_callback_start+0x82/0xd0? dpm_run_callback+0x49/0xc0 Con el siguiente RIP: RIP: 0010:native_queued_spin_lock_slowpath+0x69/0x200 Dado que la solución a la detección de recursión permitiría que ocurriera una sola recursión durante el seguimiento, esto llevó a trace_clock_global() a tomar un bloqueo de giro y luego intentarlo para tomarlo de nuevo: ring_buffer_lock_reserve() { trace_clock_global() { arch_spin_lock() { queued_spin_lock_slowpath() { /* bloqueo tomado */ (algo más es rastreado por la función de seguimiento del gráfico) ring_buffer_lock_reserve() { trace_clock_global() { arch_spin_lock() { queued_spin_lock_slowpath () { /* ¡BLOQUEO MUERTO! */ El rastreo *nunca* debe bloquearse, ya que puede provocar bloqueos extraños como el anterior. Reestructura el código trace_clock_global() para que, en lugar de simplemente tomar un bloqueo para actualizar el "prev_time" registrado, simplemente lo uses, ya que dos eventos suceden en dos CPU diferentes que llaman a esto al mismo tiempo, realmente no importa cuál va primero. Utilice un trylock para obtener el bloqueo para actualizar prev_time y, si falla, simplemente inténtelo de nuevo la próxima vez. Si no se pudo tomar, eso significa que algo más ya lo está actualizando. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=212761

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: herramientas/turbostat de potencia: soluciona el problema de desbordamiento de compensación en la conversión de índice. La función idx_to_offset() devuelve el tipo int (32 bits firmado), pero MSR_PKG_ENERGY_STAT es u32 y se interpretaría como negativo. número. El resultado final es que alcanza la verificación if (offset < 0) en update_msr_sum(), lo que evita que la devolución de llamada del temporizador actualice la estadística en segundo plano cuando se utilizan duraciones prolongadas. Existe un problema similar en offset_to_idx() y update_msr_sum(). Solucione este problema convirtiendo 'int' a 'off_t' en consecuencia.