CVE-2023-52490

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm: migrate: fix getting incorrect page mapping during page migration<br /> <br /> When running stress-ng testing, we found below kernel crash after a few hours:<br /> <br /> Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000<br /> pc : dentry_name+0xd8/0x224<br /> lr : pointer+0x22c/0x370<br /> sp : ffff800025f134c0<br /> ......<br /> Call trace:<br /> dentry_name+0xd8/0x224<br /> pointer+0x22c/0x370<br /> vsnprintf+0x1ec/0x730<br /> vscnprintf+0x2c/0x60<br /> vprintk_store+0x70/0x234<br /> vprintk_emit+0xe0/0x24c<br /> vprintk_default+0x3c/0x44<br /> vprintk_func+0x84/0x2d0<br /> printk+0x64/0x88<br /> __dump_page+0x52c/0x530<br /> dump_page+0x14/0x20<br /> set_migratetype_isolate+0x110/0x224<br /> start_isolate_page_range+0xc4/0x20c<br /> offline_pages+0x124/0x474<br /> memory_block_offline+0x44/0xf4<br /> memory_subsys_offline+0x3c/0x70<br /> device_offline+0xf0/0x120<br /> ......<br /> <br /> After analyzing the vmcore, I found this issue is caused by page migration.<br /> The scenario is that, one thread is doing page migration, and we will use the<br /> target page&amp;#39;s -&gt;mapping field to save &amp;#39;anon_vma&amp;#39; pointer between page unmap and<br /> page move, and now the target page is locked and refcount is 1.<br /> <br /> Currently, there is another stress-ng thread performing memory hotplug,<br /> attempting to offline the target page that is being migrated. It discovers that<br /> the refcount of this target page is 1, preventing the offline operation, thus<br /> proceeding to dump the page. However, page_mapping() of the target page may<br /> return an incorrect file mapping to crash the system in dump_mapping(), since<br /> the target page-&gt;mapping only saves &amp;#39;anon_vma&amp;#39; pointer without setting<br /> PAGE_MAPPING_ANON flag.<br /> <br /> There are seveval ways to fix this issue:<br /> (1) Setting the PAGE_MAPPING_ANON flag for target page&amp;#39;s -&gt;mapping when saving<br /> &amp;#39;anon_vma&amp;#39;, but this can confuse PageAnon() for PFN walkers, since the target<br /> page has not built mappings yet.<br /> (2) Getting the page lock to call page_mapping() in __dump_page() to avoid crashing<br /> the system, however, there are still some PFN walkers that call page_mapping()<br /> without holding the page lock, such as compaction.<br /> (3) Using target page-&gt;private field to save the &amp;#39;anon_vma&amp;#39; pointer and 2 bits<br /> page state, just as page-&gt;mapping records an anonymous page, which can remove<br /> the page_mapping() impact for PFN walkers and also seems a simple way.<br /> <br /> So I choose option 3 to fix this issue, and this can also fix other potential<br /> issues for PFN walkers, such as compaction.