CVE-2024-40950

See a problem?
Please try reporting it to the source first.
Source
https://nvd.nist.gov/vuln/detail/CVE-2024-40950
Import Source
https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2024-40950.json
JSON Data
https://api.osv.dev/v1/vulns/CVE-2024-40950
Related
Published
2024-07-12T13:15:17Z
Modified
2024-09-18T03:26:30.883050Z
Summary
[none]
Details

In the Linux kernel, the following vulnerability has been resolved:

mm: hugememory: fix misused mappinglargefoliosupport() for anon folios

When I did a large folios split test, a WARNING "[ 5059.122759][ T166] Cannot split file folio to non-0 order" was triggered. But the test cases are only for anonmous folios. while mappinglargefolio_support() is only reasonable for page cache folios.

In splithugepagetolisttoorder(), the folio passed to mappinglargefoliosupport() maybe anonmous folio. The foliotestanon() check is missing. So the split of the anonmous THP is failed. This is also the same for shmemmapping(). We'd better add a check for both. But the shmemmapping() in _splithugepage() is not involved, as for anonmous folios, the end parameter is set to -1, so (head[i].index >= end) is always false. shmem_mapping() is not called.

Also add a VMWARNONONCE() in mappinglargefoliosupport() for anon mapping, So we can detect the wrong use more easily.

THP folios maybe exist in the pagecache even the file system doesn't support large folio, it is because when CONFIGTRANSPARENTHUGEPAGE is enabled, khugepaged will try to collapse read-only file-backed pages to THP. But the mapping does not actually support multi order large folios properly.

Using /sys/kernel/debug/splithugepages to verify this, with this patch, large anon THP is successfully split and the warning is ceased.

References

Affected packages

Debian:13 / linux

Package

Name
linux
Purl
pkg:deb/debian/linux?arch=source

Affected ranges

Type
ECOSYSTEM
Events
Introduced
0Unknown introduced version / All previous versions are affected
Fixed
6.9.7-1

Affected versions

6.*

6.1.27-1
6.1.37-1
6.1.38-1
6.1.38-2~bpo11+1
6.1.38-2
6.1.38-3
6.1.38-4~bpo11+1
6.1.38-4
6.1.52-1
6.1.55-1~bpo11+1
6.1.55-1
6.1.64-1
6.1.66-1
6.1.67-1
6.1.69-1~bpo11+1
6.1.69-1
6.1.76-1~bpo11+1
6.1.76-1
6.1.82-1
6.1.85-1
6.1.90-1~bpo11+1
6.1.90-1
6.1.94-1~bpo11+1
6.1.94-1
6.1.98-1
6.1.99-1
6.1.106-1
6.1.106-2
6.1.106-3
6.3.1-1~exp1
6.3.2-1~exp1
6.3.4-1~exp1
6.3.5-1~exp1
6.3.7-1~bpo12+1
6.3.7-1
6.3.11-1
6.4~rc6-1~exp1
6.4~rc7-1~exp1
6.4.1-1~exp1
6.4.4-1~bpo12+1
6.4.4-1
6.4.4-2
6.4.4-3~bpo12+1
6.4.4-3
6.4.11-1
6.4.13-1
6.5~rc4-1~exp1
6.5~rc6-1~exp1
6.5~rc7-1~exp1
6.5.1-1~exp1
6.5.3-1~bpo12+1
6.5.3-1
6.5.6-1
6.5.8-1
6.5.10-1~bpo12+1
6.5.10-1
6.5.13-1
6.6.3-1~exp1
6.6.4-1~exp1
6.6.7-1~exp1
6.6.8-1
6.6.9-1
6.6.11-1
6.6.13-1~bpo12+1
6.6.13-1
6.6.15-1
6.6.15-2
6.7-1~exp1
6.7.1-1~exp1
6.7.4-1~exp1
6.7.7-1
6.7.9-1
6.7.9-2
6.7.12-1~bpo12+1
6.7.12-1
6.8.9-1
6.8.11-1
6.8.12-1~bpo12+1
6.8.12-1
6.9.2-1~exp1
6.9.7-1~bpo12+1

Ecosystem specific 

{
    "urgency": "not yet assigned"
}