Vulnerabilidades

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.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: virtio: eliminar vq en vp_find_vqs_msix() cuando request_irq() falla Cuando request_irq() falla, la ruta de error llama a vp_del_vqs(). Allí, como vq está presente en la lista, se llama a free_irq() para el mismo vector. Eso provoca el siguiente símbolo: [0.414355] Intentando liberar IRQ 27 que ya está libre [0.414403] ADVERTENCIA: CPU: 1 PID: 1 en kernel/irq/manage.c:1899 free_irq+0x1a1/0x2d0 [0.414510] Módulos vinculados en: [ 0.414540] CPU: 1 PID: 1 Comunicaciones: swapper/0 No contaminado 6.9.0-rc4+ #27 [ 0.414540] Nombre de hardware: PC estándar QEMU (i440FX + PIIX, 1996), BIOS 1.16.3-1.fc39 04/01 /2014 [0.414540] RIP: 0010:free_irq+0x1a1/0x2d0 [0.414540] Código: 1e 00 48 83 c4 08 48 89 e8 5b 5d 41 5c 41 5d 41 5e 41 5f c3 cc cc cc 90 8b 74 24 04 48 c7 c7 98 80 6c b1 e8 00 c9 f7 ff 90 <0f> 0b 90 90 48 89 ee 4c 89 ef e8 e0 20 b8 00 49 8b 47 40 48 8b 40 [ 0.414540] RSP: 0000:ffffb71480013ae0 EFLAGS: 00010086 [0,414540] RAX : 0000000000000000 RBX: ffffa099c2722000 RCX: 0000000000000000 [ 0.414540] RDX: 0000000000000000 RSI: ffffb71480013998 RDI: 0000000000000 001 [ 0.414540] RBP: 0000000000000246 R08: 00000000ffffdfff R09: 0000000000000001 [ 0.414540] R10: 00000000ffffdfff R11: fffffffb18729c0 fffa099c1c91760 [ 0.414540] R13: fffa099c1c916a4 R14: ffffa099c1d2f200 R15: ffffa099c1c91600 [ 0.414540] FS: 0000000000000000(0000) GS:ffffa099fec40000(0000) knlGS:0000000000000000 [ 0.41454 0] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 0.414540] CR2: 0000000000000000 CR3: 0000000008e3e001 CR4: 0000000000370ef0 [0.414540] Seguimiento de llamadas: [0.414540] [0.414540]? __advertir+0x80/0x120 [0.414540]? free_irq+0x1a1/0x2d0 [0.414540]? report_bug+0x164/0x190 [0.414540]? handle_bug+0x3b/0x70 [0.414540]? exc_invalid_op+0x17/0x70 [0.414540]? asm_exc_invalid_op+0x1a/0x20 [0.414540]? free_irq+0x1a1/0x2d0 [ 0.414540] vp_del_vqs+0xc1/0x220 [ 0.414540] vp_find_vqs_msix+0x305/0x470 [ 0.414540] vp_find_vqs+0x3e/0x1a0 [ 0.414540 ] vp_modern_find_vqs+0x1b/0x70 [ 0.414540] init_vqs+0x387/0x600 [ 0.414540] virtnet_probe+ 0x50a/0xc80 [0.414540] virtio_dev_probe+0x1e0/0x2b0 [0.414540]realmente_probe+0xc0/0x2c0 [0.414540]? __pfx___driver_attach+0x10/0x10 [ 0.414540] __driver_probe_device+0x73/0x120 [ 0.414540] driver_probe_device+0x1f/0xe0 [ 0.414540] __driver_attach+0x88/0x180 [ 0.414540] _for_each_dev+0x85/0xd0 [ 0.414540] bus_add_driver+0xec/0x1f0 [ 0.414540] driver_register+ 0x59/0x100 [0,414540]? __pfx_virtio_net_driver_init+0x10/0x10 [ 0.414540] virtio_net_driver_init+0x90/0xb0 [ 0.414540] do_one_initcall+0x58/0x230 [ 0.414540] kernel_init_freeable+0x1a3/0x2d0 [ 0.41 4540] ? __pfx_kernel_init+0x10/0x10 [0.414540] kernel_init+0x1a/0x1c0 [0.414540] ret_from_fork+0x31/0x50 [0.414540]? __pfx_kernel_init+0x10/0x10 [ 0.414540] ret_from_fork_asm+0x1a/0x30 [ 0.414540] Solucione este problema llamando a eliminar el vq actual cuando request_irq() falla.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ALSA: hda/cs_dsp_ctl: use private_free para la limpieza del control. Use la devolución de llamada de control private_free para liberar el bloque de datos asociado. Esto garantiza que la memoria no se pierda, sea cual sea la forma en que se destruya el control. La implementación original en realidad no eliminó los controles ALSA en hda_cs_dsp_control_remove(). Sólo liberó la estructura de seguimiento interna. Esto significaba que era posible quitar/descargar el controlador del amplificador dejando sus controles ALSA todavía presentes en la tarjeta de sonido. Obviamente, intentar acceder a ellos podría provocar errores de segmentación o al menos eliminar la referencia a punteros obsoletos.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/msm/a6xx: evite una desreferencia de nullptr cuando falla la configuración de speedbin. Llamar a a6xx_destroy() antes de adreno_gpu_init() conduce a una desreferencia de puntero nulo en: msm_gpu_cleanup() : platform_set_drvdata(gpu- >pdev, NULO); ya que gpu->pdev solo se asigna en: a6xx_gpu_init() |_ adreno_gpu_init |_ msm_gpu_init() En lugar de depender de comprobaciones nulas manuales en la cadena de limpieza, desasigne explícitamente los datos LLC y libere a6xx_gpu en su lugar. Remiendo: https://patchwork.freedesktop.org/patch/588919/

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: null_blk: corrige la dereferencia null-ptr al configurar 'power' y 'submit_queues'. Escribir 'power' y 'submit_queues' simultáneamente provocará un pánico en el kernel: Script de prueba: modprobe null_blk nr_devices= 0 mkdir -p /sys/kernel/config/nullb/nullb0 mientras sea verdadero; hacer eco 1 > enviar_queues; eco 4 > enviar_colas; hecho y mientras sea cierto; hacer eco 1 > potencia; eco 0 > potencia; hecho Resultado de la prueba: ERROR: desreferencia del puntero NULL del kernel, dirección: 0000000000000148 Ups: 0000 [#1] RIP SMP PREEMPLEADO: 0010:__lock_acquire+0x41d/0x28f0 Seguimiento de llamada: lock_acquire+0x121/0x450 down_write+0x5f/0x1d0 simple_recursive _eliminación+ 0x12f/0x5c0 blk_mq_debugfs_unregister_hctxs+0x7c/0x100 blk_mq_update_nr_hw_queues+0x4a3/0x720 nullb_update_nr_hw_queues+0x71/0xf0 [null_blk] /0xf0 [null_blk] configfs_write_iter+0x119/0x1e0 vfs_write+0x326/0x730 ksys_write+0x74/0x150 Esto se debe a que del_gendisk() puede concurrente con blk_mq_update_nr_hw_queues(): nullb_device_power_store nullb_apply_submit_queues null_del_dev del_gendisk nullb_update_nr_hw_queues if (!dev->nullb) // todavía está configurado mientras se elimina gendisk return 0 blk_mq_update_nr_hw_queues dev->nullb = NULL Fix este problema reutilizando el mutex global para proteger nullb_device_power_store() y nullb_update_nr_hw_queues() de configfs.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: netfilter: nfnetlink_queue: adquirir rcu_read_lock() en instancia_destroy_rcu() syzbot informó que se podía llamar a nf_reinject() sin rcu_read_lock() : ADVERTENCIA: uso sospechoso de RCU 6.9.0-rc7-syzkaller -02060-g5c1672705a1a #0 ¡No está contaminado net/netfilter/nfnetlink_queue.c:263 uso sospechoso de rcu_dereference_check()! otra información que podría ayudarnos a depurar esto: rcu_scheduler_active = 2, debug_locks = 1 2 bloqueos mantenidos por syz-executor.4/13427: #0: ffffffff8e334f60 (rcu_callback){....}-{0:0}, en: rcu_lock_acquire include/linux/rcupdate.h:329 [en línea] #0: ffffffff8e334f60 (rcu_callback){....}-{0:0}, en: rcu_do_batch kernel/rcu/tree.c:2190 [en línea] #0 : ffffffff8e334f60 (rcu_callback){....}-{0:0}, en: rcu_core+0xa86/0x1830 kernel/rcu/tree.c:2471 #1: ffff88801ca92958 (&inst->lock){+.-.} -{2:2}, en: spin_lock_bh include/linux/spinlock.h:356 [en línea] #1: ffff88801ca92958 (&inst->lock){+.-.}-{2:2}, en: nfqnl_flush net/ netfilter/nfnetlink_queue.c:405 [en línea] #1: ffff88801ca92958 (&inst->lock){+.-.}-{2:2}, en: instancia_destroy_rcu+0x30/0x220 net/netfilter/nfnetlink_queue.c:172 pila backtrace: CPU: 0 PID: 13427 Comm: syz-executor.4 No contaminado 6.9.0-rc7-syzkaller-02060-g5c1672705a1a #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Llamada de Google 02/04/2024 Trace: __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 nf_filt. C :323 [en línea] nfqnl_reinject+0x6ec/0x1120 net/netfilter/nfnetlink_queue.c:397 nfqnl_flush net/netfilter/nfnetlink_queue.c:410 [en línea] instancia_destroy_rcu+0x1ae/0x220 net/netfilter/nfnetlink_queue.c:172 do_batch kernel/rcu /tree.c:2196 [en línea] rcu_core+0xafd/0x1830 kernel/rcu/tree.c:2471 handle_softirqs+0x2d6/0x990 kernel/softirq.c:554 __do_softirq kernel/softirq.c:588 [en línea] invoke_softirq kernel/softirq .c:428 [en línea] __irq_exit_rcu+0xf4/0x1c0 kernel/softirq.c:637 irq_exit_rcu+0x9/0x30 kernel/softirq.c:649 instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1043 [en línea] r_interrupción+ 0xa6/0xc0 arch/x86/kernel/apic/apic.c:1043

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: tcp: corrige el desplazamiento fuera de los límites en dctcp_update_alpha(). En dctcp_update_alpha(), utilizamos un parámetro de módulo dctcp_shift_g de la siguiente manera: alpha -= min_not_zero(alpha, alpha >> dctcp_shift_g); ... entregado_ce <<= (10 - dctcp_shift_g); Parece que syzkaller comenzó a modificar los parámetros del módulo y activó el desplazamiento fuera de los límites [0] estableciendo 100 en dctcp_shift_g: memcpy((void*)0x20000080, "/sys/module/tcp_dctcp/parameters/dctcp_shift_g\000", 47) ; res = syscall(__NR_openat, /*fd=*/0xffffffffffffff9cul, /*file=*/0x20000080ul, /*flags=*/2ul, /*mode=*/0ul); memcpy((void*)0x20000000, "100\000", 4); syscall(__NR_write, /*fd=*/r[0], /*val=*/0x20000000ul, /*len=*/4ul); Limitemos el valor máximo de dctcp_shift_g mediante param_set_uint_minmax(). Con este parche: # echo 10 > /sys/module/tcp_dctcp/parameters/dctcp_shift_g # cat /sys/module/tcp_dctcp/parameters/dctcp_shift_g 10 # echo 11 > /sys/module/tcp_dctcp/parameters/dctcp_shift_g -bash: echo: error de escritura: argumento no válido [0]: UBSAN: desplazamiento fuera de los límites en net/ipv4/tcp_dctcp.c:143:12 el exponente de desplazamiento 100 es demasiado grande para el tipo 'u32' de 32 bits (también conocido como 'int sin signo' ) CPU: 0 PID: 8083 Comm: syz-executor345 No contaminado 6.9.0-05151-g1b294a1f3561 #2 Nombre del hardware: PC estándar QEMU (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 01/04/2014 Seguimiento de llamadas: __dump_stack lib/dump_stack.c:88 [en línea] dump_stack_lvl+0x201/0x300 lib/dump_stack.c:114 ubsan_epilogue lib/ubsan.c:231 [en línea] __ubsan_handle_shift_out_of_bounds+0x346/0x3a0 lib/ubsan.c :468 dctcp_update_alpha+0x540/0x570 net/ipv4/tcp_dctcp.c:143 tcp_in_ack_event net/ipv4/tcp_input.c:3802 [en línea] tcp_ack+0x17b1/0x3bc0 net/ipv4/tcp_input.c:3948 v_state_process+0x57a/0x2290 neto/ ipv4/tcp_input.c:6711 tcp_v4_do_rcv+0x764/0xc40 net/ipv4/tcp_ipv4.c:1937 sk_backlog_rcv include/net/sock.h:1106 [en línea] __release_sock+0x20f/0x350 net/core/sock.c:2983 release_sock+ 0x61/0x1f0 net/core/sock.c:3549 mptcp_subflow_shutdown+0x3d0/0x620 net/mptcp/protocol.c:2907 mptcp_check_send_data_fin+0x225/0x410 net/mptcp/protocol.c:2976 __mptcp_close+0x238/0x ad0 net/mptcp/protocolo .c:3072 mptcp_close+0x2a/0x1a0 net/mptcp/protocol.c:3127 inet_release+0x190/0x1f0 net/ipv4/af_inet.c:437 __sock_release net/socket.c:659 [en línea] sock_close+0xc0/0x240 net/ socket.c:1421 __fput+0x41b/0x890 fs/file_table.c:422 task_work_run+0x23b/0x300 kernel/task_work.c:180 exit_task_work include/linux/task_work.h:38 [en línea] do_exit+0x9c8/0x2540 kernel/exit .c:878 do_group_exit+0x201/0x2b0 kernel/exit.c:1027 __do_sys_exit_group kernel/exit.c:1038 [en línea] __se_sys_exit_group kernel/exit.c:1036 [en línea] __x64_sys_exit_group+0x3f/0x40 kernel/exit.c:10 36 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xe4/0x240 arch/x86/entry/common.c:83 Entry_SYSCALL_64_after_hwframe+0x67/0x6f RIP: 0033:0x7f6c2b5005b6 Código: no se puede acceder a los bytes del código de operación en 0x7f6c2b50058c . RSP: 002b:00007ffe883eb948 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7 RAX: ffffffffffffffda RBX: 00007f6c2b5862f0 RCX: 00007f6c2b5005b6 RDX: 0000000001 RSI: 000000000000003c RDI: 0000000000000001 RBP: 0000000000000001 R08: 00000000000000e7 R09: ffffffffffffffc0 R10: 06 R11: 0000000000000246 R12: 00007f6c2b5862f0 R13: 0000000000000001 R14: 0000000000000000 R15: 0000000000000001

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: nfc: nci: corrigió el valor uninit en nci_rx_work syzbot informó el siguiente problema de acceso al valor uninit [1] nci_rx_work() analiza el paquete recibido de ndev->rx_q. Se debe validar el tamaño del encabezado, el tamaño del payload y el tamaño total del paquete antes de procesar el paquete. Si se detecta un paquete no válido, se debe descartar silenciosamente.