Vulnerabilities

IBM CICS TX Advanced 10.1 is vulnerable to cross-site scripting. This vulnerability allows users to embed arbitrary JavaScript code in the Web UI thus altering the intended functionality potentially leading to credentials disclosure within a trusted session. IBM X-Force ID: 260769.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tun: avoid double free in tun_free_netdev<br /> <br /> Avoid double free in tun_free_netdev() by moving the<br /> dev-&gt;tstats and tun-&gt;security allocs to a new ndo_init routine<br /> (tun_net_init()) that will be called by register_netdevice().<br /> ndo_init is paired with the desctructor (tun_free_netdev()),<br /> so if there&amp;#39;s an error in register_netdevice() the destructor<br /> will handle the frees.<br /> <br /> BUG: KASAN: double-free or invalid-free in selinux_tun_dev_free_security+0x1a/0x20 security/selinux/hooks.c:5605<br /> <br /> CPU: 0 PID: 25750 Comm: syz-executor416 Not tainted 5.16.0-rc2-syzk #1<br /> Hardware name: Red Hat KVM, BIOS<br /> Call Trace:<br /> <br /> __dump_stack lib/dump_stack.c:88 [inline]<br /> dump_stack_lvl+0x89/0xb5 lib/dump_stack.c:106<br /> print_address_description.constprop.9+0x28/0x160 mm/kasan/report.c:247<br /> kasan_report_invalid_free+0x55/0x80 mm/kasan/report.c:372<br /> ____kasan_slab_free mm/kasan/common.c:346 [inline]<br /> __kasan_slab_free+0x107/0x120 mm/kasan/common.c:374<br /> kasan_slab_free include/linux/kasan.h:235 [inline]<br /> slab_free_hook mm/slub.c:1723 [inline]<br /> slab_free_freelist_hook mm/slub.c:1749 [inline]<br /> slab_free mm/slub.c:3513 [inline]<br /> kfree+0xac/0x2d0 mm/slub.c:4561<br /> selinux_tun_dev_free_security+0x1a/0x20 security/selinux/hooks.c:5605<br /> security_tun_dev_free_security+0x4f/0x90 security/security.c:2342<br /> tun_free_netdev+0xe6/0x150 drivers/net/tun.c:2215<br /> netdev_run_todo+0x4df/0x840 net/core/dev.c:10627<br /> rtnl_unlock+0x13/0x20 net/core/rtnetlink.c:112<br /> __tun_chr_ioctl+0x80c/0x2870 drivers/net/tun.c:3302<br /> tun_chr_ioctl+0x2f/0x40 drivers/net/tun.c:3311<br /> vfs_ioctl fs/ioctl.c:51 [inline]<br /> __do_sys_ioctl fs/ioctl.c:874 [inline]<br /> __se_sys_ioctl fs/ioctl.c:860 [inline]<br /> __x64_sys_ioctl+0x19d/0x220 fs/ioctl.c:860<br /> do_syscall_x64 arch/x86/entry/common.c:50 [inline]<br /> do_syscall_64+0x3a/0x80 arch/x86/entry/common.c:80<br /> entry_SYSCALL_64_after_hwframe+0x44/0xae

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> pinctrl: mediatek: fix global-out-of-bounds issue<br /> <br /> When eint virtual eint number is greater than gpio number,<br /> it maybe produce &amp;#39;desc[eint_n]&amp;#39; size globle-out-of-bounds issue.

Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> phonet/pep: refuse to enable an unbound pipe<br /> <br /> This ioctl() implicitly assumed that the socket was already bound to<br /> a valid local socket name, i.e. Phonet object. If the socket was not<br /> bound, two separate problems would occur:<br /> <br /> 1) We&amp;#39;d send an pipe enablement request with an invalid source object.<br /> 2) Later socket calls could BUG on the socket unexpectedly being<br /> connected yet not bound to a valid object.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tee: optee: Fix incorrect page free bug<br /> <br /> Pointer to the allocated pages (struct page *page) has already<br /> progressed towards the end of allocation. It is incorrect to perform<br /> __free_pages(page, order) using this pointer as we would free any<br /> arbitrary pages. Fix this by stop modifying the page pointer.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/damon/dbgfs: protect targets destructions with kdamond_lock<br /> <br /> DAMON debugfs interface iterates current monitoring targets in<br /> &amp;#39;dbgfs_target_ids_read()&amp;#39; while holding the corresponding<br /> &amp;#39;kdamond_lock&amp;#39;. However, it also destructs the monitoring targets in<br /> &amp;#39;dbgfs_before_terminate()&amp;#39; without holding the lock. This can result in<br /> a use_after_free bug. This commit avoids the race by protecting the<br /> destruction with the corresponding &amp;#39;kdamond_lock&amp;#39;.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> kfence: fix memory leak when cat kfence objects<br /> <br /> Hulk robot reported a kmemleak problem:<br /> <br /> unreferenced object 0xffff93d1d8cc02e8 (size 248):<br /> comm "cat", pid 23327, jiffies 4624670141 (age 495992.217s)<br /> hex dump (first 32 bytes):<br /> 00 40 85 19 d4 93 ff ff 00 10 00 00 00 00 00 00 .@..............<br /> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br /> backtrace:<br /> seq_open+0x2a/0x80<br /> full_proxy_open+0x167/0x1e0<br /> do_dentry_open+0x1e1/0x3a0<br /> path_openat+0x961/0xa20<br /> do_filp_open+0xae/0x120<br /> do_sys_openat2+0x216/0x2f0<br /> do_sys_open+0x57/0x80<br /> do_syscall_64+0x33/0x40<br /> entry_SYSCALL_64_after_hwframe+0x44/0xa9<br /> unreferenced object 0xffff93d419854000 (size 4096):<br /> comm "cat", pid 23327, jiffies 4624670141 (age 495992.217s)<br /> hex dump (first 32 bytes):<br /> 6b 66 65 6e 63 65 2d 23 32 35 30 3a 20 30 78 30 kfence-#250: 0x0<br /> 30 30 30 30 30 30 30 37 35 34 62 64 61 31 32 2d 0000000754bda12-<br /> backtrace:<br /> seq_read_iter+0x313/0x440<br /> seq_read+0x14b/0x1a0<br /> full_proxy_read+0x56/0x80<br /> vfs_read+0xa5/0x1b0<br /> ksys_read+0xa0/0xf0<br /> do_syscall_64+0x33/0x40<br /> entry_SYSCALL_64_after_hwframe+0x44/0xa9<br /> <br /> I find that we can easily reproduce this problem with the following<br /> commands:<br /> <br /> cat /sys/kernel/debug/kfence/objects<br /> echo scan &gt; /sys/kernel/debug/kmemleak<br /> cat /sys/kernel/debug/kmemleak<br /> <br /> The leaked memory is allocated in the stack below:<br /> <br /> do_syscall_64<br /> do_sys_open<br /> do_dentry_open<br /> full_proxy_open<br /> seq_open ---&gt; alloc seq_file<br /> vfs_read<br /> full_proxy_read<br /> seq_read<br /> seq_read_iter<br /> traverse ---&gt; alloc seq_buf<br /> <br /> And it should have been released in the following process:<br /> <br /> do_syscall_64<br /> syscall_exit_to_user_mode<br /> exit_to_user_mode_prepare<br /> task_work_run<br /> ____fput<br /> __fput<br /> full_proxy_release ---&gt; free here<br /> <br /> However, the release function corresponding to file_operations is not<br /> implemented in kfence. As a result, a memory leak occurs. Therefore,<br /> the solution to this problem is to implement the corresponding release<br /> function.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/hwpoison: clear MF_COUNT_INCREASED before retrying get_any_page()<br /> <br /> Hulk Robot reported a panic in put_page_testzero() when testing<br /> madvise() with MADV_SOFT_OFFLINE. The BUG() is triggered when retrying<br /> get_any_page(). This is because we keep MF_COUNT_INCREASED flag in<br /> second try but the refcnt is not increased.<br /> <br /> page dumped because: VM_BUG_ON_PAGE(page_ref_count(page) == 0)<br /> ------------[ cut here ]------------<br /> kernel BUG at include/linux/mm.h:737!<br /> invalid opcode: 0000 [#1] PREEMPT SMP<br /> CPU: 5 PID: 2135 Comm: sshd Tainted: G B 5.16.0-rc6-dirty #373<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014<br /> RIP: release_pages+0x53f/0x840<br /> Call Trace:<br /> free_pages_and_swap_cache+0x64/0x80<br /> tlb_flush_mmu+0x6f/0x220<br /> unmap_page_range+0xe6c/0x12c0<br /> unmap_single_vma+0x90/0x170<br /> unmap_vmas+0xc4/0x180<br /> exit_mmap+0xde/0x3a0<br /> mmput+0xa3/0x250<br /> do_exit+0x564/0x1470<br /> do_group_exit+0x3b/0x100<br /> __do_sys_exit_group+0x13/0x20<br /> __x64_sys_exit_group+0x16/0x20<br /> do_syscall_64+0x34/0x80<br /> entry_SYSCALL_64_after_hwframe+0x44/0xae<br /> Modules linked in:<br /> ---[ end trace e99579b570fe0649 ]---<br /> RIP: 0010:release_pages+0x53f/0x840

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mac80211: fix locking in ieee80211_start_ap error path<br /> <br /> We need to hold the local-&gt;mtx to release the channel context,<br /> as even encoded by the lockdep_assert_held() there. Fix it.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: VMX: Always clear vmx-&gt;fail on emulation_required<br /> <br /> Revert a relatively recent change that set vmx-&gt;fail if the vCPU is in L2<br /> and emulation_required is true, as that behavior is completely bogus.<br /> Setting vmx-&gt;fail and synthesizing a VM-Exit is contradictory and wrong:<br /> <br /> (a) it&amp;#39;s impossible to have both a VM-Fail and VM-Exit<br /> (b) vmcs.EXIT_REASON is not modified on VM-Fail<br /> (c) emulation_required refers to guest state and guest state checks are<br /> always VM-Exits, not VM-Fails.<br /> <br /> For KVM specifically, emulation_required is handled before nested exits<br /> in __vmx_handle_exit(), thus setting vmx-&gt;fail has no immediate effect,<br /> i.e. KVM calls into handle_invalid_guest_state() and vmx-&gt;fail is ignored.<br /> Setting vmx-&gt;fail can ultimately result in a WARN in nested_vmx_vmexit()<br /> firing when tearing down the VM as KVM never expects vmx-&gt;fail to be set<br /> when L2 is active, KVM always reflects those errors into L1.<br /> <br /> ------------[ cut here ]------------<br /> WARNING: CPU: 0 PID: 21158 at arch/x86/kvm/vmx/nested.c:4548<br /> nested_vmx_vmexit+0x16bd/0x17e0<br /> arch/x86/kvm/vmx/nested.c:4547<br /> Modules linked in:<br /> CPU: 0 PID: 21158 Comm: syz-executor.1 Not tainted 5.16.0-rc3-syzkaller #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011<br /> RIP: 0010:nested_vmx_vmexit+0x16bd/0x17e0 arch/x86/kvm/vmx/nested.c:4547<br /> Code: 0b e9 2e f8 ff ff e8 57 b3 5d 00 0f 0b e9 00 f1 ff ff 89 e9 80<br /> Call Trace:<br /> vmx_leave_nested arch/x86/kvm/vmx/nested.c:6220 [inline]<br /> nested_vmx_free_vcpu+0x83/0xc0 arch/x86/kvm/vmx/nested.c:330<br /> vmx_free_vcpu+0x11f/0x2a0 arch/x86/kvm/vmx/vmx.c:6799<br /> kvm_arch_vcpu_destroy+0x6b/0x240 arch/x86/kvm/x86.c:10989<br /> kvm_vcpu_destroy+0x29/0x90 arch/x86/kvm/../../../virt/kvm/kvm_main.c:441<br /> kvm_free_vcpus arch/x86/kvm/x86.c:11426 [inline]<br /> kvm_arch_destroy_vm+0x3ef/0x6b0 arch/x86/kvm/x86.c:11545<br /> kvm_destroy_vm arch/x86/kvm/../../../virt/kvm/kvm_main.c:1189 [inline]<br /> kvm_put_kvm+0x751/0xe40 arch/x86/kvm/../../../virt/kvm/kvm_main.c:1220<br /> kvm_vcpu_release+0x53/0x60 arch/x86/kvm/../../../virt/kvm/kvm_main.c:3489<br /> __fput+0x3fc/0x870 fs/file_table.c:280<br /> task_work_run+0x146/0x1c0 kernel/task_work.c:164<br /> exit_task_work include/linux/task_work.h:32 [inline]<br /> do_exit+0x705/0x24f0 kernel/exit.c:832<br /> do_group_exit+0x168/0x2d0 kernel/exit.c:929<br /> get_signal+0x1740/0x2120 kernel/signal.c:2852<br /> arch_do_signal_or_restart+0x9c/0x730 arch/x86/kernel/signal.c:868<br /> handle_signal_work kernel/entry/common.c:148 [inline]<br /> exit_to_user_mode_loop kernel/entry/common.c:172 [inline]<br /> exit_to_user_mode_prepare+0x191/0x220 kernel/entry/common.c:207<br /> __syscall_exit_to_user_mode_work kernel/entry/common.c:289 [inline]<br /> syscall_exit_to_user_mode+0x2e/0x70 kernel/entry/common.c:300<br /> do_syscall_64+0x53/0xd0 arch/x86/entry/common.c:86<br /> entry_SYSCALL_64_after_hwframe+0x44/0xae