Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ice: corrige pérdida de memoria en aRFS después del reinicio Corrige la pérdida de memoria de las estructuras aRFS (dirección de flujo de recepción acelerada) agregando un verificador para verificar si la memoria aRFS ya está asignada mientras se configura VSI. Los objetos aRFS se asignan en dos casos: - como parte de la inicialización de VSI (en la sonda), y - como parte de la gestión del reinicio. Sin embargo, la reconfiguración de VSI ejecutada durante el reinicio implica la asignación de memoria una vez más, sin liberar previamente los recursos ya asignados. Esto provocó la fuga de memoria con la siguiente firma: [root@os-delivery ~]# cat /sys/kernel/debug/kmemleak unreferenced object 0xff3c1ca7252e6000 (size 8192): comm "kworker/0:0", pid 8, jiffies 4296833052 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace (crc 0): [] __kmalloc_cache_noprof+0x275/0x340 [] ice_init_arfs+0x3a/0xe0 [ice] [] ice_vsi_cfg_def+0x607/0x850 [ice] [] ice_vsi_setup+0x5b/0x130 [ice] [] ice_init+0x1c1/0x460 [ice] [] ice_probe+0x2af/0x520 [ice] [] local_pci_probe+0x43/0xa0 [] work_for_cpu_fn+0x13/0x20 [] process_one_work+0x179/0x390 [] worker_thread+0x239/0x340 [] kthread+0xcc/0x100 [] ret_from_fork+0x2d/0x50 [] ret_from_fork_asm+0x1a/0x30 ...

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: cfg80211: cancelar wiphy_work antes de liberar wiphy. Un wiphy_work puede ponerse en cola desde el momento en que se asigna e inicializa el wiphy (es decir, wiphy_new_nm). Cuando se pone en cola un wiphy_work, también se pone en cola rdev::wiphy_work. Si se llama a wiphy_free antes de que rdev::wiphy_work se ejecute, se liberará la memoria del wiphy y, cuando finalmente se ejecute, usará memoria no válida. Para solucionar esto, cancele el trabajo antes de liberar el wiphy.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: fbdev: hyperv_fb: Permite la eliminación ordenada del framebuffer. Cuando se desvincula un dispositivo framebuffer de Hyper-V, el controlador hyperv_fb intenta liberarlo forzosamente. Si este framebuffer está en uso, genera la siguiente advertencia y, por lo tanto, nunca se libera. [44.111220] ADVERTENCIA: CPU: 35 PID: 1882 en drivers/video/fbdev/core/fb_info.c:70 framebuffer_release+0x2c/0x40 < snip > [44.111289] Rastreo de llamadas: [ 44.111290] [ 44.111291] ? show_regs+0x6c/0x80 [ 44.111295] ? __warn+0x8d/0x150 [ 44.111298] ? framebuffer_release+0x2c/0x40 [ 44.111300] ? report_bug+0x182/0x1b0 [ 44.111303] ? handle_bug+0x6e/0xb0 [ 44.111306] ? exc_invalid_op+0x18/0x80 [ 44.111308] ? asm_exc_invalid_op+0x1b/0x20 [ 44.111311] ? framebuffer_release+0x2c/0x40 [ 44.111313] ? hvfb_remove+0x86/0xa0 [hyperv_fb] [ 44.111315] vmbus_remove+0x24/0x40 [hv_vmbus] [ 44.111323] device_remove+0x40/0x80 [ 44.111325] device_release_driver_internal+0x20b/0x270 [ 44.111327] ? bus_find_device+0xb3/0xf0. Solucione esto trasladando la liberación del framebuffer y la memoria asociada a la función fb_ops.fb_destroy, para que el framework del framebuffer lo gestione correctamente. Mientras lo solucionamos, también reemplace el registro/desregistro manual del framebuffer con devm_register_framebuffer.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: eth: bnxt: return fail if interface is down in bnxt_queue_mem_alloc(). Se llama a bnxt_queue_mem_alloc() para asignar nueva memoria de cola cuando esta se reinicia. Accede internamente al descriptor de búfer rx correspondiente al índice. El descriptor de búfer rx se asigna y se establece cuando la interfaz está activa y se libera cuando esta se cae. Por lo tanto, si la cola se reinicia mientras la interfaz está caída, se produce un pánico del kernel. El problema se ve así: ERROR: no se puede gestionar el error de página para la dirección: 000000000000b240 #PF: acceso de lectura del supervisor en modo kernel #PF: error_code(0x0000) - página no presente PGD 0 P4D 0 Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 3 UID: 0 PID: 1563 Comm: ncdevmem2 No contaminado 6.14.0-rc2+ #9 844ddba6e7c459cafd0bf4db9a3198e Nombre del hardware: Nombre del producto del sistema ASUS/PRIME Z690-P D4, BIOS 0603 11/01/2021 RIP: 0010:bnxt_queue_mem_alloc+0x3f/0x4e0 [bnxt_en] Code: 41 54 4d 89 c4 4d 69 c0 c0 05 00 00 55 48 89 f5 53 48 89 fb 4c 8d b5 40 05 00 00 48 83 ec 15 RSP: 0018:ffff9dcc83fef9e8 EFLAGS: 00010202 RAX: ffffffffc0457720 RBX: ffff934ed8d40000 RCX: 0000000000000000 RDX: 000000000000001f RSI: ffff934ea508f800 RDI: ffff934ea508f808 RBP: ffff934ea508f800 R08: 000000000000b240 R09: ffff934e84f4b000 R10: ffff9dcc83fefa30 R11: ffff934e84f4b000 R12: 000000000000001f R13: ffff934ed8d40ac0 R14: ffff934ea508fd40 R15: ffff934e84f4b000 FS: 00007fa73888c740(0000) GS:ffff93559f780000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000000000b240 CR3: 0000000145a2e000 CR4: 00000000007506f0 PKRU: 55555554 Call Trace: ? __die+0x20/0x70 ? page_fault_oops+0x15a/0x460 ? exc_page_fault+0x6e/0x180 ? asm_exc_page_fault+0x22/0x30 ? __pfx_bnxt_queue_mem_alloc+0x10/0x10 [bnxt_en 7f85e76f4d724ba07471d7e39d9e773aea6597b7] ? bnxt_queue_mem_alloc+0x3f/0x4e0 [bnxt_en 7f85e76f4d724ba07471d7e39d9e773aea6597b7] netdev_rx_queue_restart+0xc5/0x240 net_devmem_bind_dmabuf_to_queue+0xf8/0x200 netdev_nl_bind_rx_doit+0x3a7/0x450 genl_family_rcv_msg_doit+0xd9/0x130 genl_rcv_msg+0x184/0x2b0 ? __pfx_netdev_nl_bind_rx_doit+0x10/0x10 ? __pfx_genl_rcv_msg+0x10/0x10 netlink_rcv_skb+0x54/0x100 genl_rcv+0x24/0x40 ...

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: 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: 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: 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.