Vulnerabilidades

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: fusible: borre FR_SENT al volver a agregar solicitudes a la lista pendiente Lee bruce informó la siguiente advertencia: ------------[ cortar aquí ]- ----------- ADVERTENCIA: CPU: 0 PID: 8264 en fs/fuse/dev.c:300 fuse_request_end+0x685/0x7e0 fs/fuse/dev.c:300 Módulos vinculados en: CPU: 0 PID: 8264 Comm: ab2 No contaminado 6.9.0-rc7 Nombre del hardware: PC estándar QEMU (i440FX + PIIX, 1996) RIP: 0010:fuse_request_end+0x685/0x7e0 fs/fuse/dev.c:300 ...... Seguimiento de llamadas: fuse_dev_do_read.constprop.0+0xd36/0x1dd0 fs/fuse/dev.c:1334 fuse_dev_read+0x166/0x200 fs/fuse/dev.c:1367 call_read_iter include/linux/fs.h:2104 [en línea ] new_sync_read fs/read_write.c:395 [en línea] vfs_read+0x85b/0xba0 fs/read_write.c:476 ksys_read+0x12f/0x260 fs/read_write.c:619 do_syscall_x64 arch/x86/entry/common.c:52 [en línea ] do_syscall_64+0xce/0x260 arch/x86/entry/common.c:83 Entry_SYSCALL_64_after_hwframe+0x77/0x7f ...... La advertencia se debe a la notificación FUSE_NOTIFY_RESEND enviada por la llamada al sistema write() en el reproductor programa y sucede de la siguiente manera: (1) llama a fuse_dev_read() para leer la solicitud INIT La lectura se realiza correctamente. Durante la lectura, se establecerá el bit FR_SENT en la solicitud. (2) llama a fuse_dev_write() para enviar una notificación USE_NOTIFY_RESEND. La notificación de reenvío reenviará todas las solicitudes de procesamiento, por lo que la solicitud INIT se mueve nuevamente de la lista de procesamiento a la lista pendiente. (3) llama a fuse_dev_read() con una dirección de salida no válida. fuse_dev_read() intentará copiar la misma solicitud INIT a la dirección de salida, pero fallará debido a la dirección no válida, por lo que la solicitud INIT finaliza y activa la advertencia en fuse_request_end (). Solucionelo borrando FR_SENT al volver a agregar solicitudes a la lista pendiente.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: usb: gadget: u_audio: se corrigió el uso de los controles en condiciones de ejecución después de liberarse durante la desvinculación del gadget. Conserve las ID de control en lugar de los punteros, ya que se manejan correctamente con candados.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: dmaengine: idxd: evita la destrucción innecesaria de file_ida file_ida se asigna durante la apertura de cdev y se libera en consecuencia durante el lanzamiento de cdev. Esta secuencia está garantizada por las operaciones del archivo del controlador. Por lo tanto, no es necesario destruir un file_ida que ya está vacío cuando se elimina WQ cdev. Peor aún, ida_free() en la versión cdev puede ocurrir después de la destrucción de file_ida según WQ cdev. Esto puede llevar a acceder a una identificación en file_ida después de haber sido destruida, lo que resulta en un pánico en el kernel. Elimine ida_destroy(&file_ida) para solucionar estos problemas.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: watchdog: cpu5wdt.c: corrige el error de use-after-free causado por cpu5wdt_trigger Cuando se elimina el módulo cpu5wdt, el código de origen usa del_timer() para desactivar el temporizador. Si el controlador del temporizador se está ejecutando, del_timer() no pudo detenerlo y regresará directamente. Si la región del puerto es liberada por release_region() y luego el controlador del temporizador cpu5wdt_trigger() llama a outb() para escribir en la región que se libera, se producirá el error de use-after-free. Cambie del_timer() a timer_shutdown_sync() para que el controlador del temporizador pueda finalizar antes de que se libere la región del puerto.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: iio: adc: PAC1934: corrige el acceso al índice de matriz fuera de los límites. Se corrige el acceso al índice de matriz fuera de los límites para mediciones promedio de corriente y voltaje. El dispositivo en sí tiene sólo 4 canales, pero en sysfs también hay canales "falsos" para voltajes y corrientes promedio.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: vfio/pci: corrige una posible pérdida de memoria en vfio_intx_enable() Si falla vfio_irq_ctx_alloc(), se producirá una pérdida de memoria del 'nombre'.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: medios: stk1160: revisión de los límites fijos en stk1160_copy_video() La resta en esta condición se invierte. La ->longitud es la longitud del búfer. El ->byteused es cuántos bytes hemos copiado hasta ahora. Cuando la condición se invierte, eso significa que el resultado de la resta siempre es negativo, pero como no tiene signo, el resultado es un valor positivo muy alto. Eso significa que la verificación de desbordamiento nunca es cierta. Además, ->bytesused en realidad no funciona para este propósito porque no estamos escribiendo en "buf->mem + buf->bytesused". En cambio, las matemáticas para calcular el destino donde estamos escribiendo son un poco complicadas. Calcula el número de líneas completas ya escritas, multiplica por dos, omite una línea si es necesario para comenzar en una línea impar y agrega el desplazamiento a la línea. Para solucionar este desbordamiento del búfer, simplemente tome el destino real donde estamos escribiendo, si el desplazamiento ya está fuera de los límites imprima un error y regrese. De lo contrario, escriba hasta buf->bytes de longitud.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: clase stm: corrige un doble free en stm_register_device() La llamada put_device(&stm->dev) activará stm_device_release() que libera "stm" para que vfree(stm) en el La siguiente línea es un doble libre.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: netfilter: tproxy: rescate si se ha deshabilitado la IP en el dispositivo syzbot informa: falla de protección general, probablemente para dirección no canónica 0xdffffc0000000003: 0000 [#1] PREEMPT SMP KASAN PTI KASAN: null-ptr-deref en el rango [0x0000000000000018-0x000000000000001f] [..] RIP: 0010:nf_tproxy_laddr4+0xb7/0x340 net/ipv4/netfilter/nf_tproxy_ipv4.c:62 Seguimiento de llamadas: nft_tproxy_ eval_v4 net/netfilter/nft_tproxy.c: 56 [en línea] nft_tproxy_eval+0xa9a/0x1a00 net/netfilter/nft_tproxy.c:168 __in_dev_get_rcu() puede devolver NULL, así que verifique esto.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: net/mlx5: utilice mlx5_ipsec_rx_status_destroy para eliminar correctamente las reglas de estado. rx_create ya no asigna una instancia de modifique_hdr que debe limpiarse. La llamada mlx5_modify_header_dealloc dará lugar a una desreferencia del puntero NULL. Anteriormente también se produjo una fuga en las reglas, ya que ahora hay dos reglas relacionadas con el estado. ERROR: desreferencia del puntero NULL del kernel, dirección: 0000000000000000 #PF: acceso de lectura del supervisor en modo kernel #PF: código_error(0x0000) - página no presente PGD 109907067 P4D 109907067 PUD 116890067 PMD 0 Ups: 0000 [#1] SMP CPU: 1 PID: 484 Comm: ip Not tainted 6.9.0-rc2-rrameshbabu+ #254 Nombre del hardware: PC estándar QEMU (Q35 + ICH9, 2009), BIOS Arch Linux 1.16.3-1-1 01/04/2014 RIP: 0010: mlx5_modify_header_dealloc+0xd/0x70 Seguimiento de llamadas: ? mostrar_regs+0x60/0x70? __morir+0x24/0x70 ? page_fault_oops+0x15f/0x430? free_to_partial_list.constprop.0+0x79/0x150? do_user_addr_fault+0x2c9/0x5c0? exc_page_fault+0x63/0x110? asm_exc_page_fault+0x27/0x30? mlx5_modify_header_dealloc+0xd/0x70 rx_create+0x374/0x590 rx_add_rule+0x3ad/0x500 ? rx_add_rule+0x3ad/0x500? mlx5_cmd_exec+0x2c/0x40? mlx5_create_ipsec_obj+0xd6/0x200 mlx5e_accel_ipsec_fs_add_rule+0x31/0xf0 mlx5e_xfrm_add_state+0x426/0xc00

En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: net: relajación del estado del socket en el momento de la aceptación. Christoph informó el siguiente símbolo: ADVERTENCIA: CPU: 1 PID: 772 en net/ipv4/af_inet.c:761 __inet_accept+0x1f4/0x4a0 Módulos vinculados en: CPU: 1 PID: 772 Comunicaciones: syz-executor510 No contaminado 6.9.0- rc7-g7da7119fe22b #56 Nombre del hardware: PC estándar QEMU (i440FX + PIIX, 1996), BIOS 1.11.0-2.el7 01/04/2014 RIP: 0010:__inet_accept+0x1f4/0x4a0 net/ipv4/af_inet.c:759 Código: 04 38 84 c0 0f 85 87 00 00 00 41 c7 04 24 03 00 00 00 48 83 c4 10 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc e8 ec b7 da fd <0f> 0b 7f fe ff ff e8 e0 b7 da fd 0f 0b e9 fe fe ff ff 89 d9 80 RSP: 0018:ffffc90000c2fc58 EFLAGS: 00010293 RAX: ffffffff836bdd14 RBX: 0000000000000000 RCX: ffff88810466 8000 RDX: 0000000000000000 RSI: 00000000000000000 RDI: 0000000000000000 RBP: dffffc0000000000 R08: ffffffff836bdb89 R09: fffff52000185f64 R10: dffffc0000000000 R11: fffff52000185f64 R12: dffffc0000000000 R13: 1ffff92000185f98 R14: ffff88810754d880 R15: 7b7800 FS: 000000001c772880(0000) GS:ffff88811b280000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fb9fcf2e178 CR3: 00000001045d2002 CR4: 0000000000770ef0 DR0: 0000000000000000 DR1: 00000000000000000 DR2: 0000000000000000 DR3: 000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Seguimiento de llamadas: inet_accept+0x138/0x1d0 net/ipv4/af_inet.c:786 do_accept+ 0x435/0x620 net/socket.c:1929 __sys_accept4_file net/socket.c:1969 [en línea] __sys_accept4+0x9b/0x110 net/socket.c:1999 __do_sys_accept net/socket.c:2016 [en línea] __se_sys_accept net/socket.c : 2013 [en línea] __x64_sys_accept+0x7d/0x90 net/Socket.c: 2013 do_syscall_x64 arch/x86/entry/comunes.c: 52 [inline] do_syscall_64+0x58/0x100 arch/x86/entry/comunes 0x76/0x7e RIP: 0033:0x4315f9 Código: fd ff 48 81 c4 80 00 00 00 e9 f1 fe ff ff 0f 1f 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 ab b4 fd ff c3 66 2e 0f 1f 84 00 00 00 00 RSP: 002b:00007ffdb26d9c78 EFLAGS: 00000246 ORIG_RAX: 000000000000002 b RAX: ffffffffffffffda RBX: 0000000000400300 RCX: 00000000004315f9 RDX: 0000000000000000 RSI : 0000000000000000 RDI: 0000000000000004 RBP: 00000000006e1018 R08: 0000000000400300 R09: 0000000000400300 R10: 0000000000400300 1: 0000000000000246 R12: 0000000000000000 R13: 000000000040cdf0 R14: 000000000040ce80 R15: 0000000000000055 El reproductor invoca el apagado() antes de ingresar al estado de escucha. Después de confirmar 94062790aedb ("tcp: aplazar el apagado (SEND_SHUTDOWN) para sockets TCP_SYN_RECV"), lo anterior hace que el niño alcance la llamada al sistema de aceptación en el estado FIN_WAIT1. Eric notó que podemos relajar la afirmación existente en __inet_accept()

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: tls: corrige la barrera de memoria faltante en tls_init En tls_init(), falta una barrera de memoria de escritura y el reordenamiento tienda-tienda puede causar una desreferencia NULL en tls_{setsockopt,getsockopt}. CPU0 CPU1 ----- ----- // En tls_init() // En tls_ctx_create() ctx = kzalloc() ctx->sk_proto = READ_ONCE(sk->sk_prot) -(1) // En update_sk_prot( ) WRITE_ONCE(sk->sk_prot, tls_prots) -(2) // En sock_common_setsockopt() READ_ONCE(sk->sk_prot)->setsockopt() // En tls_{setsockopt,getsockopt}() ctx->sk_proto->setsockopt () -(3) En el escenario anterior, cuando (1) y (2) se reordenan, (3) puede observar el valor NULL de ctx->sk_proto, lo que provoca la desreferencia NULL. Para solucionarlo, confiamos en rcu_assign_pointer() que implica la semántica de barrera de liberación. Al mover rcu_assign_pointer() después de inicializar ctx->sk_proto, podemos asegurarnos de que ctx->sk_proto sean visibles al cambiar sk->sk_prot.