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 •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2022-48797 – mm: don't try to NUMA-migrate COW pages that have other uses
https://notcve.org/view.php?id=CVE-2022-48797
In the Linux kernel, the following vulnerability has been resolved: mm: don't try to NUMA-migrate COW pages that have other uses Oded Gabbay reports that enabling NUMA balancing causes corruption with his Gaudi accelerator test load: "All the details are in the bug, but the bottom line is that somehow, this patch causes corruption when the numa balancing feature is enabled AND we don't use process affinity AND we use GUP to pin pages so our accelerator can DMA to/from system memory. Either disabling numa balancing, using process affinity to bind to specific numa-node or reverting this patch causes the bug to disappear" and Oded bisected the issue to commit 09854ba94c6a ("mm: do_wp_page() simplification"). Now, the NUMA balancing shouldn't actually be changing the writability of a page, and as such shouldn't matter for COW. But it appears it does. Suspicious. However, regardless of that, the condition for enabling NUMA faults in change_pte_range() is nonsensical. It uses "page_mapcount(page)" to decide if a COW page should be NUMA-protected or not, and that makes absolutely no sense. The number of mappings a page has is irrelevant: not only does GUP get a reference to a page as in Oded's case, but the other mappings migth be paged out and the only reference to them would be in the page count. Since we should never try to NUMA-balance a page that we can't move anyway due to other references, just fix the code to use 'page_count()'. Oded confirms that that fixes his issue. Now, this does imply that something in NUMA balancing ends up changing page protections (other than the obvious one of making the page inaccessible to get the NUMA faulting information). Otherwise the COW simplification wouldn't matter - since doing the GUP on the page would make sure it's writable. The cause of that permission change would be good to figure out too, since it clearly results in spurious COW events - but fixing the nonsensical test that just happened to work before is obviously the CorrectThing(tm) to do regardless. • https://git.kernel.org/stable/c/09854ba94c6aad7886996bfbee2530b3d8a7f4f4 https://git.kernel.org/stable/c/254090925e16abd914c87b4ad1b489440d89c4c3 https://git.kernel.org/stable/c/b3dc4b9d3ca68b370c4aeab5355007eedf948849 https://git.kernel.org/stable/c/d187eeb02d18446e5e54ed6bcbf8b47e6551daea https://git.kernel.org/stable/c/80d47f5de5e311cbc0d01ebb6ee684e8f4c196c6 •