CVE-2024-42299: fs/ntfs3: Update log->page_{mask,bits} if log->page_size changed
In the Linux kernel, the following vulnerability has been resolved:
fs/ntfs3: Update log->page_{mask,bits} if log->page_size changed
If an NTFS file system is mounted to another system with different
PAGE_SIZE from the original system, log->page_size will change in
log_replay(), but log->page_{mask,bits} don't change correspondingly.
This will cause a panic because "u32 bytes = log->page_size - page_off"
will get a negative value in the later read_log_page().
Security readout for executives and security teams
Plain-English summary
A Linux NTFS3 bookkeeping error can crash the kernel when replaying the log of an NTFS filesystem previously mounted on a system with a different memory page size. This can interrupt affected workloads. The supplied evidence does not establish remote exploitation or active attacks.
Executive priority
Treat as high priority for systems that routinely mount removable, imported, or cross-architecture NTFS media. Accelerate vendor kernel updates where a crash would disrupt critical services. Systems not using NTFS3, or not handling cross-page-size filesystems, are less likely to encounter the documented condition.
Technical view
In log_replay(), log->page_size can change without updating log->page_mask and log->page_bits. Later, read_log_page() can derive an invalid value from log->page_size minus page_off, causing a kernel panic. Linux stable commits are referenced as fixes across kernel branches.
Likely exposure
Exposure is most likely on Linux systems using NTFS3 to mount filesystems transferred between systems with different PAGE_SIZE values. The supplied affected-version data includes multiple kernel releases but does not define clean version ranges, so exact exposure must be confirmed through distribution advisories or fix-commit presence.
Exploitation context
The CVSS vector characterizes this as local, low-complexity exploitation requiring low privileges and no user interaction. CISA KEV status is false, and the supplied sources provide no evidence of active exploitation. The description establishes a kernel panic; it does not explain the CVSS-rated confidentiality or integrity impacts.
Researcher notes
Validate exposure against actual distribution source because the supplied version representation is ambiguous and vendors may backport fixes. Five Linux stable commits are referenced, apparently covering different maintained branches. No CWE is supplied. Public evidence in the bundle supports a denial-of-service panic but provides no exploit demonstration or active-exploitation claim.
Mitigation direction
Upgrade to a vendor-supported kernel containing the appropriate referenced Linux stable fix.
Check distribution security guidance for the exact fixed package version.
Temporarily avoid cross-system NTFS mounts involving different page sizes where operationally feasible.
Restrict untrusted users from supplying or mounting NTFS filesystems where feasible.
Validation and detection
Inventory systems using the NTFS3 driver and identify their running kernel versions.
Identify NTFS filesystems transferred between systems with different memory page sizes.
Confirm the installed kernel contains the applicable referenced stable commit or vendor backport.
Review kernel crash records for failures involving log_replay or read_log_page.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cve · low confidence lookup
CVE-2024-42299 mapping review
Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
We collect every scored CVSS vector available in the official CNA and ADP containers. When more than one version is present, the table keeps the source vectors side by side instead of collapsing them into the highest score.