Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: crypto: arm64/poly1305 - corrige una lectura fuera de los límites Se informó un error de kasan durante el fuzzing: BUG: KASAN: slab-out-of-bounds en neon_poly1305_blocks.constprop.0+0x1b4/0x250 [poly1305_neon] Lectura de tamaño 4 en la dirección ffff0010e293f010 por la tarea syz-executor.5/1646715 CPU: 4 PID: 1646715 Comm: syz-executor.5 Kdump: cargado No contaminado 5.10.0.aarch64 #1 Nombre del hardware: Huawei TaiShan 2280 /BC11SPCD, BIOS 1.59 31/01/2019 Rastreo de llamadas: dump_backtrace+0x0/0x394 show_stack+0x34/0x4c arch/arm64/kernel/stacktrace.c:196 __dump_stack lib/dump_stack.c:77 [en línea] dump_stack+0x158/0x1e4 lib/dump_stack.c:118 print_address_description.constprop.0+0x68/0x204 mm/kasan/report.c:387 __kasan_report+0xe0/0x140 mm/kasan/report.c:547 kasan_report+0x44/0xe0 mm/kasan/report.c:564 check_memory_region_inline mm/kasan/generic.c:187 [en línea] __asan_load4+0x94/0xd0 mm/kasan/generic.c:252 neon_poly1305_blocks.constprop.0+0x1b4/0x250 [poly1305_neon] neon_poly1305_do_update+0x6c/0x15c [poly1305_neon] neon_poly1305_update+0x9c/0x1c4 [poly1305_neon] crypto_shash_update crypto/shash.c:131 [en línea] shash_finup_unaligned+0x84/0x15c crypto/shash.c:179 crypto_shash_finup+0x8c/0x140 crypto/shash.c:193 shash_digest_unaligned+0xb8/0xe4 crypto/shash.c:201 crypto_shash_digest+0xa4/0xfc crypto/shash.c:217 crypto_shash_tfm_digest+0xb4/0x150 crypto/shash.c:229 essiv_skcipher_setkey+0x164/0x200 [essiv] crypto_skcipher_setkey+0xb0/0x160 crypto/skcipher.c:612 skcipher_setkey+0x3c/0x50 crypto/algif_skcipher.c:305 alg_setkey+0x114/0x2a0 crypto/af_alg.c:220 alg_setsockopt+0x19c/0x210 crypto/af_alg.c:253 __sys_setsockopt+0x190/0x2e0 net/socket.c:2123 __do_sys_setsockopt net/socket.c:2134 [en línea] __se_sys_setsockopt net/socket.c:2131 [en línea] __arm64_sys_setsockopt+0x78/0x94 net/socket.c:2131 __invoke_syscall arch/arm64/kernel/syscall.c:36 [en línea] invoke_syscall+0x64/0x100 arch/arm64/kernel/syscall.c:48 el0_svc_common.constprop.0+0x220/0x230 arch/arm64/kernel/syscall.c:155 do_el0_svc+0xb4/0xd4 arch/arm64/kernel/syscall.c:217 el0_svc+0x24/0x3c arch/arm64/kernel/entry-common.c:353 el0_sync_handler+0x160/0x164 arch/arm64/kernel/entry-common.c:369 el0_sync+0x160/0x180 arch/arm64/kernel/entry.S:683 Este error se puede reproducir con el siguiente código compilado como ko en un sistema con kasan habilitado: #include #include #include #include char test_data[] = "\x00\x01\x02\x03\x04\x05\x06\x07" "\x08\x09\x0a\x0b\x0c\x0d\x0e\x0f" "\x10\x11\x12\x13\x14\x15\x16\x17" "\x18\x19\x1a\x1b\x1c\x1d\x1e"; int init(void) { struct crypto_shash *tfm = NULL; char *data = NULL, *out = NULL; tfm = crypto_alloc_shash("poly1305", 0, 0); datos = kmalloc(POLY1305_KEY_SIZE - 1, GFP_KERNEL); salida = kmalloc(POLY1305_DIGEST_SIZE, GFP_KERNEL); memcpy(datos, datos_de_prueba, POLY1305_KEY_SIZE - 1); crypto_shash_tfm_digest(tfm, datos, POLY1305_KEY_SIZE - 1, salida); kfree(data); kfree(out); return 0; } void deinit(void) { } module_init(init) module_exit(deinit) MODULE_LICENSE("GPL"); La causa raíz del error reside en neon_poly1305_blocks. La lógica de neon_poly1305_blocks() es que, si se invocó con s[] y r[] sin inicializar, primero intentará inicializarlos con los datos del primer "bloque", que se cree que tiene una longitud de 32 bytes. Los primeros 16 bytes se utilizan como clave y los siguientes para s[]. Esto provocaría la lectura fuera de los límites mencionada anteriormente. Sin embargo, tras invocar poly1305_init_arch(), solo se restaron 16 bytes de la entrada y s[] se inicializa de nuevo con los siguientes 16 bytes. La segunda inicialización de s[] es ciertamente redundante, lo que indica que la primera inicialización debería ser solo para r[]. Este parche corrige el problema llamando a poly1305_init_arm64() en lugar de truncated.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: arm64: establecer UXN en las tablas de páginas del intercambiador [Este problema se corrigió accidentalmente en c3cee924bd85 ("arm64: head: cubrir toda la imagen del kernel en el mapa de ID inicial") como parte de una refactorización a gran escala del flujo de arranque de arm64. Por lo tanto, esta sencilla solución es la preferida para la retroportación de -stable]. En un sistema que implementa FEAT_EPAN, se deniega el acceso de lectura/escritura al mapa de ID porque UXN no está establecido en las PTE del intercambiador. Como resultado, idmap_kpti_install_ng_mappings genera un pánico en el kernel al acceder a __idmap_kpti_flag. Se soluciona estableciendo UXN en estas PTE.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ALSA: bcd2000: corrige un error de UAF en la ruta de error del sondeo Cuando el controlador falla en snd_card_register() en el momento del sondeo, liberará 'bcd2k->midi_out_urb' antes de matarlo, lo que puede causar un error de UAF. El siguiente registro puede revelarlo: [ 50.727020] ERROR: KASAN: uso después de la liberación en bcd2000_input_complete+0x1f1/0x2e0 [snd_bcd2000] [ 50.727623] Lectura de tamaño 8 en la dirección ffff88810fab0e88 por el intercambiador de tareas/4/0 [ 50.729530] Seguimiento de llamadas: [ 50.732899] bcd2000_input_complete+0x1f1/0x2e0 [snd_bcd2000] Solucione esto agregando usb_kill_urb() antes de usb_free_urb().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: KVM: SVM: No generar ERRORES si el espacio de usuario inyecta una interrupción con GIF=0 No generar ERRORES/ADVERTENCIAS en la inyección de interrupción debido a que se borra el GIF, ya que es trivial para el espacio de usuario forzar la situación a través de KVM_SET_VCPU_EVENTS (incluso si tener al menos un WARN allí sería correcto para las inyecciones generadas internamente por KVM). ¡ERROR del kernel en arch/x86/kvm/svm/svm.c:3386! Código de operación no válido: 0000 [#1] CPU SMP: 15 PID: 926 Comm: smm_test No contaminado 5.17.0-rc3+ #264 Nombre del hardware: PC estándar QEMU (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 RIP: 0010:svm_inject_irq+0xab/0xb0 [kvm_amd] Código: <0f> 0b 0f 1f 00 0f 1f 44 00 00 80 3d ac b3 01 00 00 55 48 89 f5 53 RSP: 0018:ffffc90000b37d88 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff88810a234ac0 RCX: 0000000000000006 RDX: 0000000000000000 RSI: ffffc90000b37df7 RDI: ffff88810a234ac0 RBP: ffffc90000b37df7 R08: ffff88810a1fa410 R09: 000000000000000 R10: 000000000000000 R11: 000000000000000 R12: 000000000000000 R13: ffff888109571000 R14: ffff88810a234ac0 R15: 0000000000000000 FS: 0000000001821380(0000) GS:ffff88846fdc0000(0000) knlGS:000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f74fc550008 CR3: 000000010a6fe000 CR4: 0000000000350ea0 Rastreo de llamadas: inject_pending_event+0x2f7/0x4c0 [kvm] kvm_arch_vcpu_ioctl_run+0x791/0x17a0 [kvm] kvm_vcpu_ioctl+0x26d/0x650 [kvm] __x64_sys_ioctl+0x82/0xb0 do_syscall_64+0x3b/0xc0 entry_SYSCALL_64_after_hwframe+0x44/0xae

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: KVM: x86/xen: Inicializar el temporizador Xen solo una vez. Se ha añadido una comprobación de los temporizadores Xen existentes antes de inicializar uno nuevo. Actualmente, se llama a kvm_xen_init_timer() en cada KVM_XEN_VCPU_ATTR_TYPE_TIMER, lo que provoca el siguiente fallo de ODEBUG cuando vcpu->arch.xen.timer ya está configurado. ODEBUG: init activo (estado activo 0) tipo de objeto: hrtimer sugerencia: xen_timer_callbac0 RIP: 0010:debug_print_object+0x16e/0x250 lib/debugobjects.c:502 Seguimiento de llamadas: __debug_object_init debug_hrtimer_init debug_init hrtimer_init kvm_xen_init_timer kvm_xen_vcpu_set_attr kvm_arch_vcpu_ioctl kvm_vcpu_ioctl vfs_ioctl

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: crypto: ccp - Use kzalloc para interfaces sev ioctl para evitar fugas de memoria en el kernel Para algunas interfaces sev ioctl, se puede pasar una entrada menor o igual a SEV_FW_BLOB_MAX_SIZE, pero mayor que los datos que devuelve el firmware de PSP. En este caso, kmalloc asignará memoria que sea del tamaño de la entrada en lugar del tamaño de los datos. Dado que el firmware de PSP no sobrescribe completamente el búfer, las interfaces sev ioctl con el problema pueden devolver memoria slab sin inicializar. Actualmente, todas las interfaces ioctl en el controlador ccp son seguras, pero para evitar problemas futuros, cambie todas las interfaces ioctl que asignan memoria con kmalloc para usar kzalloc y memset el búfer de datos a cero en sev_ioctl_do_platform_status.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: riscv:uprobe fix SR_SPIE set/clear management. En riscv, el proceso de uprobe borra spie antes de ejecutar la instrucción de origen y la configura después. Sin embargo, al acceder a la página donde se ha colocado la instrucción de origen, puede producirse un fallo de página y la función irq se ha deshabilitado en arch_uprobe_pre_xol. Esto genera una advertencia como la siguiente. No es necesario borrar/configurar spie en arch_uprobe_pre/post/abort_xol. Simplemente podemos eliminarlo. [ 31.684157] ERROR: función de suspensión llamada desde un contexto no válido en kernel/locking/rwsem.c:1488 [ 31.684677] in_atomic(): 0, irqs_disabled(): 1, non_block: 0, pid: 76, name: work [ 31.684929] preempt_count: 0, expected: 0 [ 31.685969] CPU: 2 PID: 76 Comm: work Tainted: G [ 31.686542] Nombre del hardware: riscv-virtio,qemu (DT) [ 31.686797] Rastreo de llamadas: [ 31.687053] [] dump_backtrace+0x30/0x38 [ 31.687699] [] show_stack+0x40/0x4c [ 31.688141] [] dump_stack_lvl+0x44/0x5c [ 31.688396] [] dump_stack+0x18/0x20 [ 31.688653] [] __might_resched+0x114/0x122 [ 31.688948] [] __might_sleep+0x50/0x7a [ 31.689435] [] down_read+0x30/0x130 [ 31.689728] [] do_page_fault+0x166/x446 [ 31.689997] [] ret_from_exception+0x0/0xc

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: KVM: x86/mmu: Tratar NX como un bit SPTE válido para NPT. Se trata el bit NX como válido al usar NPT, ya que KVM lo activará cuando la mitigación de páginas enormes de NX esté habilitada (¡increíble!) y activará la advertencia que se activa al activarse los bits SPTE reservados. KVM ha requerido compatibilidad con NX para SVM desde el commit b26a71a1a5b9 ("KVM: SVM: Rechazar la carga de kvm_amd si la compatibilidad con NX no está disponible") precisamente por esta razón, pero aparentemente a nadie se le ocurrió probar NPT con la mitigación habilitada. ------------[ cortar aquí ]------------ spte = 0x800000018a600ee7, nivel = 2, bits rsvd = 0x800f0000001fe000 ADVERTENCIA: CPU: 152 PID: 15966 en arch/x86/kvm/mmu/spte.c:215 make_spte+0x327/0x340 [kvm] Nombre del hardware: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 10.48.0 27/01/2022 RIP: 0010:make_spte+0x327/0x340 [kvm] Rastreo de llamadas: tdp_mmu_map_handle_target_level+0xc3/0x230 [kvm] kvm_tdp_mmu_map+0x343/0x3b0 [kvm] direct_page_fault+0x1ae/0x2a0 [kvm] kvm_tdp_page_fault+0x7d/0x90 [kvm] kvm_mmu_page_fault+0xfb/0x2e0 [kvm] npf_interception+0x55/0x90 [kvm_amd] svm_invoke_exit_handler+0x31/0xf0 [kvm_amd] svm_handle_exit+0xf6/0x1d0 [kvm_amd] vcpu_enter_guest+0xb6d/0xee0 [kvm] ? kvm_pmu_trigger_event+0x6d/0x230 [kvm] vcpu_run+0x65/0x2c0 [kvm] kvm_arch_vcpu_ioctl_run+0x355/0x610 [kvm] kvm_vcpu_ioctl+0x551/0x610 [kvm] __se_sys_ioctl+0x77/0xc0 __x64_sys_ioctl+0x1d/0x20 do_syscall_64+0x44/0xa0 entry_SYSCALL_64_after_hwframe+0x46/0xb0 ---[ fin de seguimiento 0000000000000000 ]---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: LoongArch: cpuinfo: Se corrige una advertencia para CONFIG_CPUMASK_OFFSTACK. Al seleccionar CONFIG_CPUMASK_OFFSTACK y CONFIG_DEBUG_PER_CPU_MAPS, cpu_max_bits_warn() genera una advertencia de tiempo de ejecución similar a la que se muestra a continuación mientras se muestra /proc/cpuinfo. Se corrige usando nr_cpu_ids (el límite de tiempo de ejecución) en lugar de NR_CPUS para iterar las CPU. [ 3.052463] ------------[ cortar aquí ]------------ [ 3.059679] ADVERTENCIA: CPU: 3 PID: 1 en include/linux/cpumask.h:108 show_cpuinfo+0x5e8/0x5f0 [ 3.070072] Módulos vinculados: efivarfs autofs4 [ 3.076257] CPU: 0 PID: 1 Comm: systemd No contaminado 5.19-rc5+ #1052 [ 3.084034] Nombre del hardware: Loongson Loongson-3A5000-7A1000-1w-V0.1-CRB/Loongson-LS3A5000-7A1000-1w-EVB-V1.21, BIOS Loongson-UDK2018-V2.0.04082-beta7 04/27 [3.099465] Pila: 9000000100157b08 9000000000f18530 9000000000cf846c 9000000100154000 [3.109127] 9000000100157a50 0000000000000000 9000000100157a58 9000000000ef7430 [3.118774] 90000001001578e8 000000000000040 0000000000000020 ffffffffffffffff [ 3.128412] 0000000000aaaaaa 1ab25f00eec96a37 900000010021de80 900000000101c890 [ 3.138056] 000000000000000 0000000000000000 000000000000000 00000000000000 00000000000aaaaaa [ 3.147711] ffff8000339dc220 000000000000001 0000000006ab4000 0000000000000000 [ 3.157364] 900000000101c998 0000000000000004 9000000000ef7430 0000000000000000 [ 3.167012] 0000000000000009 000000000000006c 0000000000000000 000000000000000 [ 3.176641] 9000000000d3de08 9000000001639390 90000000002086d8 00007ffff0080286 [ 3.186260] 00000000000000b0 0000000000000004 0000000000000000 0000000000071c1c [ 3.195868] ... [ 3.199917] Rastreo de llamadas: [ 3.203941] [<90000000002086d8>] show_stack+0x38/0x14c [ 3.210666] [<9000000000cf846c>] dump_stack_lvl+0x60/0x88 [ 3.217625] [<900000000023d268>] __warn+0xd0/0x100 [ 3.223958] [<9000000000cf3c90>] warn_slowpath_fmt+0x7c/0xcc [ 3.231150] [<9000000000210220>] show_cpuinfo+0x5e8/0x5f0 [ 3.238080] [<90000000004f578c>] seq_read_iter+0x354/0x4b4 [ 3.245098] [<90000000004c2e90>] new_sync_read+0x17c/0x1c4 [ 3.252114] [<90000000004c5174>] vfs_read+0x138/0x1d0 [ 3.258694] [<90000000004c55f8>] ksys_read+0x70/0x100 [ 3.265265] [<9000000000cfde9c>] do_syscall+0x7c/0x94 [ 3.271820] [<9000000000202fe4>] handle_syscall+0xc4/0x160 [ 3.281824] ---[ fin de seguimiento 8b484262b4b8c24c ]---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: tty: vt: al inicializar el búfer de pantalla Unicode, syzbot reporta una fuga de información del kernel en vcs_read() [1], ya que el búfer se puede leer inmediatamente después de la operación de cambio de tamaño. Inicialice el búfer con kzalloc(). ---------- #include #include #include #include int main(int argc, char *argv[]) { struct fb_var_screeninfo var = { }; const int fb_fd = open("/dev/fb0", 3); ioctl(fb_fd, FBIOGET_VSCREENINFO, &var); var.yres = 0x21; ioctl(fb_fd, FBIOPUT_VSCREENINFO, &var); return read(open("/dev/vcsu", O_RDONLY), &var, sizeof(var)) == -1; } ----------

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/fb-helper: Arregla el acceso fuera de los límites Recorta el rango de memoria al tamaño del búfer de pantalla para evitar el acceso fuera de los límites en el manejo de daños de E/S diferidas de fbdev. La E/S diferida de fbdev solo puede rastrear páginas. A partir del rango de páginas, el controlador de daños calcula el rectángulo de recorte para la actualización de la pantalla. Si el búfer de pantalla de fbdev termina cerca del principio de una página, esa página podría contener más líneas de exploración. El controlador de daños rastrearía entonces estas líneas de exploración inexistentes como sucias y provocaría un acceso fuera de los límites durante la actualización de la pantalla. Por lo tanto, recorta el rango máximo de memoria al tamaño del búfer de pantalla. Mientras lo haces, cambia el nombre de las variables min/max a min_off/max_off en drm_fb_helper_deferred_io(). Esto evita confusiones con las macros del mismo nombre.

Motivo del rechazo: esta autoridad de numeración CVE ha rechazado o retirado esta ID CVE.