In the Linux kernel, the following vulnerability has been resolved:
mm: avoid leaving partial pfn mappings around in error case
As Jann points out, PFN mappings are special, because unlike normal
memory mappings, there is no lifetime information associated with the
mapping - it is just a raw mapping of PFNs with no reference counting of
a 'struct page'.
That's all very much intentional, but it does mean that it's easy to
mess up the cleanup in case of errors. Yes, a failed mmap() will always
eventually clean up any partial mappings, but without any explicit
lifetime in the page table mapping itself, it's very easy to do the
error handling in the wrong order.
In particular, it's easy to mistakenly free the physical backing store
before the page tables are actually cleaned up and (temporarily) have
stale dangling PTE entries.
To make this situation less error-prone, just make sure that any partial
pfn mapping is torn down early, before any other error handling.
Metrics
Affected Vendors & Products
References
History
Fri, 08 Nov 2024 16:00:00 +0000
Type | Values Removed | Values Added |
---|---|---|
References |
|
Wed, 23 Oct 2024 15:00:00 +0000
Type | Values Removed | Values Added |
---|---|---|
Weaknesses | CWE-20 |
Mon, 21 Oct 2024 17:45:00 +0000
Type | Values Removed | Values Added |
---|---|---|
References |
|
Fri, 18 Oct 2024 15:15:00 +0000
Type | Values Removed | Values Added |
---|---|---|
First Time appeared |
Linux
Linux linux Kernel |
|
Weaknesses | CWE-459 | |
CPEs | cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* cpe:2.3:o:linux:linux_kernel:6.11:rc1:*:*:*:*:*:* cpe:2.3:o:linux:linux_kernel:6.11:rc2:*:*:*:*:*:* cpe:2.3:o:linux:linux_kernel:6.11:rc3:*:*:*:*:*:* cpe:2.3:o:linux:linux_kernel:6.11:rc4:*:*:*:*:*:* cpe:2.3:o:linux:linux_kernel:6.11:rc5:*:*:*:*:*:* cpe:2.3:o:linux:linux_kernel:6.11:rc6:*:*:*:*:*:* cpe:2.3:o:linux:linux_kernel:6.11:rc7:*:*:*:*:*:* |
|
Vendors & Products |
Linux
Linux linux Kernel |
Thu, 17 Oct 2024 14:00:00 +0000
Type | Values Removed | Values Added |
---|---|---|
References |
|
Wed, 16 Oct 2024 01:30:00 +0000
Type | Values Removed | Values Added |
---|---|---|
References |
| |
Metrics |
threat_severity
|
cvssV3_1
|
Tue, 15 Oct 2024 13:15:00 +0000
Type | Values Removed | Values Added |
---|---|---|
Metrics |
ssvc
|
Tue, 15 Oct 2024 11:00:00 +0000
Type | Values Removed | Values Added |
---|---|---|
Description | In the Linux kernel, the following vulnerability has been resolved: mm: avoid leaving partial pfn mappings around in error case As Jann points out, PFN mappings are special, because unlike normal memory mappings, there is no lifetime information associated with the mapping - it is just a raw mapping of PFNs with no reference counting of a 'struct page'. That's all very much intentional, but it does mean that it's easy to mess up the cleanup in case of errors. Yes, a failed mmap() will always eventually clean up any partial mappings, but without any explicit lifetime in the page table mapping itself, it's very easy to do the error handling in the wrong order. In particular, it's easy to mistakenly free the physical backing store before the page tables are actually cleaned up and (temporarily) have stale dangling PTE entries. To make this situation less error-prone, just make sure that any partial pfn mapping is torn down early, before any other error handling. | |
Title | mm: avoid leaving partial pfn mappings around in error case | |
References |
|
MITRE
Status: PUBLISHED
Assigner: Linux
Published: 2024-10-15T10:48:33.481Z
Updated: 2024-11-08T15:56:08.957Z
Reserved: 2024-09-30T16:00:12.937Z
Link: CVE-2024-47674
Vulnrichment
Updated: 2024-10-15T12:44:18.597Z
NVD
Status : Modified
Published: 2024-10-15T11:15:13.073
Modified: 2024-11-08T16:15:24.737
Link: CVE-2024-47674
Redhat