Vulnerabilidades

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: nilfs2: corrige un bloqueo en nilfs_lookup_dirty_data_buffers() Syzbot informó un problema de bloqueo en migrar_pages_batch() llamado por mbind() y nilfs_lookup_dirty_data_buffers() llamado en el escritor de registros de nilfs2. Mientras migrar_pages_batch() bloquea una publicación y espera a que se complete la reescritura, el subproceso del escritor de registros que debería completar la reescritura recoge la publicación que se está reescribiendo en nilfs_lookup_dirty_data_buffers() que solicita la creación de registros posteriores y estaba intentando bloquear la fol. Provocando así un punto muerto. En primer lugar, es inesperado que los folios/páginas en medio de la reescritura se actualicen y se ensucien. Nilfs2 agrega una suma de verificación para verificar la validez del registro que se está escribiendo y la usa para la recuperación en el montaje, de modo que se suprimen los cambios de datos durante la reescritura. Dado que esto no funciona, un cierre incorrecto podría provocar que falle la recuperación. La investigación reveló que la causa principal es que la espera para que se complete la reescritura en nilfs_page_mkwrite() es condicional, y si el dispositivo de respaldo no requiere escrituras estables, los datos se pueden modificar sin esperar. Solucione estos problemas haciendo que nilfs_page_mkwrite() espere a que finalice la reescritura independientemente del requisito de escritura estable del dispositivo de respaldo.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: nilfs2: corrige la corrupción de datos en la recuperación de bloques dsync para tamaños de bloques pequeños La función auxiliar nilfs_recovery_copy_block() de nilfs_recovery_dsync_blocks(), que recupera datos de los registros creados por escrituras de sincronización de datos durante un montaje después un apagado incorrecto calcula incorrectamente el desplazamiento en la página al copiar los datos de reparación en la memoria caché de la página del archivo. En entornos donde el tamaño del bloque es menor que el tamaño de la página, esta falla puede causar corrupción de datos y pérdida de bytes de memoria no inicializados durante el proceso de recuperación. Solucione estos problemas corrigiendo este cálculo de desplazamiento de bytes en la página.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: hv_netvsc: corrige la condición de ejecución entre netvsc_probe y netvsc_remove En el commit ac5047671758 ("hv_netvsc: deshabilite NAPI antes de cerrar el canal VMBus"), se llamaba a napi_disable para todos los canales, incluidos todos los subcanales sin confirmando si están habilitados o no. Esto provocó que hv_netvsc se colgara en napi_disable, cuando netvsc_probe() terminó de ejecutarse pero nvdev->subchan_work aún no se inició. netvsc_subchan_work() -> rndis_set_subchannel() no ha creado los subcanales y por eso netvsc_sc_open() no se está ejecutando. netvsc_remove() llama a cancel_work_sync(&nvdev->subchan_work), para lo cual netvsc_subchan_work no se ejecutó. netif_napi_add() establece el bit NAPI_STATE_SCHED porque garantiza que NAPI no se pueda programar. Luego netvsc_sc_open() -> napi_enable borrará el bit NAPIF_STATE_SCHED, para que pueda programarse. napi_disable() hace lo contrario. Ahora, durante netvsc_device_remove(), cuando se llama a napi_disable para esos subcanales, napi_disable se atasca en msleep infinito. Esta solución soluciona este problema garantizando que no se llame a napi_disable() para una estructura NAPI no habilitada. Pero netif_napi_del() sigue siendo necesario para estas estructuras NAPI no habilitadas con fines de limpieza. Rastreo de llamadas: [654.559417] tarea:modprobe estado:D pila: 0 pid: 2321 ppid: 1091 banderas:0x00004002 [654.568030] Rastreo de llamadas: [654.571221] [654.573790] __schedule+0x2d6/0x960 [ 65 4.577733] horario+0x69 /0xf0 [654.581214] Schedule_timeout+0x87/0x140 [654.585463]? __bpf_trace_tick_stop+0x20/0x20 [ 654.590291] msleep+0x2d/0x40 [ 654.593625] napi_disable+0x2b/0x80 [ 654.597437] netvsc_device_remove+0x8a/0x1f0 [hv_netvsc] [ 6 54.603935] rndis_filter_device_remove+0x194/0x1c0 [hv_netvsc] [654.611101]? do_wait_intr+0xb0/0xb0 [ 654.615753] netvsc_remove+0x7c/0x120 [hv_netvsc] [ 654.621675] vmbus_remove+0x27/0x40 [hv_vmbus]

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: drm/amd/display: corrige el índice de matriz fuera de los límites en dcn35_clkmgr [Por qué] Existe una posible infracción de acceso a la memoria al iterar a través de una matriz de clks dcn35. [Cómo] Limitar la iteración por tamaño de matriz.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: fs/proc: do_task_stat: use sig->stats_lock para recopilar las estadísticas de subprocesos/hijos lock_task_sighand() puede desencadenar un bloqueo completo. Si los subprocesos NR_CPUS llaman a do_task_stat() al mismo tiempo y el proceso tiene NR_THREADS, girará con irqs deshabilitados O(NR_CPUS * NR_THREADS) tiempo. Cambie do_task_stat() para usar sig->stats_lock para recopilar las estadísticas fuera de ->sección protegida siglock, en el caso probable de que este código se ejecute sin bloqueo.

*** Pendiente de traducción *** Rejected reason: **REJECT** Duplicate of CVE-2023-46784. Please refer to CVE-2023-46784.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: can: j1939: Reparar UAF en j1939_sk_match_filter durante setsockopt(SO_J1939_FILTER) Bloquear jsk->sk para evitar UAF cuando setsockopt(..., SO_J1939_FILTER, ...) modifica jsk-> filtros mientras recibe paquetes. Se vio el siguiente rastro en el sistema afectado: ============================================ ======================== ERROR: KASAN: slab-use-after-free en j1939_sk_recv_match_one+0x1af/0x2d0 [can_j1939] Lectura de tamaño 4 en dirección ffff888012144014 por tarea j1939/350 CPU: 0 PID: 350 Comm: j1939 Contaminado: GW OE 6.5.0-rc5 #1 Nombre de hardware: PC estándar QEMU (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/ 01/2014 Seguimiento de llamadas: print_report+0xd3/0x620 ? kasan_complete_mode_report_info+0x7d/0x200 ? j1939_sk_recv_match_one+0x1af/0x2d0 [can_j1939] kasan_report+0xc2/0x100 ? j1939_sk_recv_match_one+0x1af/0x2d0 [can_j1939] __asan_load4+0x84/0xb0 j1939_sk_recv_match_one+0x1af/0x2d0 [can_j1939] j1939_sk_recv+0x20b/0x320 [can_j1939] ? __kasan_check_write+0x18/0x20? __pfx_j1939_sk_recv+0x10/0x10 [can_j1939] ? j1939_simple_recv+0x69/0x280 [can_j1939] ? j1939_ac_recv+0x5e/0x310 [can_j1939] j1939_can_recv+0x43f/0x580 [can_j1939] ? __pfx_j1939_can_recv+0x10/0x10 [can_j1939] ? raw_rcv+0x42/0x3c0 [puede_raw]? __pfx_j1939_can_recv+0x10/0x10 [can_j1939] can_rcv_filter+0x11f/0x350 [puede] can_receive+0x12f/0x190 [puede]? __pfx_can_rcv+0x10/0x10 [puede] can_rcv+0xdd/0x130 [puede] ? __pfx_can_rcv+0x10/0x10 [puede] __netif_receive_skb_one_core+0x13d/0x150 ? __pfx___netif_receive_skb_one_core+0x10/0x10 ? __kasan_check_write+0x18/0x20? _raw_spin_lock_irq+0x8c/0xe0 __netif_receive_skb+0x23/0xb0 Process_backlog+0x107/0x260 __napi_poll+0x69/0x310 net_rx_action+0x2a1/0x580 ? __pfx_net_rx_action+0x10/0x10 ? __pfx__raw_spin_lock+0x10/0x10? handle_irq_event+0x7d/0xa0 __do_softirq+0xf3/0x3f8 do_softirq+0x53/0x80 __local_bh_enable_ip+0x6e/0x70 netif_rx+0x16b/0x180 can_send+0x32b/0x520 [can] ? __pfx_can_send+0x10/0x10 [puede]? __check_object_size+0x299/0x410 raw_sendmsg+0x572/0x6d0 [can_raw]? __pfx_raw_sendmsg+0x10/0x10 [can_raw]? apparmor_socket_sendmsg+0x2f/0x40? __pfx_raw_sendmsg+0x10/0x10 [can_raw] sock_sendmsg+0xef/0x100 sock_write_iter+0x162/0x220 ? __pfx_sock_write_iter+0x10/0x10? __rtnl_unlock+0x47/0x80? permiso_archivo_seguridad+0x54/0x320 vfs_write+0x6ba/0x750 ? __pfx_vfs_write+0x10/0x10? __fget_light+0x1ca/0x1f0 ? __rcu_read_unlock+0x5b/0x280 ksys_write+0x143/0x170 ? __pfx_ksys_write+0x10/0x10? __kasan_check_read+0x15/0x20 ? fpregs_assert_state_consistent+0x62/0x70 __x64_sys_write+0x47/0x60 do_syscall_64+0x60/0x90 ? do_syscall_64+0x6d/0x90? irqentry_exit+0x3f/0x50? exc_page_fault+0x79/0xf0 Entry_SYSCALL_64_after_hwframe+0x6e/0xd8 Asignado por la tarea 348: kasan_save_stack+0x2a/0x50 kasan_set_track+0x29/0x40 kasan_save_alloc_info+0x1f/0x30 __kasan_kmalloc+0xb5/0xc0 __kmalloc_node_track_caller+0x67/0x160 j1939_sk_setsockopt+0x284/0x450 [can_j1939] __sys_setsockopt+ 0x15c/0x2f0 __x64_sys_setsockopt+0x6b/0x80 do_syscall_64+0x60/0x90 Entry_SYSCALL_64_after_hwframe+0x6e/0xd8 Liberado por la tarea 349: kasan_save_stack+0x2a/0x50 kasan_set_track+0x29/0x40 ka san_save_free_info+0x2f/0x50 __kasan_slab_free+0x12e/0x1c0 __kmem_cache_free+0x1b9/0x380 kfree+ 0x7a/0x120 j1939_sk_setsockopt+0x3b2/0x450 [can_j1939] __sys_setsockopt+0x15c/0x2f0 __x64_sys_setsockopt+0x6b/0x80 do_syscall_64+0x60/0x90 Entry_SYSCALL_64_after_h wframe+0x6e/0xd8

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: can: j1939: previene el interbloqueo cambiando j1939_socks_lock a rwlock Los siguientes 3 bloqueos competirían entre sí, causando la situación de interbloqueo en el informe de error de Syzbot: - j1939_socks_lock - active_session_list_lock - sk_session_queue_lock A Una solución razonable es cambiar j1939_socks_lock por un rwlock, ya que en las raras situaciones en las que se requiere un bloqueo de escritura para la lista vinculada que j1939_socks_lock está protegiendo, el código no intenta adquirir más bloqueos. Esto rompería la dependencia del bloqueo circular, donde, por ejemplo, el subproceso actual ya bloquea j1939_socks_lock e intenta adquirir sk_session_queue_lock y, al mismo tiempo, otro subproceso intenta adquirir j1939_socks_lock mientras mantiene sk_session_queue_lock. NOTA: Este parche no soluciona el error unregister_netdevice informado por Syzbot; en cambio, resuelve una situación de punto muerto para prepararse para uno o más parches adicionales para corregir el error Syzbot, que parece ser un problema de conteo de referencias dentro del código base j1939. [mkl: eliminar cambio de nueva línea no relacionado]

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: KVM: s390: vsie: corrige la ejecución durante la creación de la sombra. En este momento es posible ver que gmap->private es cero en kvm_s390_vsie_gmap_notifier, lo que provoca un bloqueo. Esto se debe al hecho de que agregamos gmap->private == kvm después de la creación: static int adquirir_gmap_shadow(struct kvm_vcpu *vcpu, struct vsie_page *vsie_page) { [...] gmap = gmap_shadow(vcpu->arch.gmap, asce, edat); si (IS_ERR(gmap)) devuelve PTR_ERR(gmap); gmap->privado = vcpu->kvm; Deje que los niños hereden el campo privado del padre.

Se ha encontrado una vulnerabilidad en SourceCodester Internship Portal Management System 1.0. Ha sido declarada crítica. Esta vulnerabilidad afecta al código desconocido del archivo admin/delete_activity.php. La manipulación del argumento id_actividad conduce a la inyección SQL. El ataque se puede iniciar de forma remota. El exploit ha sido divulgado al público y puede utilizarse. El identificador de esta vulnerabilidad es VDB-259108.

Se encontró una falla de desreferencia de puntero NULL en KubeVirt. Esta falla permite que un atacante que tiene acceso a una máquina virtual invitada en un nodo con DownwardMetrics habilitado provoque una denegación de servicio al emitir una gran cantidad de llamadas a vm-dump-metrics --virtio y luego eliminar la máquina virtual.

Existe una vulnerabilidad de validación de entrada incorrecta en la funcionalidad de configuración de usuario del motor OAS de Open Automation Software OAS Platform V19.00.0057. Una serie de solicitudes de red especialmente manipuladas pueden generar datos inesperados en la configuración. Un atacante puede enviar una secuencia de solicitudes para desencadenar esta vulnerabilidad.