Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/ncsi: deshabilitar la función work de ncsi antes de liberar la estructura asociada. La función work puede ejecutarse después de que se libera el dispositivo ncsi, lo que genera errores de use after free o pánico del kernel.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: prueba de que csum_start no sea demasiado pequeño en virtio_net_hdr_to_skb() syzbot pudo activar esta advertencia [1], después de inyectar un paquete malicioso a través de af_packet, configurando skb->csum_start y, por lo tanto, el encabezado de transporte con un valor incorrecto. Al menos podemos asegurarnos de que el encabezado de transporte esté después del final del encabezado de red (con un tamaño mínimo estimado). [1] [ 67.873027] longitud skb=4096 espacio libre=16 longitud libre=14 espacio libre=0 mac=(-1,-1) longitud_mac=0 red=(16,-6) trans=10 shinfo(txflags=0 nr_frags=1 gso(tamaño=0 tipo=0 segmentos=0)) suma_c(0xa inicio=10 desplazamiento=0 suma_ip=3 software_completo=0 válido=0 nivel=0) hash(0x0 software=0 l4=0) proto=0x0800 tipo_paquete=0 iif=0 prioridad=0x0 marca=0x0 asignar_cpu=10 vlan_all=0x0 encapsulación=0 interno(proto=0x0000, mac=0, red=0, trans=0) [ 67.877172] nombre_de_desarrollo=veth0_vlan hazaña=0x000061164fdd09e9 [ 67.877764] familia sk=17 tipo=3 proto=0 [ 67.878279] skb lineal: 00000000: 00 00 10 00 00 00 00 00 0f 00 00 00 08 00 [ 67.879128] fragmento skb: 00000000: 0e 00 07 00 00 00 28 00 08 80 1c 00 04 00 00 02 [ 67.879877] fragmento skb: 00000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.880647] skb frag: 00000020: 00 00 02 00 00 00 08 00 1b 00 00 00 00 00 00 00 [ 67.881156] skb frag: 0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [67.881753] skb frag: 00000040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [67.882173] fragmento de skb: 00000050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [67.882790] fragmento de skb: 00000060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.883171] skb frag: 00000070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.883733] fragmento: 00000080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.884206] fragmento skb: 00000090: 00 00 00 00 00 00 00 00 00 00 69 70 76 6c 61 6e [ 67.884704] fragmento skb: 000000a0: 31 00 00 00 00 00 00 00 00 00 2b 00 00 00 00 00 [ 67.885139] fragmento skb: 000000b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.885677] fragmento de skb: 000000c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.886042] fragmento de skb: 000000d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.886408] fragmento de skb: 000000e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.887020] fragmento skb: 000000f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.887384] fragmento skb: 00000100: 00 00 [ 67.887878] ------------[ cortar aquí ]------------ [ 67.887908] desplazamiento (-6) >= skb_headlen() (14) [ 67.888445] ADVERTENCIA: CPU: 10 PID: 2088 en net/core/dev.c:3332 skb_checksum_help (net/core/dev.c:3332 (discriminador 2)) [ 67.889353] Módulos vinculados en: macsec macvtap macvlan hsr wireguard curve25519_x86_64 libcurve25519_generic libchacha20poly1305 chacha_x86_64 libchacha poly1305_x86_64 puente ficticio sr_mod cdrom evdev pcspkr i2c_piix4 9pnet_virtio 9p 9pnet netfs [ 67.890111] CPU: 10 UID: 0 PID: 2088 Comm: b363492833 No contaminado 6.11.0-virtme #1011 [ 67.890183] Nombre del hardware: QEMU PC estándar (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 01/04/2014 [ 67.890309] RIP: 0010:skb_checksum_help (net/core/dev.c:3332 (discriminador 2)) [ 67.891043] Seguimiento de llamadas: [ 67.891173] [ 67.891274] ? __warn (kernel/panic.c:741) [ 67.891320] ? skb_checksum_help (net/core/dev.c:3332 (discriminador 2)) [ 67.891333] ? report_bug (lib/bug.c:180 lib/bug.c:219) [ 67.891348] ? handle_bug (arch/x86/kernel/traps.c:239) [ 67.891363] ? exc_invalid_op (arch/x86/kernel/traps.c:260 (discriminador 1)) [ ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/mlx5e: Se corrige el fallo causado por llamar a __xfrm_state_delete() dos veces. El km.state no se comprueba en el trabajo retrasado del controlador. Cuando se llama a xfrm_state_check_expire(), el estado se puede restablecer a XFRM_STATE_EXPIRED, incluso si ya está XFRM_STATE_DEAD. Esto sucede cuando se elimina el estado de xfrm, pero aún no se libera. Cuando se vuelve a llamar a __xfrm_state_delete() en el temporizador de xfrm, se produce el siguiente fallo. Para solucionar este problema, omita xfrm_state_check_expire() si km.state no es XFRM_STATE_VALID. Ups: fallo de protección general, probablemente para la dirección no canónica 0xdead000000000108: 0000 [#1] CPU SMP: 5 UID: 0 PID: 7448 Comm: kworker/u102:2 No contaminado 6.11.0-rc2+ #1 Nombre del hardware: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 01/04/2014 Cola de trabajo: mlx5e_ipsec: eth%d mlx5e_ipsec_handle_sw_limits [mlx5_core] RIP: 0010:__xfrm_state_delete+0x3d/0x1b0 Código: 0f 84 8b 01 00 00 48 89 fd c6 87 c8 00 00 00 05 48 8d bb 40 10 00 00 e8 11 04 1a 00 48 8b 95 b8 00 00 00 48 8b 85 c0 00 00 00 <48> 89 42 08 48 89 10 48 8b 55 10 48 b8 00 01 00 00 00 00 ad de 48 RSP: 0018:ffff88885f945ec8 EFLAGS: 00010246 RAX: muerto000000000122 RBX: ffffffff82afa940 RCX: 00000000000000036 RDX: muerto000000000100 RSI: 0000000000000000 RDI: ffffffff82afb980 RBP: ffff888109a20340 R08: ffff88885f945ea0 R09: 0000000000000000 R10: 0000000000000000 R11: ffff88885f945ff8 R12: 0000000000000246 R13: ffff888109a20340 R14: ffff88885f95f420 R15: ffff88885f95f400 FS: 0000000000000000(0000) GS:ffff88885f940000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f2163102430 CR3: 00000001128d6001 CR4: 0000000000370eb0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Rastreo de llamadas: ? die_addr+0x33/0x90 ? exc_general_protection+0x1a2/0x390 ? asm_exc_general_protection+0x22/0x30 ? __xfrm_state_delete+0x3d/0x1b0 ? __xfrm_state_delete+0x2f/0x1b0 xfrm_timer_handler+0x174/0x350 ? __local_bh_enable_ip+0x47/0x50 mlx5e_ipsec_handle_sw_limits+0x7d/0x90 [mlx5_core] process_one_work+0x137/0x2d0 worker_thread+0x28d/0x3a0 ? rescuer_thread+0x480/0x480 kthread+0xb8/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: gfs2: se corrige el error doble destroy_workqueue Cuando falla gfs2_fill_super(), se llama destroy_workqueue() dentro de gfs2_gl_hash_clear() y la ruta de código posterior vuelve a llamar a destroy_workqueue() en la misma cola de trabajo. Este problema se puede solucionar configurando el puntero de la cola de trabajo en NULL después de la primera llamada destroy_workqueue() y comprobando si hay un puntero NULL antes de intentar destruir la cola de trabajo nuevamente.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: Bluetooth: MGMT: Se corrige un posible fallo en mgmt_index_removed Si se llama a mgmt_index_removed mientras hay comandos en cola en cmd_sync, podría provocar fallos como el siguiente seguimiento: 0x0000053D: __list_del_entry_valid_or_report+0x98/0xdc 0x0000053D: mgmt_pending_remove+0x18/0x58 [bluetooth] 0x0000053E: mgmt_remove_adv_monitor_complete+0x80/0x108 [bluetooth] 0x0000053E: hci_cmd_sync_work+0xbc/0x164 [bluetooth] Entonces, mientras se maneja mgmt_index_removed, esto intenta quitar de la cola los comandos pasados como usuario_data a cmd_sync.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ppp: no asuma que bh se mantiene en ppp_channel_bridge_input() La ruta de recepción de red generalmente se maneja desde el controlador BH. Sin embargo, algunos protocolos necesitan adquirir el bloqueo del socket y los paquetes pueden almacenarse en el backlog del socket si el socket era propiedad de un proceso de usuario. En este caso, release_sock(), __release_sock() y sk_backlog_rcv() pueden llamar al controlador sk->sk_backlog_rcv() en el contexto del proceso. sybot capturó que ppp no estaba considerando este caso en ppp_channel_bridge_input(): ADVERTENCIA: estado de bloqueo inconsistente 6.11.0-rc7-syzkaller-g5f5673607153 #0 No contaminado -------------------------------- uso inconsistente de {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W}. ksoftirqd/1/24 [HC0[0]:SC1[1]:HE1:SE0] toma: ffff0000db7f11e0 (&pch->downl){+.?.}-{2:2}, en: spin_lock include/linux/spinlock.h:351 [en línea] ffff0000db7f11e0 (&pch->downl){+.?.}-{2:2}, en: ppp_channel_bridge_input drivers/net/ppp/ppp_generic.c:2272 [en línea] ffff0000db7f11e0 (&pch->downl){+.?.}-{2:2}, en: ppp_input+0x16c/0x854 drivers/net/ppp/ppp_generic.c:2304 El estado {SOFTIRQ-ON-W} se registró en: lock_acquire+0x240/0x728 kernel/locking/lockdep.c:5759 __raw_spin_lock include/linux/spinlock_api_smp.h:133 [en línea] _raw_spin_lock+0x48/0x60 kernel/locking/spinlock.c:154 spin_lock include/linux/spinlock.h:351 [en línea] ppp_channel_bridge_input drivers/net/ppp/ppp_generic.c:2272 [en línea] ppp_input+0x16c/0x854 drivers/net/ppp/ppp_generic.c:2304 pppoe_rcv_core+0xfc/0x314 drivers/net/ppp/pppoe.c:379 sk_backlog_rcv incluir/net/sock.h:1111 [en línea] __release_sock+0x1a8/0x3d8 net/core/sock.c:3004 release_sock+0x68/0x1b8 net/core/sock.c:3558 pppoe_sendmsg+0xc8/0x5d8 drivers/net/ppp/pppoe.c:903 sock_sendmsg_nosec net/socket.c:730 [en línea] __sock_sendmsg net/socket.c:745 [en línea] __sys_sendto+0x374/0x4f4 net/socket.c:2204 __do_sys_sendto net/socket.c:2216 [en línea] __se_sys_sendto net/socket.c:2212 [en línea] __arm64_sys_sendto+0xd8/0xf8 net/socket.c:2212 __invoke_syscall arch/arm64/kernel/syscall.c:35 [en línea] invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:49 el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:132 do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:151 el0_svc+0x54/0x168 arch/arm64/kernel/entry-common.c:712 el0t_64_sync_handler+0x84/0xfc arch/arm64/kernel/entry-common.c:730 el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:598 marca de evento de irq: 282914 hardirqs habilitados por última vez en (282914): [] __raw_spin_unlock_irqrestore include/linux/spinlock_api_smp.h:151 [en línea] hardirqs habilitados por última vez en (282914): [] _raw_spin_unlock_irqrestore+0x38/0x98 kernel/locking/spinlock.c:194 hardirqs deshabilitados por última vez en (282913): [] __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:108 [en línea] hardirqs se desactivó por última vez en (282913): [] _raw_spin_lock_irqsave+0x2c/0x7c kernel/locking/spinlock.c:162 softirqs se activó por última vez en (282904): [] softirq_handle_end kernel/softirq.c:400 [en línea] softirqs se activó por última vez en (282904): [] handle_softirqs+0xa3c/0xbfc kernel/softirq.c:582 softirqs se desactivó por última vez en (282909): [] run_ksoftirqd+0x70/0x158 kernel/softirq.c:928 otra información que podría ayudarnos a depurar esto: Posible escenario de bloqueo inseguro: CPU0 ---- lock(&pch->downl); lock(&pch->downl); *** BLOQUEO INTERMEDIO *** 1 bloqueo mantenido por ksoftirqd/1/24: #0: ffff80008f74dfa0 (rcu_read_lock){....}-{1:2}, en: rcu_lock_acquire+0x10/0x4c include/linux/rcupdate.h:325 seguimiento de pila: CPU: 1 UID: 0 PID: 24 Comm: ksoftirqd/1 No contaminado 6.11.0-rc7-syzkaller-g5f5673607153 #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 Seguimiento de llamadas: dump_backtrace+0x1b8/0x1e4 arch/ar---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: añadir más comprobaciones de cordura a qdisc_pkt_len_init() Una ruta se encarga de SKB_GSO_DODGY, asumiendo que skb->len es más grande que hdr_len. virtio_net_hdr_to_skb() no disecciona completamente los encabezados TCP, solo se asegura de que tengan al menos 20 bytes. Es posible que un usuario proporcione un paquete 'GSO' malicioso, con una longitud total de 80 bytes. - 20 bytes de encabezado IPv4 - 60 bytes de encabezado TCP - un gso_size pequeño como 8 virtio_net_hdr_to_skb() declararía este paquete como un paquete GSO normal, porque vería 40 bytes de carga útil, más grande que gso_size. Necesitamos hacer que detecte este caso para no desbordar qdisc_skb_cb(skb)->pkt_len.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: evitar un posible desbordamiento en qdisc_pkt_len_init() con UFO Después de el commit 7c6d2ecbda83 ("net: sea más cuidadoso con las solicitudes gso tontas que vienen del usuario"), virtio_net_hdr_to_skb() tuvo una verificación de cordura para detectar intentos maliciosos desde el espacio del usuario de cocinar un paquete GSO defectuoso. Luego, confirma cf9acc90c80ec ("net: virtio_net_hdr_to_skb: cuenta el encabezado de transporte en UFO") mientras corrige un problema, permitió que el espacio de usuario cocinara un paquete GSO con la siguiente característica: IPv4 SKB_GSO_UDP, gso_size=3, skb->len = 28. Cuando este paquete llega a qdisc_pkt_len_init(), terminamos con hdr_len = 28 (encabezado IPv4 + encabezado UDP), que coincide con skb->len. Luego, lo siguiente establece gso_segs en 0: gso_segs = DIV_ROUND_UP(skb->len - hdr_len, shinfo->gso_size); Luego, configuramos qdisc_skb_cb(skb)->pkt_len nuevamente a cero :/ qdisc_skb_cb(skb)->pkt_len += (gso_segs - 1) * hdr_len; Esto genera el siguiente bloqueo en fq_codel [1] qdisc_pkt_len_init() es el mejor esfuerzo, solo queremos una estimación de los bytes enviados en la red, no bloquear el kernel. Este parche soluciona este problema en particular, el siguiente agrega más controles de cordura para otro error potencial. [1] [ 70.724101] ERROR: desreferencia de puntero NULL del núcleo, dirección: 0000000000000000 [ 70.724561] #PF: acceso de lectura del supervisor en modo núcleo [ 70.724561] #PF: error_code(0x0000) - página no presente [ 70.724561] PGD 10ac61067 P4D 10ac61067 PUD 107ee2067 PMD 0 [ 70.724561] Oops: Oops: 0000 [#1] SMP NOPTI [ 70.724561] CPU: 11 UID: 0 PID: 2163 Comm: b358537762 No contaminado 6.11.0-virtme #991 [ 70.724561] Nombre del hardware: PC estándar QEMU (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 01/04/2014 [ 70.724561] RIP: 0010:fq_codel_enqueue (net/sched/sch_fq_codel.c:120 net/sched/sch_fq_codel.c:168 net/sched/sch_fq_codel.c:230) sch_fq_codel [ 70.724561] Código: 24 08 49 c1 e1 06 44 89 7c 24 18 45 31 ed 45 31 c0 31 ff 89 44 24 14 4c 03 8b 90 01 00 00 eb 04 39 ca 73 37 4d 8b 39 83 c7 01 <49> 8b 17 49 89 11 41 8b 57 28 45 8b 5f 34 49 c7 07 00 00 00 00 49 Todo el código ======== 0: 24 08 y $0x8,%al 2: 49 c1 e1 06 shl $0x6,%r9 6: 44 89 7c 24 18 mov %r15d,0x18(%rsp) b: 45 31 ed xor %r13d,%r13d e: 45 31 c0 xor %r8d,%r8d 11: 31 ff xor %edi,%edi 13: 89 44 24 14 mov %eax,0x14(%rsp) 17: 4c 03 8b 90 01 00 00 suma 0x190(%rbx),%r9 1e: eb 04 jmp 0x24 20: 39 ca cmp %ecx,%edx 22: 73 37 jae 0x5b 24: 4d 8b 39 mov (%r9),%r15 27: 83 c7 01 suma $0x1,%edi 2a:* 49 8b 17 mov (%r15),%rdx <-- instrucción de captura 2d: 49 89 11 mov %rdx,(%r9) 30: 41 8b 57 28 mov 0x28(%r15),%edx 34: 45 8b 5f 34 mov 0x34(%r15),%r11d 38: 49 c7 07 00 00 00 00 movq $0x0,(%r15) 3f: 49 rex.WB Código que comienza con la instrucción que fallo ============================================= 0: 49 8b 17 mov (%r15),%rdx 3: 49 89 11 mov %rdx,(%r9) 6: 41 8b 57 28 mov 0x28(%r15),%edx a: 45 8b 5f 34 mov 0x34(%r15),%r11d e: 49 c7 07 00 00 00 00 movq $0x0,(%r15) 15: 49 rex.WB [ 70.724561] RSP: 0018:ffff95ae85e6fb90 EFLAGS: 00000202 [ 70.724561] RAX: 000000000200000 RBX: ffff95ae841de000 RCX: 0000000000000000 [ 70.724561] RDX: 0000000000000000 RSI: 0000000000000001 RDI: 00000000000000001 [ 70.724561] RBP: ffff95ae85e6fbf8 R08: 0000000000000000 R09: ffff95b710a30000 [ 70.724561] R10: 000000000000000 R11: bdf289445ce31881 R12: ffff95ae85e6fc58 [ 70.724561] R13: 000000000000000 R14: 0000000000000040 R15: 0000000000000000 [ 70.724561] FS: 000000002c5c1380(0000) GS:ffff95bd7fcc0000(0000) knlGS:0000000000000000 [ 70.724561] CS: 0010 DS: 0000 ES: 0000 C ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: Bluetooth: L2CAP: Fix uaf en l2cap_connect [Syzbot informó] ERROR: KASAN: slab-use-after-free en l2cap_connect.constprop.0+0x10d8/0x1270 net/bluetooth/l2cap_core.c:3949 Lectura de tamaño 8 en la dirección ffff8880241e9800 por la tarea kworker/u9:0/54 CPU: 0 UID: 0 PID: 54 Comm: kworker/u9:0 No contaminado 6.11.0-rc6-syzkaller-00268-g788220eee30d #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 Cola de trabajo: hci2 hci_rx_work Seguimiento de llamadas: __dump_stack lib/dump_stack.c:93 [en línea] dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:119 imprimir_dirección_descripción mm/kasan/report.c:377 [en línea] imprimir_report+0xc3/0x620 mm/kasan/report.c:488 kasan_report+0xd9/0x110 mm/kasan/report.c:601 l2cap_connect.constprop.0+0x10d8/0x1270 net/bluetooth/l2cap_core.c:3949 l2cap_connect_req net/bluetooth/l2cap_core.c:4080 [en línea] l2cap_bredr_sig_cmd net/bluetooth/l2cap_core.c:4772 [en línea] l2cap_sig_channel net/bluetooth/l2cap_core.c:5543 [en línea] l2cap_recv_frame+0xf0b/0x8eb0 net/bluetooth/l2cap_core.c:6825 l2cap_recv_acldata+0x9b4/0xb70 net/bluetooth/l2cap_core.c:7514 hci_acldata_packet net/bluetooth/hci_core.c:3791 [en línea] hci_rx_work+0xaab/0x1610 net/bluetooth/hci_core.c:4028 process_one_work+0x9c5/0x1b40 kernel/workqueue.c:3231 process_scheduled_works kernel/workqueue.c:3312 [en línea] worker_thread+0x6c8/0xed0 kernel/workqueue.c:3389 kthread+0x2c1/0x3a0 kernel/kthread.c:389 ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 ... Liberado por la tarea 5245: kasan_save_stack+0x33/0x60 mm/kasan/common.c:47 kasan_save_track+0x14/0x30 mm/kasan/common.c:68 kasan_save_free_info+0x3b/0x60 mm/kasan/generic.c:579 poison_slab_object+0xf7/0x160 mm/kasan/common.c:240 __kasan_slab_free+0x32/0x50 mm/kasan/common.c:256 kasan_slab_free include/linux/kasan.h:184 [en línea] slab_free_hook mm/slub.c:2256 [en línea] slab_free mm/slub.c:4477 [en línea] kfree+0x12a/0x3b0 mm/slub.c:4598 l2cap_conn_free net/bluetooth/l2cap_core.c:1810 [en línea] kref_put include/linux/kref.h:65 [en línea] l2cap_conn_put net/bluetooth/l2cap_core.c:1822 [en línea] l2cap_conn_del+0x59d/0x730 net/bluetooth/l2cap_core.c:1802 l2cap_connect_cfm+0x9e6/0xf80 red/bluetooth/l2cap_core.c:7241 hci_connect_cfm include/red/bluetooth/hci_core.h:1960 [en línea] hci_conn_failed+0x1c3/0x370 red/bluetooth/hci_conn.c:1265 hci_abort_conn_sync+0x75a/0xb50 red/bluetooth/hci_sync.c:5583 abort_conn_sync+0x197/0x360 red/bluetooth/hci_conn.c:2917 hci_cmd_sync_work+0x1a4/0x410 red/bluetooth/hci_sync.c:328 process_one_work+0x9c5/0x1b40 kernel/workqueue.c:3231 process_scheduled_works kernel/workqueue.c:3312 [en línea] worker_thread+0x6c8/0xed0 kernel/workqueue.c:3389 kthread+0x2c1/0x3a0 kernel/kthread.c:389 ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: netfilter: nf_tables: prevent nf_skb_duplicated democracy syzbot encontró que nf_dup_ipv4() o nf_dup_ipv6() podrían escribir la variable por CPU nf_skb_duplicated de una manera insegura [1]. Deshabilitar la preempción como lo sugiere el splat no es suficiente, también tenemos que deshabilitar las interrupciones suaves. [1] ERROR: uso de __this_cpu_write() en código preemptible [00000000]: syz.4.282/6316 el llamador es nf_dup_ipv4+0x651/0x8f0 net/ipv4/netfilter/nf_dup_ipv4.c:87 CPU: 0 UID: 0 PID: 6316 Comm: syz.4.282 No contaminado 6.11.0-rc7-syzkaller-00104-g7052622fccb1 #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 Seguimiento de llamadas: __dump_stack lib/dump_stack.c:93 [en línea] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119 check_preemption_disabled+0x10e/0x120 lib/smp_processor_id.c:49 nf_dup_ipv4+0x651/0x8f0 net/ipv4/netfilter/nf_dup_ipv4.c:87 nft_dup_ipv4_eval+0x1db/0x300 net/ipv4/netfilter/nft_dup_ipv4.c:30 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_ipv4+0x202/0x320 net/netfilter/nft_chain_filter.c:23 nf_hook_entry_hookfn incluye/linux/netfilter.h:154 [en línea] nf_hook_slow+0xc3/0x220 net/netfilter/core.c:626 nf_hook+0x2c4/0x450 incluye/linux/netfilter.h:269 NF_HOOK_COND incluye/linux/netfilter.h:302 [en línea] ip_output+0x185/0x230 net/ipv4/ip_output.c:433 ip_local_out net/ipv4/ip_output.c:129 [en línea] ip_send_skb+0x74/0x100 net/ipv4/ip_output.c:1495 udp_send_skb+0xacf/0x1650 net/ipv4/udp.c:981 udp_sendmsg+0x1c21/0x2a60 net/ipv4/udp.c:1269 sock_sendmsg_nosec net/socket.c:730 [en línea] __sock_sendmsg+0x1a6/0x270 net/socket.c:745 ____sys_sendmsg+0x525/0x7d0 net/socket.c:2597 ___sys_sendmsg net/socket.c:2651 [en línea] __sys_sendmmsg+0x3b2/0x740 net/socket.c:2737 __do_sys_sendmmsg net/socket.c:2766 [en línea] __se_sys_sendmmsg net/socket.c:2763 [en línea] __x64_sys_sendmmsg+0xa0/0xb0 net/socket.c:2763 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:0x7f4ce4f7def9 Código: 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:00007f4ce5d4a038 EFLAGS: 00000246 ORIG_RAX: 0000000000000133 RAX: ffffffffffffffda RBX: 00007f4ce5135f80 RCX: 00007f4ce4f7def9 RDX: 00000000000000001 RSI: 0000000020005d40 RDI: 0000000000000006 RBP: 00007f4ce4ff0b76 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 0000000000000000 R14: 00007f4ce5135f80 R15: 00007ffd4cbc6d68

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: static_call: Reemplazar WARN_ON() sin sentido en static_call_module_notify() static_call_module_notify() activa un WARN_ON() cuando la asignación de memoria fallo en __static_call_add_module(). Esto no está realmente justificado, porque el caso de fallo debe ser manejado correctamente por la cadena de llamadas conocida y el código de error se pasa a la aplicación de espacio de usuario que la inicia. Un error en la asignación de memoria no es un problema fatal, pero WARN_ON() deja fuera de servicio la máquina cuando se establece panic_on_warn. Reemplázalo con un pr_warn().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ACPI: batería: se corrige un posible fallo al anular el registro de un gancho de batería Cuando un gancho de batería devuelve un error al añadir una batería nueva, el gancho de batería se anula automáticamente el registro. Sin embargo, el proveedor del gancho de batería no puede saberlo, por lo que más tarde llamará a battery_hook_unregister() en el gancho de batería ya anulado, lo que provocará un fallo. Solucione esto utilizando el encabezado de lista para marcar los ganchos de batería ya anulados como ya anulados para que battery_hook_unregister() pueda ignorarlos.