CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2022-48802 – fs/proc: task_mmu.c: don't read mapcount for migration entry
https://notcve.org/view.php?id=CVE-2022-48802
In the Linux kernel, the following vulnerability has been resolved: fs/proc: task_mmu.c: don't read mapcount for migration entry The syzbot reported the below BUG: kernel BUG at include/linux/page-flags.h:785! invalid opcode: 0000 [#1] PREEMPT SMP KASAN CPU: 1 PID: 4392 Comm: syz-executor560 Not tainted 5.16.0-rc6-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:PageDoubleMap include/linux/page-flags.h:785 [inline] RIP: 0010:__page_mapcount+0x2d2/0x350 mm/util.c:744 Call Trace: page_mapcount include/linux/mm.h:837 [inline] smaps_account+0x470/0xb10 fs/proc/task_mmu.c:466 smaps_pte_entry fs/proc/task_mmu.c:538 [inline] smaps_pte_range+0x611/0x1250 fs/proc/task_mmu.c:601 walk_pmd_range mm/pagewalk.c:128 [inline] walk_pud_range mm/pagewalk.c:205 [inline] walk_p4d_range mm/pagewalk.c:240 [inline] walk_pgd_range mm/pagewalk.c:277 [inline] __walk_page_range+0xe23/0x1ea0 mm/pagewalk.c:379 walk_page_vma+0x277/0x350 mm/pagewalk.c:530 smap_gather_stats.part.0+0x148/0x260 fs/proc/task_mmu.c:768 smap_gather_stats fs/proc/task_mmu.c:741 [inline] show_smap+0xc6/0x440 fs/proc/task_mmu.c:822 seq_read_iter+0xbb0/0x1240 fs/seq_file.c:272 seq_read+0x3e0/0x5b0 fs/seq_file.c:162 vfs_read+0x1b5/0x600 fs/read_write.c:479 ksys_read+0x12d/0x250 fs/read_write.c:619 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae The reproducer was trying to read /proc/$PID/smaps when calling MADV_FREE at the mean time. MADV_FREE may split THPs if it is called for partial THP. It may trigger the below race: CPU A CPU B ----- ----- smaps walk: MADV_FREE: page_mapcount() PageCompound() split_huge_page() page = compound_head(page) PageDoubleMap(page) When calling PageDoubleMap() this page is not a tail page of THP anymore so the BUG is triggered. This could be fixed by elevated refcount of the page before calling mapcount, but that would prevent it from counting migration entries, and it seems overkilling because the race just could happen when PMD is split so all PTE entries of tail pages are actually migration entries, and smaps_account() does treat migration entries as mapcount == 1 as Kirill pointed out. Add a new parameter for smaps_account() to tell this entry is migration entry then skip calling page_mapcount(). Don't skip getting mapcount for device private entries since they do track references with mapcount. Pagemap also has the similar issue although it was not reported. • https://git.kernel.org/stable/c/e9b61f19858a5d6c42ce2298cf138279375d0d9b https://git.kernel.org/stable/c/db3f3636e4aed2cba3e4e7897a053323f7a62249 https://git.kernel.org/stable/c/a8dd0cfa37792863b6c4bf9542975212a6715d49 https://git.kernel.org/stable/c/05d3f8045efa59457b323caf00bdb9273b7962fa https://git.kernel.org/stable/c/24d7275ce2791829953ed4e72f68277ceb2571c6 •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2022-48801 – iio: buffer: Fix file related error handling in IIO_BUFFER_GET_FD_IOCTL
https://notcve.org/view.php?id=CVE-2022-48801
In the Linux kernel, the following vulnerability has been resolved: iio: buffer: Fix file related error handling in IIO_BUFFER_GET_FD_IOCTL If we fail to copy the just created file descriptor to userland, we try to clean up by putting back 'fd' and freeing 'ib'. The code uses put_unused_fd() for the former which is wrong, as the file descriptor was already published by fd_install() which gets called internally by anon_inode_getfd(). This makes the error handling code leaving a half cleaned up file descriptor table around and a partially destructed 'file' object, allowing userland to play use-after-free tricks on us, by abusing the still usable fd and making the code operate on a dangling 'file->private_data' pointer. Instead of leaving the kernel in a partially corrupted state, don't attempt to explicitly clean up and leave this to the process exit path that'll release any still valid fds, including the one created by the previous call to anon_inode_getfd(). Simply return -EFAULT to indicate the error. • https://git.kernel.org/stable/c/f73f7f4da581875f9b1f2fb8ebd1ab15ed634488 https://git.kernel.org/stable/c/b7f54894aa7517d2b6c797a499b9f491e9db9083 https://git.kernel.org/stable/c/202071d2518537866d291aa7cf26af54e674f4d4 https://git.kernel.org/stable/c/c72ea20503610a4a7ba26c769357d31602769c01 •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2022-48800 – mm: vmscan: remove deadlock due to throttling failing to make progress
https://notcve.org/view.php?id=CVE-2022-48800
In the Linux kernel, the following vulnerability has been resolved: mm: vmscan: remove deadlock due to throttling failing to make progress A soft lockup bug in kcompactd was reported in a private bugzilla with the following visible in dmesg; watchdog: BUG: soft lockup - CPU#33 stuck for 26s! [kcompactd0:479] watchdog: BUG: soft lockup - CPU#33 stuck for 52s! [kcompactd0:479] watchdog: BUG: soft lockup - CPU#33 stuck for 78s! [kcompactd0:479] watchdog: BUG: soft lockup - CPU#33 stuck for 104s! [kcompactd0:479] The machine had 256G of RAM with no swap and an earlier failed allocation indicated that node 0 where kcompactd was run was potentially unreclaimable; Node 0 active_anon:29355112kB inactive_anon:2913528kB active_file:0kB inactive_file:0kB unevictable:64kB isolated(anon):0kB isolated(file):0kB mapped:8kB dirty:0kB writeback:0kB shmem:26780kB shmem_thp: 0kB shmem_pmdmapped: 0kB anon_thp: 23480320kB writeback_tmp:0kB kernel_stack:2272kB pagetables:24500kB all_unreclaimable? • https://git.kernel.org/stable/c/d818fca1cac31b1fc9301bda83e195a46fb4ebaa https://git.kernel.org/stable/c/3980cff6349687f73d5109f156f23cb261c24164 https://git.kernel.org/stable/c/b485c6f1f9f54b81443efda5f3d8a5036ba2cd91 •
CVSS: 5.5EPSS: 0%CPEs: 7EXPL: 0CVE-2022-48799 – perf: Fix list corruption in perf_cgroup_switch()
https://notcve.org/view.php?id=CVE-2022-48799
In the Linux kernel, the following vulnerability has been resolved: perf: Fix list corruption in perf_cgroup_switch() There's list corruption on cgrp_cpuctx_list. This happens on the following path: perf_cgroup_switch: list_for_each_entry(cgrp_cpuctx_list) cpu_ctx_sched_in ctx_sched_in ctx_pinned_sched_in merge_sched_in perf_cgroup_event_disable: remove the event from the list Use list_for_each_entry_safe() to allow removing an entry during iteration. • https://git.kernel.org/stable/c/058fe1c0440e68a1ba3c2270ae43e9f0298b27d8 https://git.kernel.org/stable/c/5d76ed4223403f90421782adb2f20a9ecbc93186 https://git.kernel.org/stable/c/30d9f3cbe47e1018ddc8069ac5b5c9e66fbdf727 https://git.kernel.org/stable/c/a2ed7b29d0673ba361546e2d87dbbed149456c45 https://git.kernel.org/stable/c/f6b5d51976fcefef5732da3e3feb3ccff680f7c8 https://git.kernel.org/stable/c/7969fe91c9830e045901970e9d755b7505881d4a https://git.kernel.org/stable/c/2142bc1469a316fddd10012d76428f7265258f81 https://git.kernel.org/stable/c/5f4e5ce638e6a490b976ade4a40017b40 • CWE-99: Improper Control of Resource Identifiers ('Resource Injection') •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2022-48798 – s390/cio: verify the driver availability for path_event call
https://notcve.org/view.php?id=CVE-2022-48798
In the Linux kernel, the following vulnerability has been resolved: s390/cio: verify the driver availability for path_event call If no driver is attached to a device or the driver does not provide the path_event function, an FCES path-event on this device could end up in a kernel-panic. Verify the driver availability before the path_event function call. • https://git.kernel.org/stable/c/32ef938815c1fb42d65212aac860ab153a64de1a https://git.kernel.org/stable/c/fe990b7bf6ac93f1d850d076b8f0e758268aa4ab https://git.kernel.org/stable/c/a0619027f11590b2070624297530c34dc7f91bcd https://git.kernel.org/stable/c/dd9cb842fa9d90653a9b48aba52f89c069f3bc50 •