CVE-2024-41014: xfs: add bounds checking to xlog_recover_process_data
In the Linux kernel, the following vulnerability has been resolved:
xfs: add bounds checking to xlog_recover_process_data
There is a lack of verification of the space occupied by fixed members
of xlog_op_header in the xlog_recover_process_data.
We can create a crafted image to trigger an out of bounds read by
following these steps:
1) Mount an image of xfs, and do some file operations to leave records
2) Before umounting, copy the image for subsequent steps to simulate
abnormal exit. Because umount will ensure that tail_blk and
head_blk are the same, which will result in the inability to enter
xlog_recover_process_data
3) Write a tool to parse and modify the copied image in step 2
4) Make the end of the xlog_op_header entries only 1 byte away from
xlog_rec_header->h_size
5) xlog_rec_header->h_num_logops++
6) Modify xlog_rec_header->h_crc
Fix:
Add a check to make sure there is sufficient space to access fixed members
of xlog_op_header.
Security readout for executives and security teams
Plain-English summary
A malformed XFS filesystem image can cause the Linux kernel to read beyond expected memory boundaries during log recovery. Successful triggering requires local interaction with a crafted image, but the stated impact includes serious confidentiality and availability risks. Systems processing untrusted XFS images deserve prompt review.
Executive priority
Prioritize remediation for forensic, virtualization, backup, recovery, hosting, and image-processing systems that handle untrusted disk images. For other Linux systems, schedule the vendor kernel update through normal high-severity patching. No source provided here supports emergency response for active exploitation.
Technical view
The XFS recovery function xlog_recover_process_data did not verify that enough record space remained before accessing fixed xlog_op_header members. A crafted recovery log can therefore trigger an out-of-bounds read. The published fix adds the missing bounds check. CVSS 3.1 is 7.1: local attack, low complexity, no privileges, user interaction required, with high confidentiality and availability impact.
Likely exposure
Exposure is most likely where affected Linux kernels mount or recover attacker-controlled, externally supplied, or otherwise untrusted XFS images. Ordinary systems that never process such images have a narrower attack surface. The supplied affected-version data spans older kernels through listed 6.x releases, but distribution backports make package-level verification necessary.
Exploitation context
The supplied record says this is not in CISA KEV and provides no evidence of active exploitation. Exploitation requires a specially altered XFS recovery log and user interaction involving the image. Treat public proof-of-concept or in-the-wild status as unconfirmed from these sources.
Researcher notes
The defect concerns validation of remaining log-record space before fixed xlog_op_header fields are read during XFS log recovery. Multiple Linux stable commits are referenced. Exact exposure should be mapped through distribution package histories because vendors may backport fixes without adopting upstream version numbers. The bundle does not identify a CWE or confirm exploitation.
Mitigation direction
Install a vendor-supported kernel containing the published XFS bounds-checking fix.
Review Linux distribution advisories for package-specific fixed versions and backports.
Restrict mounting of untrusted or externally supplied XFS filesystem images.
Prioritize systems that routinely inspect, recover, or mount customer-provided disk images.
Validation and detection
Inventory kernel versions on systems capable of mounting XFS filesystems.
Compare installed kernel packages with vendor advisories and package changelogs.
Confirm the applicable kernel source includes the xlog_recover_process_data bounds check.
Identify workflows accepting disk images from users, customers, or external automation.
After updating, verify systems boot normally and XFS workloads pass operational checks.
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-41014 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.