Vulnerabilities

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

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> platform/x86: intel_pmc_core: fix memleak on registration failure<br /> <br /> In case device registration fails during module initialisation, the<br /> platform device structure needs to be freed using platform_device_put()<br /> to properly free all resources (e.g. the device name).

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: x86/mmu: Don&amp;#39;t advance iterator after restart due to yielding<br /> <br /> After dropping mmu_lock in the TDP MMU, restart the iterator during<br /> tdp_iter_next() and do not advance the iterator. Advancing the iterator<br /> results in skipping the top-level SPTE and all its children, which is<br /> fatal if any of the skipped SPTEs were not visited before yielding.<br /> <br /> When zapping all SPTEs, i.e. when min_level == root_level, restarting the<br /> iter and then invoking tdp_iter_next() is always fatal if the current gfn<br /> has as a valid SPTE, as advancing the iterator results in try_step_side()<br /> skipping the current gfn, which wasn&amp;#39;t visited before yielding.<br /> <br /> Sprinkle WARNs on iter-&gt;yielded being true in various helpers that are<br /> often used in conjunction with yielding, and tag the helper with<br /> __must_check to reduce the probabily of improper usage.<br /> <br /> Failing to zap a top-level SPTE manifests in one of two ways. If a valid<br /> SPTE is skipped by both kvm_tdp_mmu_zap_all() and kvm_tdp_mmu_put_root(),<br /> the shadow page will be leaked and KVM will WARN accordingly.<br /> <br /> WARNING: CPU: 1 PID: 3509 at arch/x86/kvm/mmu/tdp_mmu.c:46 [kvm]<br /> RIP: 0010:kvm_mmu_uninit_tdp_mmu+0x3e/0x50 [kvm]<br /> Call Trace:<br /> <br /> kvm_arch_destroy_vm+0x130/0x1b0 [kvm]<br /> kvm_destroy_vm+0x162/0x2a0 [kvm]<br /> kvm_vcpu_release+0x34/0x60 [kvm]<br /> __fput+0x82/0x240<br /> task_work_run+0x5c/0x90<br /> do_exit+0x364/0xa10<br /> ? futex_unqueue+0x38/0x60<br /> do_group_exit+0x33/0xa0<br /> get_signal+0x155/0x850<br /> arch_do_signal_or_restart+0xed/0x750<br /> exit_to_user_mode_prepare+0xc5/0x120<br /> syscall_exit_to_user_mode+0x1d/0x40<br /> do_syscall_64+0x48/0xc0<br /> entry_SYSCALL_64_after_hwframe+0x44/0xae<br /> <br /> If kvm_tdp_mmu_zap_all() skips a gfn/SPTE but that SPTE is then zapped by<br /> kvm_tdp_mmu_put_root(), KVM triggers a use-after-free in the form of<br /> marking a struct page as dirty/accessed after it has been put back on the<br /> free list. This directly triggers a WARN due to encountering a page with<br /> page_count() == 0, but it can also lead to data corruption and additional<br /> errors in the kernel.<br /> <br /> WARNING: CPU: 7 PID: 1995658 at arch/x86/kvm/../../../virt/kvm/kvm_main.c:171<br /> RIP: 0010:kvm_is_zone_device_pfn.part.0+0x9e/0xd0 [kvm]<br /> Call Trace:<br /> <br /> kvm_set_pfn_dirty+0x120/0x1d0 [kvm]<br /> __handle_changed_spte+0x92e/0xca0 [kvm]<br /> __handle_changed_spte+0x63c/0xca0 [kvm]<br /> __handle_changed_spte+0x63c/0xca0 [kvm]<br /> __handle_changed_spte+0x63c/0xca0 [kvm]<br /> zap_gfn_range+0x549/0x620 [kvm]<br /> kvm_tdp_mmu_put_root+0x1b6/0x270 [kvm]<br /> mmu_free_root_page+0x219/0x2c0 [kvm]<br /> kvm_mmu_free_roots+0x1b4/0x4e0 [kvm]<br /> kvm_mmu_unload+0x1c/0xa0 [kvm]<br /> kvm_arch_destroy_vm+0x1f2/0x5c0 [kvm]<br /> kvm_put_kvm+0x3b1/0x8b0 [kvm]<br /> kvm_vcpu_release+0x4e/0x70 [kvm]<br /> __fput+0x1f7/0x8c0<br /> task_work_run+0xf8/0x1a0<br /> do_exit+0x97b/0x2230<br /> do_group_exit+0xda/0x2a0<br /> get_signal+0x3be/0x1e50<br /> arch_do_signal_or_restart+0x244/0x17f0<br /> exit_to_user_mode_prepare+0xcb/0x120<br /> syscall_exit_to_user_mode+0x1d/0x40<br /> do_syscall_64+0x4d/0x90<br /> entry_SYSCALL_64_after_hwframe+0x44/0xae<br /> <br /> Note, the underlying bug existed even before commit 1af4a96025b3 ("KVM:<br /> x86/mmu: Yield in TDU MMU iter even if no SPTES changed") moved calls to<br /> tdp_mmu_iter_cond_resched() to the beginning of loops, as KVM could still<br /> incorrectly advance past a top-level entry when yielding on a lower-level<br /> entry. But with respect to leaking shadow pages, the bug was introduced<br /> by yielding before processing the current gfn.<br /> <br /> Alternatively, tdp_mmu_iter_cond_resched() could simply fall through, or<br /> callers could jump to their "retry" label. The downside of that approach<br /> is that tdp_mmu_iter_cond_resched() _must_ be called before anything else<br /> in the loop, and there&amp;#39;s no easy way to enfornce that requirement.<br /> <br /> Ideally, KVM would handling the cond_resched() fully within the iterator<br /> macro (the code is actually quite clean) and avoid this entire class of<br /> bugs, but that is extremely difficult do wh<br /> ---truncated---