Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: tcp: evitar la ejecución concurrente de tcp_sk_exit_batch Es posible que dos subprocesos llamen a tcp_sk_exit_batch() simultáneamente, una vez desde la cola de trabajo cleanup_net, otra desde una tarea que no pudo clonar una nueva netns. En el último caso, el desenrollado de errores llama a los controladores de salida en orden inverso para las netns "fallidas". tcp_sk_exit_batch() llama a tcp_twsk_purge(). El problema es que desde el commit b099ce2602d8 ("net: Batch inet_twsk_purge"), esta función recoge twsk en cualquier netn moribundo, no solo en el que se pasa a través de la lista exit_batch. Esto significa que el desenrollado de errores de setup_net() puede "robar" y destruir los sockets timewait que pertenecen a las netns que salen. Esto permite que el trabajador de salida netns proceda a llamar a WARN_ON_ONCE(!refcount_dec_and_test(&net->ipv4.tcp_death_row.tw_refcount)); sin la transición esperada de 1 -> 0, que luego falla. Al mismo tiempo, la ruta de desenrollado de error que también está ejecutando inet_twsk_purge() también se mostrará: ADVERTENCIA: .. en lib/refcount.c:31 refcount_warn_saturate+0x1ed/0x210 ... refcount_dec include/linux/refcount.h:351 [en línea] inet_twsk_kill+0x758/0x9c0 net/ipv4/inet_timewait_sock.c:70 inet_twsk_deschedule_put net/ipv4/inet_timewait_sock.c:221 inet_twsk_purge+0x725/0x890 net/ipv4/inet_timewait_sock.c:304 tcp_sk_exit_batch+0x1c/0x170 net/ipv4/tcp_ipv4.c:3522 ops_exit_list+0x128/0x180 net/core/net_namespace.c:178 setup_net+0x714/0xb40 net/core/net_namespace.c:375 copy_net_ns+0x2f0/0x670 net/core/net_namespace.c:508 create_new_namespaces+0x3ea/0xb10 kernel/nsproxy.c:110 ... porque refcount_dec() de tw_refcount cayó inesperadamente a 0. Esto no parece un error real (no se perdieron sockets tw y no veo un use-after-free) sino un disparador erróneo de la comprobación de depuración. Agregue un mutex para forzar un orden estricto: la tarea que llama a tcp_twsk_purge() impide que otra tarea realice _dec_and_test final antes de que el propietario del mutex haya eliminado todos los sockets tw de los netn moribundos.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net:hns3: se corrige un problema de bloqueo cuando se configura TC durante el reinicio Cuando se configura TC durante el proceso de reinicio, puede causar un bloqueo, el flujo es el siguiente: pf reset start ? ? ...... setup tc ? ? ? ? DOWN: napi_disable() napi_disable()(skip) ? ? ? ? ? ...... ...... ? ? ? ? napi_enable() ? ? UINIT: netif_napi_del() ? ? ...... ? ? INIT: netif_napi_add() ? ? ...... global reset start ? ? ? ? UP: napi_enable()(skip) ...... ? ? ? ? ...... napi_disable() En el proceso de reinicio, el controlador DESACTIVARÁ el puerto y luego UINIT; en este caso, el proceso de configuración tc DESACTIVARÁ el puerto antes de UINIT, lo que provocará el problema. Agrega un proceso DESACTIVADO en UINIT para solucionarlo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: atm: idt77252: evitar use after free en dequeue_rx() No podemos desreferenciar "skb" después de llamar a vcc->push() porque skb está liberado.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: gtp: extraer encabezados de red en gtp_dev_xmit() syzbot/KMSAN informó del uso de uninit-value en get_dev_xmit() [1] Debemos asegurarnos de que el encabezado IPv4 o Ipv6 se extraiga en skb->head antes de acceder a los campos que contienen. Utilice pskb_inet_may_pull() para solucionar este problema. [1] ERROR: KMSAN: valor no inicializado en ipv6_pdp_find drivers/net/gtp.c:220 [en línea] ERROR: KMSAN: valor no inicializado en gtp_build_skb_ip6 drivers/net/gtp.c:1229 [en línea] ERROR: KMSAN: valor no inicializado en gtp_dev_xmit+0x1424/0x2540 drivers/net/gtp.c:1281 ipv6_pdp_find drivers/net/gtp.c:220 [en línea] gtp_build_skb_ip6 drivers/net/gtp.c:1229 [en línea] gtp_dev_xmit+0x1424/0x2540 drivers/net/gtp.c:1281 __netdev_start_xmit incluir/linux/netdevice.h:4913 [en línea] netdev_start_xmit incluir/linux/netdevice.h:4922 [en línea] xmit_one net/core/dev.c:3580 [en línea] dev_hard_start_xmit+0x247/0xa20 net/core/dev.c:3596 __dev_queue_xmit+0x358c/0x5610 net/core/dev.c:4423 dev_queue_xmit incluir/linux/netdevice.h:3105 [en línea] paquete_xmit+0x9c/0x6c0 net/paquete/af_packet.c:276 paquete_snd net/paquete/af_packet.c:3145 [en línea] paquete_sendmsg+0x90e3/0xa3a0 net/packet/af_packet.c:3177 sock_sendmsg_nosec net/socket.c:730 [en línea] __sock_sendmsg+0x30f/0x380 net/socket.c:745 __sys_sendto+0x685/0x830 net/socket.c:2204 __do_sys_sendto net/socket.c:2216 [en línea] __se_sys_sendto net/socket.c:2212 [en línea] __x64_sys_sendto+0x125/0x1d0 net/socket.c:2212 x64_sys_call+0x3799/0x3c10 arch/x86/include/generated/asm/syscalls_64.h:45 do_syscall_x64 arch/x86/entry/common.c:52 [en línea] do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f Uninit se creó en: slab_post_alloc_hook mm/slub.c:3994 [en línea] slab_alloc_node mm/slub.c:4037 [en línea] kmem_cache_alloc_node_noprof+0x6bf/0xb80 mm/slub.c:4080 kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:583 __alloc_skb+0x363/0x7b0 net/core/skbuff.c:674 alloc_skb include/linux/skbuff.h:1320 [en línea] alloc_skb_with_frags+0xc8/0xbf0 net/core/skbuff.c:6526 sock_alloc_send_pskb+0xa81/0xbf0 net/core/sock.c:2815 packet_alloc_skb net/packet/af_packet.c:2994 [en línea] packet_snd net/packet/af_packet.c:3088 [en línea] packet_sendmsg+0x749c/0xa3a0 net/packet/af_packet.c:3177 sock_sendmsg_nosec net/socket.c:730 [en línea] __sock_sendmsg+0x30f/0x380 net/socket.c:745 __sys_sendto+0x685/0x830 red/socket.c:2204 __do_sys_sendto red/socket.c:2216 [en línea] __se_sys_sendto red/socket.c:2212 [en línea] __x64_sys_sendto+0x125/0x1d0 red/socket.c:2212 x64_sys_call+0x3799/0x3c10 arch/x86/include/generated/asm/syscalls_64.h:45 do_syscall_x64 arch/x86/entry/common.c:52 [en línea] do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f CPU: 0 UID: 0 PID: 7115 Comm: syz.1.515 No contaminado 6.11.0-rc1-syzkaller-00043-g94ede2a3e913 #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 27/06/2024

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: fs/netfs/fscache_cookie: agregar comprobación "n_accesses" faltante Esto corrige un error de desreferencia de puntero NULL debido a una ejecución de datos que se ve así: ERROR: desreferencia de puntero NULL del kernel, dirección: 0000000000000008 #PF: acceso de lectura de supervisor en modo kernel #PF: error_code(0x0000) - página no presente PGD 0 P4D 0 Oops: 0000 [#1] SMP PTI CPU: 33 PID: 16573 Comm: kworker/u97:799 No contaminado 6.8.7-cm4all1-hp+ #43 Nombre del hardware: HP ProLiant DL380 Gen9/ProLiant DL380 Gen9, BIOS P89 17/10/2018 Cola de trabajo: events_unbound netfs_rreq_write_to_cache_work RIP: 0010:cachefiles_prepare_write+0x30/0xa0 Código: 57 41 56 45 89 ce 41 55 49 89 cd 41 54 49 89 d4 55 53 48 89 fb 48 83 ec 08 48 8b 47 08 48 83 7f 10 00 48 89 34 24 48 8b 68 20 <48> 8b 45 08 4c 8b 38 74 45 49 8b 7f 50 e8 4e a9 b0 ff 48 8b 73 10 RSP: 0018:ffffb4e78113bde0 EFLAGS: 00010286 RAX: ffff976126be6d10 RBX: ffff97615cdb8438 RCX: 0000000000020000 RDX: ffff97605e6c4c68 RSI: ffff97605e6c4c60 RDI: ffff97615cdb8438 RBP: 000000000000000 R08: 0000000000278333 R09: 0000000000000001 R10: ffff97605e6c4600 R11: 0000000000000001 R12: ffff97605e6c4c68 R13: 0000000000020000 R14: 0000000000000001 R15: ffff976064fe2c00 FS: 000000000000000(0000) GS:ffff9776dfd40000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000000000008 CR3: 000000005942c002 CR4: 00000000001706f0 Seguimiento de llamadas: ? __die+0x1f/0x70 ? page_fault_oops+0x15d/0x440 ? search_module_extables+0xe/0x40 ? fixup_exception+0x22/0x2f0 ? exc_page_fault+0x5f/0x100 ? asm_exc_page_fault+0x22/0x30 ? cachefiles_prepare_write+0x30/0xa0 netfs_rreq_write_to_cache_work+0x135/0x2e0 process_one_work+0x137/0x2c0 subproceso_trabajador+0x2e9/0x400 ? __pfx_worker_thread+0x10/0x10 kthread+0xcc/0x100 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x30/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1b/0x30 Módulos vinculados en: CR2: 000000000000008 ---[ fin del seguimiento 000000000000000 ]--- Esto sucedió porque fscache_cookie_state_machine() era lento y todavía se estaba ejecutando mientras otro proceso invocaba fscache_unuse_cookie(); Esto llevó a una llamada a fscache_cookie_lru_do_one(), que estableció el indicador FSCACHE_COOKIE_DO_LRU_DISCARD, que fue detectado por fscache_cookie_state_machine(), retirando la cookie a través de cachefiles_withdraw_cookie(), borrando cookie->cache_priv. Al mismo tiempo, otro proceso invocó cachefiles_prepare_write(), que encontró un puntero NULL en esta línea de código: struct cachefiles_object *object = cachefiles_cres_object(cres); La siguiente línea falla, obviamente: struct cachefiles_cache *cache = object->volume->cache; Durante cachefiles_prepare_write(), el contador "n_accesses" no es cero (a través de fscache_begin_operation()). La cookie no debe retirarse hasta que baje a cero. El contador se comprueba mediante fscache_cookie_state_machine() antes de cambiar a FSCACHE_COOKIE_STATE_RELINQUISHING y FSCACHE_COOKIE_STATE_WITHDRAWING (en el "caso FSCACHE_COOKIE_STATE_FAILED"), pero no para FSCACHE_COOKIE_STATE_LRU_DISCARDING ("caso FSCACHE_COOKIE_STATE_ACTIVE"). Este parche agrega la comprobación faltante. Con un contador de acceso distinto de cero, la función retorna y la siguiente llamada fscache_end_cookie_access() pondrá en cola otra llamada fscache_cookie_state_machine() para manejar la FSCACHE_COOKIE_DO_LRU_DISCARD aún pendiente.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: rtla/osnoise: Evitar la desreferenciación NULL en el manejo de errores. Si la asignación "tool->data" falla, entonces no es necesario llamar a osnoise_free_top() y, de hecho, hacerlo provocará una desreferenciación NULL.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: vfs: No desalojar inodo bajo el contexto de recorrido lru de inodo El proceso de recuperación de inodo (ver función prune_icache_sb) recopila todos los inodos recuperables y los marca con el indicador I_FREEING al principio, en ese momento, otros procesos se atascarán si intentan obtener estos inodos (ver función find_inode_fast), luego el proceso de recuperación destruye los inodos mediante la función dispose_list(). Algunos sistemas de archivos (por ejemplo, ext4 con la función ea_inode, ubifs con xattr) pueden realizar una búsqueda de inodo en la función de devolución de llamada de expulsión de inodo, si la búsqueda de inodo se opera bajo el contexto de recorrido lru de inodo, pueden ocurrir problemas de interbloqueo. Caso 1: En la función ext4_evict_inode(), la búsqueda de inodo ea podría ocurrir si la característica ea_inode está habilitada, el proceso de búsqueda se quedará atascado bajo el contexto de desalojo de esta manera: 1. El archivo A tiene un inodo i_reg y un inodo ea i_ea 2. getfattr(A, xattr_buf) // i_ea se agrega a lru // lru->i_ea 3. Luego, los siguientes tres procesos se ejecutan de esta manera: PA PB echo 2 > /proc/sys/vm/drop_caches shrink_slab prune_dcache_sb // i_reg se agrega a lru, lru->i_ea->i_reg prune_icache_sb list_lru_walk_one inode_lru_isolate i_ea->i_state |= I_FREEING // establece el estado del inodo inode_lru_isolate __iget(i_reg) spin_unlock(&i_reg->i_lock) spin_unlock(lru_lock) rm archivo A i_reg->nlink = 0 iput(i_reg) // i_reg->nlink es 0, desalojar ext4_evict_inode ext4_xattr_delete_inode ext4_xattr_inode_dec_ref_all ext4_xattr_inode_iget ext4_iget(i_ea->i_ino) iget_locked find_inode_fast __wait_on_freeing_inode(i_ea) ----? Bloqueo AA dispose_list // no puede ser ejecutado por prune_icache_sb wake_up_bit(&i_ea->i_state) Caso 2: En la función de escritura de inodo eliminado ubifs_jnl_write_inode(), el proceso de eliminación de archivo retiene BASEHD wbuf->io_mutex mientras obtiene el inodo xattr, que podría competir con el proceso de recuperación de inodo (el proceso de recuperación podría intentar bloquear wbuf->io_mutex de BASEHD en la función de desalojo de inodo), entonces ocurriría un problema de bloqueo ABBA de la siguiente manera: 1. El archivo A tiene un inodo ia y un xattr (con un inodo ixa), el archivo B normal tiene un inodo ib y un xattr. 2. getfattr(A, xattr_buf) // ixa se agrega a lru // lru->ixa 3. Luego, los siguientes tres procesos se ejecutan de esta manera: PA PB PC echo 2 > /proc/sys/vm/drop_caches shrink_slab prune_dcache_sb // ib e ia se agregan a lru, lru->ixa->ib->ia prune_icache_sb list_lru_walk_one inode_lru_isolate ixa->i_state |= I_FREEING // establece el estado del inodo inode_lru_isolate __iget(ib) spin_unlock(&ib->i_lock) spin_unlock(lru_lock) rm archivo B ib->nlink = 0 rm archivo A iput(ia) ubifs_evict_inode(ia) ubifs_jnl_delete_inode(ia) ubifs_jnl_write_inode(ia) make_reservation(BASEHD) // Bloquear wbuf->io_mutex ubifs_iget(ixa->i_ino) iget_locked find_inode_fast __wait_on_freeing_inode(ixa) | iput(ib) // ib->nlink es 0, desalojar | ubifs_evict_inode | ubifs_jnl_delete_inode(ib) ? ubifs_jnl_write_inode Bloqueo ABBA ?-----make_reservation(BASEHD) dispose_list // no puede ser ejecutado por prune_icache_sb wake_up_bit(&ixa->i_state) Corrija el posible bloqueo utilizando el nuevo indicador de estado de inodo I_LRU_ISOLATING para fijar el inodo en la memoria mientras inode_lru_isolate( ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: xhci: Fix Panther point NULL point deref at full-speed re-enumeration reenumerar dispositivos de velocidad completa después de un comando de dispositivo de dirección fallido puede desencadenar una desreferencia de puntero NULL. Los dispositivos de velocidad completa pueden necesitar reconfigurar el valor 0 Max Packet Size del endpoint durante la enumeración. Usb core llama a usb_ep0_reinit() en este caso, que termina llamando a xhci_configure_endpoint(). En Panther point xHC, la función xhci_configure_endpoint() verificará y reservará adicionalmente el ancho de banda en el software. Otros hosts hacen esto en el hardware Si el comando de dispositivo de dirección xHC falla, se asigna una nueva estructura xhci_virt_device como parte de la rehabilitación de la ranura, pero los punteros de la tabla de ancho de banda no se configuran correctamente aquí. Esto activa la desreferencia del puntero NULL la próxima vez que se llama a usb_ep0_reinit() y xhci_configure_endpoint() intenta verificar y reservar el ancho de banda [46710.713538] usb 3-1: nuevo dispositivo USB de velocidad completa número 5 que usa xhci_hcd [46710.713699] usb 3-1: el dispositivo no responde a la dirección de configuración. [46710.917684] usb 3-1: el dispositivo no responde a la dirección de configuración. [46711.125536] usb 3-1: el dispositivo no acepta la dirección 5, error -71 [46711.125594] ERROR: desreferencia de puntero NULL del kernel, dirección: 0000000000000008 [46711.125600] #PF: acceso de lectura del supervisor en modo kernel [46711.125603] #PF: error_code(0x0000) - página no presente [46711.125606] PGD 0 P4D 0 [46711.125610] Oops: Oops: 0000 [#1] PREEMPT SMP PTI [46711.125615] CPU: 1 PID: 25760 Comm: kworker/1:2 No contaminado 6.10.3_2 #1 [46711.125620] Nombre del hardware: Gigabyte Technology Co., Ltd. [46711.125623] Cola de trabajo: usb_hub_wq hub_event [usbcore] [46711.125668] RIP: 0010:xhci_reserve_bandwidth (drivers/usb/host/xhci.c Solucione esto asegurándose de que los punteros de la tabla de ancho de banda estén configurados correctamente después de un comando de dispositivo de dirección fallido y, además, evitando verificar el ancho de banda en casos como este donde no se agregan ni eliminan endpoints reales, es decir, solo se evalúa el contexto para el endpoint de control predeterminado 0.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bonding: fix xfrm real_dev null pointer dereference No deberíamos establecer real_dev en NULL porque los paquetes pueden estar en tránsito y xfrm podría llamar a xdo_dev_offload_ok() en paralelo. Todas las devoluciones de llamadas suponen que real_dev está establecido. Ejemplo de seguimiento: kernel: BUG: no se puede manejar el error de página para la dirección: 0000000000001030 kernel: bond0: (esclavo eni0np1): haciendo que la interfaz sea la nueva activa kernel: #PF: acceso de escritura del supervisor en modo kernel kernel: #PF: error_code(0x0002) - página no presente kernel: PGD 0 P4D 0 kernel: Oops: 0002 [#1] PREEMPT SMP kernel: CPU: 4 PID: 2237 Comm: ping No contaminado 6.7.7+ #12 kernel: Nombre del hardware: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014 kernel: RIP: 0010:nsim_ipsec_offload_ok+0xc/0x20 [netdevsim] kernel: bond0: (esclavo eni0np1): bond_ipsec_add_sa_all: no se pudo agregar el kernel SA: Código: e0 0f 0b 48 83 7f 38 00 74 de 0f 0b 48 8b 47 08 48 8b 37 48 8b 78 40 e9 b2 e5 9a d7 66 90 0f 1f 44 00 00 48 8b 86 80 02 00 00 <83> 80 30 10 00 00 01 b8 01 00 00 00 c3 0f 1f 80 00 00 00 00 0f 1f kernel: bond0: (esclavo eni0np1): haciendo que la interfaz sea la nueva activa kernel: RSP: 0018:ffffabde81553b98 EFLAGS: 00010246 kernel: bond0: (esclavo eni0np1): bond_ipsec_add_sa_all: no se pudo agregar SA kernel: kernel: RAX: 0000000000000000 RBX: ffff9eb404e74900 RCX: ffff9eb403d97c60 kernel: RDX: ffffffffc090de10 RSI: ffff9eb404e74900 RDI: ffff9eb3c5de9e00 kernel: RBP: ffff9eb3c0a42000 R08: 000000000000010 R09: 0000000000000014 kernel: R10: 797420303030303030 R11: 3030303030303030 R12: 0000000000000000 núcleo: R13: ffff9eb3c5de9e00 R14: ffffabde81553cc8 R15: ffff9eb404c53000 núcleo: FS: 00007f2a77a3ad00(0000) GS:ffff9eb43bd00000(0000) knlGS:0000000000000000 núcleo: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 núcleo: CR2: 0000000000001030 CR3: 00000001122ab000 CR4: 0000000000350ef0 kernel: bond0: (esclavo eni0np1): haciendo que la interfaz sea la nueva activa kernel: Seguimiento de llamadas: kernel: kernel: ? __die+0x1f/0x60 kernel: bond0: (esclavo eni0np1): bond_ipsec_add_sa_all: error al agregar SA kernel: ? page_fault_oops+0x142/0x4c0 kernel: ? do_user_addr_fault+0x65/0x670 kernel: ? kvm_read_and_reset_apf_flags+0x3b/0x50 kernel: bond0: (esclavo eni0np1): haciendo que la interfaz sea la nueva activa kernel: ? exc_page_fault+0x7b/0x180 kernel: ? asm_exc_page_fault+0x22/0x30 kernel: ? nsim_bpf_uninit+0x50/0x50 [netdevsim] kernel: bond0: (esclavo eni0np1): bond_ipsec_add_sa_all: no se pudo agregar SA kernel: ? nsim_ipsec_offload_ok+0xc/0x20 [netdevsim] kernel: bond0: (esclavo eni0np1): haciendo que la interfaz sea la nueva activa kernel: bond_ipsec_offload_ok+0x7b/0x90 [vinculación] kernel: xfrm_output+0x61/0x3b0 kernel: bond0: (esclavo eni0np1): bond_ipsec_add_sa_all: no se pudo agregar SA kernel: ip_push_pending_frames+0x56/0x80

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bonding: corregir desreferenciación de puntero nulo en bond_ipsec_offload_ok Debemos comprobar si hay un esclavo activo antes de desreferenciar el puntero.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: cgroup/cpuset: arregla el pánico causado por partcmd_update Encontramos un error como el siguiente: ERROR: no se puede manejar el error de página para la dirección: 00000003 PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 3 PID: 358 Comm: bash Tainted: GWI 6.6.0-10893-g60d6 Nombre del hardware: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/4 RIP: 0010:partition_sched_domains_locked+0x483/0x600 Código: 01 48 85 d2 74 0d 48 83 05 29 3f f8 03 01 f3 48 0f bc c2 89 c0 48 9 RSP: 0018:ffffc90000fdbc58 EFLAGS: 00000202 RAX: 0000000100000003 RBX: ffff888100b3dfa0 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000002fe80 RBP: ffff888100b3dfb0 R08: 0000000000000001 R09: 0000000000000000 R10: ffffc90000fdbcb0 R11: 0000000000000004 R12: 0000000000000002 R13: ffff888100a92b48 R14: 0000000000000000 R15: 0000000000000000 FS: 00007f44a5425740(0000) GS:ffff888237d80000(0000) knlGS:0000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000100030973 CR3: 000000010722c000 CR4: 00000000000006e0 Seguimiento de llamadas: ? show_regs+0x8c/0xa0 ? __die_body+0x23/0xa0 ? __die+0x3a/0x50 ? page_fault_oops+0x1d2/0x5c0 ? particion_sched_domains_locked+0x483/0x600 ? search_module_extables+0x2a/0xb0 ? search_exception_tables+0x67/0x90 ? kernelmode_fixup_or_oops+0x144/0x1b0 ? __bad_area_nosemaphore+0x211/0x360 ? up_read+0x3b/0x50 ? semáforo de nariz de área defectuosa+0x1a/0x30 ? exc_page_fault+0x890/0xd90 ? __lock_acquire.constprop.0+0x24f/0x8d0 ? __lock_acquire.constprop.0+0x24f/0x8d0 ? asm_exc_page_fault+0x26/0x30 ? dominios programados de partición bloqueados+0x483/0x600 ? partición_sched_dominios_bloqueados+0xf0/0x600 reconstruir_sched_dominios_bloqueados+0x806/0xdc0 actualizar_partición_sd_lb+0x118/0x130 resmask_escritura_cpuset+0xffc/0x1420 escritura_archivo_cgroup+0xb2/0x290 iterador_escritura_fop_kernfs+0x194/0x290 nueva_escritura_sincronizada+0xeb/0x160 escritura_vfs+0x16f/0x1d0 escritura_ksys+0x81/0x180 escritura_sys___x64+0x21/0x30 llamada_sys_x64+0x2f25/0x4630 llamada_sys_64+0x44/0xb0 entry_SYSCALL_64_after_hwframe+0x78/0xe2 RIP: 0033:0x7f44a553c887 Se puede reproducir con los siguientes comandos: cd /sys/fs/cgroup/ mkdir test cd test/ echo +cpuset > ../cgroup.subtree_control echo root > cpuset.cpus.partition cat /sys/fs/cgroup/cpuset.cpus.effective 0-3 echo 0-3 > cpuset.cpus // quitar todas las CPU de la raíz Este problema se debe a la reconstrucción incorrecta de los dominios de programación. En este escenario, test/cpuset.cpus.partition debería ser una raíz no válida y no debería activar la reconstrucción de los dominios de programación. Al llamar a update_parent_effective_cpumask con partcmd_update, si newmask no es nulo, debe volver a verificar si newmask tiene CPU disponibles para parect/cs que tiene tareas.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ata: pata_macio: Fix DMA table overflow Kolbjørn y Jonáš informaron que sus PowerMacs de 32 bits fallaban en pata-macio desde el commit 09fe2bfa6b83 ("ata: pata_macio: Fix max_segment_size with PAGE_SIZE == 64K"). Por ejemplo: ¡ERROR del kernel en drivers/ata/pata_macio.c:544! Ups: Excepción en modo kernel, firma: 5 [#1] BE PAGE_SIZE=4K MMU=Hash SMP NR_CPUS=2 DEBUG_PAGEALLOC PowerMac ... NIP pata_macio_qc_prep+0xf4/0x190 LR pata_macio_qc_prep+0xfc/0x190 Rastreo de llamadas: 0xc1421660 (no confiable) ata_qc_issue+0x14c/0x2d4 __ata_scsi_queuecmd+0x200/0x53c ata_scsi_queuecmd+0x50/0xe0 scsi_queue_rq+0x788/0xb1c __blk_mq_issue_directly+0x58/0xf4 blk_mq_plug_issue_direct+0x8c/0x1b4 blk_mq_flush_plug_list.part.0+0x584/0x5e0 __blk_flush_plug+0xf8/0x194 __submit_bio+0x1b8/0x2e0 submission_bio_noacct_nocheck+0x230/0x304 btrfs_work_helper+0x200/0x338 process_one_work+0x1a8/0x338 worker_thread+0x364/0x4c0 kthread+0x100/0x104 start_kernel_thread+0x10/0x14 Esa confirmación aumentó max_segment_size a 64 KB, con la justificación de que el núcleo SCSI ya estaba usando ese tamaño cuando PAGE_SIZE == 64 KB, y que existía una lógica para dividir las solicitudes de gran tamaño. Sin embargo, con una solicitud lo suficientemente grande, la lógica de división hace que cada sg se divida en dos comandos en la tabla DMA, lo que provoca un desbordamiento de la tabla DMA y activa el BUG_ON(). Con la configuración predeterminada, el error no se activa, porque el tamaño de la solicitud está limitado por max_sectors_kb == 1280, sin embargo, max_sectors_kb se puede aumentar y, aparentemente, algunas distribuciones lo hacen de forma predeterminada utilizando reglas de udev. Corrija el error para los núcleos de 4 KB volviendo al antiguo max_segment_size. Para los núcleos de 64 KB, el sg_tablesize debe reducirse a la mitad, para permitir la posibilidad de que cada sg se divida en dos.