Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/display: Evite la división por cero inicializando el paso ficticio en 1 [Por qué] Si los valores ficticios en `populate_dummy_dml_surface_cfg()` no se actualizan, pueden provocar una división por cero en los llamadores posteriores como CalculateVMAndRowBytes() [Cómo] Inicialice el valor ficticio en un valor para evitar la división por cero.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: exfat: corrige la doble liberación en delayed_free La doble liberación podría ocurrir en la siguiente ruta. exfat_create_upcase_table() exfat_create_upcase_table() : devolver error exfat_free_upcase_table() : liberar ->vol_utbl exfat_load_default_upcase_table : devolver error exfat_kill_sb() delayed_free() exfat_free_upcase_table() <--------- doble liberación Este parche establece ->vol_util como NULL después de liberarlo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: jfs: se corrige la lectura de array-index-out-of-bounds en add_missing_indices. El stbl es s8, pero debe contener desplazamientos en la ranura, que pueden ir de 0 a 127. Se añadió una comprobación de límite para ese error y se devuelve -EIO si la comprobación falla. También se hace que jfs_readdir devuelva un error si add_missing_indices devuelve un error.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: jfs: Fix null-ptr-deref in jfs_ioc_trim [Informe de Syzkaller] Oops: fallo de protección general, probablemente para la dirección no canónica 0xdffffc0000000087: 0000 [#1 KASAN: null-ptr-deref in range [0x0000000000000438-0x000000000000043f] CPU: 2 UID: 0 PID: 10614 Comm: syz-executor.0 Not tainted 6.13.0-rc6-gfbfd64d25c7a-dirty #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Sched_ext: serialise (enabled+all), task: runnable_at=-30ms RIP: 0010:jfs_ioc_trim+0x34b/0x8f0 Code: e7 e8 59 a4 87 fe 4d 8b 24 24 4d 8d bc 24 38 04 00 00 48 8d 93 90 82 fe ff 4c 89 ff 31 f6 RSP: 0018:ffffc900055f7cd0 EFLAGS: 00010206 RAX: 0000000000000087 RBX: 00005866a9e67ff8 RCX: 000000000000000a RDX: 0000000000000001 RSI: 0000000000000004 RDI: 0000000000000001 RBP: dffffc0000000000 R08: ffff88807c180003 R09: 1ffff1100f830000 R10: dffffc0000000000 R11: ffffed100f830001 R12: 0000000000000000 R13: 0000000000000000 R14: 0000000000000001 R15: 0000000000000438 FS: 00007fe520225640(0000) GS:ffff8880b7e80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00005593c91b2c88 CR3: 000000014927c000 CR4: 00000000000006f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? __die_body+0x61/0xb0 ? die_addr+0xb1/0xe0 ? exc_general_protection+0x333/0x510 ? asm_exc_general_protection+0x26/0x30 ? jfs_ioc_trim+0x34b/0x8f0 jfs_ioctl+0x3c8/0x4f0 ? __pfx_jfs_ioctl+0x10/0x10 ? __pfx_jfs_ioctl+0x10/0x10 __se_sys_ioctl+0x269/0x350 ? __pfx___se_sys_ioctl+0x10/0x10 ? do_syscall_64+0xfb/0x210 do_syscall_64+0xee/0x210 ? syscall_exit_to_user_mode+0x1e0/0x330 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fe51f4903ad Code: c3 e8 a7 2b 00 00 0f 1f 80 00 00 00 00 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d RSP: 002b:00007fe5202250c8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 00007fe51f5cbf80 RCX: 00007fe51f4903ad RDX: 0000000020000680 RSI: 00000000c0185879 RDI: 0000000000000005 RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 00007fe520225640 R13: 000000000000000e R14: 00007fe51f44fca0 R15: 00007fe52021d000 Modules linked in: ---[ end trace 0000000000000000 ]--- RIP: 0010:jfs_ioc_trim+0x34b/0x8f0 Code: e7 e8 59 a4 87 fe 4d 8b 24 24 4d 8d bc 24 38 04 00 00 48 8d 93 90 82 fe ff 4c 89 ff 31 f6 RSP: 0018:ffffc900055f7cd0 EFLAGS: 00010206 RAX: 0000000000000087 RBX: 00005866a9e67ff8 RCX: 000000000000000a RDX: 0000000000000001 RSI: 0000000000000004 RDI: 0000000000000001 RBP: dffffc0000000000 R08: ffff88807c180003 R09: 1ffff1100f830000 R10: dffffc0000000000 R11: ffffed100f830001 R12: 0000000000000000 R13: 0000000000000000 R14: 0000000000000001 R15: 0000000000000438 FS: 00007fe520225640(0000) GS:ffff8880b7e80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00005593c91b2c88 CR3: 000000014927c000 CR4: 00000000000006f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Kernel panic - not syncing: Fatal exception [ Analysis ] Creemos que hemos encontrado un error de concurrencia en el módulo `fs/jfs` que da como resultado una desreferencia de puntero nulo. Existe un problema estrechamente relacionado que ya se ha corregido: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d6c1b3599b2feb5c7291f5ac3a36e5fa7cedb234... pero, lamentablemente, el parche aceptado parece seguir siendo susceptible a una desreferencia de puntero nulo en algunas intercalaciones. Creemos que para desencadenar el error, `JFS_SBI(ipbmap->i_sb)->bmap` se establece en NULL en `dbFreeBits` y luego se desreferencia en `jfs_ioc_trim`. Este error es poco frecuente en circunstancias normales, pero se puede desencadenar desde un programa syz.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf: La comprobación de rcu_read_lock_trace_held() en bpf_map_lookup_percpu_elem() también está disponible para programas bpf en suspensión. Cuando BPF JIT está deshabilitado o en un host de 32 bits, bpf_map_lookup_percpu_elem() no se incluirá en línea. Su uso en un programa bpf en suspensión activará la advertencia en bpf_map_lookup_percpu_elem(), ya que el programa bpf solo mantiene el bloqueo rcu_read_lock_trace. Por lo tanto, se debe agregar la comprobación omitida.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: netfilter: nft_set_pipapo: fijar el tamaño máximo del contenedor de mapas a INT_MAX. De lo contrario, es posible que se active WARN_ON_ONCE en __kvmalloc_node_noprof() al redimensionar la tabla hash porque __GFP_NOWARN no está configurado. Similar a: b541ba7d1f5a ("netfilter: conntrack: fijar el tamaño máximo de la tabla hash a INT_MAX")

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: ath12k: Se solucionó una fuga de memoria debido a la asignación múltiple de rx_stats. rx_stats para cada arsta se asigna al añadir una estación. arsta->rx_stats se liberará al eliminar una estación. Se producen asignaciones redundantes cuando se añade la misma estación varias veces. Esto provoca que ath12k_mac_station_add() se invoque varias veces y que rx_stats se asigne cada vez. Como resultado, se producen fugas de memoria. Evite las asignaciones múltiples de rx_stats cuando ath12k_mac_station_add() se invoque repetidamente comprobando si rx_stats ya está asignado antes de volver a asignarlo. Asigne arsta->rx_stats si arsta->rx_stats es NULL, respectivamente. Probado en: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00173-QCAHKSWPL_SILICONZ-1 Probado en: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: i40e: se corrige el acceso de escritura MMIO a una página no válida en i40e_clear_hw. Cuando el dispositivo envía una entrada específica, puede producirse un desbordamiento de enteros, lo que provoca el acceso de escritura MMIO a una página no válida. Para evitar este desbordamiento, cambie el tipo de las variables relacionadas.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: fbcon: Asegúrese de que modelist no esté configurado en una consola no registrada Parece que intentar escribir en el nodo sysfs "store_modes" entrará en conflicto con las consolas no registradas: UBSAN: array-index-out-of-bounds in drivers/video/fbdev/core/fbcon.c:122:28 index -1 is out of range for type 'fb_info *[32]' ... fbcon_info_from_console+0x192/0x1a0 drivers/video/fbdev/core/fbcon.c:122 fbcon_new_modelist+0xbf/0x2d0 drivers/video/fbdev/core/fbcon.c:3048 fb_new_modelist+0x328/0x440 drivers/video/fbdev/core/fbmem.c:673 store_modes+0x1c9/0x3e0 drivers/video/fbdev/core/fbsysfs.c:113 dev_attr_store+0x55/0x80 drivers/base/core.c:2439 static struct fb_info *fbcon_registered_fb[FB_MAX]; ... static signed char con2fb_map[MAX_NR_CONSOLES]; ... static struct fb_info *fbcon_info_from_console(int console) ... return fbcon_registered_fb[con2fb_map[console]]; Si con2fb_map contiene un valor de -1, la situación podría fallar. En su lugar, se devuelve NULL, ya que quienes llaman a fbcon_info_from_console() intentan comparar con punteros "info" existentes, por lo que la gestión de errores debería funcionar correctamente.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: LoongArch: Se corrige el pánico causado por NULL-PMD en huge_pte_offset() INFORMACIÓN DE ERROR: CPU 25 No se puede manejar la solicitud de paginación del kernel en la dirección virtual 0x0 ... Seguimiento de llamadas: [<900000000023c30c>] huge_pte_offset+0x3c/0x58 [<900000000057fd4c>] hugetlb_follow_page_mask+0x74/0x438 [<900000000051fee8>] __get_user_pages+0xe0/0x4c8 [<9000000000522414>] faultin_page_range+0x84/0x380 [<9000000000564e8c>] madvise_vma_behavior+0x534/0xa48 [<900000000056689c>] do_madvise+0x1bc/0x3e8 [<9000000000566df4>] sys_madvise+0x24/0x38 [<90000000015b9e88>] do_syscall+0x78/0x98 [<9000000000221f18>] handle_syscall+0xb8/0x158 En algunos casos, pmd puede ser NULL y depender de NULL como valor de retorno para el procesamiento, por lo que es necesario determinar esta situación aquí.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: io_uring/rsrc: validar el recuento de búfer con desplazamiento para la clonación syzbot informa que puede activar un WARN_ON() para un intento de kmalloc() que es demasiado grande: CPU: 0 PID: 6488 at mm/slub.c:5024 __kvmalloc_node_noprof+0x520/0x640 mm/slub.c:5024 Modules linked in: CPU: 0 UID: 0 PID: 6488 Comm: syz-executor312 Not tainted 6.15.0-rc7-syzkaller-gd7fa1af5b33e #0 PREEMPT Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025 pstate: 20400005 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : __kvmalloc_node_noprof+0x520/0x640 mm/slub.c:5024 lr : __do_kmalloc_node mm/slub.c:-1 [inline] lr : __kvmalloc_node_noprof+0x3b4/0x640 mm/slub.c:5012 sp : ffff80009cfd7a90 x29: ffff80009cfd7ac0 x28: ffff0000dd52a120 x27: 0000000000412dc0 x26: 0000000000000178 x25: ffff7000139faf70 x24: 0000000000000000 x23: ffff800082f4cea8 x22: 00000000ffffffff x21: 000000010cd004a8 x20: ffff0000d75816c0 x19: ffff0000dd52a000 x18: 00000000ffffffff x17: ffff800092f39000 x16: ffff80008adbe9e4 x15: 0000000000000005 x14: 1ffff000139faf1c x13: 0000000000000000 x12: 0000000000000000 x11: ffff7000139faf21 x10: 0000000000000003 x9 : ffff80008f27b938 x8 : 0000000000000002 x7 : 0000000000000000 x6 : 0000000000000000 x5 : 00000000ffffffff x4 : 0000000000400dc0 x3 : 0000000200000000 x2 : 000000010cd004a8 x1 : ffff80008b3ebc40 x0 : 0000000000000001 Call trace: __kvmalloc_node_noprof+0x520/0x640 mm/slub.c:5024 (P) kvmalloc_array_node_noprof include/linux/slab.h:1065 [inline] io_rsrc_data_alloc io_uring/rsrc.c:206 [inline] io_clone_buffers io_uring/rsrc.c:1178 [inline] io_register_clone_buffers+0x484/0xa14 io_uring/rsrc.c:1287 __io_uring_register io_uring/register.c:815 [inline] __do_sys_io_uring_register io_uring/register.c:926 [inline] __se_sys_io_uring_register io_uring/register.c:903 [inline] __arm64_sys_io_uring_register+0x42c/0xea8 io_uring/register.c:903 __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline] 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+0x58/0x17c arch/arm64/kernel/entry-common.c:767 el0t_64_sync_handler+0x78/0x108 arch/arm64/kernel/entry-common.c:786 el0t_64_sync+0x198/0x19c arch/arm64/kernel/entry.S:600 Esto se debe a que offset + buffer_count es demasiado grande. El código de registro solo verifica el recuento total de búferes, pero dado que la indexación es una matriz, también debería verificar offset + count. Esto tampoco puede superar IORING_MAX_REG_BUFFERS, ya que no es posible acceder a búferes más allá de ese límite. Registrar una tabla tan grande no presenta ningún problema, salvo que no tiene sentido registrar búferes inaccesibles y que puede activar la advertencia de kmalloc() por intentar una asignación demasiado grande.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: atm: Revertir atm_account_tx() si copy_from_iter_full() falla. En vcc_sendmsg(), contabilizamos skb->truesize como sk->sk_wmem_alloc mediante atm_account_tx(). Se espera que sea revertido por atm_pop_raw(), posteriormente llamado por vcc->dev->ops->send(vcc, skb). Sin embargo, vcc_sendmsg() no realiza la misma reversión cuando copy_from_iter_full() falla, y entonces se filtrará un socket. Factoricemos la parte de la reversión como atm_return_tx() y la llamemos en la ruta de error. Tenga en cuenta que la operación sk_wmem_alloc correspondiente se puede encontrar en alloc_tx() a partir de la confirmación culpable. $ git culpa -L:alloc_tx net/atm/common.c c55fa3ccccc2c~