CVE-2024-45026: s390/dasd: fix error recovery leading to data corruption on ESE devices
In the Linux kernel, the following vulnerability has been resolved:
s390/dasd: fix error recovery leading to data corruption on ESE devices
Extent Space Efficient (ESE) or thin provisioned volumes need to be
formatted on demand during usual IO processing.
The dasd_ese_needs_format function checks for error codes that signal
the non existence of a proper track format.
The check for incorrect length is to imprecise since other error cases
leading to transport of insufficient data also have this flag set.
This might lead to data corruption in certain error cases for example
during a storage server warmstart.
Fix by removing the check for incorrect length and replacing by
explicitly checking for invalid track format in transport mode.
Also remove the check for file protected since this is not a valid
ESE handling case.
Security readout for executives and security teams
Plain-English summary
A Linux storage-driver error can corrupt data on IBM s390 systems using Extent Space Efficient, or thin-provisioned, DASD volumes. During certain storage errors, including a storage-server warmstart, the kernel may mistake incomplete data for an unformatted track and handle it incorrectly. Systems not using this architecture and storage configuration are unlikely to be exposed.
Executive priority
Treat this as high priority where s390 workloads depend on ESE DASD because successful triggering may affect confidentiality, integrity, and availability. Schedule expedited kernel maintenance and data-integrity review. For environments without s390 ESE storage, document non-exposure rather than initiating broad emergency remediation.
Technical view
The s390 DASD ESE recovery logic imprecisely interpreted an incorrect-length flag as evidence that a track required formatting. Other transport failures can set the same flag, potentially triggering unsafe format-on-demand handling. The correction explicitly checks for invalid track format in transport mode and removes the inappropriate file-protected check.
Likely exposure
Exposure is narrow but consequential: Linux on s390 using DASD ESE or thin-provisioned volumes. The supplied record identifies affected kernel lines beginning with 5.3 and provides stable fixes across supported branches. Confirm distribution backports because kernel version numbers alone may not establish status.
Exploitation context
The CVSS vector requires local access, low privileges, and high attack complexity, with no user interaction. CISA KEV status is false in the supplied bundle, and no cited evidence establishes active exploitation. The documented trigger concerns particular storage error conditions, such as a storage-server warmstart, rather than ordinary remote attack traffic.
Researcher notes
The core flaw is an error-classification problem in dasd_ese_needs_format, not evidence of a general remote compromise path. The supplied data lacks confirmed attack reports and detailed prerequisites beyond the CVSS vector and storage scenario. Distribution backports may make apparent version comparisons misleading; verify the corrective commit or vendor package status.
Mitigation direction
Install the distribution-supported kernel update containing the applicable stable fix.
Consult the Linux distribution or platform vendor for branch-specific backport status.
Prioritize affected s390 hosts using ESE or thin-provisioned DASD storage.
Maintain verified backups and integrity controls until patched systems are validated.
Validation and detection
Inventory s390 Linux systems and identify DASD ESE or thin-provisioned volumes.
Record running kernel builds and compare them with vendor advisories or stable fix commits.
Confirm the updated kernel is running after maintenance, not merely installed.
Review storage warmstarts, DASD errors, and integrity alerts for possible corruption.
Perform application-consistent integrity checks on data exposed during relevant storage errors.
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-45026 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.