Vulnerabilidades

Se ha encontrado una vulnerabilidad en ChaiScript hasta la versión 6.1.0. Esto afecta a la función chaiscript::Type_Info::bare_equal del archivo include/chaiscript/dispatchkit/type_info.hpp. Esta manipulación causa uso después de liberar. El ataque requiere acceso local. La complejidad del ataque se califica como alta. La explotabilidad se informa como difícil. El exploit ha sido publicado y puede ser utilizado. El proyecto fue informado del problema tempranamente a través de un informe de incidencia, pero aún no ha respondido.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> riscv: trace: fix snapshot deadlock with sbi ecall<br /> <br /> If sbi_ecall.c&amp;#39;s functions are traceable,<br /> <br /> echo "__sbi_ecall:snapshot" &gt; /sys/kernel/tracing/set_ftrace_filter<br /> <br /> may get the kernel into a deadlock.<br /> <br /> (Functions in sbi_ecall.c are excluded from tracing if<br /> CONFIG_RISCV_ALTERNATIVE_EARLY is set.)<br /> <br /> __sbi_ecall triggers a snapshot of the ringbuffer. The snapshot code<br /> raises an IPI interrupt, which results in another call to __sbi_ecall<br /> and another snapshot...<br /> <br /> All it takes to get into this endless loop is one initial __sbi_ecall.<br /> On RISC-V systems without SSTC extension, the clock events in<br /> timer-riscv.c issue periodic sbi ecalls, making the problem easy to<br /> trigger.<br /> <br /> Always exclude the sbi_ecall.c functions from tracing to fix the<br /> potential deadlock.<br /> <br /> sbi ecalls can easiliy be logged via trace events, excluding ecall<br /> functions from function tracing is not a big limitation.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> gpio: loongson-64bit: Fix incorrect NULL check after devm_kcalloc()<br /> <br /> Fix incorrect NULL check in loongson_gpio_init_irqchip().<br /> The function checks chip-&gt;parent instead of chip-&gt;irq.parents.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> mm/slab: Añadir alloc_tagging_slab_free_hook para memcg_alloc_abort_single<br /> <br /> Cuando CONFIG_MEM_ALLOC_PROFILING_DEBUG está habilitado, la siguiente advertencia puede ser notada:<br /> <br /> [ 3959.023862] ------------[ cut here ]------------<br /> [ 3959.023891] alloc_tag no fue limpiado (obtuvo etiqueta para lib/xarray.c:378)<br /> [ 3959.023947] ADVERTENCIA: ./include/linux/alloc_tag.h:155 en alloc_tag_add+0x128/0x178, CPU#6: mkfs.ntfs/113998<br /> [ 3959.023978] Módulos enlazados: dns_resolver tun brd overlay exfat btrfs blake2b libblake2b xor xor_neon raid6_pq loop sctp ip6_udp_tunnel udp_tunnel ext4 crc16 mbcache jbd2 rfkill sunrpc vfat fat sg fuse nfnetlink sr_mod virtio_gpu cdrom drm_client_lib virtio_dma_buf drm_shmem_helper drm_kms_helper ghash_ce drm sm4 backlight virtio_net net_failover virtio_scsi failover virtio_console virtio_blk virtio_mmio dm_mirror dm_region_hash dm_log dm_multipath dm_mod i2c_dev aes_neon_bs aes_ce_blk [último descargado: hwpoison_inject]<br /> [ 3959.024170] CPU: 6 UID: 0 PID: 113998 Comm: mkfs.ntfs Kdump: cargado Tainted: G W 6.19.0-rc7+ #7 PREEMPT(voluntary)<br /> [ 3959.024182] Tainted: [W]=WARN<br /> [ 3959.024186] Nombre del hardware: Máquina virtual QEMU KVM, BIOS desconocido 2/2/2022<br /> [ 3959.024192] pstate: 604000c5 (nZCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> [ 3959.024199] pc : alloc_tag_add+0x128/0x178<br /> [ 3959.024207] lr : alloc_tag_add+0x128/0x178<br /> [ 3959.024214] sp : ffff80008b696d60<br /> [ 3959.024219] x29: ffff80008b696d60 x28: 0000000000000000 x27: 0000000000000240<br /> [ 3959.024232] x26: 0000000000000000 x25: 0000000000000240 x24: ffff800085d17860<br /> [ 3959.024245] x23: 0000000000402800 x22: ffff0000c0012dc0 x21: 00000000000002d0<br /> [ 3959.024257] x20: ffff0000e6ef3318 x19: ffff800085ae0410 x18: 0000000000000000<br /> [ 3959.024269] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000<br /> [ 3959.024281] x14: 0000000000000000 x13: 0000000000000001 x12: ffff600064101293<br /> [ 3959.024292] x11: 1fffe00064101292 x10: ffff600064101292 x9 : dfff800000000000<br /> [ 3959.024305] x8 : 00009fff9befed6e x7 : ffff000320809493 x6 : 0000000000000001<br /> [ 3959.024316] x5 : ffff000320809490 x4 : ffff600064101293 x3 : ffff800080691838<br /> [ 3959.024328] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0000d5bcd640<br /> [ 3959.024340] Traza de llamada:<br /> [ 3959.024346] alloc_tag_add+0x128/0x178 (P)<br /> [ 3959.024355] __alloc_tagging_slab_alloc_hook+0x11c/0x1a8<br /> [ 3959.024362] kmem_cache_alloc_lru_noprof+0x1b8/0x5e8<br /> [ 3959.024369] xas_alloc+0x304/0x4f0<br /> [ 3959.024381] xas_create+0x1e0/0x4a0<br /> [ 3959.024388] xas_store+0x68/0xda8<br /> [ 3959.024395] __filemap_add_folio+0x5b0/0xbd8<br /> [ 3959.024409] filemap_add_folio+0x16c/0x7e0<br /> [ 3959.024416] __filemap_get_folio_mpol+0x2dc/0x9e8<br /> [ 3959.024424] iomap_get_folio+0xfc/0x180<br /> [ 3959.024435] __iomap_get_folio+0x2f8/0x4b8<br /> [ 3959.024441] iomap_write_begin+0x198/0xc18<br /> [ 3959.024448] iomap_write_iter+0x2ec/0x8f8<br /> [ 3959.024454] iomap_file_buffered_write+0x19c/0x290<br /> [ 3959.024461] blkdev_write_iter+0x38c/0x978<br /> [ 3959.024470] vfs_write+0x4d4/0x928<br /> [ 3959.024482] ksys_write+0xfc/0x1f8<br /> [ 3959.024489] __arm64_sys_write+0x74/0xb0<br /> [ 3959.024496] invoke_syscall+0xd4/0x258<br /> [ 3959.024507] el0_svc_common.constprop.0+0xb4/0x240<br /> [ 3959.024514] do_el0_svc+0x48/0x68<br /> [ 3959.024520] el0_svc+0x40/0xf8<br /> [ 3959.024526] el0t_64_sync_handler+0xa0/0xe8<br /> [ 3959.024533] el0t_64_sync+0x1ac/0x1b0<br /> [ 3959.024540] ---[ fin de traza 0000000000000000 ]---<br /> <br /> Cuando __memcg_slab_post_alloc_hook() falla, hay dos rutas de liberación diferentes dependiendo de si size == 1 o size != 1. En la ruta de kmem_cache_free_bulk(), sí llamamos a alloc_tagging_slab_free_hook(). Sin embargo, en memcg_alloc_abort_single() no lo hacemos, la advertencia anterior se activará en la siguiente asignación.<br /> <br /> Por lo tanto, añadir alloc_tagging_slab_free_hook() a la ruta de memcg_alloc_abort_single().

Jenkins 2.483 a 2.550 (ambos inclusive), LTS 2.492.1 a 2.541.1 (ambos inclusive) no escapa la descripción proporcionada por el usuario de la causa de desconexión &amp;#39;Marcar temporalmente sin conexión&amp;#39;, lo que resulta en una vulnerabilidad de cross-site scripting (XSS) almacenado explotable por atacantes con permiso de Agente/Configurar o Agente/Desconectar.

Jenkins 2.550 y anteriores, LTS 2.541.1 y anteriores acepta valores de parámetros de ejecución que hacen referencia a compilaciones a las que el usuario que envía la compilación no tiene acceso, permitiendo a atacantes con permiso de Elemento/Compilación y Elemento/Configurar obtener información sobre la existencia de trabajos, la existencia de compilaciones, y si una compilación especificada existe, su nombre de visualización.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm, swap: restore swap_space attr aviod kernel panic<br /> <br /> commit 8b47299a411a ("mm, swap: mark swap address space ro and add context<br /> debug check") made the swap address space read-only. It may lead to<br /> kernel panic if arch_prepare_to_swap returns a failure under heavy memory<br /> pressure as follows,<br /> <br /> el1_abort+0x40/0x64<br /> el1h_64_sync_handler+0x48/0xcc<br /> el1h_64_sync+0x84/0x88<br /> errseq_set+0x4c/0xb8 (P)<br /> __filemap_set_wb_err+0x20/0xd0<br /> shrink_folio_list+0xc20/0x11cc<br /> evict_folios+0x1520/0x1be4<br /> try_to_shrink_lruvec+0x27c/0x3dc<br /> shrink_one+0x9c/0x228<br /> shrink_node+0xb3c/0xeac<br /> do_try_to_free_pages+0x170/0x4f0<br /> try_to_free_pages+0x334/0x534<br /> __alloc_pages_direct_reclaim+0x90/0x158<br /> __alloc_pages_slowpath+0x334/0x588<br /> __alloc_frozen_pages_noprof+0x224/0x2fc<br /> __folio_alloc_noprof+0x14/0x64<br /> vma_alloc_zeroed_movable_folio+0x34/0x44<br /> do_pte_missing+0xad4/0x1040<br /> handle_mm_fault+0x4a4/0x790<br /> do_page_fault+0x288/0x5f8<br /> do_translation_fault+0x38/0x54<br /> do_mem_abort+0x54/0xa8<br /> <br /> Restore swap address space as not ro to avoid the panic.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bonding: annotate data-races around slave-&gt;last_rx<br /> <br /> slave-&gt;last_rx and slave-&gt;target_last_arp_rx[...] can be read and written<br /> locklessly. Add READ_ONCE() and WRITE_ONCE() annotations.<br /> <br /> syzbot reported:<br /> <br /> BUG: KCSAN: data-race in bond_rcv_validate / bond_rcv_validate<br /> <br /> write to 0xffff888149f0d428 of 8 bytes by interrupt on cpu 1:<br /> bond_rcv_validate+0x202/0x7a0 drivers/net/bonding/bond_main.c:3335<br /> bond_handle_frame+0xde/0x5e0 drivers/net/bonding/bond_main.c:1533<br /> __netif_receive_skb_core+0x5b1/0x1950 net/core/dev.c:6039<br /> __netif_receive_skb_one_core net/core/dev.c:6150 [inline]<br /> __netif_receive_skb+0x59/0x270 net/core/dev.c:6265<br /> netif_receive_skb_internal net/core/dev.c:6351 [inline]<br /> netif_receive_skb+0x4b/0x2d0 net/core/dev.c:6410<br /> ...<br /> <br /> write to 0xffff888149f0d428 of 8 bytes by interrupt on cpu 0:<br /> bond_rcv_validate+0x202/0x7a0 drivers/net/bonding/bond_main.c:3335<br /> bond_handle_frame+0xde/0x5e0 drivers/net/bonding/bond_main.c:1533<br /> __netif_receive_skb_core+0x5b1/0x1950 net/core/dev.c:6039<br /> __netif_receive_skb_one_core net/core/dev.c:6150 [inline]<br /> __netif_receive_skb+0x59/0x270 net/core/dev.c:6265<br /> netif_receive_skb_internal net/core/dev.c:6351 [inline]<br /> netif_receive_skb+0x4b/0x2d0 net/core/dev.c:6410<br /> br_netif_receive_skb net/bridge/br_input.c:30 [inline]<br /> NF_HOOK include/linux/netfilter.h:318 [inline]<br /> ...<br /> <br /> value changed: 0x0000000100005365 -&gt; 0x0000000100005366

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/pm: Disable MMIO access during SMU Mode 1 reset<br /> <br /> During Mode 1 reset, the ASIC undergoes a reset cycle and becomes<br /> temporarily inaccessible via PCIe. Any attempt to access MMIO registers<br /> during this window (e.g., from interrupt handlers or other driver threads)<br /> can result in uncompleted PCIe transactions, leading to NMI panics or<br /> system hangs.<br /> <br /> To prevent this, set the `no_hw_access` flag to true immediately after<br /> triggering the reset. This signals other driver components to skip<br /> register accesses while the device is offline.<br /> <br /> A memory barrier `smp_mb()` is added to ensure the flag update is<br /> globally visible to all cores before the driver enters the sleep/wait<br /> state.<br /> <br /> (cherry picked from commit 7edb503fe4b6d67f47d8bb0dfafb8e699bb0f8a4)

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: reject new transactions if the fs is fully read-only<br /> <br /> [BUG]<br /> There is a bug report where a heavily fuzzed fs is mounted with all<br /> rescue mount options, which leads to the following warnings during<br /> unmount:<br /> <br /> BTRFS: Transaction aborted (error -22)<br /> Modules linked in:<br /> CPU: 0 UID: 0 PID: 9758 Comm: repro.out Not tainted<br /> 6.19.0-rc5-00002-gb71e635feefc #7 PREEMPT(full)<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014<br /> RIP: 0010:find_free_extent_update_loop fs/btrfs/extent-tree.c:4208 [inline]<br /> RIP: 0010:find_free_extent+0x52f0/0x5d20 fs/btrfs/extent-tree.c:4611<br /> Call Trace:<br /> <br /> btrfs_reserve_extent+0x2cd/0x790 fs/btrfs/extent-tree.c:4705<br /> btrfs_alloc_tree_block+0x1e1/0x10e0 fs/btrfs/extent-tree.c:5157<br /> btrfs_force_cow_block+0x578/0x2410 fs/btrfs/ctree.c:517<br /> btrfs_cow_block+0x3c4/0xa80 fs/btrfs/ctree.c:708<br /> btrfs_search_slot+0xcad/0x2b50 fs/btrfs/ctree.c:2130<br /> btrfs_truncate_inode_items+0x45d/0x2350 fs/btrfs/inode-item.c:499<br /> btrfs_evict_inode+0x923/0xe70 fs/btrfs/inode.c:5628<br /> evict+0x5f4/0xae0 fs/inode.c:837<br /> __dentry_kill+0x209/0x660 fs/dcache.c:670<br /> finish_dput+0xc9/0x480 fs/dcache.c:879<br /> shrink_dcache_for_umount+0xa0/0x170 fs/dcache.c:1661<br /> generic_shutdown_super+0x67/0x2c0 fs/super.c:621<br /> kill_anon_super+0x3b/0x70 fs/super.c:1289<br /> btrfs_kill_super+0x41/0x50 fs/btrfs/super.c:2127<br /> deactivate_locked_super+0xbc/0x130 fs/super.c:474<br /> cleanup_mnt+0x425/0x4c0 fs/namespace.c:1318<br /> task_work_run+0x1d4/0x260 kernel/task_work.c:233<br /> exit_task_work include/linux/task_work.h:40 [inline]<br /> do_exit+0x694/0x22f0 kernel/exit.c:971<br /> do_group_exit+0x21c/0x2d0 kernel/exit.c:1112<br /> __do_sys_exit_group kernel/exit.c:1123 [inline]<br /> __se_sys_exit_group kernel/exit.c:1121 [inline]<br /> __x64_sys_exit_group+0x3f/0x40 kernel/exit.c:1121<br /> x64_sys_call+0x2210/0x2210 arch/x86/include/generated/asm/syscalls_64.h:232<br /> do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]<br /> do_syscall_64+0xe8/0xf80 arch/x86/entry/syscall_64.c:94<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> RIP: 0033:0x44f639<br /> Code: Unable to access opcode bytes at 0x44f60f.<br /> RSP: 002b:00007ffc15c4e088 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7<br /> RAX: ffffffffffffffda RBX: 00000000004c32f0 RCX: 000000000044f639<br /> RDX: 000000000000003c RSI: 00000000000000e7 RDI: 0000000000000001<br /> RBP: 0000000000000001 R08: ffffffffffffffc0 R09: 0000000000000000<br /> R10: 0000000000000000 R11: 0000000000000246 R12: 00000000004c32f0<br /> R13: 0000000000000001 R14: 0000000000000000 R15: 0000000000000001<br /> <br /> <br /> Since rescue mount options will mark the full fs read-only, there should<br /> be no new transaction triggered.<br /> <br /> But during unmount we will evict all inodes, which can trigger a new<br /> transaction, and triggers warnings on a heavily corrupted fs.<br /> <br /> [CAUSE]<br /> Btrfs allows new transaction even on a read-only fs, this is to allow<br /> log replay happen even on read-only mounts, just like what ext4/xfs do.<br /> <br /> However with rescue mount options, the fs is fully read-only and cannot<br /> be remounted read-write, thus in that case we should also reject any new<br /> transactions.<br /> <br /> [FIX]<br /> If we find the fs has rescue mount options, we should treat the fs as<br /> error, so that no new transaction can be started.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> x86/vmware: Fix hypercall clobbers<br /> <br /> Fedora QA reported the following panic:<br /> <br /> BUG: unable to handle page fault for address: 0000000040003e54<br /> #PF: supervisor write access in kernel mode<br /> #PF: error_code(0x0002) - not-present page<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS edk2-20251119-3.fc43 11/19/2025<br /> RIP: 0010:vmware_hypercall4.constprop.0+0x52/0x90<br /> ..<br /> Call Trace:<br /> vmmouse_report_events+0x13e/0x1b0<br /> psmouse_handle_byte+0x15/0x60<br /> ps2_interrupt+0x8a/0xd0<br /> ...<br /> <br /> because the QEMU VMware mouse emulation is buggy, and clears the top 32<br /> bits of %rdi that the kernel kept a pointer in.<br /> <br /> The QEMU vmmouse driver saves and restores the register state in a<br /> "uint32_t data[6];" and as a result restores the state with the high<br /> bits all cleared.<br /> <br /> RDI originally contained the value of a valid kernel stack address<br /> (0xff5eeb3240003e54). After the vmware hypercall it now contains<br /> 0x40003e54, and we get a page fault as a result when it is dereferenced.<br /> <br /> The proper fix would be in QEMU, but this works around the issue in the<br /> kernel to keep old setups working, when old kernels had not happened to<br /> keep any state in %rdi over the hypercall.<br /> <br /> In theory this same issue exists for all the hypercalls in the vmmouse<br /> driver; in practice it has only been seen with vmware_hypercall3() and<br /> vmware_hypercall4(). For now, just mark RDI/RSI as clobbered for those<br /> two calls. This should have a minimal effect on code generation overall<br /> as it should be rare for the compiler to want to make RDI/RSI live<br /> across hypercalls.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: target: iscsi: Fix use-after-free in iscsit_dec_conn_usage_count()<br /> <br /> In iscsit_dec_conn_usage_count(), the function calls complete() while<br /> holding the conn-&gt;conn_usage_lock. As soon as complete() is invoked, the<br /> waiter (such as iscsit_close_connection()) may wake up and proceed to free<br /> the iscsit_conn structure.<br /> <br /> If the waiter frees the memory before the current thread reaches<br /> spin_unlock_bh(), it results in a KASAN slab-use-after-free as the function<br /> attempts to release a lock within the already-freed connection structure.<br /> <br /> Fix this by releasing the spinlock before calling complete().