Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: vsock: Mantener la vinculación hasta la destrucción del socket Preservar las vinculaciones de los sockets; esto incluye tanto las resultantes de un bind() explícito como las vinculadas implícitamente a través de autobind durante connect(). Evita la desvinculación de sockets durante una reasignación de transporte, lo que soluciona un use after free: 1. vsock_create() (refcnt=1) calls vsock_insert_unbound() (refcnt=2) 2. transport->release() calls vsock_remove_bound() without checking if sk was bound and moved to bound list (refcnt=1) 3. vsock_bind() assumes sk is in unbound list and before __vsock_insert_bound(vsock_bound_sockets()) calls __vsock_remove_bound() which does: list_del_init(&vsk->bound_table); // nop sock_put(&vsk->sk); // refcnt=0 BUG: KASAN: slab-use-after-free in __vsock_bind+0x62e/0x730 Read of size 4 at addr ffff88816b46a74c by task a.out/2057 dump_stack_lvl+0x68/0x90 print_report+0x174/0x4f6 kasan_report+0xb9/0x190 __vsock_bind+0x62e/0x730 vsock_bind+0x97/0xe0 __sys_bind+0x154/0x1f0 __x64_sys_bind+0x6e/0xb0 do_syscall_64+0x93/0x1b0 entry_SYSCALL_64_after_hwframe+0x76/0x7e Allocated by task 2057: kasan_save_stack+0x1e/0x40 kasan_save_track+0x10/0x30 __kasan_slab_alloc+0x85/0x90 kmem_cache_alloc_noprof+0x131/0x450 sk_prot_alloc+0x5b/0x220 sk_alloc+0x2c/0x870 __vsock_create.constprop.0+0x2e/0xb60 vsock_create+0xe4/0x420 __sock_create+0x241/0x650 __sys_socket+0xf2/0x1a0 __x64_sys_socket+0x6e/0xb0 do_syscall_64+0x93/0x1b0 entry_SYSCALL_64_after_hwframe+0x76/0x7e Freed by task 2057: kasan_save_stack+0x1e/0x40 kasan_save_track+0x10/0x30 kasan_save_free_info+0x37/0x60 __kasan_slab_free+0x4b/0x70 kmem_cache_free+0x1a1/0x590 __sk_destruct+0x388/0x5a0 __vsock_bind+0x5e1/0x730 vsock_bind+0x97/0xe0 __sys_bind+0x154/0x1f0 __x64_sys_bind+0x6e/0xb0 do_syscall_64+0x93/0x1b0 entry_SYSCALL_64_after_hwframe+0x76/0x7e refcount_t: addition on 0; use-after-free. WARNING: CPU: 7 PID: 2057 at lib/refcount.c:25 refcount_warn_saturate+0xce/0x150 RIP: 0010:refcount_warn_saturate+0xce/0x150 __vsock_bind+0x66d/0x730 vsock_bind+0x97/0xe0 __sys_bind+0x154/0x1f0 __x64_sys_bind+0x6e/0xb0 do_syscall_64+0x93/0x1b0 entry_SYSCALL_64_after_hwframe+0x76/0x7e refcount_t: underflow; use-after-free. WARNING: CPU: 7 PID: 2057 at lib/refcount.c:28 refcount_warn_saturate+0xee/0x150 RIP: 0010:refcount_warn_saturate+0xee/0x150 vsock_remove_bound+0x187/0x1e0 __vsock_release+0x383/0x4a0 vsock_release+0x90/0x120 __sock_release+0xa3/0x250 sock_close+0x14/0x20 __fput+0x359/0xa80 task_work_run+0x107/0x1d0 do_exit+0x847/0x2560 do_group_exit+0xb8/0x250 __x64_sys_exit_group+0x3a/0x50 x64_sys_call+0xfec/0x14f0 do_syscall_64+0x93/0x1b0 entry_SYSCALL_64_after_hwframe+0x76/0x7e

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ipv6: mcast: agregar protección RCU a mld_newpack() mld_newpack() se puede llamar sin que se mantenga RTNL o RCU. Tenga en cuenta que ya no podemos usar sock_alloc_send_skb() porque ipv6.igmp_sk usa asignaciones GFP_KERNEL que pueden dormir. En su lugar, use alloc_skb() y cargue el socket net->ipv6.igmp_sk bajo la protección RCU.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ndisc: extender la protección de RCU en ndisc_send_skb() ndisc_send_skb() se puede llamar sin RTNL o RCU retenido. Adquiera rcu_read_lock() antes, para que podamos usar dev_net_rcu() y evitar un posible UAF.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: openvswitch: usar la protección RCU en ovs_vport_cmd_fill_info() ovs_vport_cmd_fill_info() se puede llamar sin RTNL o RCU. Use la protección RCU y dev_net_rcu() para evitar posibles UAF.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: arp: usar protección RCU en arp_xmit(). Se puede llamar a arp_xmit() sin protección RTNL o RCU. Use protección RCU para evitar posibles UAF.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: neighbor: use la protección RCU en __neigh_notify() __neigh_notify() se puede llamar sin RTNL ni protección RCU. Use la protección RCU para evitar posibles UAF.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: btrfs: no use btrfs_set_item_key_safe en extensiones de bandas RAID No use btrfs_set_item_key_safe() para modificar las claves en el árbol de bandas RAID, ya que esto puede provocar la corrupción del árbol, lo que es detectado por las comprobaciones en btrfs_set_item_key_safe(): Información de BTRFS (dispositivo nvme1n1): leaf 49168384 gen 15 total ptrs 194 free space 8329 owner 12 Información de BTRFS (dispositivo nvme1n1): refs 2 lock_owner 1030 current 1030 [ snip ] item 105 key (354549760 230 20480) itemoff 14587 itemsize 16 stride 0 devid 5 physical 67502080 elemento 106 clave (354631680 230 4096) itemoff 14571 tamaño del elemento 16 paso 0 devid 1 físico 88559616 elemento 107 clave (354631680 230 32768) itemoff 14555 tamaño del elemento 16 paso 0 devid 1 físico 88555520 elemento 108 clave (354717696 230 28672) itemoff 14539 tamaño del elemento 16 paso 0 devid 2 físico 67604480 [ snip ] BTRFS crítico (dispositivo nvme1n1): ranura 106 clave (354631680 230 32768) nueva clave (354635776 230 4096) ------------[ cortar aquí ]------------ ¡ERROR del kernel en fs/btrfs/ctree.c:2602! Oops: código de operación no válido: 0000 [#1] PREEMPT SMP PTI CPU: 1 UID: 0 PID: 1055 Comm: fsstress No contaminado 6.13.0-rc1+ #1464 Nombre del hardware: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.2-3-gd478f380-rebuilt.opensuse.org 01/04/2014 RIP: 0010:btrfs_set_item_key_safe+0xf7/0x270 Código: RSP: 0018:ffffc90001337ab0 EFLAGS: 00010287 RAX: 000000000000000 RBX: ffff8881115fd000 RCX: 0000000000000000 RDX: 0000000000000001 RSI: 000000000000001 RDI: 000000000ffffffff RBP: ffff888110ed6f50 R08: 00000000ffffefff R09: ffffffff8244c500 R10: 00000000ffffefff R11: 00000000ffffffff R12: ffff888100586000 R13: 00000000000000c9 R14: ffffc90001337b1f R15: ffff888110f23b58 FS: 00007f7d75c72740(0000) GS:ffff88813bd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fa811652c60 CR3: 0000000111398001 CR4: 0000000000370eb0 Seguimiento de llamadas: ? __die_body.cold+0x14/0x1a ? die+0x2e/0x50 ? do_trap+0xca/0x110 ? btrfs_set_item_key_safe+0xf7/0x270 ? exc_invalid_op+0x50/0x70 ? btrfs_set_item_key_safe+0xf7/0x270 ? asm_exc_invalid_op+0x1a/0x20 ? btrfs_set_item_key_safe+0xf7/0x270 btrfs_partially_delete_raid_extent+0xc4/0xe0 btrfs_delete_raid_extent+0x227/0x240 __btrfs_free_extent.isra.0+0x57f/0x9c0 ? exc_coproc_segment_overrun+0x40/0x40 __btrfs_run_delayed_refs+0x2fa/0xe80 btrfs_run_delayed_refs+0x81/0xe0 btrfs_commit_transaction+0x2dd/0xbe0 ? preempt_count_add+0x52/0xb0 btrfs_sync_file+0x375/0x4c0 do_fsync+0x39/0x70 __x64_sys_fsync+0x13/0x20 do_syscall_64+0x54/0x110 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7f7d7550ef90 Código: RSP: 002b:00007ffd70237248 EFLAGS: 00000202 ORIG_RAX: 000000000000004a RAX: ffffffffffffffda RBX: 000000000000004 RCX: 00007f7d7550ef90 RDX: 000000000000013a RSI: 000000000040eb28 RDI: 0000000000000004 RBP: 000000000000001b R08: 0000000000000078 R09: 00007ffd7023725c R10: 00007f7d75400390 R11: 0000000000000202 R12: 028f5c28f5c28f5c R13: 8f5c28f5c28f5c29 R14: 000000000040b520 R15: 00007f7d75c726c8 Si bien la causa raíz de la corrupción del orden del árbol no está clara, usar btrfs_duplicate_item() para copiar el elemento y luego ajustar tanto la clave como las direcciones físicas por dispositivo es una forma segura de contrarrestar este problema.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/ast: astdp: Se ha solucionado el problema del tiempo de espera para habilitar la señal de vídeo. El transmisor ASTDP a veces tarda hasta 1 segundo en habilitar la señal de vídeo, mientras que el tiempo de espera es de solo 200 ms. Esto da como resultado un mensaje de error del kernel. Aumente el tiempo de espera a 1 segundo. A continuación se muestra un ejemplo del mensaje de error. [ 697.084433] ------------[ cortar aquí ]------------ [ 697.091115] ast 0000:02:00.0: [drm] drm_WARN_ON(!__ast_dp_wait_enable(ast, enabled)) [ 697.091233] ADVERTENCIA: CPU: 1 PID: 160 en drivers/gpu/drm/ast/ast_dp.c:232 ast_dp_set_enable+0x123/0x140 [ast] [...] [ 697.272469] RIP: 0010:ast_dp_set_enable+0x123/0x140 [ast] [...] [ 697.415283] Seguimiento de llamadas: [ 697.420727] [ __warn.cold+0xaf/0xca [ 697.464713] ? ast_dp_set_enable+0x123/0x140 [ast] [ 697.472633] ? report_bug+0x134/0x1d0 [ 697.479544] ? handle_bug+0x58/0x90 [ 697.486127] ? exc_invalid_op+0x13/0x40 [ 697.492975] ? asm_exc_invalid_op+0x16/0x20 [ 697.500224] ? preempt_count_sub+0x14/0xc0 [ 697.507473] ? ast_dp_set_enable+0x123/0x140 [ast] [ 697.515377] ? ast_dp_set_enable+0x123/0x140 [ast] [ 697.523227] drm_atomic_helper_commit_modeset_enables+0x30a/0x470 [ 697.532388] drm_atomic_helper_commit_tail+0x58/0x90 [ 697.540400] ast_mode_config_helper_atomic_commit_tail+0x30/0x40 [ast] [ 697.550009] commit_tail+0xfe/0x1d0 [ 697.556547] drm_atomic_helper_commit+0x198/0x1c0 Este es un problema cosmético. La habilitación de la señal de video aún funciona incluso con el mensaje de error. El problema siempre ha estado presente, pero solo las versiones recientes del controlador ast advierten sobre la pérdida del tiempo de espera.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/mlx5: HWS, cambiar el flujo de error en la desconexión del comparador Actualmente, cuando ocurre una falla de firmware durante el flujo de desconexión del comparador, el flujo de error de la función vuelve a conectar el comparador y devuelve un error, que continúa ejecutando la función de llamada y finalmente libera el comparador que se está desconectando. Esto lleva a un caso en el que tenemos un comparador liberado en la lista de comparadores, lo que a su vez lleva a un use after free y un eventual bloqueo. Este parche lo corrige al no intentar volver a conectar el comparador cuando algún comando de FW falla durante la desconexión. Tenga en cuenta que aquí estamos tratando con un error de FW. No podemos superar este problema. Esto puede llevar a un mal estado de dirección (por ejemplo, conexión incorrecta entre comparadores) y también conducirá a una fuga de recursos, como es el caso con cualquier otro manejo de errores durante la destrucción de recursos. Sin embargo, el objetivo aquí es permitir que el controlador continúe y no bloquee la máquina con un error de use after free.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ksmbd: corrige desbordamientos de enteros en sistemas de 32 bits En sistemas de 32 bits, las operaciones de suma en ipc_msg_alloc() pueden potencialmente desbordarse y provocar daños en la memoria. Agregue la comprobación de los límites mediante KSMBD_IPC_MAX_PAYLOAD para evitar desbordamientos.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: rose: bloquear el socket en rose_bind() syzbot informó un bloqueo suave en rose_loopback_timer(), con una reproducción que llama a bind() desde múltiples subprocesos. rose_bind() debe bloquear el socket para evitar este problema.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: brcmfmac: comprobar el valor de retorno de of_property_read_string_index() En algún momento entre 6.10 y 6.11, el controlador comenzó a fallar en mi MacBookPro14,3. La propiedad no existe y 'tmp' permanece sin inicializar, por lo que pasamos un puntero aleatorio a devm_kstrdup(). El fallo que estoy teniendo se parece a esto: ERROR: no se puede manejar el error de página para la dirección: 00007f033c669379 PF: acceso de lectura del supervisor en modo kernel PF: error_code(0x0001) - violación de permisos PGD 8000000101341067 P4D 8000000101341067 PUD 101340067 PMD 1013bb067 PTE 800000010aee9025 Oops: Oops: 0001 [#1] SMP PTI CPU: 4 UID: 0 PID: 827 Comm: (udev-worker) No contaminado 6.11.8-gentoo #1 Nombre del hardware: Apple Inc. MacBookPro14,3/Mac-551B86E5744E2388, BIOS 529.140.2.0.0 23/06/2024 RIP: 0010:strlen+0x4/0x30 Código: f7 75 ec 31 c0 c3 cc cc cc cc 48 89 f8 c3 cc cc cc cc 0f 1f 40 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa <80> 3f 00 74 14 48 89 f8 48 83 c0 01 80 38 00 75 f7 48 29 f8 c3 cc RSP: 0018:ffffb4aac0683ad8 EFLAGS: 00010202 RAX: 00000000ffffffea RBX: 00007f033c669379 RCX: 0000000000000001 RDX: 0000000000000cc0 RSI: 00007f033c669379 RDI: 00007f033c669379 RBP: 00000000ffffffea R08: 0000000000000000 R09: 00000000c0ba916a R10: ffffffffffffffff R11: ffffffffb61ea260 R12: ffff91f7815b50c8 R13: 0000000000000cc0 R14: ffff91fafefffe30 R15: ffffb4aac0683b30 FS: 00007f033ccbe8c0(0000) GS:ffff91faeed00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f033c669379 CR3: 0000000107b1e004 CR4: 00000000003706f0 DR0: 0000000000000000 DR1: 00000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Seguimiento de llamadas: ? __die+0x23/0x70 ? page_fault_oops+0x149/0x4c0 ? raw_spin_rq_lock_nested+0xe/0x20 ? sched_balance_newidle+0x22b/0x3c0 ? update_load_avg+0x78/0x770 ? exc_page_fault+0x6f/0x150 ? asm_exc_page_fault+0x26/0x30 ? __pfx_pci_conf1_write+0x10/0x10 ? strlen+0x4/0x30 devm_kstrdup+0x25/0x70 brcmf_of_probe+0x273/0x350 [brcmfmac]