Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> kernel/irq/irqdomain.c: fix memory leak with using debugfs_lookup()<br /> <br /> When calling debugfs_lookup() the result must have dput() called on it,<br /> otherwise the memory will leak over time. To make things simpler, just<br /> call debugfs_lookup_and_remove() instead which handles all of the logic<br /> at once.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> HV: hv_balloon: fix memory leak with using debugfs_lookup()<br /> <br /> When calling debugfs_lookup() the result must have dput() called on it,<br /> otherwise the memory will leak over time. To make things simpler, just<br /> call debugfs_lookup_and_remove() instead which handles all of the logic<br /> at once.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: typec: ucsi: Don&amp;#39;t attempt to resume the ports before they exist<br /> <br /> This will fix null pointer dereference that was caused by<br /> the driver attempting to resume ports that were not yet<br /> registered.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm: memcg: fix NULL pointer in mem_cgroup_track_foreign_dirty_slowpath()<br /> <br /> As commit 18365225f044 ("hwpoison, memcg: forcibly uncharge LRU pages"),<br /> hwpoison will forcibly uncharg a LRU hwpoisoned page, the folio_memcg<br /> could be NULl, then, mem_cgroup_track_foreign_dirty_slowpath() could<br /> occurs a NULL pointer dereference, let&amp;#39;s do not record the foreign<br /> writebacks for folio memcg is null in mem_cgroup_track_foreign_dirty() to<br /> fix it.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/khugepaged: fix -&gt;anon_vma race<br /> <br /> If an -&gt;anon_vma is attached to the VMA, collapse_and_free_pmd() requires<br /> it to be locked.<br /> <br /> Page table traversal is allowed under any one of the mmap lock, the<br /> anon_vma lock (if the VMA is associated with an anon_vma), and the<br /> mapping lock (if the VMA is associated with a mapping); and so to be<br /> able to remove page tables, we must hold all three of them. <br /> retract_page_tables() bails out if an -&gt;anon_vma is attached, but does<br /> this check before holding the mmap lock (as the comment above the check<br /> explains).<br /> <br /> If we racily merged an existing -&gt;anon_vma (shared with a child<br /> process) from a neighboring VMA, subsequent rmap traversals on pages<br /> belonging to the child will be able to see the page tables that we are<br /> concurrently removing while assuming that nothing else can access them.<br /> <br /> Repeat the -&gt;anon_vma check once we hold the mmap lock to ensure that<br /> there really is no concurrent page table access.<br /> <br /> Hitting this bug causes a lockdep warning in collapse_and_free_pmd(),<br /> in the line "lockdep_assert_held_write(&amp;vma-&gt;anon_vma-&gt;root-&gt;rwsem)". <br /> It can also lead to use-after-free access.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Skip invalid kfunc call in backtrack_insn<br /> <br /> The verifier skips invalid kfunc call in check_kfunc_call(), which<br /> would be captured in fixup_kfunc_call() if such insn is not eliminated<br /> by dead code elimination. However, this can lead to the following<br /> warning in backtrack_insn(), also see [1]:<br /> <br /> ------------[ cut here ]------------<br /> verifier backtracking bug<br /> WARNING: CPU: 6 PID: 8646 at kernel/bpf/verifier.c:2756 backtrack_insn<br /> kernel/bpf/verifier.c:2756<br /> __mark_chain_precision kernel/bpf/verifier.c:3065<br /> mark_chain_precision kernel/bpf/verifier.c:3165<br /> adjust_reg_min_max_vals kernel/bpf/verifier.c:10715<br /> check_alu_op kernel/bpf/verifier.c:10928<br /> do_check kernel/bpf/verifier.c:13821 [inline]<br /> do_check_common kernel/bpf/verifier.c:16289<br /> [...]<br /> <br /> So make backtracking conservative with this by returning ENOTSUPP.<br /> <br /> [1] https://lore.kernel.org/bpf/CACkBjsaXNceR8ZjkLG=dT3P=4A8SBsg0Z5h5PWLryF5=ghKq=g@mail.gmail.com/

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nvmem: core: fix cleanup after dev_set_name()<br /> <br /> If dev_set_name() fails, we leak nvmem-&gt;wp_gpio as the cleanup does not<br /> put this. While a minimal fix for this would be to add the gpiod_put()<br /> call, we can do better if we split device_register(), and use the<br /> tested nvmem_release() cleanup code by initialising the device early,<br /> and putting the device.<br /> <br /> This results in a slightly larger fix, but results in clear code.<br /> <br /> Note: this patch depends on "nvmem: core: initialise nvmem-&gt;id early"<br /> and "nvmem: core: remove nvmem_config wp_gpio".<br /> <br /> [Srini: Fixed subject line and error code handing with wp_gpio while applying.]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/i915: Fix potential bit_17 double-free<br /> <br /> A userspace with multiple threads racing I915_GEM_SET_TILING to set the<br /> tiling to I915_TILING_NONE could trigger a double free of the bit_17<br /> bitmask. (Or conversely leak memory on the transition to tiled.) Move<br /> allocation/free&amp;#39;ing of the bitmask within the section protected by the<br /> obj lock.<br /> <br /> [tursulin: Correct fixes tag and added cc stable.]<br /> (cherry picked from commit 10e0cbaaf1104f449d695c80bcacf930dcd3c42e)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/i915: Avoid potential vm use-after-free<br /> <br /> Adding the vm to the vm_xa table makes it visible to userspace, which<br /> could try to race with us to close the vm. So we need to take our extra<br /> reference before putting it in the table.<br /> <br /> (cherry picked from commit 99343c46d4e2b34c285d3d5f68ff04274c2f9fb4)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/swapfile: add cond_resched() in get_swap_pages()<br /> <br /> The softlockup still occurs in get_swap_pages() under memory pressure. 64<br /> CPU cores, 64GB memory, and 28 zram devices, the disksize of each zram<br /> device is 50MB with same priority as si. Use the stress-ng tool to<br /> increase memory pressure, causing the system to oom frequently.<br /> <br /> The plist_for_each_entry_safe() loops in get_swap_pages() could reach tens<br /> of thousands of times to find available space (extreme case:<br /> cond_resched() is not called in scan_swap_map_slots()). Let&amp;#39;s add<br /> cond_resched() into get_swap_pages() when failed to find available space<br /> to avoid softlockup.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/hugetlb: fix PTE marker handling in hugetlb_change_protection()<br /> <br /> Patch series "mm/hugetlb: uffd-wp fixes for hugetlb_change_protection()".<br /> <br /> Playing with virtio-mem and background snapshots (using uffd-wp) on<br /> hugetlb in QEMU, I managed to trigger a VM_BUG_ON(). Looking into the<br /> details, hugetlb_change_protection() seems to not handle uffd-wp correctly<br /> in all cases.<br /> <br /> Patch #1 fixes my test case. I don&amp;#39;t have reproducers for patch #2, as it<br /> requires running into migration entries.<br /> <br /> I did not yet check in detail yet if !hugetlb code requires similar care.<br /> <br /> <br /> This patch (of 2):<br /> <br /> There are two problematic cases when stumbling over a PTE marker in<br /> hugetlb_change_protection():<br /> <br /> (1) We protect an uffd-wp PTE marker a second time using uffd-wp: we will<br /> end up in the "!huge_pte_none(pte)" case and mess up the PTE marker.<br /> <br /> (2) We unprotect a uffd-wp PTE marker: we will similarly end up in the<br /> "!huge_pte_none(pte)" case even though we cleared the PTE, because<br /> the "pte" variable is stale. We&amp;#39;ll mess up the PTE marker.<br /> <br /> For example, if we later stumble over such a "wrongly modified" PTE marker,<br /> we&amp;#39;ll treat it like a present PTE that maps some garbage page.<br /> <br /> This can, for example, be triggered by mapping a memfd backed by huge<br /> pages, registering uffd-wp, uffd-wp&amp;#39;ing an unmapped page and (a)<br /> uffd-wp&amp;#39;ing it a second time; or (b) uffd-unprotecting it; or (c)<br /> unregistering uffd-wp. Then, ff we trigger fallocate(FALLOC_FL_PUNCH_HOLE)<br /> on that file range, we will run into a VM_BUG_ON:<br /> <br /> [ 195.039560] page:00000000ba1f2987 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x0<br /> [ 195.039565] flags: 0x7ffffc0001000(reserved|node=0|zone=0|lastcpupid=0x1fffff)<br /> [ 195.039568] raw: 0007ffffc0001000 ffffe742c0000008 ffffe742c0000008 0000000000000000<br /> [ 195.039569] raw: 0000000000000000 0000000000000000 00000001ffffffff 0000000000000000<br /> [ 195.039569] page dumped because: VM_BUG_ON_PAGE(compound &amp;&amp; !PageHead(page))<br /> [ 195.039573] ------------[ cut here ]------------<br /> [ 195.039574] kernel BUG at mm/rmap.c:1346!<br /> [ 195.039579] invalid opcode: 0000 [#1] PREEMPT SMP NOPTI<br /> [ 195.039581] CPU: 7 PID: 4777 Comm: qemu-system-x86 Not tainted 6.0.12-200.fc36.x86_64 #1<br /> [ 195.039583] Hardware name: LENOVO 20WNS1F81N/20WNS1F81N, BIOS N35ET50W (1.50 ) 09/15/2022<br /> [ 195.039584] RIP: 0010:page_remove_rmap+0x45b/0x550<br /> [ 195.039588] Code: [...]<br /> [ 195.039589] RSP: 0018:ffffbc03c3633ba8 EFLAGS: 00010292<br /> [ 195.039591] RAX: 0000000000000040 RBX: ffffe742c0000000 RCX: 0000000000000000<br /> [ 195.039592] RDX: 0000000000000002 RSI: ffffffff8e7aac1a RDI: 00000000ffffffff<br /> [ 195.039592] RBP: 0000000000000001 R08: 0000000000000000 R09: ffffbc03c3633a08<br /> [ 195.039593] R10: 0000000000000003 R11: ffffffff8f146328 R12: ffff9b04c42754b0<br /> [ 195.039594] R13: ffffffff8fcc6328 R14: ffffbc03c3633c80 R15: ffff9b0484ab9100<br /> [ 195.039595] FS: 00007fc7aaf68640(0000) GS:ffff9b0bbf7c0000(0000) knlGS:0000000000000000<br /> [ 195.039596] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 195.039597] CR2: 000055d402c49110 CR3: 0000000159392003 CR4: 0000000000772ee0<br /> [ 195.039598] PKRU: 55555554<br /> [ 195.039599] Call Trace:<br /> [ 195.039600] <br /> [ 195.039602] __unmap_hugepage_range+0x33b/0x7d0<br /> [ 195.039605] unmap_hugepage_range+0x55/0x70<br /> [ 195.039608] hugetlb_vmdelete_list+0x77/0xa0<br /> [ 195.039611] hugetlbfs_fallocate+0x410/0x550<br /> [ 195.039612] ? _raw_spin_unlock_irqrestore+0x23/0x40<br /> [ 195.039616] vfs_fallocate+0x12e/0x360<br /> [ 195.039618] __x64_sys_fallocate+0x40/0x70<br /> [ 195.039620] do_syscall_64+0x58/0x80<br /> [ 195.039623] ? syscall_exit_to_user_mode+0x17/0x40<br /> [ 195.039624] ? do_syscall_64+0x67/0x80<br /> [ 195.039626] entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> [ 195.039628] RIP: 0033:0x7fc7b590651f<br /> [ 195.039653] Code: [...]<br /> [ 195.039654] RSP: 002b:00007fc7aaf66e70 EFLAGS: 00000293 ORIG_RAX: 000000000000011d<br /> [ 195.039655] RAX: ffffffffffffffda RBX: 0000558ef4b7f370 RCX: 00007fc7b590651f<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> reset: uniphier-glue: Fix possible null-ptr-deref<br /> <br /> It will cause null-ptr-deref when resource_size(res) invoked,<br /> if platform_get_resource() returns NULL.