Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: cachefiles: corrige la pérdida de memoria en cachefiles_add_cache() Se informó la siguiente pérdida de memoria después de desvincular /dev/cachefiles: ================= ==================================================== objeto sin referencia 0xffff9b674176e3c0 (tamaño 192): comm "cachefilesd2", pid 680, jiffies 4294881224 volcado hexadecimal (primeros 32 bytes): 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ retroceso (crc ea38a44b): [ ] kmem_cache_alloc+0x2d5/0x370 [] prepare_creds+0x26/0x2e0 [] cachefiles_determine_cache_security+0x1f/0x120 [] cachefiles_add_cache+0x13c/0x 3a0 [] cachefiles_daemon_write+0x146/0x1c0 [ ] vfs_write+0xcb/0x520 [] ksys_write+0x69/0xf0 [] do_syscall_64+0x72/0x140 [] Entry_SYSCALL_64_after_hwframe+0x6e/0x76 =============== ==================================================== == Coloque el recuento de referencias de cache_cred en cachefiles_daemon_unbind() para solucionar el problema. Y también coloque cache_cred en la rama de error cachefiles_add_cache() para evitar pérdidas de memoria.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: LoongArch: actualice cpu_sibling_map al deshabilitar las CPU que no son de arranque. Actualice cpu_sibling_map al deshabilitar las CPU que no son de arranque definiendo y llamando a clear_cpu_sibling_map(); de lo contrario, obtenemos este tipo de errores en los sistemas SMT: etiqueta de salto: recuento negativo. ADVERTENCIA: CPU: 6 PID: 45 en kernel/jump_label.c:263 __static_key_slow_dec_cpuslocked+0xec/0x100 CPU: 6 PID: 45 Comm: cpuhp/6 No contaminado 6.8.0-rc5+ #1340 pc 90000000004c302c ra 90000000004c3 02c tp 90000001005bc000 sp 90000001005bfd20 a0 000000000000001B A1 900000000224C278 A2 90000001005BFB58 A3 900000000224C280 A4 900000000224C278 A5 90000001005BFB50 A6 00000000000001 A7 00000000000001 T0 763EB5234A T2 0000000000000000 T3 000000000000000000 T4 000000000000000006 T5 00000000000000 T6 0000000000000064 T7 000000000000001964 T8 46a2d8 S1 fffffffffffffff S2 fffffffffffffff S3 90000000021518C0 S4 0000000000000040 S5 9000000002151058 S6 9000000009828e40 s7 00000000000000b4 s8 0000000000000006 ra: 90000000004c302c __static_key_slow_dec_cpuslocked+0xec/0x100 ERA: 90000000004c302c _key_slow_dec_cpuslocked+0xec/0x100 CRMD: 000000b0 (PLV0 -IE -DA +PG DACF=CC DACM=CC -WE) PRMD: 00000004 (PPLV0 +PIE -PWE ) EUEN: 00000000 (-FPE -SXE -ASXE -BTE) ECFG: 00071c1c (LIE=2-4,10-12 VS=7) ESTAT: 000c0000 [BRK] (IS= ECode=12 EssubCode=0) PRID: 0014d000 (Loongson-64bit, Loongson-3A6000-HV) CPU: 6 PID: 45 Comm: CPUHP/6 No contaminado 6.8.0-RC5+ #1340 Pila: 000000000000000000 90000000000203F258 90000000000179AFC8 90000005BC000 900001005BF980 005bf988 900000000001FE0BE0 900000000224C280 90000000000224C278 9000000001005BF8C0 0000000000000001 0000000000000001 CE87A4763EB5234A 0000000007F38000 90000000033F8CA0000000000000000000000000000000000 MUTITOS. 0000000000000006 0000000000000000 4C206E6F73676E6F 6F4C203A656D616E 000000000009EC99 0000000007F38000 000000000000000000000000214BECT 0000000000000009 FFFFFFFFFFFAFDABE 00000000000000B4 000000000000000006 90000000004C302C 9000000000224528 00005555939A0C7C 0000000000000000B0 00000000000004 4528>] show_stack+0x48/0x1a0 [<900000000179AFC8>] dump_stack_lvl+0x78/0xa0 [ <9000000000263ed0>] __warn+0x90/0x1a0 [<90000000017419b8>] report_bug+0x1b8/0x280 [<900000000179c564>] do_bp+0x264/0x420 [<90000000004c302c>] __static_key_slow_dec_cpuslocked+0xec/0x100 [<90000000002b4d7c>] sched_cpu_deactivate+0x2fc/0x300 [ <9000000000266498>] cpuhp_invoke_callback+0x178/0x8a0 [<9000000000267f70>] cpuhp_thread_fun+0xf0/0x240 [<90000000002a117c>] smpboot_thread_fn+0x1dc/0x2e0 [<900000000029a720>] kthread+0x140/0x160 [<9000000000222288>] ret_from_kernel_thread+0xc/0xa4

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: scsi: ufs: core: solucione el problema de cambio en ufshcd_clear_cmd() Cuando task_tag >= 32 (en modo MCQ) y sizeof(unsigned int) == 4, 1U << task_tag será fuera de los límites para una máscara u32. Solucione esto para evitar SHIFT_ISSUE (desplazamientos bit a bit que están fuera de los límites de su tipo de datos). [nombre:debug_monitors&]Excepción inesperada de BRK del kernel en EL1 [nombre:traps&]Error interno: controlador BRK: 00000000f2005514 [#1] PREEMPT SMP [nombre:mediatek_cpufreq_hw&]cpufreq detiene el registro DVFS hecho [nombre:mrdump&]Kernel Offset: 0x1ba5800000 de 0xffffffc0 08000000 [nombre:mrdump&]PHYS_OFFSET: 0x80000000 [nombre:mrdump&]pstate: 22400005 (nzCv daif +PAN -UAO) [nombre:mrdump&]pc: [0xffffffdbaf52bb2c] ufshcd_clear_cmd+0x280/0x288 [nombre:mrdump&]lr: [0xffffffdbaf52 a774] ufshcd_wait_for_dev_cmd +0x3e4/0x82c [nombre:mrdump&]sp: ffffffc0081471b0 Cola de trabajo: ufs_eh_wq_0 ufshcd_err_handler Rastreo de llamadas: dump_backtrace+0xf8/0x144 show_stack+0x18/0x24 dump_stack_lvl+0x78/0x9c dump_stack+0x1 8/0x44 mrdump_common_die+0x254/0x480 [mrdump] ipanic_die+0x20/0x30 [mrdump] notify_die+0x15c/0x204 die+0x10c/0x5f8 arm64_notify_die+0x74/0x13c do_debug_exception+0x164/0x26c el1_dbg+0x64/0x80 el1h_64_sync_handler+0x3c/0x90 el 1h_64_sync+0x68/0x6c ufshcd_clear_cmd+0x280/0x288 ufshcd_wait_for_dev_cmd+ 0x3e4/0x82c ufshcd_exec_dev_cmd+0x5bc/0x9ac ufshcd_verify_dev_init+0x84/0x1c8 ufshcd_probe_hba+0x724/0x1ce0 ufshcd_host_reset_and_restore+0x260/0x574 ufshcd_reset_and_restore+0x13 8/0xbd0 ufshcd_err_handler+0x1218/0x2f28 proceso_one_work+0x5fc/0x1140 trabajador_thread+0x7d8/0xe20 kthread+0x25c/0x468 ret_from_fork+ 0x10/0x20

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: plataforma/x86: think-lmi: corrige el orden del código de operación de contraseña para las estaciones de trabajo Las estaciones de trabajo Lenovo requieren que se ejecute el código de operación de la contraseña antes de cambiar el valor del atributo (si la contraseña de administrador está habilitada). Probado en algunos Thinkpads para confirmar que también están de acuerdo con este pedido.

Vulnerabilidad de falta de autorización en Mitchell Bennis Simple File List. Este problema afecta a Simple File List: desde n/a hasta 6.1.9.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: medios: rc: bpf adjunto/detach requiere permiso de escritura. Tenga en cuenta que bpf adjunto/detach también requiere CAP_NET_ADMIN.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: iio: core: corrige memleak en iio_device_register_sysfs Cuando falla iio_device_register_sysfs_group(), debemos liberar iio_dev_opaque->chan_attr_group.attrs para evitar posibles fugas de mem.

Vulnerabilidad de autorización faltante en Prasidhda Malla Honeypot for WP Comment. Este problema afecta a Honeypot para comentarios de WP: desde n/a hasta 2.2.3.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: herramientas/rtla: Repare la advertencia de clang sobre el tamaño de var de mount_point clang informa esta advertencia: $ make HOSTCC=clang CC=clang LLVM_IAS=1 [...] clang -O -g -DVERSION=\"6.8.0-rc3\" -flto=auto -fExceptions -fstack-protector-strong -fasynchronous-unwind-tables -fstack-clash-protection -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE= 2 -Wp,-D_GLIBCXX_ASSERTIONS $(pkg-config --cflags libtracefs) -c -o src/utils.o src/utils.c src/utils.c:548:66: advertencia: 'fscanf' puede desbordarse; el búfer de destino en el argumento 3 tiene un tamaño 1024, pero el especificador correspondiente puede requerir un tamaño 1025 [-Wfortify-source] 548 | while (fscanf(fp, "%*s %" STR(MAX_PATH) "s %99s %*s %*d %*d\n", punto_montaje, tipo) == 2) { | ^ Aumente el tamaño de la variable mount_point a MAX_PATH+1 para evitar el desbordamiento.

Motivo del rechazo: este ID CVE ha sido rechazado o retirado por su autoridad de numeración CVE.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: hv_netvsc: registre VF en netvsc_probe si se perdió NET_DEVICE_REGISTER. Si el controlador hv_netvsc se descarga y se vuelve a cargar, el controlador NET_DEVICE_REGISTER no puede realizar el registro VF exitosamente ya que la llamada de registro se recibe antes de que finalice netvsc_probe. Esto se debe a que registramos Register_netdevice_notifier() muy temprano (incluso antes de vmbus_driver_register()). Para solucionar este problema, intentamos registrar cada VF coincidente (si es visible como un dispositivo de red) al final de netvsc_probe.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: fs: relajar las comprobaciones de permisos de mount_setattr() Cuando agregamos mount_setattr(), agregué comprobaciones adicionales en comparación con los ayudantes heredados do_reconfigure_mnt() y do_change_type() utilizados por el mount(2) normal. Si ese montaje tenía un padre, verifique que la persona que llama y el espacio de nombres del montaje coincidan y, de lo contrario, asegúrese de que sea un montaje anónimo. Los rootfs reales no entran en ninguna de las dos categorías. No es un montaje anónimo porque obviamente está adjunto al espacio de nombres de montaje inicial pero obviamente tampoco tiene un montaje principal. Eso significa que el montaje heredado (2) permite cambiar las propiedades de montaje en los rootfs reales, pero mount_setattr (2) bloquea esto. Nunca pensé mucho en esto pero, por supuesto, alguien en este planeta tierra cambia las propiedades de las raíces reales como se puede ver en [1]. Dado que util-linux finalmente cambió a la nueva API de montaje en 2.39 no hace mucho, también depende de mount_setattr() y surgió este problema cuando Fedora 39 finalmente cambió a ella. Arregla esto.