Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: gtp: Supresión de la corrupción de listas en gtp_net_exit_batch_rtnl(). Brad Spengler reportó la corrupción de list_del() en gtp_net_exit_batch_rtnl(). [0] El commit eb28fd76c0a0 ("gtp: Destruir dispositivo junto con el desmantelamiento de netns del socket UDP") añadió el bucle for_each_netdev() en gtp_net_exit_batch_rtnl() para destruir dispositivos en cada netns, como se hace en los túneles geneve e IP. Sin embargo, esto podría activar ->dellink() dos veces para el mismo dispositivo durante ->exit_batch_rtnl(). Digamos que tenemos dos netns A y B y un dispositivo gtp B que reside en netns B pero cuyo socket UDP está en netns A. 1. cleanup_net() procesa netns A y luego B. 2. gtp_net_exit_batch_rtnl() encuentra el dispositivo B mientras itera gn->gtp_dev_list de netns A y llama a ->dellink(). [el dispositivo B aún no está desvinculado de netns B ya que no se ha llamado a unregister_netdevice_many().] 3. gtp_net_exit_batch_rtnl() encuentra el dispositivo B mientras itera for_each_netdev() de netns B y llama a ->dellink(). gtp_dellink() limpia la tabla hash del dispositivo, desvincula el dev de gn->gtp_dev_list y llama a unregister_netdevice_queue(). Básicamente, llamar a gtp_dellink() varias veces no tiene problema a menos que CONFIG_DEBUG_LIST esté habilitado. Eliminemos for_each_netdev() en gtp_net_exit_batch_rtnl() y deleguemos la destrucción a default_device_exit_batch() como se hace en bareudp. [0]: corrupción en list_del, ffff8880aaa62c00->next (autoslab_size_M_dev_P_net_core_dev_11127_8_1328_8_S_4096_A_64_n_139+0xc00/0x1000 [slab object]) is LIST_POISON1 (ffffffffffffff02) (prev is 0xffffffffffffff04) kernel BUG at lib/list_debug.c:58! Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN CPU: 1 UID: 0 PID: 1804 Comm: kworker/u8:7 Tainted: G T 6.12.13-grsec-full-20250211091339 #1 Tainted: [T]=RANDSTRUCT Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Workqueue: netns cleanup_net RIP: 0010:[] __list_del_entry_valid_or_report+0x141/0x200 lib/list_debug.c:58 Code: c2 76 91 31 c0 e8 9f b1 f7 fc 0f 0b 4d 89 f0 48 c7 c1 02 ff ff ff 48 89 ea 48 89 ee 48 c7 c7 e0 c2 76 91 31 c0 e8 7f b1 f7 fc <0f> 0b 4d 89 e8 48 c7 c1 04 ff ff ff 48 89 ea 48 89 ee 48 c7 c7 60 RSP: 0018:fffffe8040b4fbd0 EFLAGS: 00010283 RAX: 00000000000000cc RBX: dffffc0000000000 RCX: ffffffff818c4054 RDX: ffffffff84947381 RSI: ffffffff818d1512 RDI: 0000000000000000 RBP: ffff8880aaa62c00 R08: 0000000000000001 R09: fffffbd008169f32 R10: fffffe8040b4f997 R11: 0000000000000001 R12: a1988d84f24943e4 R13: ffffffffffffff02 R14: ffffffffffffff04 R15: ffff8880aaa62c08 RBX: kasan shadow of 0x0 RCX: __wake_up_klogd.part.0+0x74/0xe0 kernel/printk/printk.c:4554 RDX: __list_del_entry_valid_or_report+0x141/0x200 lib/list_debug.c:58 RSI: vprintk+0x72/0x100 kernel/printk/printk_safe.c:71 RBP: autoslab_size_M_dev_P_net_core_dev_11127_8_1328_8_S_4096_A_64_n_139+0xc00/0x1000 [slab object] RSP: process kstack fffffe8040b4fbd0+0x7bd0/0x8000 [kworker/u8:7+netns 1804 ] R09: kasan shadow of process kstack fffffe8040b4f990+0x7990/0x8000 [kworker/u8:7+netns 1804 ] R10: process kstack fffffe8040b4f997+0x7997/0x8000 [kworker/u8:7+netns 1804 ] R15: autoslab_size_M_dev_P_net_core_dev_11127_8_1328_8_S_4096_A_64_n_139+0xc08/0x1000 [slab object] FS: 0000000000000000(0000) GS:ffff888116000000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000748f5372c000 CR3: 0000000015408000 CR4: 00000000003406f0 shadow CR4: 00000000003406f0 Stack: 0000000000000000 ffffffff8a0c35e7 ffffffff8a0c3603 ffff8880aaa62c00 ffff8880aaa62c00 0000000000000004 ffff88811145311c 0000000000000005 0000000000000001 ffff8880aaa62000 fffffe8040b4fd40 ffffffff8a0c360d Call Trace: [] __list_del_entry_valid include/linux/list.h:131 [inline] fffffe8040b4fc28 [] __list_del_entry include/linux/list.h:248 [inline] fffffe8040b4fc28 [] list_del include/linux/list.h:262 [inl ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: tcp: descartar secpath al mismo tiempo que descartamos dst Xiumei informó haber alcanzado el WARN en xfrm6_tunnel_net_exit mientras ejecutaba pruebas que se reducen a: - crear un par de netns - ejecutar una prueba TCP básica sobre ipcomp6 - eliminar el par de netns El xfrm_state encontrado en spi_byaddr no se eliminó en el momento en que eliminamos los netns, porque aún tenemos una referencia en él. Esta referencia persistente proviene de un secpath (que contiene una referencia en xfrm_state), que aún está adjunto a un skb. Este skb no se filtra, termina en sk_receive_queue y luego se libera mediante skb_attempt_defer_free. El problema ocurre cuando posponemos la liberación de un skb (insertarlo en la lista defer_list de una CPU) y no limpiamos esa lista antes de eliminar netns. En ese caso, aún tenemos una referencia en xfrm_state inesperada en este momento. Ya eliminamos el dst del skb en la ruta de recepción TCP cuando ya no es necesario, así que también eliminamos el secpath. En este punto, tcp_filter ya ha llamado a los ganchos LSM que podrían requerir el secpath, por lo que ya no debería ser necesario. Sin embargo, en algunos de esos lugares, la extensión MPTCP se acaba de adjuntar al skb, por lo que no podemos simplemente eliminar todas las extensiones.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: io_uring: evita la especulación de código de operación. sqe->opcode se utiliza para diferentes tablas, asegúrese de que lo desinfectemos contra especulaciones.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drop_monitor: fix incorrect initialization order Syzkaller reports the following bug: BUG: spinlock bad magic on CPU#1, syz-executor.0/7995 lock: 0xffff88805303f3e0, .magic: 00000000, .owner: /-1, .owner_cpu: 0 CPU: 1 PID: 7995 Comm: syz-executor.0 Tainted: G E 5.10.209+ #1 Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 11/12/2020 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x119/0x179 lib/dump_stack.c:118 debug_spin_lock_before kernel/locking/spinlock_debug.c:83 [inline] do_raw_spin_lock+0x1f6/0x270 kernel/locking/spinlock_debug.c:112 __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:117 [inline] _raw_spin_lock_irqsave+0x50/0x70 kernel/locking/spinlock.c:159 reset_per_cpu_data+0xe6/0x240 [drop_monitor] net_dm_cmd_trace+0x43d/0x17a0 [drop_monitor] genl_family_rcv_msg_doit+0x22f/0x330 net/netlink/genetlink.c:739 genl_family_rcv_msg net/netlink/genetlink.c:783 [inline] genl_rcv_msg+0x341/0x5a0 net/netlink/genetlink.c:800 netlink_rcv_skb+0x14d/0x440 net/netlink/af_netlink.c:2497 genl_rcv+0x29/0x40 net/netlink/genetlink.c:811 netlink_unicast_kernel net/netlink/af_netlink.c:1322 [inline] netlink_unicast+0x54b/0x800 net/netlink/af_netlink.c:1348 netlink_sendmsg+0x914/0xe00 net/netlink/af_netlink.c:1916 sock_sendmsg_nosec net/socket.c:651 [inline] __sock_sendmsg+0x157/0x190 net/socket.c:663 ____sys_sendmsg+0x712/0x870 net/socket.c:2378 ___sys_sendmsg+0xf8/0x170 net/socket.c:2432 __sys_sendmsg+0xea/0x1b0 net/socket.c:2461 do_syscall_64+0x30/0x40 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x62/0xc7 RIP: 0033:0x7f3f9815aee9 Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f3f972bf0c8 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 00007f3f9826d050 RCX: 00007f3f9815aee9 RDX: 0000000020000000 RSI: 0000000020001300 RDI: 0000000000000007 RBP: 00007f3f981b63bd R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 000000000000006e R14: 00007f3f9826d050 R15: 00007ffe01ee6768 Si drop_monitor se compila como un módulo del kernel, syzkaller podría tener tiempo de enviar un mensaje NET_DM_CMD_START de netlink durante la carga del módulo. Esto llamará a la función net_dm_monitor_start(), que utiliza un spinlock aún no inicializado. Para solucionar esto, prioricemos la inicialización de recursos al registro de una familia genérica de netlink. Encontrado por InfoTeCS en nombre del Centro de Verificación de Linux (linuxtesting.org) con Syzkaller.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm/migrate_device: no se añade el folio que se liberará a la LRU en la función migrar_device_finalize(). Si la migración se realizó correctamente, se invocó folio_migrate_flags()->mem_cgroup_migrate() para migrar el memcg del folio antiguo al nuevo. Esto establecerá el valor de memcg_data del folio antiguo en 0. De igual forma, si la migración falla, el valor de memcg_data del folio de destino no se establece. Si se invoca folio_putback_lru() en dichos folios (memcg_data == 0), se añadirá el folio que se liberará a la LRU, lo que provocará un error en el código de memcg. Ejecutando las autopruebas hmm: # ./hmm-tests ... # RUN hmm.hmm_device_private.migrate ... [ 102.078007][T14893] page: refcount:1 mapcount:0 mapping:0000000000000000 index:0x7ff27d200 pfn:0x13cc00 [ 102.079974][T14893] anon flags: 0x17ff00000020018(uptodate|dirty|swapbacked|node=0|zone=2|lastcpupid=0x7ff) [ 102.082037][T14893] raw: 017ff00000020018 dead000000000100 dead000000000122 ffff8881353896c9 [ 102.083687][T14893] raw: 00000007ff27d200 0000000000000000 00000001ffffffff 0000000000000000 [ 102.085331][T14893] page dumped because: VM_WARN_ON_ONCE_FOLIO(!memcg && !mem_cgroup_disabled()) [ 102.087230][T14893] ------------[ cut here ]------------ [ 102.088279][T14893] WARNING: CPU: 0 PID: 14893 at ./include/linux/memcontrol.h:726 folio_lruvec_lock_irqsave+0x10e/0x170 [ 102.090478][T14893] Modules linked in: [ 102.091244][T14893] CPU: 0 UID: 0 PID: 14893 Comm: hmm-tests Not tainted 6.13.0-09623-g6c216bc522fd #151 [ 102.093089][T14893] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014 [ 102.094848][T14893] RIP: 0010:folio_lruvec_lock_irqsave+0x10e/0x170 [ 102.096104][T14893] Code: ... [ 102.099908][T14893] RSP: 0018:ffffc900236c37b0 EFLAGS: 00010293 [ 102.101152][T14893] RAX: 0000000000000000 RBX: ffffea0004f30000 RCX: ffffffff8183f426 [ 102.102684][T14893] RDX: ffff8881063cb880 RSI: ffffffff81b8117f RDI: ffff8881063cb880 [ 102.104227][T14893] RBP: 0000000000000000 R08: 0000000000000005 R09: 0000000000000000 [ 102.105757][T14893] R10: 0000000000000001 R11: 0000000000000002 R12: ffffc900236c37d8 [ 102.107296][T14893] R13: ffff888277a2bcb0 R14: 000000000000001f R15: 0000000000000000 [ 102.108830][T14893] FS: 00007ff27dbdd740(0000) GS:ffff888277a00000(0000) knlGS:0000000000000000 [ 102.110643][T14893] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 102.111924][T14893] CR2: 00007ff27d400000 CR3: 000000010866e000 CR4: 0000000000750ef0 [ 102.113478][T14893] PKRU: 55555554 [ 102.114172][T14893] Call Trace: [ 102.114805][T14893] [ 102.115397][T14893] ? folio_lruvec_lock_irqsave+0x10e/0x170 [ 102.116547][T14893] ? __warn.cold+0x110/0x210 [ 102.117461][T14893] ? folio_lruvec_lock_irqsave+0x10e/0x170 [ 102.118667][T14893] ? report_bug+0x1b9/0x320 [ 102.119571][T14893] ? handle_bug+0x54/0x90 [ 102.120494][T14893] ? exc_invalid_op+0x17/0x50 [ 102.121433][T14893] ? asm_exc_invalid_op+0x1a/0x20 [ 102.122435][T14893] ? __wake_up_klogd.part.0+0x76/0xd0 [ 102.123506][T14893] ? dump_page+0x4f/0x60 [ 102.124352][T14893] ? folio_lruvec_lock_irqsave+0x10e/0x170 [ 102.125500][T14893] folio_batch_move_lru+0xd4/0x200 [ 102.126577][T14893] ? __pfx_lru_add+0x10/0x10 [ 102.127505][T14893] __folio_batch_add_and_move+0x391/0x720 [ 102.128633][T14893] ? __pfx_lru_add+0x10/0x10 [ 102.129550][T14893] folio_putback_lru+0x16/0x80 [ 102.130564][T14893] migrate_device_finalize+0x9b/0x530 [ 102.131640][T14893] dmirror_migrate_to_device.constprop.0+0x7c5/0xad0 [ 102.133047][T14893] dmirror_fops_unlocked_ioctl+0x89b/0xc80 Probablemente, no haya ningún otro problema: al añadir la última referencia de folio, este se eliminará de la LRU. Por lo tanto, además de las quejas de memcg, añadir el folio que se liberará a la LRU es simplemente un paso innecesario. El nuevo flujo se asemeja a lo que tenemos en migration_folio_move(): agrega el dst al lru, rem ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf: evitar mantener freeze_mutex durante la operación mmap. Usamos map->freeze_mutex para evitar ejecuciones entre map_freeze() y el mapeo de memoria del contenido del mapa BPF con permisos de escritura. Esta forma ingenua de hacerlo implica mantener freeze_mutex durante todas las manipulaciones mm y VMA, lo cual es completamente innecesario. Esto también puede provocar interbloqueos, como informa syzbot en [0]. Por lo tanto, se mantiene freeze_mutex solo durante las comprobaciones de escritura, se aumenta (proactivamente) el contador de "escritura activa" del mapa, se desbloquea el mutex y se continúa con la lógica mmap. Solo si algo falla durante la lógica mmap, se deshace el incremento del contador de "escritura activa". [0] https://lore.kernel.org/bpf/678dcbc9.050a0220.303755.0066.GAE@google.com/

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm/zswap: se corrige una inconsistencia al fallar zswap_store_page(). El commit b7c0ccdfbafd ("mm: zswap: admite folios grandes en zswap_store()") omite el cobro de las entradas zswap cuando no se logra el cobro de todo el folio. Sin embargo, cuando se realizan cobros de algunas páginas base, pero no se logra el cobro de todo el folio, la operación de cobro se revierte. Al liberar las entradas zswap de esas páginas, zswap_entry_free() descarga las entradas zswap que no se habían cargado previamente, lo que provoca que el cobro de zswap se vuelva inconsistente. Esta inconsistencia activa dos advertencias con los siguientes pasos: # En una máquina con 64 GiB de RAM y 36 GiB de zswap $ stress-ng --bigheap 2 # esperar hasta que OOM-killer elimine stress-ng $ sudo reboot Las dos advertencias son: en mm/memcontrol.c:163, función obj_cgroup_release(): WARN_ON_ONCE(nr_bytes & (PAGE_SIZE - 1)); en mm/page_counter.c:60, función page_counter_cancel(): if (WARN_ONCE(new < 0, "page_counter underflow: %ld nr_pages=%lu\n", new, nr_pages)) zswap_stored_pages también se vuelve inconsistente de la misma manera. Como sugirió Kanchana, incremente zswap_stored_pages y cargue las entradas zswap dentro de zswap_store_page() cuando tenga éxito. De esta forma, zswap_entry_free() decrementará el contador y descargará las entradas cuando no pueda intercambiar todo el folio con zswap. Si bien esto podría optimizarse agrupando la carga de objcg e incrementando el contador, centrémonos en corregir el error esta vez y dejemos la optimización para más adelante, tras una evaluación. Tras resolver la inconsistencia, las advertencias desaparecen. [42.hyeyoo@gmail.com: refactorizar zswap_store_page()] Enlace: https://lkml.kernel.org/r/20250131082037.2426-1-42.hyeyoo@gmail.com

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: USB: gadget: f_midi: f_midi_complete para llamar a queue_work. Al usar USB MIDI, se intenta adquirir un bloqueo dos veces mediante una llamada reentrante a f_midi_transmit, lo que provoca un bloqueo. Se soluciona usando queue_work() para programar la función f_midi_transmit() interna mediante una cola de trabajo de alta prioridad desde el controlador de finalización.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: geneve: Se corrige el problema de uso después de la liberación en geneve_find_dev(). syzkaller reportó un problema de uso después de la liberación en geneve_find_dev() [0] sin reproducción. geneve_configure() vincula la estructura geneve_dev.next con net_generic(net, geneve_net_id)->geneve_list. La red aquí podría diferir de dev_net(dev) si se configura IFLA_NET_NS_PID, IFLA_NET_NS_FD o IFLA_TARGET_NETNSID. Al desmantelar dev_net(dev), geneve_exit_batch_rtnl() finalmente llama a unregister_netdevice_queue() para cada dispositivo en la red, y posteriormente se libera el dispositivo. Sin embargo, su geneve_dev.next aún está vinculado a la red del socket UDP del backend. Entonces, se producirá un "use-after-free" al crear otro "geneve dev" en la red. En su lugar, llamaremos a "geneve_dellink()" en "geneve_destroy_tunnels()". [0]: ERROR: KASAN: slab-use-after-free in geneve_find_dev drivers/net/geneve.c:1295 [inline] BUG: KASAN: slab-use-after-free in geneve_configure+0x234/0x858 drivers/net/geneve.c:1343 Read of size 2 at addr ffff000054d6ee24 by task syz.1.4029/13441 CPU: 1 UID: 0 PID: 13441 Comm: syz.1.4029 Not tainted 6.13.0-g0ad9617c78ac #24 dc35ca22c79fb82e8e7bc5c9c9adafea898b1e3d Hardware name: linux,dummy-virt (DT) Call trace: show_stack+0x38/0x50 arch/arm64/kernel/stacktrace.c:466 (C) __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0xbc/0x108 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0x16c/0x6f0 mm/kasan/report.c:489 kasan_report+0xc0/0x120 mm/kasan/report.c:602 __asan_report_load2_noabort+0x20/0x30 mm/kasan/report_generic.c:379 geneve_find_dev drivers/net/geneve.c:1295 [inline] geneve_configure+0x234/0x858 drivers/net/geneve.c:1343 geneve_newlink+0xb8/0x128 drivers/net/geneve.c:1634 rtnl_newlink_create+0x23c/0x868 net/core/rtnetlink.c:3795 __rtnl_newlink net/core/rtnetlink.c:3906 [inline] rtnl_newlink+0x1054/0x1630 net/core/rtnetlink.c:4021 rtnetlink_rcv_msg+0x61c/0x918 net/core/rtnetlink.c:6911 netlink_rcv_skb+0x1dc/0x398 net/netlink/af_netlink.c:2543 rtnetlink_rcv+0x34/0x50 net/core/rtnetlink.c:6938 netlink_unicast_kernel net/netlink/af_netlink.c:1322 [inline] netlink_unicast+0x618/0x838 net/netlink/af_netlink.c:1348 netlink_sendmsg+0x5fc/0x8b0 net/netlink/af_netlink.c:1892 sock_sendmsg_nosec net/socket.c:713 [inline] __sock_sendmsg net/socket.c:728 [inline] ____sys_sendmsg+0x410/0x6f8 net/socket.c:2568 ___sys_sendmsg+0x178/0x1d8 net/socket.c:2622 __sys_sendmsg net/socket.c:2654 [inline] __do_sys_sendmsg net/socket.c:2659 [inline] __se_sys_sendmsg net/socket.c:2657 [inline] __arm64_sys_sendmsg+0x12c/0x1c8 net/socket.c:2657 __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline] invoke_syscall+0x90/0x278 arch/arm64/kernel/syscall.c:49 el0_svc_common+0x13c/0x250 arch/arm64/kernel/syscall.c:132 do_el0_svc+0x54/0x70 arch/arm64/kernel/syscall.c:151 el0_svc+0x4c/0xa8 arch/arm64/kernel/entry-common.c:744 el0t_64_sync_handler+0x78/0x108 arch/arm64/kernel/entry-common.c:762 el0t_64_sync+0x198/0x1a0 arch/arm64/kernel/entry.S:600 Allocated by task 13247: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x30/0x68 mm/kasan/common.c:68 kasan_save_alloc_info+0x44/0x58 mm/kasan/generic.c:568 poison_kmalloc_redzone mm/kasan/common.c:377 [inline] __kasan_kmalloc+0x84/0xa0 mm/kasan/common.c:394 kasan_kmalloc include/linux/kasan.h:260 [inline] __do_kmalloc_node mm/slub.c:4298 [inline] __kmalloc_node_noprof+0x2a0/0x560 mm/slub.c:4304 __kvmalloc_node_noprof+0x9c/0x230 mm/util.c:645 alloc_netdev_mqs+0xb8/0x11a0 net/core/dev.c:11470 rtnl_create_link+0x2b8/0xb50 net/core/rtnetlink.c:3604 rtnl_newlink_create+0x19c/0x868 net/core/rtnetlink.c:3780 __rtnl_newlink net/core/rtnetlink.c:3906 [inline] rtnl_newlink+0x1054/0x1630 net/core/rtnetlink.c:4021 rtnetlink_rcv_msg+0x61c/0x918 net/core/rtnetlink.c:6911 netlink_rcv_skb+0x1dc/0x398 net/netlink/af_netlink.c:2543 rtnetlink_rcv+0x34/0x50 net/core/rtnetlink.c:6938 netlink_unicast_kernel net/netlink/af_n ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/sched: cls_api: se corrige el error de gestión que causa la desreferencia de NULL. tcf_exts_miss_cookie_base_alloc() llama a xa_alloc_cyclic(), que puede devolver 1 si la asignación se realizó correctamente tras el encapsulado. Esto se trató como un error, con el valor 1 devuelto al llamador tcf_exts_init_ex(), que establece exts->actions en NULL y devuelve 1 al llamador fl_change(). fl_change() trata err == 1 como correcto, llamando a tcf_exts_validate_ex(), que llama a tcf_action_init() con exts->actions como argumento, donde se desreferencia. Ejemplo de seguimiento: ERROR: desreferencia de puntero NULL del núcleo, dirección: 0000000000000000 CPU: 114 PID: 16151 Comm: handler114 Kdump: cargado No contaminado 5.14.0-503.16.1.el9_5.x86_64 #1 RIP: 0010:tcf_action_init+0x1f8/0x2c0 Seguimiento de llamadas: tcf_action_init+0x1f8/0x2c0 tcf_exts_validate_ex+0x175/0x190 fl_change+0x537/0x1120 [cls_flower]

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: s390/ism: añadir función de liberación para struct device. Según device_release() en /drivers/base/core.c, un dispositivo sin función de liberación es un dispositivo dañado y debe repararse. El código actual libera el dispositivo directamente tras llamar a device_add() sin esperar a que otras partes del kernel liberen sus referencias. Por lo tanto, una referencia a un dispositivo de estructura podría seguir manteniéndose, por ejemplo, mediante sysfs, lo que podría provocar problemas de uso después de la liberación si no se configura una función de liberación adecuada.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ibmvnic: No hacer referencia a skb después de enviar a VIOS. Anteriormente, tras vaciar correctamente el búfer de transmisión a VIOS, la estadística tx_bytes se incrementaba según la longitud de skb. No es posible acceder a la memoria de skb después de enviar el búfer a VIOS, ya que, en cualquier momento posterior al envío, VIOS puede activar una interrupción para liberar esta memoria. Es posible que se produzca una carrera entre la lectura de skb->len y la liberación de skb (especialmente durante LPM) y esto dará como resultado un uso después de la liberación: ======================================================================== ERROR KASAN: slab-use-after-free in ibmvnic_xmit+0x75c/0x1808 [ibmvnic] Read of size 4 at addr c00000024eb48a70 by task hxecom/14495 <...> Call Trace: [c000000118f66cf0] [c0000000018cba6c] dump_stack_lvl+0x84/0xe8 (unreliable) [c000000118f66d20] [c0000000006f0080] print_report+0x1a8/0x7f0 [c000000118f66df0] [c0000000006f08f0] kasan_report+0x128/0x1f8 [c000000118f66f00] [c0000000006f2868] __asan_load4+0xac/0xe0 [c000000118f66f20] [c0080000046eac84] ibmvnic_xmit+0x75c/0x1808 [ibmvnic] [c000000118f67340] [c0000000014be168] dev_hard_start_xmit+0x150/0x358 <...> Freed by task 0: kasan_save_stack+0x34/0x68 kasan_save_track+0x2c/0x50 kasan_save_free_info+0x64/0x108 __kasan_mempool_poison_object+0x148/0x2d4 napi_skb_cache_put+0x5c/0x194 net_tx_action+0x154/0x5b8 handle_softirqs+0x20c/0x60c do_softirq_own_stack+0x6c/0x88 <...> The buggy address belongs to the object at c00000024eb48a00 which belongs to the cache skbuff_head_cache of size 224 =======================================================================