Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: mctp: paquetes no compartidos al reensamblar. Asegúrese de que la lista de fragmentos utilizada para el reensamblado no se comparta con otros paquetes. Esto evita un reensamblado incorrecto al clonar paquetes y previene una fuga de memoria debido a referencias circulares entre fragmentos y su skb_shared_info. El próximo controlador MCTP sobre USB utiliza skb_clone, lo que puede desencadenar el problema; otros controladores MCTP no comparten los SKB. Se ha añadido una prueba kunit para reproducir el problema.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: Bluetooth: L2CAP: Se corrige la lectura de slab-use-after-free en l2cap_send_cmd. Después de que el comando hci sync libere l2cap_conn, la cola de trabajo de datos de recepción de hci hace referencia a la l2cap_conn liberada al enviar a la capa superior. Se añade el bloqueo de desarrollo de hci a la cola de trabajo de datos de recepción de hci para sincronizar ambos. [1] ERROR: KASAN: slab-use-after-free en l2cap_send_cmd+0x187/0x8d0 net/bluetooth/l2cap_core.c:954 Lectura de tamaño 8 en la dirección ffff8880271a4000 por la tarea kworker/u9:2/5837 CPU: 0 UID: 0 PID: 5837 Comm: kworker/u9:2 No contaminado 6.13.0-rc5-syzkaller-00163-gab75170520d4 #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 13/09/2024 Cola de trabajo: hci1 hci_rx_work Rastreo de llamadas: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0x169/0x550 mm/kasan/report.c:489 kasan_report+0x143/0x180 mm/kasan/report.c:602 l2cap_build_cmd net/bluetooth/l2cap_core.c:2964 [inline] l2cap_send_cmd+0x187/0x8d0 net/bluetooth/l2cap_core.c:954 l2cap_sig_send_rej net/bluetooth/l2cap_core.c:5502 [inline] l2cap_sig_channel net/bluetooth/l2cap_core.c:5538 [inline] l2cap_recv_frame+0x221f/0x10db0 net/bluetooth/l2cap_core.c:6817 hci_acldata_packet net/bluetooth/hci_core.c:3797 [inline] hci_rx_work+0x508/0xdb0 net/bluetooth/hci_core.c:4040 process_one_work kernel/workqueue.c:3229 [inline] process_scheduled_works+0xa66/0x1840 kernel/workqueue.c:3310 worker_thread+0x870/0xd30 kernel/workqueue.c:3391 kthread+0x2f0/0x390 kernel/kthread.c:389 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 Asignado por la tarea 5837: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 poison_kmalloc_redzone mm/kasan/common.c:377 [inline] __kasan_kmalloc+0x98/0xb0 mm/kasan/common.c:394 kasan_kmalloc include/linux/kasan.h:260 [inline] __kmalloc_cache_noprof+0x243/0x390 mm/slub.c:4329 kmalloc_noprof include/linux/slab.h:901 [inline] kzalloc_noprof include/linux/slab.h:1037 [inline] l2cap_conn_add+0xa9/0x8e0 net/bluetooth/l2cap_core.c:6860 l2cap_connect_cfm+0x115/0x1090 net/bluetooth/l2cap_core.c:7239 hci_connect_cfm include/net/bluetooth/hci_core.h:2057 [inline] hci_remote_features_evt+0x68e/0xac0 net/bluetooth/hci_event.c:3726 hci_event_func net/bluetooth/hci_event.c:7473 [inline] hci_event_packet+0xac2/0x1540 net/bluetooth/hci_event.c:7525 hci_rx_work+0x3f3/0xdb0 net/bluetooth/hci_core.c:4035 process_one_work kernel/workqueue.c:3229 [inline] process_scheduled_works+0xa66/0x1840 kernel/workqueue.c:3310 worker_thread+0x870/0xd30 kernel/workqueue.c:3391 kthread+0x2f0/0x390 kernel/kthread.c:389 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 Freed by task 54: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:582 poison_slab_object mm/kasan/common.c:247 [inline] __kasan_slab_free+0x59/0x70 mm/kasan/common.c:264 kasan_slab_free include/linux/kasan.h:233 [inline] slab_free_hook mm/slub.c:2353 [inline] slab_free mm/slub.c:4613 [inline] kfree+0x196/0x430 mm/slub.c:4761 l2cap_connect_cfm+0xcc/0x1090 net/bluetooth/l2cap_core.c:7235 hci_connect_cfm include/net/bluetooth/hci_core.h:2057 [inline] hci_conn_failed+0x287/0x400 net/bluetooth/hci_conn.c:1266 hci_abort_conn_sync+0x56c/0x11f0 net/bluetooth/hci_sync.c:5603 hci_cmd_sync_work+0x22b/0x400 net/bluetooth/hci_sync.c:332 process_one_work kernel/workqueue.c:3229 [inline] process_scheduled_works+0xa66/0x1840 kernel/workqueue.c:3310 worker_thread+0x870/0xd30 kernel/workqueue.c:3391 kthread+0x2f0/0x390 kernel/kthread.c:389 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entr ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: eth: bnxt: corrige el pánico del kernel en bnxt_get_queue_stats{rx | tx} Cuando se ejecuta la operación qstats-get, se llaman las devoluciones de llamada de netdev_stats_ops. bnxt_get_queue_stats{rx | tx} recopila estadísticas por cola de sw_stats en los anillos. Pero {rx | tx | cp}_ring se asignan cuando la interfaz está activa. Por lo tanto, estos anillos no se asignan cuando la interfaz está inactiva. qstats-get está permitido incluso si la interfaz está inactiva. Sin embargo, bnxt_get_queue_stats{rx | tx}() accede a cp_ring y tx_ring sin comprobación de valores nulos. Por lo tanto, debe evitar acceder a los anillos si la interfaz está inactiva. Reproductor: ip link set $interface down ./cli.py --spec netdev.yaml --dump qstats-get O ip link set $interface down python ./stats.py El problema se parece a esto: ERROR: desreferencia de puntero NULL del kernel, dirección: 0000000000000000 #PF: acceso de lectura del supervisor en modo kernel #PF: error_code(0x0000) - página no presente PGD 1680fa067 P4D 1680fa067 PUD 16be3b067 PMD 0 Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 0 UID: 0 PID: 1495 Comm: python3 No contaminado 6.14.0-rc4+ #32 5cd0f999d5a15c574ac72b3e4b907341 Nombre del hardware: Nombre del producto del sistema ASUS System Product Name/PRIME Z690-P D4, BIOS 0603 11/01/2021 RIP: 0010:bnxt_get_queue_stats_rx+0xf/0x70 [bnxt_en] Code: c6 87 b5 18 00 00 02 eb a2 66 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 0f 1f 44 01 RSP: 0018:ffffabef43cdb7e0 EFLAGS: 00010282 RAX: 0000000000000000 RBX: ffffffffc04c8710 RCX: 0000000000000000 RDX: ffffabef43cdb858 RSI: 0000000000000000 RDI: ffff8d504e850000 RBP: ffff8d506c9f9c00 R08: 0000000000000004 R09: ffff8d506bcd901c R10: 0000000000000015 R11: ffff8d506bcd9000 R12: 0000000000000000 R13: ffffabef43cdb8c0 R14: ffff8d504e850000 R15: 0000000000000000 FS: 00007f2c5462b080(0000) GS:ffff8d575f600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 0000000167fd0000 CR4: 00000000007506f0 PKRU: 55555554 Call Trace: ? __die+0x20/0x70 ? page_fault_oops+0x15a/0x460 ? sched_balance_find_src_group+0x58d/0xd10 ? exc_page_fault+0x6e/0x180 ? asm_exc_page_fault+0x22/0x30 ? bnxt_get_queue_stats_rx+0xf/0x70 [bnxt_en cdd546fd48563c280cfd30e9647efa420db07bf1] netdev_nl_stats_by_netdev+0x2b1/0x4e0 ? xas_load+0x9/0xb0 ? xas_find+0x183/0x1d0 ? xa_find+0x8b/0xe0 netdev_nl_qstats_get_dumpit+0xbf/0x1e0 genl_dumpit+0x31/0x90 netlink_dump+0x1a8/0x360

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/display: Corrección de slab-use-after-free en hdcp_work [Por qué] Se reporta un slab-use-after-free cuando se destruye HDCP, pero la cola property_validate_dwork sigue en ejecución. [Cómo] Cancelar el trabajo retrasado al destruir la cola de trabajo. (Seleccionado de el commit 725a04ba5a95e89c89633d4322430cfbca7ce128)

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/mlx5: Puente, corrige el fallo causado por la comprobación del estado de LAG Al retirar el dispositivo LAG del puente, se activa el evento NETDEV_CHANGEUPPER. El controlador encuentra los dispositivos inferiores (PF) para vaciar todas las entradas descargadas. Y mlx5_lag_is_shared_fdb está marcado, devuelve falso si uno de los PF está descargado. En tal caso, mlx5_esw_bridge_lag_rep_get() y su llamador devuelven NULL, en lugar del PF vivo, y se omite el vaciado. Además, el lastuse de la entrada fdb del puente se actualiza en el controlador de eventos del puente mlx5. Pero este evento SWITCHDEV_FDB_ADD_TO_BRIDGE se puede ignorar en este caso porque se elimina la interfaz superior para el enlace y la entrada nunca se envejecerá porque lastuse nunca se actualiza. Para empeorar las cosas, mientras la entrada esté activa, la cola de trabajo del puente mlx5 sigue enviando ese evento, que luego gestiona el notificador del puente del núcleo. Esto provoca el siguiente fallo al acceder al enlace transferido netdev, que ya está destruido. Para solucionar este problema, elimine estas comprobaciones. El estado de LAG ya se comprobó en el commit 15f8f168952f ("net/mlx5: Puente, verificar el estado de LAG al agregar el enlace al puente"). El controlador aún debe omitir la descarga si el estado de LAG se vuelve inválido después de la inicialización. Ups: segmento de pila: 0000 [#1] CPU SMP: 3 UID: 0 PID: 23695 Comm: kworker/u40:3 Contaminado: G OE 6.11.0_mlnx #1 Contaminado: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE Nombre del hardware: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 Workqueue: mlx5_bridge_wq mlx5_esw_bridge_update_work [mlx5_core] RIP: 0010:br_switchdev_event+0x2c/0x110 [bridge] Code: 44 00 00 48 8b 02 48 f7 00 00 02 00 00 74 69 41 54 55 53 48 83 ec 08 48 8b a8 08 01 00 00 48 85 ed 74 4a 48 83 fe 02 48 89 d3 <4c> 8b 65 00 74 23 76 49 48 83 fe 05 74 7e 48 83 fe 06 75 2f 0f b7 RSP: 0018:ffffc900092cfda0 EFLAGS: 00010297 RAX: ffff888123bfe000 RBX: ffffc900092cfe08 RCX: 00000000ffffffff RDX: ffffc900092cfe08 RSI: 0000000000000001 RDI: ffffffffa0c585f0 RBP: 6669746f6e690a30 R08: 0000000000000000 R09: ffff888123ae92c8 R10: 0000000000000000 R11: fefefefefefefeff R12: ffff888123ae9c60 R13: 0000000000000001 R14: ffffc900092cfe08 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffff88852c980000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f15914c8734 CR3: 0000000002830005 CR4: 0000000000770ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: ? __die_body+0x1a/0x60 ? die+0x38/0x60 ? do_trap+0x10b/0x120 ? do_error_trap+0x64/0xa0 ? exc_stack_segment+0x33/0x50 ? asm_exc_stack_segment+0x22/0x30 ? br_switchdev_event+0x2c/0x110 [bridge] ? sched_balance_newidle.isra.149+0x248/0x390 notifier_call_chain+0x4b/0xa0 atomic_notifier_call_chain+0x16/0x20 mlx5_esw_bridge_update+0xec/0x170 [mlx5_core] mlx5_esw_bridge_update_work+0x19/0x40 [mlx5_core] process_scheduled_works+0x81/0x390 worker_thread+0x106/0x250 ? bh_worker+0x110/0x110 kthread+0xb7/0xe0 ? kthread_park+0x80/0x80 ret_from_fork+0x2d/0x50 ? kthread_park+0x80/0x80 ret_from_fork_asm+0x11/0x20

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net_sched: Impide la creación de clases con TC_H_ROOT La función qdisc_tree_reduce_backlog() usa TC_H_ROOT como condición de terminación al recorrer el árbol qdisc para actualizar los contadores de backlog primarios. Sin embargo, si se crea una clase con classid TC_H_ROOT, el recorrido termina prematuramente en esta clase en lugar de alcanzar la qdisc root real, lo que provoca que las estadísticas primarias se mantengan incorrectamente. En caso de DRR, esto podría provocar un fallo como lo informó Mingi Cho. Impide la creación de cualquier clase Qdisc con classid TC_H_ROOT (0xFFFFFFFF) en todos los tipos de qdisc, como sugirió Jamal.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/mlx5: gestión de errores en mlx5_chains_create_table(). En mlx5_chains_create_table(), se debe comprobar el valor de retorno de mlx5_get_fdb_sub_ns() y mlx5_get_flow_namespace() para evitar desreferencias de punteros nulos. Si alguna de las funciones falla, debe registrar un mensaje de error con mlx5_core_warn() y devolver un puntero de error.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: sched_ext: Validar prev_cpu en scx_bpf_select_cpu_dfl(). Si un programador BPF proporciona una CPU no válida (fuera del rango nr_cpu_ids) como prev_cpu a scx_bpf_select_cpu_dfl(), puede provocar un fallo del kernel. Para evitarlo, valide prev_cpu en scx_bpf_select_cpu_dfl() y genere un error scx si se especifica una CPU no válida.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: Revertir "openvswitch: cambiar al conteo de etiquetas por acción en conntrack". Actualmente, ovs_ct_set_labels() solo se llama para entradas de conntrack confirmadas (ct) dentro de ovs_ct_commit(). Sin embargo, si la entrada de conntrack no tiene la extensión labels_ext, al intentar asignarla en ovs_ct_get_conn_labels() para una entrada confirmada, se genera una advertencia en nf_ct_ext_add(): WARN_ON(nf_ct_is_confirmed(ct)); Esto ocurre cuando la entrada de conntrack se crea externamente antes de que OVS incremente net->ct.labels_used. El problema se ha vuelto más frecuente desde el commit fcb1aa5163b1 ("openvswitch: cambio al conteo de etiquetas por acción en conntrack"), que cambió para usar el conteo de etiquetas por acción e incrementar net->ct.labels_used al agregar un flujo con la acción ct. Dado que actualmente no existe una solución directa para este problema, esta reversión de el commit evita la interrupción de los casos de uso existentes.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: eth: bnxt: corrección de truesize para el caso mb-xdp-pass. Cuando mb-xdp está configurado y el valor de retorno es XDP_PASS, el paquete se convierte de xdp_buff a sk_buff con xdp_update_skb_shared_info() en bnxt_xdp_build_skb(). bnxt_xdp_build_skb() pasa un argumento truesize incorrecto a xdp_update_skb_shared_info(). El truesize se calcula como BNXT_RX_PAGE_SIZE * sinfo->nr_frags, pero napi_build_skb() borró previamente skb_shared_info. De este modo, almacena sinfo->nr_frags antes de bnxt_xdp_build_skb() y lo utiliza en lugar de obtener skb_shared_info de xdp_get_shared_info_from_buff(). El splat se ve así: ------------[ cortar aquí ]------------ ADVERTENCIA: CPU: 2 PID: 0 en net/core/skbuff.c:6072 skb_try_coalesce+0x504/0x590 Módulos enlazados en: xt_nat xt_tcpudp veth af_packet xt_conntrack nft_chain_nat xt_MASQUERADE nf_conntrack_netlink xfrm_user xt_addrtype nft_coms CPU: 2 UID: 0 PID: 0 Comm: swapper/2 No contaminado 6.14.0-rc2+ #3 RIP: 0010:skb_try_coalesce+0x504/0x590 Código: 4b fd ff ff 49 8b 34 24 40 80 e6 40 0f 84 3d fd ff ff 49 8b 74 24 48 40 f6 c6 01 0f 84 2e fd ff ff 48 8d 4e ff e9 25 fd ff ff <0f> 0b e99 RSP: 0018:ffffb62c4120caa8 EFLAGS: 00010287 RAX: 000000000000003 RBX: ffffb62c4120cb14 RCX: 0000000000000ec0 RDX: 0000000000001000 RSI: ffffa06e5d7dc000 RDI: 000000000000003 RBP: ffffa06e5d7ddec0 R08: ffffa06e6120a800 R09: ffffa06e7a119900 R10: 0000000000002310 R11: ffffa06e5d7dcec0 R12: ffffe4360575f740 R13: ffffe43600000000 R14: 000000000000002 R15: 0000000000000002 FS: 000000000000000(0000) GS:ffffa0755f700000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f147b76b0f8 CR3: 00000001615d4000 CR4: 00000000007506f0 PKRU: 55555554 Rastreo de llamadas: ? __warn+0x84/0x130 ? skb_try_coalesce+0x504/0x590 ? report_bug+0x18a/0x1a0 ? handle_bug+0x53/0x90 ? exc_invalid_op+0x14/0x70 ? asm_exc_invalid_op+0x16/0x20 ? skb_try_coalesce+0x504/0x590 inet_frag_reasm_finish+0x11f/0x2e0 ip_defrag+0x37a/0x900 ip_local_deliver+0x51/0x120 ip_sublist_rcv_finish+0x64/0x70 ip_sublist_rcv+0x179/0x210 ip_list_rcv+0xf9/0x130 Cómo reproducir: enlace ip establecido $interfaz1 xdp obj xdp_pass.o enlace ip establecido $interfaz1 mtu 9000 activo ip aa 10.0.0.1/24 dev $interfaz1 enlace ip establecido $interfaz2 mtu 9000 activo ip aa 10.0.0.2/24 El siguiente parche de ping.py agrega el caso xdp-mb-pass, por lo que ping.py podrá reproducir este problema.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: dm-flakey: corrige la corrupción de memoria en la función opcional corrupt_bio_byte Corrige la corrupción de memoria debido al parámetro incorrecto que se pasa a bio_init

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ksmbd: se corrige el problema de use-after-free en ksmbd_free_work_struct -> la entrada provisional de ksmbd_work podría eliminarse tras la liberación del bloqueo de operón. No es necesario gestionarlo con una lista enlazada. La solicitud provisional podría enviarse inmediatamente cuando se requiera una espera para la interrupción del bloqueo de operón.