CVE-2023-52489

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/sparsemem: fix race in accessing memory_section-&gt;usage<br /> <br /> The below race is observed on a PFN which falls into the device memory<br /> region with the system memory configuration where PFN&amp;#39;s are such that<br /> [ZONE_NORMAL ZONE_DEVICE ZONE_NORMAL]. Since normal zone start and end<br /> pfn contains the device memory PFN&amp;#39;s as well, the compaction triggered<br /> will try on the device memory PFN&amp;#39;s too though they end up in NOP(because<br /> pfn_to_online_page() returns NULL for ZONE_DEVICE memory sections). When<br /> from other core, the section mappings are being removed for the<br /> ZONE_DEVICE region, that the PFN in question belongs to, on which<br /> compaction is currently being operated is resulting into the kernel crash<br /> with CONFIG_SPASEMEM_VMEMAP enabled. The crash logs can be seen at [1].<br /> <br /> compact_zone() memunmap_pages<br /> ------------- ---------------<br /> __pageblock_pfn_to_page<br /> ......<br /> (a)pfn_valid():<br /> valid_section()//return true<br /> (b)__remove_pages()-&gt;<br /> sparse_remove_section()-&gt;<br /> section_deactivate():<br /> [Free the array ms-&gt;usage and set<br /> ms-&gt;usage = NULL]<br /> pfn_section_valid()<br /> [Access ms-&gt;usage which<br /> is NULL]<br /> <br /> NOTE: From the above it can be said that the race is reduced to between<br /> the pfn_valid()/pfn_section_valid() and the section deactivate with<br /> SPASEMEM_VMEMAP enabled.<br /> <br /> The commit b943f045a9af("mm/sparse: fix kernel crash with<br /> pfn_section_valid check") tried to address the same problem by clearing<br /> the SECTION_HAS_MEM_MAP with the expectation of valid_section() returns<br /> false thus ms-&gt;usage is not accessed.<br /> <br /> Fix this issue by the below steps:<br /> <br /> a) Clear SECTION_HAS_MEM_MAP before freeing the -&gt;usage.<br /> <br /> b) RCU protected read side critical section will either return NULL<br /> when SECTION_HAS_MEM_MAP is cleared or can successfully access -&gt;usage.<br /> <br /> c) Free the -&gt;usage with kfree_rcu() and set ms-&gt;usage = NULL. No<br /> attempt will be made to access -&gt;usage after this as the<br /> SECTION_HAS_MEM_MAP is cleared thus valid_section() return false.<br /> <br /> Thanks to David/Pavan for their inputs on this patch.<br /> <br /> [1] https://lore.kernel.org/linux-mm/994410bb-89aa-d987-1f50-f514903c55aa@quicinc.com/<br /> <br /> On Snapdragon SoC, with the mentioned memory configuration of PFN&amp;#39;s as<br /> [ZONE_NORMAL ZONE_DEVICE ZONE_NORMAL], we are able to see bunch of<br /> issues daily while testing on a device farm.<br /> <br /> For this particular issue below is the log. Though the below log is<br /> not directly pointing to the pfn_section_valid(){ ms-&gt;usage;}, when we<br /> loaded this dump on T32 lauterbach tool, it is pointing.<br /> <br /> [ 540.578056] Unable to handle kernel NULL pointer dereference at<br /> virtual address 0000000000000000<br /> [ 540.578068] Mem abort info:<br /> [ 540.578070] ESR = 0x0000000096000005<br /> [ 540.578073] EC = 0x25: DABT (current EL), IL = 32 bits<br /> [ 540.578077] SET = 0, FnV = 0<br /> [ 540.578080] EA = 0, S1PTW = 0<br /> [ 540.578082] FSC = 0x05: level 1 translation fault<br /> [ 540.578085] Data abort info:<br /> [ 540.578086] ISV = 0, ISS = 0x00000005<br /> [ 540.578088] CM = 0, WnR = 0<br /> [ 540.579431] pstate: 82400005 (Nzcv daif +PAN -UAO +TCO -DIT -SSBSBTYPE=--)<br /> [ 540.579436] pc : __pageblock_pfn_to_page+0x6c/0x14c<br /> [ 540.579454] lr : compact_zone+0x994/0x1058<br /> [ 540.579460] sp : ffffffc03579b510<br /> [ 540.579463] x29: ffffffc03579b510 x28: 0000000000235800 x27:000000000000000c<br /> [ 540.579470] x26: 0000000000235c00 x25: 0000000000000068 x24:ffffffc03579b640<br /> [ 540.579477] x23: 0000000000000001 x22: ffffffc03579b660 x21:0000000000000000<br /> [ 540.579483] x20: 0000000000235bff x19: ffffffdebf7e3940 x18:ffffffdebf66d140<br /> [ 540.579489] x17: 00000000739ba063 x16: 00000000739ba063 x15:00000000009f4bff<br /> [ 540.579495] x14: 0000008000000000 x13: 0000000000000000 x12:0000000000000001<br /> [ 540.579501] x11: 0000000000000000 x10: 0000000000000000 x9 :ffffff897d2cd440<br /> [ 540.579507] x8 : 0000000000000000 x7 : 0000000000000000 x6 :ffffffc03579b5b4<br /> [ 540.579512] x5 : 0000000000027f25 x4 : ffffffc03579b5b8 x3 :0000000000000<br /> ---truncated---