Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> virtio/vsock: Fix accept_queue memory leak<br /> <br /> As the final stages of socket destruction may be delayed, it is possible<br /> that virtio_transport_recv_listen() will be called after the accept_queue<br /> has been flushed, but before the SOCK_DONE flag has been set. As a result,<br /> sockets enqueued after the flush would remain unremoved, leading to a<br /> memory leak.<br /> <br /> vsock_release<br /> __vsock_release<br /> lock<br /> virtio_transport_release<br /> virtio_transport_close<br /> schedule_delayed_work(close_work)<br /> sk_shutdown = SHUTDOWN_MASK<br /> (!) flush accept_queue<br /> release<br /> virtio_transport_recv_pkt<br /> vsock_find_bound_socket<br /> lock<br /> if flag(SOCK_DONE) return<br /> virtio_transport_recv_listen<br /> child = vsock_create_connected<br /> (!) vsock_enqueue_accept(child)<br /> release<br /> close_work<br /> lock<br /> virtio_transport_do_close<br /> set_flag(SOCK_DONE)<br /> virtio_transport_remove_sock<br /> vsock_remove_sock<br /> vsock_remove_bound<br /> release<br /> <br /> Introduce a sk_shutdown check to disallow vsock_enqueue_accept() during<br /> socket destruction.<br /> <br /> unreferenced object 0xffff888109e3f800 (size 2040):<br /> comm "kworker/5:2", pid 371, jiffies 4294940105<br /> hex dump (first 32 bytes):<br /> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br /> 28 00 0b 40 00 00 00 00 00 00 00 00 00 00 00 00 (..@............<br /> backtrace (crc 9e5f4e84):<br /> [] kmem_cache_alloc_noprof+0x2c1/0x360<br /> [] sk_prot_alloc+0x30/0x120<br /> [] sk_alloc+0x2c/0x4b0<br /> [] __vsock_create.constprop.0+0x2a/0x310<br /> [] virtio_transport_recv_pkt+0x4dc/0x9a0<br /> [] vsock_loopback_work+0xfd/0x140<br /> [] process_one_work+0x20c/0x570<br /> [] worker_thread+0x1bf/0x3a0<br /> [] kthread+0xdd/0x110<br /> [] ret_from_fork+0x2d/0x50<br /> [] ret_from_fork_asm+0x1a/0x30

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/mlx5e: CT: Fix null-ptr-deref in add rule err flow<br /> <br /> In error flow of mlx5_tc_ct_entry_add_rule(), in case ct_rule_add()<br /> callback returns error, zone_rule-&gt;attr is used uninitiated. Fix it to<br /> use attr which has the needed pointer value.<br /> <br /> Kernel log:<br /> BUG: kernel NULL pointer dereference, address: 0000000000000110<br /> RIP: 0010:mlx5_tc_ct_entry_add_rule+0x2b1/0x2f0 [mlx5_core]<br /> …<br /> Call Trace:<br /> <br /> ? __die+0x20/0x70<br /> ? page_fault_oops+0x150/0x3e0<br /> ? exc_page_fault+0x74/0x140<br /> ? asm_exc_page_fault+0x22/0x30<br /> ? mlx5_tc_ct_entry_add_rule+0x2b1/0x2f0 [mlx5_core]<br /> ? mlx5_tc_ct_entry_add_rule+0x1d5/0x2f0 [mlx5_core]<br /> mlx5_tc_ct_block_flow_offload+0xc6a/0xf90 [mlx5_core]<br /> ? nf_flow_offload_tuple+0xd8/0x190 [nf_flow_table]<br /> nf_flow_offload_tuple+0xd8/0x190 [nf_flow_table]<br /> flow_offload_work_handler+0x142/0x320 [nf_flow_table]<br /> ? finish_task_switch.isra.0+0x15b/0x2b0<br /> process_one_work+0x16c/0x320<br /> worker_thread+0x28c/0x3a0<br /> ? __pfx_worker_thread+0x10/0x10<br /> kthread+0xb8/0xf0<br /> ? __pfx_kthread+0x10/0x10<br /> ret_from_fork+0x2d/0x50<br /> ? __pfx_kthread+0x10/0x10<br /> ret_from_fork_asm+0x1a/0x30<br />

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/mlx5: fs, lock FTE when checking if active<br /> <br /> The referenced commits introduced a two-step process for deleting FTEs:<br /> <br /> - Lock the FTE, delete it from hardware, set the hardware deletion function<br /> to NULL and unlock the FTE.<br /> - Lock the parent flow group, delete the software copy of the FTE, and<br /> remove it from the xarray.<br /> <br /> However, this approach encounters a race condition if a rule with the same<br /> match value is added simultaneously. In this scenario, fs_core may set the<br /> hardware deletion function to NULL prematurely, causing a panic during<br /> subsequent rule deletions.<br /> <br /> To prevent this, ensure the active flag of the FTE is checked under a lock,<br /> which will prevent the fs_core layer from attaching a new steering rule to<br /> an FTE that is in the process of deletion.<br /> <br /> [ 438.967589] MOSHE: 2496 mlx5_del_flow_rules del_hw_func<br /> [ 438.968205] ------------[ cut here ]------------<br /> [ 438.968654] refcount_t: decrement hit 0; leaking memory.<br /> [ 438.969249] WARNING: CPU: 0 PID: 8957 at lib/refcount.c:31 refcount_warn_saturate+0xfb/0x110<br /> [ 438.970054] Modules linked in: act_mirred cls_flower act_gact sch_ingress openvswitch nsh mlx5_vdpa vringh vhost_iotlb vdpa mlx5_ib mlx5_core xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink xt_addrtype iptable_nat nf_nat br_netfilter rpcsec_gss_krb5 auth_rpcgss oid_registry overlay rpcrdma rdma_ucm ib_iser libiscsi scsi_transport_iscsi ib_umad rdma_cm ib_ipoib iw_cm ib_cm ib_uverbs ib_core zram zsmalloc fuse [last unloaded: cls_flower]<br /> [ 438.973288] CPU: 0 UID: 0 PID: 8957 Comm: tc Not tainted 6.12.0-rc1+ #8<br /> [ 438.973888] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014<br /> [ 438.974874] RIP: 0010:refcount_warn_saturate+0xfb/0x110<br /> [ 438.975363] Code: 40 66 3b 82 c6 05 16 e9 4d 01 01 e8 1f 7c a0 ff 0f 0b c3 cc cc cc cc 48 c7 c7 10 66 3b 82 c6 05 fd e8 4d 01 01 e8 05 7c a0 ff 0b c3 cc cc cc cc 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 90<br /> [ 438.976947] RSP: 0018:ffff888124a53610 EFLAGS: 00010286<br /> [ 438.977446] RAX: 0000000000000000 RBX: ffff888119d56de0 RCX: 0000000000000000<br /> [ 438.978090] RDX: ffff88852c828700 RSI: ffff88852c81b3c0 RDI: ffff88852c81b3c0<br /> [ 438.978721] RBP: ffff888120fa0e88 R08: 0000000000000000 R09: ffff888124a534b0<br /> [ 438.979353] R10: 0000000000000001 R11: 0000000000000001 R12: ffff888119d56de0<br /> [ 438.979979] R13: ffff888120fa0ec0 R14: ffff888120fa0ee8 R15: ffff888119d56de0<br /> [ 438.980607] FS: 00007fe6dcc0f800(0000) GS:ffff88852c800000(0000) knlGS:0000000000000000<br /> [ 438.983984] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 438.984544] CR2: 00000000004275e0 CR3: 0000000186982001 CR4: 0000000000372eb0<br /> [ 438.985205] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> [ 438.985842] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> [ 438.986507] Call Trace:<br /> [ 438.986799] <br /> [ 438.987070] ? __warn+0x7d/0x110<br /> [ 438.987426] ? refcount_warn_saturate+0xfb/0x110<br /> [ 438.987877] ? report_bug+0x17d/0x190<br /> [ 438.988261] ? prb_read_valid+0x17/0x20<br /> [ 438.988659] ? handle_bug+0x53/0x90<br /> [ 438.989054] ? exc_invalid_op+0x14/0x70<br /> [ 438.989458] ? asm_exc_invalid_op+0x16/0x20<br /> [ 438.989883] ? refcount_warn_saturate+0xfb/0x110<br /> [ 438.990348] mlx5_del_flow_rules+0x2f7/0x340 [mlx5_core]<br /> [ 438.990932] __mlx5_eswitch_del_rule+0x49/0x170 [mlx5_core]<br /> [ 438.991519] ? mlx5_lag_is_sriov+0x3c/0x50 [mlx5_core]<br /> [ 438.992054] ? xas_load+0x9/0xb0<br /> [ 438.992407] mlx5e_tc_rule_unoffload+0x45/0xe0 [mlx5_core]<br /> [ 438.993037] mlx5e_tc_del_fdb_flow+0x2a6/0x2e0 [mlx5_core]<br /> [ 438.993623] mlx5e_flow_put+0x29/0x60 [mlx5_core]<br /> [ 438.994161] mlx5e_delete_flower+0x261/0x390 [mlx5_core]<br /> [ 438.994728] tc_setup_cb_destroy+0xb9/0x190<br /> [ 438.995150] fl_hw_destroy_filter+0x94/0xc0 [cls_flower]<br /> [ 438.995650] fl_change+0x11a4/0x13c0 [cls_flower]<br /> [ 438.996105] tc_new_tfilter+0x347/0xbc0<br /> [ 438.996503] ? __<br /> ---truncated---

Improper Neutralization of Input During Web Page Generation (&amp;#39;Cross-site Scripting&amp;#39;) vulnerability in Imbasynergy ImbaChat allows DOM-Based XSS.This issue affects ImbaChat: from n/a through 3.1.4.

Improper Neutralization of Input During Web Page Generation (&amp;#39;Cross-site Scripting&amp;#39;) vulnerability in Tailored Web Services Tailored Tools allows Stored XSS.This issue affects Tailored Tools: from n/a through 1.8.4.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fs/proc/task_mmu: prevent integer overflow in pagemap_scan_get_args()<br /> <br /> The "arg-&gt;vec_len" variable is a u64 that comes from the user at the start<br /> of the function. The "arg-&gt;vec_len * sizeof(struct page_region))"<br /> multiplication can lead to integer wrapping. Use size_mul() to avoid<br /> that.<br /> <br /> Also the size_add/mul() functions work on unsigned long so for 32bit<br /> systems we need to ensure that "arg-&gt;vec_len" fits in an unsigned long.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: Adjust VSDB parser for replay feature<br /> <br /> At some point, the IEEE ID identification for the replay check in the<br /> AMD EDID was added. However, this check causes the following<br /> out-of-bounds issues when using KASAN:<br /> <br /> [ 27.804016] BUG: KASAN: slab-out-of-bounds in amdgpu_dm_update_freesync_caps+0xefa/0x17a0 [amdgpu]<br /> [ 27.804788] Read of size 1 at addr ffff8881647fdb00 by task systemd-udevd/383<br /> <br /> ...<br /> <br /> [ 27.821207] Memory state around the buggy address:<br /> [ 27.821215] ffff8881647fda00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00<br /> [ 27.821224] ffff8881647fda80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00<br /> [ 27.821234] &gt;ffff8881647fdb00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc<br /> [ 27.821243] ^<br /> [ 27.821250] ffff8881647fdb80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc<br /> [ 27.821259] ffff8881647fdc00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00<br /> [ 27.821268] ==================================================================<br /> <br /> This is caused because the ID extraction happens outside of the range of<br /> the edid lenght. This commit addresses this issue by considering the<br /> amd_vsdb_block size.<br /> <br /> (cherry picked from commit b7e381b1ccd5e778e3d9c44c669ad38439a861d8)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nommu: pass NULL argument to vma_iter_prealloc()<br /> <br /> When deleting a vma entry from a maple tree, it has to pass NULL to<br /> vma_iter_prealloc() in order to calculate internal state of the tree, but<br /> it passed a wrong argument. As a result, nommu kernels crashed upon<br /> accessing a vma iterator, such as acct_collect() reading the size of vma<br /> entries after do_munmap().<br /> <br /> This commit fixes this issue by passing a right argument to the<br /> preallocation call.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/mremap: fix address wraparound in move_page_tables()<br /> <br /> On 32-bit platforms, it is possible for the expression `len + old_addr

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm: page_alloc: move mlocked flag clearance into free_pages_prepare()<br /> <br /> Syzbot reported a bad page state problem caused by a page being freed<br /> using free_page() still having a mlocked flag at free_pages_prepare()<br /> stage:<br /> <br /> BUG: Bad page state in process syz.5.504 pfn:61f45<br /> page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x61f45<br /> flags: 0xfff00000080204(referenced|workingset|mlocked|node=0|zone=1|lastcpupid=0x7ff)<br /> raw: 00fff00000080204 0000000000000000 dead000000000122 0000000000000000<br /> raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000<br /> page dumped because: PAGE_FLAGS_CHECK_AT_FREE flag(s) set<br /> page_owner tracks the page as allocated<br /> page last allocated via order 0, migratetype Unmovable, gfp_mask 0x400dc0(GFP_KERNEL_ACCOUNT|__GFP_ZERO), pid 8443, tgid 8442 (syz.5.504), ts 201884660643, free_ts 201499827394<br /> set_page_owner include/linux/page_owner.h:32 [inline]<br /> post_alloc_hook+0x1f3/0x230 mm/page_alloc.c:1537<br /> prep_new_page mm/page_alloc.c:1545 [inline]<br /> get_page_from_freelist+0x303f/0x3190 mm/page_alloc.c:3457<br /> __alloc_pages_noprof+0x292/0x710 mm/page_alloc.c:4733<br /> alloc_pages_mpol_noprof+0x3e8/0x680 mm/mempolicy.c:2265<br /> kvm_coalesced_mmio_init+0x1f/0xf0 virt/kvm/coalesced_mmio.c:99<br /> kvm_create_vm virt/kvm/kvm_main.c:1235 [inline]<br /> kvm_dev_ioctl_create_vm virt/kvm/kvm_main.c:5488 [inline]<br /> kvm_dev_ioctl+0x12dc/0x2240 virt/kvm/kvm_main.c:5530<br /> __do_compat_sys_ioctl fs/ioctl.c:1007 [inline]<br /> __se_compat_sys_ioctl+0x510/0xc90 fs/ioctl.c:950<br /> do_syscall_32_irqs_on arch/x86/entry/common.c:165 [inline]<br /> __do_fast_syscall_32+0xb4/0x110 arch/x86/entry/common.c:386<br /> do_fast_syscall_32+0x34/0x80 arch/x86/entry/common.c:411<br /> entry_SYSENTER_compat_after_hwframe+0x84/0x8e<br /> page last free pid 8399 tgid 8399 stack trace:<br /> reset_page_owner include/linux/page_owner.h:25 [inline]<br /> free_pages_prepare mm/page_alloc.c:1108 [inline]<br /> free_unref_folios+0xf12/0x18d0 mm/page_alloc.c:2686<br /> folios_put_refs+0x76c/0x860 mm/swap.c:1007<br /> free_pages_and_swap_cache+0x5c8/0x690 mm/swap_state.c:335<br /> __tlb_batch_free_encoded_pages mm/mmu_gather.c:136 [inline]<br /> tlb_batch_pages_flush mm/mmu_gather.c:149 [inline]<br /> tlb_flush_mmu_free mm/mmu_gather.c:366 [inline]<br /> tlb_flush_mmu+0x3a3/0x680 mm/mmu_gather.c:373<br /> tlb_finish_mmu+0xd4/0x200 mm/mmu_gather.c:465<br /> exit_mmap+0x496/0xc40 mm/mmap.c:1926<br /> __mmput+0x115/0x390 kernel/fork.c:1348<br /> exit_mm+0x220/0x310 kernel/exit.c:571<br /> do_exit+0x9b2/0x28e0 kernel/exit.c:926<br /> do_group_exit+0x207/0x2c0 kernel/exit.c:1088<br /> __do_sys_exit_group kernel/exit.c:1099 [inline]<br /> __se_sys_exit_group kernel/exit.c:1097 [inline]<br /> __x64_sys_exit_group+0x3f/0x40 kernel/exit.c:1097<br /> x64_sys_call+0x2634/0x2640 arch/x86/include/generated/asm/syscalls_64.h:232<br /> do_syscall_x64 arch/x86/entry/common.c:52 [inline]<br /> do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> Modules linked in:<br /> CPU: 0 UID: 0 PID: 8442 Comm: syz.5.504 Not tainted 6.12.0-rc6-syzkaller #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024<br /> Call Trace:<br /> <br /> __dump_stack lib/dump_stack.c:94 [inline]<br /> dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120<br /> bad_page+0x176/0x1d0 mm/page_alloc.c:501<br /> free_page_is_bad mm/page_alloc.c:918 [inline]<br /> free_pages_prepare mm/page_alloc.c:1100 [inline]<br /> free_unref_page+0xed0/0xf20 mm/page_alloc.c:2638<br /> kvm_destroy_vm virt/kvm/kvm_main.c:1327 [inline]<br /> kvm_put_kvm+0xc75/0x1350 virt/kvm/kvm_main.c:1386<br /> kvm_vcpu_release+0x54/0x60 virt/kvm/kvm_main.c:4143<br /> __fput+0x23f/0x880 fs/file_table.c:431<br /> task_work_run+0x24f/0x310 kernel/task_work.c:239<br /> exit_task_work include/linux/task_work.h:43 [inline]<br /> do_exit+0xa2f/0x28e0 kernel/exit.c:939<br /> do_group_exit+0x207/0x2c0 kernel/exit.c:1088<br /> __do_sys_exit_group kernel/exit.c:1099 [in<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ima: fix buffer overrun in ima_eventdigest_init_common<br /> <br /> Function ima_eventdigest_init() calls ima_eventdigest_init_common()<br /> with HASH_ALGO__LAST which is then used to access the array<br /> hash_digest_size[] leading to buffer overrun. Have a conditional<br /> statement to handle this.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> vp_vdpa: fix id_table array not null terminated error<br /> <br /> Allocate one extra virtio_device_id as null terminator, otherwise<br /> vdpa_mgmtdev_get_classes() may iterate multiple times and visit<br /> undefined memory.