Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/sched: Abort __tc_modify_qdisc si la clase padre no existe. El parche de Lion [1] reveló un error antiguo en la API de qdisc. Siempre que un usuario crea o modifica una qdisc que especifica otra qdisc como padre, la API de qdisc detecta, durante el injerto, que el usuario no intenta asociarse a una clase y lo rechaza. Sin embargo, el injerto se realiza después de ejecutar qdisc_create (y, por lo tanto, la devolución de llamada de inicio de la qdisc). En las qdisc que eventualmente llaman a qdisc_tree_reduce_backlog durante la inicialización o el cambio (como fq, hhf, choke, etc.), surge un problema. Por ejemplo, al ejecutar los siguientes comandos: sudo tc qdisc add dev lo root handle a: htb default 2 sudo tc qdisc add dev lo parent a: handle beef fq Las Qdisc como fq, hhf, choke, etc., invocan incondicionalmente qdisc_tree_reduce_backlog() en su ruta de control init() o change(), lo que provoca un error al no encontrar la clase hija; sin embargo, esto no detiene la invocación incondicional de qlen_notify de la qdisc hija asumida con una clase nula. Todas estas qdisc asumen que la clase no es nula. La solución es garantizar que qdisc_leaf(), que busca la clase padre y se invoca antes que qdisc_create(), devuelva un error al no encontrar la clase. En este parche, aprovechamos qdisc_leaf para devolver ERR_PTR siempre que el parentid no corresponda a una clase, de modo que podamos detectarlo antes y abortar antes de que se llame a qdisc_create. [1] https://lore.kernel.org/netdev/d912cbd7-193b-4269-9857-525bee8bbb6a@gmail.com/

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: atm: clip: Se corrige la desreferencia del puntero NULL en vcc_sendmsg() atmarpd_dev_ops no implementa el método de envío, lo que puede provocar un bloqueo como el que se muestra a continuación. BUG: kernel NULL pointer dereference, address: 0000000000000000 PGD 0 P4D 0 Oops: Oops: 0010 [#1] SMP KASAN NOPTI CPU: 0 UID: 0 PID: 5324 Comm: syz.0.0 Not tainted 6.15.0-rc6-syzkaller-00346-g5723cc3450bc #0 PREEMPT(full) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 RIP: 0010:0x0 Code: Unable to access opcode bytes at 0xffffffffffffffd6. RSP: 0018:ffffc9000d3cf778 EFLAGS: 00010246 RAX: 1ffffffff1910dd1 RBX: 00000000000000c0 RCX: dffffc0000000000 RDX: ffffc9000dc82000 RSI: ffff88803e4c4640 RDI: ffff888052cd0000 RBP: ffffc9000d3cf8d0 R08: ffff888052c9143f R09: 1ffff1100a592287 R10: dffffc0000000000 R11: 0000000000000000 R12: 1ffff92001a79f00 R13: ffff888052cd0000 R14: ffff88803e4c4640 R15: ffffffff8c886e88 FS: 00007fbc762566c0(0000) GS:ffff88808d6c2000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffffffffffffd6 CR3: 0000000041f1b000 CR4: 0000000000352ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: vcc_sendmsg+0xa10/0xc50 net/atm/common.c:644 sock_sendmsg_nosec net/socket.c:712 [inline] __sock_sendmsg+0x219/0x270 net/socket.c:727 ____sys_sendmsg+0x52d/0x830 net/socket.c:2566 ___sys_sendmsg+0x21f/0x2a0 net/socket.c:2620 __sys_sendmmsg+0x227/0x430 net/socket.c:2709 __do_sys_sendmmsg net/socket.c:2736 [inline] __se_sys_sendmmsg net/socket.c:2733 [inline] __x64_sys_sendmmsg+0xa0/0xc0 net/socket.c:2733 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xf6/0x210 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: atm: clip: Se corrige la llamada recursiva infinita de clip_push(). syzbot informó del problema a continuación. [0] Esto sucede si llamamos a ioctl(ATMARP_MKIP) más de una vez. Durante la primera llamada, clip_mkip() establece clip_push() en vcc->push() y la segunda llamada lo copia a clip_vcc->old_push(). Más tarde, cuando se cierra el socket, vcc_destroy_socket() pasa NULL skb a clip_push(), que llama a clip_vcc->old_push() y activa la recursión infinita. Prevengamos el segundo ioctl(ATMARP_MKIP) comprobando vcc->user_back, que se asigna en la primera llamada como clip_vcc. Tenga en cuenta también que usamos lock_sock() para evitar llamadas con mucha carga. [0]: BUG: TASK stack guard page was hit at ffffc9000d66fff8 (stack is ffffc9000d670000..ffffc9000d678000) Oops: stack guard page: 0000 [#1] SMP KASAN NOPTI CPU: 0 UID: 0 PID: 5322 Comm: syz.0.0 Not tainted 6.16.0-rc4-syzkaller #0 PREEMPT(full) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 RIP: 0010:clip_push+0x5/0x720 net/atm/clip.c:191 Code: e0 8f aa 8c e8 1c ad 5b fa eb ae 66 2e 0f 1f 84 00 00 00 00 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 55 <41> 57 41 56 41 55 41 54 53 48 83 ec 20 48 89 f3 49 89 fd 48 bd 00 RSP: 0018:ffffc9000d670000 EFLAGS: 00010246 RAX: 1ffff1100235a4a5 RBX: ffff888011ad2508 RCX: ffff8880003c0000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff888037f01000 RBP: dffffc0000000000 R08: ffffffff8fa104f7 R09: 1ffffffff1f4209e R10: dffffc0000000000 R11: ffffffff8a99b300 R12: ffffffff8a99b300 R13: ffff888037f01000 R14: ffff888011ad2500 R15: ffff888037f01578 FS: 000055557ab6d500(0000) GS:ffff88808d250000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffc9000d66fff8 CR3: 0000000043172000 CR4: 0000000000352ef0 Call Trace: clip_push+0x6dc/0x720 net/atm/clip.c:200 clip_push+0x6dc/0x720 net/atm/clip.c:200 clip_push+0x6dc/0x720 net/atm/clip.c:200 ... clip_push+0x6dc/0x720 net/atm/clip.c:200 clip_push+0x6dc/0x720 net/atm/clip.c:200 clip_push+0x6dc/0x720 net/atm/clip.c:200 vcc_destroy_socket net/atm/common.c:183 [inline] vcc_release+0x157/0x460 net/atm/common.c:205 __sock_release net/socket.c:647 [inline] sock_close+0xc0/0x240 net/socket.c:1391 __fput+0x449/0xa70 fs/file_table.c:465 task_work_run+0x1d1/0x260 kernel/task_work.c:227 resume_user_mode_work include/linux/resume_user_mode.h:50 [inline] exit_to_user_mode_loop+0xec/0x110 kernel/entry/common.c:114 exit_to_user_mode_prepare include/linux/entry-common.h:330 [inline] syscall_exit_to_user_mode_work include/linux/entry-common.h:414 [inline] syscall_exit_to_user_mode include/linux/entry-common.h:449 [inline] do_syscall_64+0x2bd/0x3b0 arch/x86/entry/syscall_64.c:100 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7ff31c98e929 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 a8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fffb5aa1f78 EFLAGS: 00000246 ORIG_RAX: 00000000000001b4 RAX: 0000000000000000 RBX: 0000000000012747 RCX: 00007ff31c98e929 RDX: 0000000000000000 RSI: 000000000000001e RDI: 0000000000000003 RBP: 00007ff31cbb7ba0 R08: 0000000000000001 R09: 0000000db5aa226f R10: 00007ff31c7ff030 R11: 0000000000000246 R12: 00007ff31cbb608c R13: 00007ff31cbb6080 R14: ffffffffffffffff R15: 00007fffb5aa2090 Modules linked in:

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: atm: clip: Se corrige un posible error de referencia nulo en to_atmarpd(). atmarpd está protegido por RTNL desde el commit f3a0592b37b8 ("[ATM]: clip provoca un bloqueo al cancelar el registro"). Sin embargo, esto no es suficiente, ya que to_atmarpd() se llama sin RTNL, especialmente clip_neigh_solicit() / neigh_ops->solicit() no se puede suspender. Además, atmarpd no depende de RTNL. Usemos un mutex privado y una RCU para proteger el acceso a atmarpd en to_atmarpd().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: vsock: Se corrige la asignación de transporte transport_* TOCTOU que podría competir con la descarga del módulo. Se evita que new_transport se convierta en un puntero obsoleto. Esto también soluciona una llamada insegura en vsock_use_local_transport(); se añade una aserción lockdep. BUG: unable to handle page fault for address: fffffbfff8056000 Oops: Oops: 0000 [#1] SMP KASAN RIP: 0010:vsock_assign_transport+0x366/0x600 Call Trace: vsock_connect+0x59c/0xc40 __sys_connect+0xe8/0x100 __x64_sys_connect+0x6e/0xc0 do_syscall_64+0x92/0x1c0 entry_SYSCALL_64_after_hwframe+0x4b/0x53

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: clk: imx: Se corrige un acceso fuera de los límites en dispmix_csr_clk_dev_data. Cuando num_parents es 4, __clk_register() genera un acceso fuera de los límites al acceder al miembro parent_names. Use ARRAY_SIZE() en lugar de codificar el número. BUG: KASAN: global-out-of-bounds in __clk_register+0x1844/0x20d8 Read of size 8 at addr ffff800086988e78 by task kworker/u24:3/59 Hardware name: NXP i.MX95 19X19 board (DT) Workqueue: events_unbound deferred_probe_work_func Call trace: dump_backtrace+0x94/0xec show_stack+0x18/0x24 dump_stack_lvl+0x8c/0xcc print_report+0x398/0x5fc kasan_report+0xd4/0x114 __asan_report_load8_noabort+0x20/0x2c __clk_register+0x1844/0x20d8 clk_hw_register+0x44/0x110 __clk_hw_register_mux+0x284/0x3a8 imx95_bc_probe+0x4f4/0xa70

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm/rmap: corrige el posible acceso fuera de los límites de la tabla de páginas durante la desasignación por lotes Como señaló David[1], la lógica de desasignación por lotes en try_to_unmap_one() puede leer más allá del final de una tabla PTE cuando las asignaciones PTE de un folio grande no están completamente contenidas dentro de una sola tabla de páginas. Si bien este escenario puede ser poco común, un problema desencadenable desde el espacio de usuario debe corregirse independientemente de su probabilidad. Este parche corrige el acceso fuera de los límites refactorizando la lógica en un nuevo ayudante, folio_unmap_pte_batch(). El nuevo ayudante calcula correctamente el tamaño de lote seguro al limitar el escaneo en los límites de VMA y PMD. Para simplificar el código, también admite el procesamiento por lotes parcial (es decir, cualquier número de páginas desde 1 hasta el máximo seguro calculado), ya que no hay una razón sólida para un caso especial de folios completamente mapeados.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: usb: gadget: u_serial: Corrección de la condición de ejecución en la activación de TTY. Una condición de ejecución ocurre cuando gs_start_io() llama a gs_start_rx() o gs_start_tx(), ya que estas funciones desactivan brevemente el port_lock para usb_ep_queue(). Esto permite que gs_close() y gserial_disconnect() borren port.tty y port_usb, respectivamente. Utilice la función auxiliar de puerto TTY segura para nulos para activar TTY. Ejemplo CPU1: CPU2: gserial_connect() // bloquear gs_close() // esperar bloqueo gs_start_rx() // desbloquear usb_ep_queue() gs_close() // bloquear, restablecer port.tty y desbloquear gs_start_rx() // bloquear tty_wakeup() // NPE

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/gem: Adquisición de referencias en manejadores GEM para framebuffers. Un manejador GEM puede liberarse mientras el objeto de búfer GEM está asociado a un framebuffer DRM. Esto provoca la liberación del dma-buf que respalda el objeto de búfer, si lo hay. [1] Intentar usar el framebuffer en otras operaciones de configuración de modo provoca un fallo de segmentación. Esto ocurre con mayor frecuencia con controladores que utilizan planos de sombra para vmapear el dma-buf durante un cambio de página. A continuación se muestra un ejemplo. [ 156.791968] ------------[ cut here ]------------ [ 156.796830] WARNING: CPU: 2 PID: 2255 at drivers/dma-buf/dma-buf.c:1527 dma_buf_vmap+0x224/0x430 [...] [ 156.942028] RIP: 0010:dma_buf_vmap+0x224/0x430 [ 157.043420] Call Trace: [ 157.045898] [ 157.048030] ? show_trace_log_lvl+0x1af/0x2c0 [ 157.052436] ? show_trace_log_lvl+0x1af/0x2c0 [ 157.056836] ? show_trace_log_lvl+0x1af/0x2c0 [ 157.061253] ? drm_gem_shmem_vmap+0x74/0x710 [ 157.065567] ? dma_buf_vmap+0x224/0x430 [ 157.069446] ? __warn.cold+0x58/0xe4 [ 157.073061] ? dma_buf_vmap+0x224/0x430 [ 157.077111] ? report_bug+0x1dd/0x390 [ 157.080842] ? handle_bug+0x5e/0xa0 [ 157.084389] ? exc_invalid_op+0x14/0x50 [ 157.088291] ? asm_exc_invalid_op+0x16/0x20 [ 157.092548] ? dma_buf_vmap+0x224/0x430 [ 157.096663] ? dma_resv_get_singleton+0x6d/0x230 [ 157.101341] ? __pfx_dma_buf_vmap+0x10/0x10 [ 157.105588] ? __pfx_dma_resv_get_singleton+0x10/0x10 [ 157.110697] drm_gem_shmem_vmap+0x74/0x710 [ 157.114866] drm_gem_vmap+0xa9/0x1b0 [ 157.118763] drm_gem_vmap_unlocked+0x46/0xa0 [ 157.123086] drm_gem_fb_vmap+0xab/0x300 [ 157.126979] drm_atomic_helper_prepare_planes.part.0+0x487/0xb10 [ 157.133032] ? lockdep_init_map_type+0x19d/0x880 [ 157.137701] drm_atomic_helper_commit+0x13d/0x2e0 [ 157.142671] ? drm_atomic_nonblocking_commit+0xa0/0x180 [ 157.147988] drm_mode_atomic_ioctl+0x766/0xe40 [...] [ 157.346424] ---[ end trace 0000000000000000 ]--- Acquiring GEM handles for the framebuffer's GEM buffer objects prevents this from happening. The framebuffer's cleanup later puts the handle references. Commit 1a148af06000 ("drm/gem-shmem: Use dma_buf from GEM object instance") triggers the segmentation fault easily by using the dma-buf field more widely. The underlying issue with reference counting has been present before. v2: - acquire the handle instead of the BO (Christian) - fix comment style (Christian) - drop the Fixes tag (Christian) - rename err_ gotos - add missing Link tag

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: mt76: mt7925: evitar la desreferencia de puntero nulo en mt7925_sta_set_decap_offload(). Se ha añadido una comprobación nula para msta->vif antes de acceder a sus miembros para evitar un pánico del kernel en la implementación en modo AP. Esto también soluciona el problema reportado en [1]. El fallo se produce cuando esta función se activa antes de que la estación se inicialice por completo. El seguimiento de llamadas muestra un fallo de página en mt7925_sta_set_decap_offload() debido al acceso a recursos cuando msta->vif es nulo. Para solucionar esto, se añade un retorno anticipado si msta->vif es nulo y se comprueba que wcid.sta esté listo. Esto garantiza que solo procedamos con la configuración de descarga de decap cuando el estado de la estación se inicialice correctamente. [14739.655703] Unable to handle kernel paging request at virtual address ffffffffffffffa0 [14739.811820] CPU: 0 UID: 0 PID: 895854 Comm: hostapd Tainted: G [14739.821394] Tainted: [C]=CRAP, [O]=OOT_MODULE [14739.825746] Hardware name: Raspberry Pi 4 Model B Rev 1.1 (DT) [14739.831577] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [14739.838538] pc : mt7925_sta_set_decap_offload+0xc0/0x1b8 [mt7925_common] [14739.845271] lr : mt7925_sta_set_decap_offload+0x58/0x1b8 [mt7925_common] [14739.851985] sp : ffffffc085efb500 [14739.855295] x29: ffffffc085efb500 x28: 0000000000000000 x27: ffffff807803a158 [14739.862436] x26: ffffff8041ececb8 x25: 0000000000000001 x24: 0000000000000001 [14739.869577] x23: 0000000000000001 x22: 0000000000000008 x21: ffffff8041ecea88 [14739.876715] x20: ffffff8041c19ca0 x19: ffffff8078031fe0 x18: 0000000000000000 [14739.883853] x17: 0000000000000000 x16: ffffffe2aeac1110 x15: 000000559da48080 [14739.890991] x14: 0000000000000001 x13: 0000000000000000 x12: 0000000000000000 [14739.898130] x11: 0a10020001008e88 x10: 0000000000001a50 x9 : ffffffe26457bfa0 [14739.905269] x8 : ffffff8042013bb0 x7 : ffffff807fb6cbf8 x6 : dead000000000100 [14739.912407] x5 : dead000000000122 x4 : ffffff80780326c8 x3 : 0000000000000000 [14739.919546] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffffff8041ececb8 [14739.926686] Call trace: [14739.929130] mt7925_sta_set_decap_offload+0xc0/0x1b8 [mt7925_common] [14739.935505] ieee80211_check_fast_rx+0x19c/0x510 [mac80211] [14739.941344] _sta_info_move_state+0xe4/0x510 [mac80211] [14739.946860] sta_info_move_state+0x1c/0x30 [mac80211] [14739.952116] sta_apply_auth_flags.constprop.0+0x90/0x1b0 [mac80211] [14739.958708] sta_apply_parameters+0x234/0x5e0 [mac80211] [14739.964332] ieee80211_add_station+0xdc/0x190 [mac80211] [14739.969950] nl80211_new_station+0x46c/0x670 [cfg80211] [14739.975516] genl_family_rcv_msg_doit+0xdc/0x150 [14739.980158] genl_rcv_msg+0x218/0x298 [14739.983830] netlink_rcv_skb+0x64/0x138 [14739.987670] genl_rcv+0x40/0x60 [14739.990816] netlink_unicast+0x314/0x380 [14739.994742] netlink_sendmsg+0x198/0x3f0 [14739.998664] __sock_sendmsg+0x64/0xc0 [14740.002324] ____sys_sendmsg+0x260/0x298 [14740.006242] ___sys_sendmsg+0xb4/0x110

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: md/md-bitmap: corrección de GPF en bitmap_get_stats(). El mensaje del commit 6ec1f0239485 ("md/md-bitmap: corrección de la recopilación de estadísticas para mapas de bits externos") indica: Se elimina la comprobación de mapas de bits externos, ya que las estadísticas deben estar disponibles independientemente de su ubicación de almacenamiento. Se devuelve -EINVAL solo para mapas de bits no válidos sin almacenamiento (ni en superbloque ni en archivo externo). Sin embargo, el código no cumple con lo anterior, ya que solo comprueba si hay un superbloque válido para mapas de bits "internos". Por lo tanto, observamos: Oops: GPF, probablemente para la dirección no canónica 0x1cd66f1f40000028 RIP: 0010:bitmap_get_stats+0x45/0xd0 Rastreo de llamadas: seq_read_iter+0x2b9/0x46a seq_read+0x12f/0x180 proc_reg_read+0x57/0xb0 vfs_read+0xf6/0x380 ksys_read+0x6d/0xf0 do_syscall_64+0x8c/0x1b0 entry_SYSCALL_64_after_hwframe+0x76/0x7e Solucionamos esto verificando la existencia de un superbloque tanto para el caso interno como para el externo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: ethernet: rtsn: Se corrige una desreferencia de puntero nulo en rtsn_probe(). Se agrega una verificación para el valor de retorno de rcar_gen4_ptp_alloc() para evitar una posible desreferencia de puntero nulo.