Vulnerabilidades

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: RDMA/cma: corrija kmemleak en rdma_core observado durante el uso de blktests nvme/rdma siw Al ejecutar blktests nvme/rdma, aparecerá el siguiente problema de kmemleak. kmemleak: detector de pérdida de memoria del kernel inicializado (mempool disponible: 36041) kmemleak: hilo de escaneo automático de memoria iniciado kmemleak: 2 nuevas pérdidas de memoria sospechosas (ver /sys/kernel/debug/kmemleak) kmemleak: 8 nuevas pérdidas de memoria sospechosas (ver /sys/ kernel/debug/kmemleak) kmemleak: 17 nuevas pérdidas de memoria sospechosas (ver /sys/kernel/debug/kmemleak) kmemleak: 4 nuevas pérdidas de memoria sospechosas (ver /sys/kernel/debug/kmemleak) objeto sin referencia 0xffff88855da53400 (tamaño 192): comm "rdma", pid 10630, sjiffies 4296575922 volcado hexadecimal (primeros 32 bytes): 37 00 00 00 00 00 00 00 c0 ff ff ff 1f 00 00 00 7................. 10 34 a5 5d 85 88 ff ff 10 34 a5 5d 85 88 ff ff .4.].....4.].... backtrace (crc 47f66721): [] kmalloc_trace+0x30d/0x3b0 [< ffffffffc2640ff7>] alloc_gid_entry+0x47/0x380 [ib_core] [] add_modify_gid+0x166/0x930 [ib_core] [] ib_cache_update.part.0+0x6d8/0x910 [ib_core] [] ib_cache_setup_one+0x24a/ 0x350 [ib_core] [] ib_register_device+0x9e/0x3a0 [ib_core] [] 0xffffffffc2a3d389 [] nldev_newlink+0x2b8/0x520 [ib_core] ffffffffc2645fe3>] rdma_nl_rcv_msg+0x2c3/0x520 [ib_core] [ ] rdma_nl_rcv_skb.constprop.0.isra.0+0x23c/0x3a0 [ib_core] [] netlink_unicast+0x445/0x710 [] 0 [] __sys_sendto+0x3a9/0x420 [] __x64_sys_sendto+0xdc/0x1b0 [] do_syscall_64+0x93/0x180 [] Entry_SYSCALL_64_after_hwframe+0x71/0x79 La causa raíz: _gid_attr no se llama cuando sgid_attr está configurado en ERR_PTR(-ENODEV).

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: lib/test_hmm.c: maneja el error de asignación de src_pfns y dst_pfns El kcalloc() en dmirror_device_evict_chunk() devolverá nulo si la memoria física se ha agotado. Como resultado, si se desreferencia src_pfns o dst_pfns, se producirá el error de desreferencia del puntero nulo. Además, el dispositivo va a desaparecer. Si kcalloc() falla, las páginas que asignan un fragmento no podrán ser desalojadas. Entonces agregue una bandera __GFP_NOFAIL en kcalloc(). Finalmente, como no es necesario tener memoria físicamente contigua, cambie kcalloc() a kvcalloc() para evitar asignaciones fallidas.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm: vc4: corrige posible desreferencia del puntero nulo En vc4_hdmi_audio_init() of_get_address() puede devolver NULL, que luego se desreferencia. Corrija este error agregando una verificación NULL. Encontrado por el Centro de verificación de Linux (linuxtesting.org) con SVACE.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: media: atomisp: ssh_css: corrige una desreferencia de puntero nulo en load_video_binaries La falla de asignación de mycs->yuv_scaler_binary en load_video_binaries() va seguida de una desreferencia de mycs->yuv_scaler_binary después de siguiente cadena de llamadas: sh_css_pipe_load_binaries() |-> load_video_binaries(mycs->yuv_scaler_binary == NULL) | |-> sh_css_pipe_unload_binaries() |-> unload_video_binaries() En unload_video_binaries(), llama a ia_css_binary_unload con el argumento &pipe->pipe_settings.video.yuv_scaler_binary[i], que se refiere a la misma ranura de memoria que mycs->yuv_scaler_binary. Por lo tanto, se activa una desreferencia de puntero nulo.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: RDMA/hns: corrige UAF para el evento cq async El recuento de CQ no está protegido por bloqueos. Cuando los eventos asincrónicos de CQ y la destrucción de CQ son simultáneos, es posible que se haya liberado CQ, lo que provocará UAF. Utilice xa_lock() para proteger el recuento de CQ.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: RDMA/mana_ib: verificación de los límites antes de instalar devoluciones de llamadas de cq Agregue una verificación de los límites dentro de mana_ib_install_cq_cb para evitar el desbordamiento del índice.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bnxt_re: evita el comportamiento de cambio indefinido en bnxt_qplib_alloc_init_hwq El comportamiento indefinido se activa cuando se llama a bnxt_qplib_alloc_init_hwq con hwq_attr->aux_ Depth != 0 y hwq_attr->aux_stride == 0. En ese caso, " Se llama a roundup_pow_of_two(hwq_attr->aux_stride)". roundup_pow_of_two está documentado como indefinido para 0. Corríjalo en la única persona que llamó que tenía esta combinación. UBSAN detectó el comportamiento indefinido: UBSAN: desplazamiento fuera de los límites en ./include/linux/log2.h:57:13 el exponente de desplazamiento 64 es demasiado grande para CPU 'long unsigned int' de tipo de 64 bits: 24 PID: 1075 Comm: (udev-worker) Not tainted 6.9.0-rc6+ #4 Nombre del hardware: Abacus electric, sro - servis@abacus.cz Super Server/H12SSW-iN, BIOS 2.7 25/10/2023 Seguimiento de llamadas: < TAREA> dump_stack_lvl+0x5d/0x80 ubsan_epilogue+0x5/0x30 __ubsan_handle_shift_out_of_bounds.cold+0x61/0xec __roundup_pow_of_two+0x25/0x35 [bnxt_re] bnxt_qplib_alloc_init_hwq+0xa1/0x470 bnxt_re] bnxt_qplib_create_qp+0x19e/0x840 [bnxt_re] bnxt_re_create_qp+0x9b1/0xcd0 [bnxt_re ] ? srso_alias_return_thunk+0x5/0xfbef5? srso_alias_return_thunk+0x5/0xfbef5? __kmalloc+0x1b6/0x4f0 ? create_qp.part.0+0x128/0x1c0 [ib_core]? __pfx_bnxt_re_create_qp+0x10/0x10 [bnxt_re] create_qp.part.0+0x128/0x1c0 [ib_core] ib_create_qp_kernel+0x50/0xd0 [ib_core] create_mad_qp+0x8e/0xe0 [ib_core] ? __pfx_qp_event_handler+0x10/0x10 [ib_core] ib_mad_init_device+0x2be/0x680 [ib_core] add_client_context+0x10d/0x1a0 [ib_core] enable_device_and_get+0xe0/0x1d0 [ib_register_device+0x53c/0x63 0 [ib_core] ? srso_alias_return_thunk+0x5/0xfbef5 bnxt_re_probe+0xbd8/0xe50 [bnxt_re] ? __pfx_bnxt_re_probe+0x10/0x10 [bnxt_re] sonda_bus_auxiliar+0x49/0x80 ? driver_sysfs_add+0x57/0xc0 realmente_probe+0xde/0x340? pm_runtime_barrier+0x54/0x90? __pfx___driver_attach+0x10/0x10 __driver_probe_device+0x78/0x110 driver_probe_device+0x1f/0xa0 __driver_attach+0xba/0x1c0 bus_for_each_dev+0x8f/0xe0 bus_add_driver+0x146/0x220 driver_register+0x72/ 0xd0 __auxiliary_driver_register+0x6e/0xd0 ? __pfx_bnxt_re_mod_init+0x10/0x10 [bnxt_re] bnxt_re_mod_init+0x3e/0xff0 [bnxt_re] ? __pfx_bnxt_re_mod_init+0x10/0x10 [bnxt_re] do_one_initcall+0x5b/0x310 do_init_module+0x90/0x250 init_module_from_file+0x86/0xc0 idempotent_init_module+0x121/0x2b0 __x64_sys_finit _module+0x5e/0xb0 do_syscall_64+0x82/0x160 ? srso_alias_return_thunk+0x5/0xfbef5? syscall_exit_to_user_mode_prepare+0x149/0x170? srso_alias_return_thunk+0x5/0xfbef5? syscall_exit_to_user_mode+0x75/0x230? srso_alias_return_thunk+0x5/0xfbef5? do_syscall_64+0x8e/0x160? srso_alias_return_thunk+0x5/0xfbef5? __count_memcg_events+0x69/0x100? srso_alias_return_thunk+0x5/0xfbef5? count_memcg_events.constprop.0+0x1a/0x30? srso_alias_return_thunk+0x5/0xfbef5? handle_mm_fault+0x1f0/0x300? srso_alias_return_thunk+0x5/0xfbef5? do_user_addr_fault+0x34e/0x640? srso_alias_return_thunk+0x5/0xfbef5? srso_alias_return_thunk+0x5/0xfbef5 Entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7f4e5132821d Código: ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 9 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d e3 db 0c 00 f7 d8 64 89 01 48 RSP: 002b:00007ffca9c906a8 EFLAGS: 00000246 IG_RAX: 0000000000000139 RAX: ffffffffffffffda RBX: 0000563ec8a8f130 RCX: 00007f4e5132821d RDX: 0000000000000000 RSI: 00007f4e518fa07d RDI: 000000000000003b RBP: 00007ffca9c90760 R08: 00007f4e513f6b20 00007ffca9c906f0 R10: 0000563ec8a8faa0 R11: 0000000000000246 R12: 00007f4e518fa07d R13: 0000000000020000 R14: 0000563ec8409e90 R15: 0563ec8a8fa60 ---[ finalizar rastreo ] ---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: of: módulo: agregar control de desbordamiento del búfer of_modalias() En of_modalias(), si el búfer es demasiado pequeño incluso para la primera llamada a snprintf(), el parámetro len se vuelve negativo y el parámetro str (si no es NULL inicialmente) apuntará más allá del final del búfer. Agregue la verificación de desbordamiento del búfer después de la primera llamada a snprintf() y corrija dicha verificación después de la llamada strlen() (teniendo en cuenta el carácter NUL de terminación).

Vulnerabilidad de autorización faltante en ThemeFusion Fusion Builder. Este problema afecta a Fusion Builder: desde n/a hasta 3.11.1.

Un usuario con altos privilegios, al que se le permite crear paquetes de osquery personalizados 17, podría afectar la disponibilidad de Kibana al cargar un paquete de osquery creado con fines malintencionados.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: net: bridge: mst: fix vlan use-after-free syzbot informó un uso sospechoso de rcu[1] en el código mst del puente. Mientras lo solucionaba, noté que nada impide que se libere una VLAN mientras se recorre la lista desde el mismo camino (br temporizador de retardo de avance). Corrija el uso de rcu y también asegúrese de que no accedamos a la memoria liberada haciendo que br_mst_vlan_set_state use el bloqueo de lectura de rcu. [1] ADVERTENCIA: uso sospechoso de RCU 6.9.0-rc6-syzkaller #0 No contaminado ----------------------- net/ bridge/br_private.h:1599 ¡uso sospechoso de rcu_dereference_protected()! ... seguimiento de pila: CPU: 1 PID: 8017 Comm: syz-executor.1 No contaminado 6.9.0-rc6-syzkaller #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 27/03/2024 Llamada Seguimiento: __dump_stack lib/dump_stack.c:88 [en línea] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114 lockdep_rcu_suspicious+0x221/0x340 kernel/locking/lockdep.c:6712 nbp_vlan_group net/bridge/br_private.h :1599 [en línea] br_mst_set_state+0x1ea/0x650 net/bridge/br_mst.c:105 br_set_state+0x28a/0x7b0 net/bridge/br_stp.c:47 br_forward_delay_timer_expired+0x176/0x440 net/bridge/br_stp_timer.c:88 n+0x18e /0x650 kernel/time/timer.c:1793 expire_timers kernel/time/timer.c:1844 [en línea] __run_timers kernel/time/timer.c:2418 [en línea] __run_timer_base+0x66a/0x8e0 kernel/time/timer.c: 2429 run_timer_base kernel/time/timer.c:2438 [en línea] run_timer_softirq+0xb7/0x170 kernel/time/timer.c:2448 __do_softirq+0x2c6/0x980 kernel/softirq.c:554 invoke_softirq kernel/softirq.c:428 [en línea ] __irq_exit_rcu+0xf2/0x1c0 kernel/softirq.c:633 irq_exit_rcu+0x9/0x30 kernel/softirq.c:645 instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1043 [en línea] 0xc0 arco/x86 /kernel/apic/apic.c:1043 asm_sysvec_apic_timer_interrupt+0x1a/0x20 arch/x86/include/asm/idtentry.h:702 RIP: 0010:lock_acquire+0x264/0x550 kernel/locking/lockdep. c:5758 Código: 2b 00 74 08 4c 89 f7 e8 ba d1 84 00 f6 44 24 61 02 0f 85 85 01 00 00 41 f7 c7 00 02 00 00 74 01 fb 48 c7 44 24 40 0e 36 e0 <4b> c7 44 25 00 00 00 00 00 43 c7 44 25 09 00 00 00 00 43 c7 44 25 RSP: 0018:ffffc90013657100 EFLAGS: 00000206 RAX: 0000000000000001 RBX: ffff920026cae2c RCX: 0000000000000001 RDX: dffffc0000000000 RSI: ffffffff8bcaca00 RDI: ffffffff8c1eaa60 RBP: ffffc90013657260 R08: ffffffff92efe507 R09: 1ffffffff25dfca0 R10: dffffc0000000000 R11: ffffbfff25dfca1 R12: 1ffff920026cae28 R13: dffffc0000000000 R14: ffffc90013657160 5: 0000000000000246

IBM Storage Protect for Virtual Environments: Data Protection for VMware 8.1.0.0 a 8.1.22.0 podría permitir a un atacante autenticado remoto eludir las restricciones de seguridad causadas por una validación inadecuada del permiso del usuario. Al enviar una solicitud especialmente manipulada, un atacante podría aprovechar esta vulnerabilidad para cambiar su configuración, activar copias de seguridad, restaurar copias de seguridad y también eliminar todas las copias de seguridad anteriores mediante la rotación de registros. ID de IBM X-Force: 294994.