CVE-2022-48800

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm: vmscan: remove deadlock due to throttling failing to make progress<br /> <br /> A soft lockup bug in kcompactd was reported in a private bugzilla with<br /> the following visible in dmesg;<br /> <br /> watchdog: BUG: soft lockup - CPU#33 stuck for 26s! [kcompactd0:479]<br /> watchdog: BUG: soft lockup - CPU#33 stuck for 52s! [kcompactd0:479]<br /> watchdog: BUG: soft lockup - CPU#33 stuck for 78s! [kcompactd0:479]<br /> watchdog: BUG: soft lockup - CPU#33 stuck for 104s! [kcompactd0:479]<br /> <br /> The machine had 256G of RAM with no swap and an earlier failed<br /> allocation indicated that node 0 where kcompactd was run was potentially<br /> unreclaimable;<br /> <br /> Node 0 active_anon:29355112kB inactive_anon:2913528kB active_file:0kB<br /> inactive_file:0kB unevictable:64kB isolated(anon):0kB isolated(file):0kB<br /> mapped:8kB dirty:0kB writeback:0kB shmem:26780kB shmem_thp:<br /> 0kB shmem_pmdmapped: 0kB anon_thp: 23480320kB writeback_tmp:0kB<br /> kernel_stack:2272kB pagetables:24500kB all_unreclaimable? yes<br /> <br /> Vlastimil Babka investigated a crash dump and found that a task<br /> migrating pages was trying to drain PCP lists;<br /> <br /> PID: 52922 TASK: ffff969f820e5000 CPU: 19 COMMAND: "kworker/u128:3"<br /> Call Trace:<br /> __schedule<br /> schedule<br /> schedule_timeout<br /> wait_for_completion<br /> __flush_work<br /> __drain_all_pages<br /> __alloc_pages_slowpath.constprop.114<br /> __alloc_pages<br /> alloc_migration_target<br /> migrate_pages<br /> migrate_to_node<br /> do_migrate_pages<br /> cpuset_migrate_mm_workfn<br /> process_one_work<br /> worker_thread<br /> kthread<br /> ret_from_fork<br /> <br /> This failure is specific to CONFIG_PREEMPT=n builds. The root of the<br /> problem is that kcompact0 is not rescheduling on a CPU while a task that<br /> has isolated a large number of the pages from the LRU is waiting on<br /> kcompact0 to reschedule so the pages can be released. While<br /> shrink_inactive_list() only loops once around too_many_isolated, reclaim<br /> can continue without rescheduling if sc-&gt;skipped_deactivate == 1 which<br /> could happen if there was no file LRU and the inactive anon list was not<br /> low.