Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: sock_map: corrige una desreferencia de puntero NULL en sock_map_link_update_prog() La siguiente condición de ejecución podría desencadenar una desreferencia de puntero NULL: sock_map_link_detach(): sock_map_link_update_prog(): mutex_lock(&sockmap_mutex); ... sockmap_link->map = NULL; mutex_unlock(&sockmap_mutex); mutex_lock(&sockmap_mutex); ... sock_map_prog_link_lookup(sockmap_link->map); mutex_unlock(&sockmap_mutex); Solucione el problema añadiendo una comprobación de puntero NULL. En este caso específico, no tiene sentido actualizar un enlace que se está publicando.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: se corrige el fallo al configurar un gso_max_size/gso_ipv4_max_size pequeño. Configurar un gso_max_size/gso_ipv4_max_size pequeño provocará un desbordamiento en sk_dst_gso_max_size(), lo que puede desencadenar un fallo BUG_ON, porque sk->sk_gso_max_size sería mucho mayor que los límites del dispositivo. Seguimiento de llamadas: tcp_write_xmit tso_segs = tcp_init_tso_segs(skb, mss_now); tcp_set_skb_tso_segs tcp_skb_pcount_set // skb->len = 524288, mss_now = 8 // u16 tso_segs = 524288/8 = 65535 -> 0 tso_segs = DIV_ROUND_UP(skb->len, mss_now) BUG_ON(!tso_segs) Agregar verificación para el valor mínimo de gso_max_size y gso_ipv4_max_size.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: Bluetooth: hci: corregir null-ptr-deref en hci_read_supported_codecs Corregir __hci_cmd_sync_sk() para que no devuelva NULL para códigos de operación desconocidos. __hci_cmd_sync_sk() devuelve NULL si un comando devuelve un evento de estado. Sin embargo, también devuelve NULL cuando no existe un código de operación en la tabla hci_cc porque hci_cmd_complete_evt() asume status = skb->data[0] para códigos de operación desconocidos. Esto lleva a null-ptr-deref en cmd_sync para HCI_OP_READ_LOCAL_CODECS ya que no hay hci_cc para HCI_OP_READ_LOCAL_CODECS, que siempre asume status = skb->data[0]. KASAN: null-ptr-deref en el rango [0x0000000000000070-0x0000000000000077] CPU: 1 PID: 2000 Comm: kworker/u9:5 No contaminado 6.9.0-ga6bcb805883c-dirty #10 Nombre del hardware: PC estándar QEMU (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Cola de trabajo: hci7 hci_power_on RIP: 0010:hci_read_supported_codecs+0xb9/0x870 net/bluetooth/hci_codec.c:138 Código: 08 48 89 ef e8 b8 c1 8f fd 48 8b 75 00 e9 96 00 00 00 49 89 c6 48 ba 00 00 00 00 00 fc ff df 4c 8d 60 70 4c 89 e3 48 c1 eb 03 <0f> b6 04 13 84 c0 0f 85 82 06 00 00 41 83 3c 24 02 77 0a e8 bf 78 RSP: 0018:ffff888120bafac8 EFLAGS: 00010212 RAX: 000000000000000 RBX: 000000000000000e RCX: ffff8881173f0040 RDX: dffffc0000000000 RSI: ffffffffa58496c0 RDI: ffff88810b9ad1e4 RBP: ffff88810b9ac000 R08: ffffffffa77882a7 R09: 1ffffffff4ef1054 R10: dffffc0000000000 R11: fffffbfff4ef1055 R12: 0000000000000070 R13: 0000000000000000 R14: 0000000000000000 R15: ffff88810b9ac000 FS: 0000000000000000(0000) GS:ffff8881f6c00000(0000) knlGS:00000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f6ddaa3439e CR3: 0000000139764003 CR4: 0000000000770ef0 PKRU: 55555554 Seguimiento de llamadas: hci_read_local_codecs_sync net/bluetooth/hci_sync.c:4546 [en línea] hci_init_stage_sync net/bluetooth/hci_sync.c:3441 [en línea] hci_init4_sync net/bluetooth/hci_sync.c:4706 [en línea] hci_init_sync net/bluetooth/hci_sync.c:4742 [en línea] hci_dev_init_sync net/bluetooth/hci_sync.c:4912 [en línea] hci_dev_open_sync+0x19a9/0x2d30 net/bluetooth/hci_sync.c:4994 hci_dev_do_open net/bluetooth/hci_core.c:483 [en línea] hci_power_on+0x11e/0x560 net/bluetooth/hci_core.c:1015 proceso_uno_trabajo kernel/workqueue.c:3267 [en línea] proceso_trabajos_programados+0x8ef/0x14f0 kernel/workqueue.c:3348 subproceso de trabajo+0x91f/0xe50 kernel/workqueue.c:3429 subproceso de trabajo+0x2cb/0x360 kernel/kthread.c:388 ret_de_bifurcación+0x4d/0x80 arch/x86/kernel/process.c:147 ret_de_bifurcación_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: netfilter: nf_reject_ipv6: soluciona un posible fallo en nf_send_reset6() Recibí un informe de syzbot sin una reproducción [1] que falla en nf_send_reset6() Creo que el problema es que dev->hard_header_len es cero, e intentamos más tarde enviar un encabezado Ethernet. Utilice LL_MAX_HEADER, como otras funciones en net/ipv6/netfilter/nf_reject_ipv6.c. [1] skbuff: skb_under_panic: texto:ffffffff89b1d008 longitud:74 puesta:14 cabeza:ffff88803123aa00 datos:ffff88803123a9f2 cola:0x3c fin:0x140 desarrollo:syz_tun ERROR del kernel en net/core/skbuff.c:206 ! Oops: código de operación no válido: 0000 [#1] PREEMPT SMP KASAN PTI CPU: 0 UID: 0 PID: 7373 Comm: syz.1.568 No contaminado 6.12.0-rc2-syzkaller-00631-g6d858708d465 #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 13/09/2024 RIP: 0010:skb_panic net/core/skbuff.c:206 [en línea] RIP: 0010:skb_under_panic+0x14b/0x150 net/core/skbuff.c:216 Código: 0d 8d 48 c7 c6 60 a6 29 8e 48 8b 54 24 08 8b 0c 24 44 8b 44 24 04 4d 89 e9 50 41 54 41 57 41 56 e8 ba 30 38 02 48 83 c4 20 90 <0f> 0b 0f 1f 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 RSP: 0018:ffffc900045269b0 EFLAGS: 00010282 RAX: 000000000000088 RBX: dffffc0000000000 RCX: cd66dacdc5d8e800 RDX: 00000000000000000 RSI: 0000000000000200 RDI: 0000000000000000 RBP: ffff88802d39a3d0 R08: ffffffff8174afec R09: 1ffff920008a4ccc R10: dffffc0000000000 R11: fffff520008a4ccd R12: 0000000000000140 R13: ffff88803123aa00 R14: ffff88803123a9f2 R15: 000000000000003c FS: 00007fdbee5ff6c0(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 000000005d322000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Seguimiento de llamadas: skb_push+0xe5/0x100 net/core/skbuff.c:2636 eth_header+0x38/0x1f0 net/ethernet/eth.c:83 dev_hard_header include/linux/netdevice.h:3208 [en línea] nf_send_reset6+0xce6/0x1270 net/ipv6/netfilter/nf_reject_ipv6.c:358 nft_reject_inet_eval+0x3b9/0x690 net/netfilter/nft_reject_inet.c:48 expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [en línea] nft_do_chain+0x4ad/0x1da0 net/netfilter/nf_tables_core.c:288 nft_do_chain_inet+0x418/0x6b0 net/netfilter/nft_chain_filter.c:161 nf_hook_entry_hookfn incluye/linux/netfilter.h:154 [en línea] nf_hook_slow+0xc3/0x220 net/netfilter/core.c:626 nf_hook incluye/linux/netfilter.h:269 [en línea] NF_HOOK incluye/linux/netfilter.h:312 [en línea] br_nf_pre_routing_ipv6+0x63e/0x770 net/bridge/br_netfilter_ipv6.c:184 nf_hook_entry_hookfn include/linux/netfilter.h:154 [en línea] nf_hook_bridge_pre net/bridge/br_input.c:277 [en línea] br_handle_frame+0x9fd/0x1530 net/bridge/br_input.c:424 __netif_receive_skb_core+0x13e8/0x4570 net/core/dev.c:5562 __netif_receive_skb_one_core net/core/dev.c:5666 [en línea] __netif_receive_skb+0x12f/0x650 net/core/dev.c:5781 netif_receive_skb_internal net/core/dev.c:5867 [en línea] netif_receive_skb+0x1e8/0x890 net/core/dev.c:5926 tun_rx_batched+0x1b7/0x8f0 drivers/net/tun.c:1550 tun_get_user+0x3056/0x47e0 drivers/net/tun.c:2007 tun_chr_write_iter+0x10d/0x1f0 drivers/net/tun.c:2053 new_sync_write fs/read_write.c:590 [en línea] vfs_write+0xa6d/0xc90 fs/read_write.c:683 ksys_write+0x183/0x2b0 fs/read_write.c:736 do_syscall_x64 arch/x86/entry/common.c:52 [en línea] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fdbeeb7d1ff Código: 89 54 24 18 48 89 74 24 10 89 7c 24 08 e8 c9 8d 02 00 48 8b 54 24 18 48 8b 74 24 10 41 89 c0 8b 7c 24 08 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 31 44 89 c7 48 89 44 24 08 e8 1c 8e 02 00 48 RSP: 002b:00007fdbee5ff000 EFLAGS: 00000293 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 00007fdbeed36058 RCX: 00007fdbeeb7d1ff RDX: 00000000000008e RSI: 0000000020000040 RDI: 0000000000000c8 RBP: 00007fdbeebf12be R08: 0000000 ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: netfilter: Se corrige el problema use-after-free en la descarga del módulo ip6table_nat get_info() que tiene una advertencia refcnt para UAF. El seguimiento de llamadas es: ADVERTENCIA: CPU: 1 PID: 379 en kernel/module/main.c:853 module_put+0x6f/0x80 Módulos vinculados en: ip6table_nat(-) CPU: 1 UID: 0 PID: 379 Comm: ip6tables No contaminado 6.12.0-rc4-00047-gc2ee9f594da8-dirty #205 Nombre del hardware: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:module_put+0x6f/0x80 Seguimiento de llamadas: get_info+0x128/0x180 La ejecución simultánea de la descarga del módulo y get_info() activó la advertencia. La causa raíz es la siguiente: cpu0 cpu1 module_exit //mod->state = MODULE_STATE_GOING ip6table_nat_exit xt_unregister_template kfree(t) //eliminado de la lista de plantillas getinfo() t = xt_find_table_lock list_for_each_entry(tmpl, &xt_templates[af]...) if (strcmp(tmpl->name, name)) continue; //tabla no encontrada try_module_get list_for_each_entry(t, &xt_net->tables[af]...) return t; //no obtener refcnt module_put(t->me) //uaf unregister_pernet_subsys //eliminar tabla de la lista xt_net Mientras el módulo xt_table desaparecía y se eliminaba de la lista xt_templates, no pudimos obtener refcnt de xt_table->me. Verifique el módulo en el recorrido de lista xt_net->tables para solucionarlo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: netdevsim: agregar un cero final para terminar la cadena en nsim_nexthop_bucket_activity_write(). Esto lo encontró un analizador estático. No debemos olvidar el cero final después de copy_from_user() si vamos a realizar más operaciones con cadenas, sscanf() en este caso. Agregar un cero final garantizará que la función se ejecute correctamente.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: macsec: Se corrige el use-after-free al enviar el paquete de descarga KASAN informa el siguiente UAF. El metadata_dst, que se utiliza para almacenar el valor SCI para la descarga de macsec, ya está liberado por metadata_dst_free() en macsec_free_netdev(), mientras que el controlador aún lo usa para enviar el paquete. Para solucionar este problema, se utiliza dst_release() en su lugar para liberar metadata_dst. Por lo tanto, no se libera instantáneamente en macsec_free_netdev() si aún se hace referencia a él mediante skb. ERROR: KASAN: uso de losa después de la liberación en mlx5e_xmit+0x1e8f/0x4190 [mlx5_core] Lectura de tamaño 2 en la dirección ffff88813e42e038 por la tarea kworker/7:2/714 [...] Cola de trabajo: mld mld_ifc_work Seguimiento de llamadas: dump_stack_lvl+0x51/0x60 print_report+0xc1/0x600 kasan_report+0xab/0xe0 mlx5e_xmit+0x1e8f/0x4190 [mlx5_core] dev_hard_start_xmit+0x120/0x530 sch_direct_xmit+0x149/0x11e0 __qdisc_run+0x3ad/0x1730 __dev_queue_xmit+0x1196/0x2ed0 vlan_dev_hard_start_xmit+0x32e/0x510 [8021q] dev_hard_start_xmit+0x120/0x530 __dev_queue_xmit+0x14a7/0x2ed0 macsec_start_xmit+0x13e9/0x2340 dev_hard_start_xmit+0x120/0x530 __dev_queue_xmit+0x14a7/0x2ed0 ip6_finish_output2+0x923/0x1a70 ip6_finish_output+0x2d7/0x970 ip6_output+0x1ce/0x3a0 Asignado por la tarea 3922: kasan_save_stack+0x20/0x40 kasan_save_track+0x10/0x30 __kasan_kmalloc+0x77/0x90 __kmalloc_noprof+0x188/0x400 metadatos_dst_alloc+0x1f/0x4e0 macsec_newlink+0x914/0x1410 __rtnl_newlink+0xe08/0x15b0 rtnl_newlink+0x5f/0x90 rtnetlink_rcv_msg+0x667/0xa80 netlink_rcv_skb+0x12c/0x360 netlink_unicast+0x551/0x770 netlink_sendmsg+0x72d/0xbd0 __sock_sendmsg+0xc5/0x190 ____sys_sendmsg+0x52e/0x6a0 ___sys_sendmsg+0xeb/0x170 __sys_sendmsg+0xb5/0x140 do_syscall_64+0x4c/0x100 entry_SYSCALL_64_after_hwframe+0x4b/0x53 Liberado por la tarea 4011: kasan_save_stack+0x20/0x40 kasan_save_track+0x10/0x30 kasan_save_free_info+0x37/0x50 poison_slab_object+0x10c/0x190 __kasan_slab_free+0x11/0x30 kfree+0xe0/0x290 macsec_free_netdev+0x3f/0x140 netdev_run_todo+0x450/0xc70 rtnetlink_rcv_msg+0x66f/0xa80 netlink_rcv_skb+0x12c/0x360 netlink_unicast+0x551/0x770 netlink_sendmsg+0x72d/0xbd0 __sock_sendmsg+0xc5/0x190 ____sys_sendmsg+0x52e/0x6a0 ___sys_sendmsg+0xeb/0x170 __sys_sendmsg+0xb5/0x140 hacer_syscall_64+0x4c/0x100 entrada_SYSCALL_64_después_hwframe+0x4b/0x53

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf: Se corrige la escritura fuera de los límites en trie_get_next_key() trie_get_next_key() asigna una pila de nodos con tamaño trie->max_prefixlen, mientras escribe (trie->max_prefixlen + 1) nodos en la pila cuando tiene rutas completas desde la raíz hasta las hojas. Por ejemplo, considere un trie con max_prefixlen es 8, y los nodos con clave 0x00/0, 0x00/1, 0x00/2, ... 0x00/8 insertados. Las llamadas posteriores a trie_get_next_key con _key con .prefixlen = 8 hacen que se escriban 9 nodos en la pila de nodos con tamaño 8.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ntfs3: Agregar verificación de los límites a mi_enum_attr() Se agregó verificación de los límites para asegurarse de que cada atributo no se desvíe de una región de memoria válida.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: fs/ntfs3: Agregar comprobación aproximada del atributo alloc_size

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: fs/ntfs3: Se corrigió un error de protección general en run_is_mapped_full. Se corrigió la eliminación de un atributo no residente en la reversión de ntfs_create_inode().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: fs/ntfs3: Comprobación adicional en ni_clear() Se agregó la comprobación de NTFS_FLAGS_LOG_REPLAYING para evitar el acceso a un mapa de bits no inicializado durante el proceso de reproducción.