U.S. flag   An official website of the United States government
Dot gov

Official websites use .gov
A .gov website belongs to an official government organization in the United States.

Https

Secure .gov websites use HTTPS
A lock (Dot gov) or https:// means you've safely connected to the .gov website. Share sensitive information only on official, secure websites.

National Vulnerability Database

National Vulnerability Database

NVD

National Vulnerability Database
  1. Vulnerabilities

CVE-2024-50250 Detail

Description

In the Linux kernel, the following vulnerability has been resolved: fsdax: dax_unshare_iter needs to copy entire blocks The code that copies data from srcmap to iomap in dax_unshare_iter is very very broken, which bfoster's recent fsx changes have exposed. If the pos and len passed to dax_file_unshare are not aligned to an fsblock boundary, the iter pos and length in the _iter function will reflect this unalignment. dax_iomap_direct_access always returns a pointer to the start of the kmapped fsdax page, even if its pos argument is in the middle of that page. This is catastrophic for data integrity when iter->pos is not aligned to a page, because daddr/saddr do not point to the same byte in the file as iter->pos. Hence we corrupt user data by copying it to the wrong place. If iter->pos + iomap_length() in the _iter function not aligned to a page, then we fail to copy a full block, and only partially populate the destination block. This is catastrophic for data confidentiality because we expose stale pmem contents. Fix both of these issues by aligning copy_pos/copy_len to a page boundary (remember, this is fsdax so 1 fsblock == 1 base page) so that we always copy full blocks. We're not done yet -- there's no call to invalidate_inode_pages2_range, so programs that have the file range mmap'd will continue accessing the old memory mapping after the file metadata updates have completed. Be careful with the return value -- if the unshare succeeds, we still need to return the number of bytes that the iomap iter thinks we're operating on.


Metrics

 
NVD enrichment efforts reference publicly available information to associate vector strings. CVSS information contributed by other sources is also displayed.
CVSS 4.0 Severity and Vector Strings:

NIST CVSS score
NIST: NVD
N/A
NVD assessment not yet provided.

References to Advisories, Solutions, and Tools

By selecting these links, you will be leaving NIST webspace. We have provided these links to other web sites because they may have information that would be of interest to you. No inferences should be drawn on account of other sites being referenced, or not, from this page. There may be other web sites that are more appropriate for your purpose. NIST does not necessarily endorse the views expressed, or concur with the facts presented on these sites. Further, NIST does not endorse any commercial products that may be mentioned on these sites. Please address comments about this page to nvd@nist.gov.

Hyperlink Resource
https://git.kernel.org/stable/c/50793801fc7f6d08def48754fb0f0706b0cfc394 Patch 
https://git.kernel.org/stable/c/8e9c0f500b42216ef930f5c0d1703989a451913d Patch 
https://git.kernel.org/stable/c/9bc18bb476e50e32e5d08f2734d63d63e0fa528c Patch 
https://git.kernel.org/stable/c/bdbc96c23197d773a7d1bf03e4f11de593b0ff28 Patch 

Weakness Enumeration

CWE-ID CWE Name Source
NVD-CWE-noinfo Insufficient Information cwe source acceptance level NIST  

Known Affected Software Configurations Switch to CPE 2.2

CPEs loading, please wait.

Denotes Vulnerable Software
Are we missing a CPE here? Please let us know.

Change History

2 change records found show changes

Quick Info

CVE Dictionary Entry:
CVE-2024-50250
NVD Published Date:
11/09/2024
NVD Last Modified:
11/14/2024
Source:
kernel.org