Vulnerabilidades

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

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/xe: Liberar trabajo antes de xe_exec_queue_put La liberación de trabajo depende de que job->vm sea válido, el último xe_exec_queue_put puede destruir la máquina virtual. Evite UAF liberando trabajo antes de xe_exec_queue_put. (seleccionado de el commit 32a42c93b74c8ca6d0915ea3eba21bceff53042f)

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/xe: Se corrige la falta de destrucción de la cola de trabajo en xe_gt_pagefault. Al recargar el controlador, nunca liberamos la memoria para las colas de trabajo del contador de acceso y de Pagefault. Agregue esas llamadas de destrucción aquí. (seleccionadas de el commit 7586fc52b14e0b8edd0d1f8a434e0de2078b7b2b)

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/xe: Fix opregion leak Como parte de la pantalla, lo ideal sería que la configuración y la limpieza las hiciera la propia pantalla. Sin embargo, se trata de una refactorización más grande que debe realizarse tanto en i915 como en xe. Por ahora, solo arregle la fuga: objeto sin referencia 0xffff8881a0300008 (tamaño 192): comm "modprobe", pid 4354, jiffies 4295647021 volcado hexadecimal (primeros 32 bytes): 00 00 87 27 81 88 ff ff 18 80 9b 00 00 c9 ff ff ...'............ 18 81 9b 00 00 c9 ff ff 00 00 00 00 00 00 00 00 ................ backtrace (crc 99260e31): [] kmemleak_alloc+0x4b/0x80 [] kmalloc_trace_noprof+0x312/0x3d0 [] intel_opregion_setup+0x89/0x700 [xe] [] xe_display_init_noirq+0x2f/0x90 [xe] [] xe_device_probe+0x7a3/0xbf0 [xe] [] xe_pci_probe+0x333/0x5b0 [xe] [] local_pci_probe+0x48/0xb0 [] pci_device_probe+0xc8/0x280 [] really_probe+0xf8/0x390 [] __driver_probe_device+0x8a/0x170 [] driver_probe_device+0x23/0xb0 [] __driver_attach+0xc7/0x190 [] bus_for_each_dev+0x7d/0xd0 [] driver_attach+0x1e/0x30 [] bus_add_driver+0x117/0x250 (seleccionado de el commit) 6f4e43a2f771b737d991142ec4f6d4b7ff31fbb4)

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: workqueue: Se corrige el error de 'desbordamiento de sustracción' de UBSAN en shift_and_mask() UBSAN informa el siguiente error de 'desbordamiento de sustracción' al arrancar en una máquina virtual en Android: | Error interno: UBSAN: desbordamiento de sustracción de enteros: 00000000f2005515 [#1] PREEMPT SMP | Módulos vinculados en: | CPU: 0 PID: 1 Comm: swapper/0 No contaminado 6.10.0-00006-g3cbe9e5abd46-dirty #4 | Nombre del hardware: linux,dummy-virt (DT) | pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--) | pc : cancel_delayed_work+0x34/0x44 | lr : cancelar_trabajo_retrasado+0x2c/0x44 | sp : ffff80008002ba60 | x29: ffff80008002ba60 x28: 0000000000000000 x27: 0000000000000000 | x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000000 | x23: 0000000000000000 x22: 0000000000000000 x21: ffff1f65014cd3c0 | x20: ffffc0e84c9d0da0 x19: ffffc0e84cab3558 x18: ffff800080009058 | x17: 00000000247ee1f8 x16: 00000000247ee1f8 x15: 00000000bdcb279d | x14: 0000000000000001 x13: 0000000000000075 x12: 00000a0000000000 | x11: ffff1f6501499018 x10: 00984901651fffff x9 : ffff5e7cc35af000 | x8 : 0000000000000001 x7 : 3d4d455453595342 x6 : 000000004e514553 | x5 : ffff1f6501499265 x4 : ffff1f650ff60b10 x3 : 0000000000000620 | x2 : ffff80008002ba78 x1 : 0000000000000000 x0 : 0000000000000000 | Rastreo de llamadas: | cancel_delayed_work+0x34/0x44 | deferred_probe_extend_timeout+0x20/0x70 | driver_register+0xa8/0x110 | __platform_driver_register+0x28/0x3c | syscon_init+0x24/0x38 | hacer_una_initcall+0xe4/0x338 | hacer_initcall_level+0xac/0x178 | hacer_initcalls+0x5c/0xa0 | hacer_configuración_básica+0x20/0x30 | kernel_init_freeable+0x8c/0xf8 | kernel_init+0x28/0x1b4 | ret_from_fork+0x10/0x20 | Código: f9000fbf 97fffa2f 39400268 37100048 (d42aa2a0) | ---[ fin de seguimiento 000000000000000 ]--- | Pánico del núcleo: no se sincroniza: UBSAN: desbordamiento de sustracción de enteros: excepción fatal Esto se debe a que shift_and_mask() usa una función inmediata con signo para construir la máscara y se la llama con un desplazamiento de 31 (WORK_OFFQ_POOL_SHIFT), por lo que termina disminuyendo desde INT_MIN. Use una constante sin signo '1U' para generar la máscara en shift_and_mask().