CVE-2023-52489
- Source
- https://nvd.nist.gov/vuln/detail/CVE-2023-52489
- Import Source
- https://storage.googleapis.com/osv-test-cve-osv-conversion/osv-output/CVE-2023-52489.json
- JSON Data
- https://api.test.osv.dev/v1/vulns/CVE-2023-52489
- Downstream
- Related
- Published
- 2024-02-29T15:52:08Z
- Modified
- 2025-10-16T12:30:51.793440Z
- Summary
- mm/sparsemem: fix race in accessing memory_section->usage
- Details
-
In the Linux kernel, the following vulnerability has been resolved:
mm/sparsemem: fix race in accessing memory_section->usage
The below race is observed on a PFN which falls into the device memory region with the system memory configuration where PFN's are such that [ZONENORMAL ZONEDEVICE ZONENORMAL]. Since normal zone start and end pfn contains the device memory PFN's as well, the compaction triggered will try on the device memory PFN's too though they end up in NOP(because pfntoonlinepage() returns NULL for ZONEDEVICE memory sections). When from other core, the section mappings are being removed for the ZONEDEVICE region, that the PFN in question belongs to, on which compaction is currently being operated is resulting into the kernel crash with CONFIGSPASEMEMVMEMAP enabled. The crash logs can be seen at [1].
compactzone() memunmappages ------------- --------------- pageblockpfntopage ...... (a)pfnvalid(): validsection()//return true (b)removepages()-> sparseremovesection()-> sectiondeactivate(): [Free the array ms->usage and set ms->usage = NULL] pfnsection_valid() [Access ms->usage which is NULL]
NOTE: From the above it can be said that the race is reduced to between the pfnvalid()/pfnsectionvalid() and the section deactivate with SPASEMEMVMEMAP enabled.
The commit b943f045a9af("mm/sparse: fix kernel crash with pfnsectionvalid check") tried to address the same problem by clearing the SECTIONHASMEMMAP with the expectation of validsection() returns false thus ms->usage is not accessed.
Fix this issue by the below steps:
a) Clear SECTIONHASMEM_MAP before freeing the ->usage.
b) RCU protected read side critical section will either return NULL when SECTIONHASMEM_MAP is cleared or can successfully access ->usage.
c) Free the ->usage with kfreercu() and set ms->usage = NULL. No attempt will be made to access ->usage after this as the SECTIONHASMEMMAP is cleared thus valid_section() return false.
Thanks to David/Pavan for their inputs on this patch.
[1] https://lore.kernel.org/linux-mm/994410bb-89aa-d987-1f50-f514903c55aa@quicinc.com/
On Snapdragon SoC, with the mentioned memory configuration of PFN's as [ZONENORMAL ZONEDEVICE ZONE_NORMAL], we are able to see bunch of issues daily while testing on a device farm.
For this particular issue below is the log. Though the below log is not directly pointing to the pfnsectionvalid(){ ms->usage;}, when we loaded this dump on T32 lauterbach tool, it is pointing.
[ 540.578056] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 [ 540.578068] Mem abort info: [ 540.578070] ESR = 0x0000000096000005 [ 540.578073] EC = 0x25: DABT (current EL), IL = 32 bits [ 540.578077] SET = 0, FnV = 0 [ 540.578080] EA = 0, S1PTW = 0 [ 540.578082] FSC = 0x05: level 1 translation fault [ 540.578085] Data abort info: [ 540.578086] ISV = 0, ISS = 0x00000005 [ 540.578088] CM = 0, WnR = 0 [ 540.579431] pstate: 82400005 (Nzcv daif +PAN -UAO +TCO -DIT -SSBSBTYPE=--) [ 540.579436] pc : _pageblockpfntopage+0x6c/0x14c [ 540.579454] lr : compact_zone+0x994/0x1058 [ 540.579460] sp : ffffffc03579b510 [ 540.579463] x29: ffffffc03579b510 x28: 0000000000235800 x27:000000000000000c [ 540.579470] x26: 0000000000235c00 x25: 0000000000000068 x24:ffffffc03579b640 [ 540.579477] x23: 0000000000000001 x22: ffffffc03579b660 x21:0000000000000000 [ 540.579483] x20: 0000000000235bff x19: ffffffdebf7e3940 x18:ffffffdebf66d140 [ 540.579489] x17: 00000000739ba063 x16: 00000000739ba063 x15:00000000009f4bff [ 540.579495] x14: 0000008000000000 x13: 0000000000000000 x12:0000000000000001 [ 540.579501] x11: 0000000000000000 x10: 0000000000000000 x9 :ffffff897d2cd440 [ 540.579507] x8 : 0000000000000000 x7 : 0000000000000000 x6 :ffffffc03579b5b4 [ 540.579512] x5 : 0000000000027f25 x4 : ffffffc03579b5b8 x3 :0000000000000 ---truncated---
- References
-
- https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
- https://git.kernel.org/stable/c/3a01daace71b521563c38bbbf874e14c3e58adb7
- https://git.kernel.org/stable/c/5ec8e8ea8b7783fab150cf86404fc38cb4db8800
- https://git.kernel.org/stable/c/68ed9e33324021e9d6b798e9db00ca3093d2012a
- https://git.kernel.org/stable/c/70064241f2229f7ba7b9599a98f68d9142e81a97
- https://git.kernel.org/stable/c/90ad17575d26874287271127d43ef3c2af876cea
- https://git.kernel.org/stable/c/b448de2459b6d62a53892487ab18b7d823ff0529
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
Affected packages
Git / git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Affected ranges
- Type
- GIT
- Repo
- https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
- Events
-
Introducedf46edbd1b1516da1fb34c917775168d5df576f78Fixed90ad17575d26874287271127d43ef3c2af876cea
- Type
- GIT
- Repo
- https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
- Events
-
Introducedf46edbd1b1516da1fb34c917775168d5df576f78Fixedb448de2459b6d62a53892487ab18b7d823ff0529
- Type
- GIT
- Repo
- https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
- Events
-
Introducedf46edbd1b1516da1fb34c917775168d5df576f78Fixed68ed9e33324021e9d6b798e9db00ca3093d2012a
- Type
- GIT
- Repo
- https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
- Events
-
Introducedf46edbd1b1516da1fb34c917775168d5df576f78Fixed70064241f2229f7ba7b9599a98f68d9142e81a97
- Type
- GIT
- Repo
- https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
- Events
-
Introducedf46edbd1b1516da1fb34c917775168d5df576f78Fixed3a01daace71b521563c38bbbf874e14c3e58adb7
- Type
- GIT
- Repo
- https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
- Events
-
Introducedf46edbd1b1516da1fb34c917775168d5df576f78Fixed5ec8e8ea8b7783fab150cf86404fc38cb4db8800