CVSS: 7.1EPSS: 0%CPEs: 8EXPL: 0CVE-2022-48804 – vt_ioctl: fix array_index_nospec in vt_setactivate
https://notcve.org/view.php?id=CVE-2022-48804
In the Linux kernel, the following vulnerability has been resolved: vt_ioctl: fix array_index_nospec in vt_setactivate array_index_nospec ensures that an out-of-bounds value is set to zero on the transient path. Decreasing the value by one afterwards causes a transient integer underflow. vsa.console should be decreased first and then sanitized with array_index_nospec. Kasper Acknowledgements: Jakob Koschel, Brian Johannesmeyer, Kaveh Razavi, Herbert Bos, Cristiano Giuffrida from the VUSec group at VU Amsterdam. • https://git.kernel.org/stable/c/830c5aa302ec16b4ee641aec769462c37f802c90 https://git.kernel.org/stable/c/2a45a6bd1e6d651770aafff57ab3e1d3bb0b42e0 https://git.kernel.org/stable/c/170325aba4608bde3e7d21c9c19b7bc266ac0885 https://git.kernel.org/stable/c/ae3d57411562260ee3f4fd5e875f410002341104 https://git.kernel.org/stable/c/778302ca09498b448620edd372dc908bebf80bdf https://git.kernel.org/stable/c/ffe54289b02e9c732d6f04c8ebbe3b2d90d32118 https://git.kernel.org/stable/c/6550bdf52846f85a2a3726a5aa0c7c4399f2fc02 https://git.kernel.org/stable/c/61cc70d9e8ef5b042d4ed87994d20100e •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2022-48803 – phy: ti: Fix missing sentinel for clk_div_table
https://notcve.org/view.php?id=CVE-2022-48803
In the Linux kernel, the following vulnerability has been resolved: phy: ti: Fix missing sentinel for clk_div_table _get_table_maxdiv() tries to access "clk_div_table" array out of bound defined in phy-j721e-wiz.c. Add a sentinel entry to prevent the following global-out-of-bounds error reported by enabling KASAN. [ 9.552392] BUG: KASAN: global-out-of-bounds in _get_maxdiv+0xc0/0x148 [ 9.558948] Read of size 4 at addr ffff8000095b25a4 by task kworker/u4:1/38 [ 9.565926] [ 9.567441] CPU: 1 PID: 38 Comm: kworker/u4:1 Not tainted 5.16.0-116492-gdaadb3bd0e8d-dirty #360 [ 9.576242] Hardware name: Texas Instruments J721e EVM (DT) [ 9.581832] Workqueue: events_unbound deferred_probe_work_func [ 9.587708] Call trace: [ 9.590174] dump_backtrace+0x20c/0x218 [ 9.594038] show_stack+0x18/0x68 [ 9.597375] dump_stack_lvl+0x9c/0xd8 [ 9.601062] print_address_description.constprop.0+0x78/0x334 [ 9.606830] kasan_report+0x1f0/0x260 [ 9.610517] __asan_load4+0x9c/0xd8 [ 9.614030] _get_maxdiv+0xc0/0x148 [ 9.617540] divider_determine_rate+0x88/0x488 [ 9.622005] divider_round_rate_parent+0xc8/0x124 [ 9.626729] wiz_clk_div_round_rate+0x54/0x68 [ 9.631113] clk_core_determine_round_nolock+0x124/0x158 [ 9.636448] clk_core_round_rate_nolock+0x68/0x138 [ 9.641260] clk_core_set_rate_nolock+0x268/0x3a8 [ 9.645987] clk_set_rate+0x50/0xa8 [ 9.649499] cdns_sierra_phy_init+0x88/0x248 [ 9.653794] phy_init+0x98/0x108 [ 9.657046] cdns_pcie_enable_phy+0xa0/0x170 [ 9.661340] cdns_pcie_init_phy+0x250/0x2b0 [ 9.665546] j721e_pcie_probe+0x4b8/0x798 [ 9.669579] platform_probe+0x8c/0x108 [ 9.673350] really_probe+0x114/0x630 [ 9.677037] __driver_probe_device+0x18c/0x220 [ 9.681505] driver_probe_device+0xac/0x150 [ 9.685712] __device_attach_driver+0xec/0x170 [ 9.690178] bus_for_each_drv+0xf0/0x158 [ 9.694124] __device_attach+0x184/0x210 [ 9.698070] device_initial_probe+0x14/0x20 [ 9.702277] bus_probe_device+0xec/0x100 [ 9.706223] deferred_probe_work_func+0x124/0x180 [ 9.710951] process_one_work+0x4b0/0xbc0 [ 9.714983] worker_thread+0x74/0x5d0 [ 9.718668] kthread+0x214/0x230 [ 9.721919] ret_from_fork+0x10/0x20 [ 9.725520] [ 9.727032] The buggy address belongs to the variable: [ 9.732183] clk_div_table+0x24/0x440 • https://git.kernel.org/stable/c/091876cc355d6739e393efa4b3d07f451a6a035c https://git.kernel.org/stable/c/3c75d1017cb362b6a4e0935746ef5da28250919f https://git.kernel.org/stable/c/7a360e546ad9e7c3fd53d6bb60348c660cd28f54 https://git.kernel.org/stable/c/5b0c9569135a37348c1267c81e8b0274b21a86ed https://git.kernel.org/stable/c/6d1e6bcb31663ee83aaea1f171f3dbfe95dd4a69 •
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: 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: 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 •