CVE - CVE-2024-50250

CVE-ID
CVE-2024-50250	Learn more at National Vulnerability Database (NVD) • CVSS Severity Rating • Fix Information • Vulnerable Software Versions • SCAP Mappings • CPE Information
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.
References
Note: References are provided for the convenience of the reader to help distinguish between vulnerabilities. The list is not intended to be complete.
MISC:https://git.kernel.org/stable/c/50793801fc7f6d08def48754fb0f0706b0cfc394 URL:https://git.kernel.org/stable/c/50793801fc7f6d08def48754fb0f0706b0cfc394 MISC:https://git.kernel.org/stable/c/8e9c0f500b42216ef930f5c0d1703989a451913d URL:https://git.kernel.org/stable/c/8e9c0f500b42216ef930f5c0d1703989a451913d MISC:https://git.kernel.org/stable/c/9bc18bb476e50e32e5d08f2734d63d63e0fa528c URL:https://git.kernel.org/stable/c/9bc18bb476e50e32e5d08f2734d63d63e0fa528c MISC:https://git.kernel.org/stable/c/bdbc96c23197d773a7d1bf03e4f11de593b0ff28 URL:https://git.kernel.org/stable/c/bdbc96c23197d773a7d1bf03e4f11de593b0ff28
Assigning CNA
kernel.org
Date Record Created
20241021	Disclaimer: The record creation date may reflect when the CVE ID was allocated or reserved, and does not necessarily indicate when this vulnerability was discovered, shared with the affected vendor, publicly disclosed, or updated in CVE.
Phase (Legacy)
Assigned (20241021)
Votes (Legacy)

Comments (Legacy)

Proposed (Legacy)
N/A
This is an record on the CVE List, which provides common identifiers for publicly known cybersecurity vulnerabilities.
Search CVE Using Keywords: You can also search by reference using the CVE Reference Maps.
For More Information: CVE Request Web Form (select "Other" from dropdown)