{"cve":"CVE-2024-50250","nvd":{"published":"2024-11-09T11:15:10.833","modified":"2026-08-04T11:21:36.767","status":"Modified","description":"In the Linux kernel, the following vulnerability has been resolved:\n\nfsdax: dax_unshare_iter needs to copy entire blocks\n\nThe code that copies data from srcmap to iomap in dax_unshare_iter is\nvery very broken, which bfoster's recent fsx changes have exposed.\n\nIf the pos and len passed to dax_file_unshare are not aligned to an\nfsblock boundary, the iter pos and length in the _iter function will\nreflect this unalignment.\n\ndax_iomap_direct_access always returns a pointer to the start of the\nkmapped fsdax page, even if its pos argument is in the middle of that\npage.  This is catastrophic for data integrity when iter->pos is not\naligned to a page, because daddr/saddr do not point to the same byte in\nthe file as iter->pos.  Hence we corrupt user data by copying it to the\nwrong place.\n\nIf iter->pos + iomap_length() in the _iter function not aligned to a\npage, then we fail to copy a full block, and only partially populate the\ndestination block.  This is catastrophic for data confidentiality\nbecause we expose stale pmem contents.\n\nFix both of these issues by aligning copy_pos/copy_len to a page\nboundary (remember, this is fsdax so 1 fsblock == 1 base page) so that\nwe always copy full blocks.\n\nWe're not done yet -- there's no call to invalidate_inode_pages2_range,\nso programs that have the file range mmap'd will continue accessing the\nold memory mapping after the file metadata updates have completed.\n\nBe careful with the return value -- if the unshare succeeds, we still\nneed to return the number of bytes that the iomap iter thinks we're\noperating on.","cvss_v4":null,"cvss_v3":{"version":"3.1","vector":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N","score":7.1},"cwes":[],"references":["https://git.kernel.org/stable/c/50793801fc7f6d08def48754fb0f0706b0cfc394","https://git.kernel.org/stable/c/8e9c0f500b42216ef930f5c0d1703989a451913d","https://git.kernel.org/stable/c/9bc18bb476e50e32e5d08f2734d63d63e0fa528c","https://git.kernel.org/stable/c/bdbc96c23197d773a7d1bf03e4f11de593b0ff28","https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html"],"products":["linux:linux_kernel"],"source":"nvd","synced_at":"2026-10-19T21:57:07.693694550+00:00"},"epss":{"cve":"CVE-2024-50250","score":0.00228,"percentile":0.13665,"date":"2026-11-01"},"kev":null,"osv":[],"attribution":["This product uses the NVD API but is not endorsed or certified by the NVD.","EPSS scores: FIRST Exploit Prediction Scoring System, https://www.first.org/epss","Known exploited vulnerabilities: CISA Known Exploited Vulnerabilities Catalog, https://www.cisa.gov/known-exploited-vulnerabilities-catalog","Package advisories: OSV (https://osv.dev), from the GitHub Advisory Database, PyPA, Go, RustSec and other ecosystem databases, under CC-BY 4.0 or CC0","CVE records: the CVE Program's CVE List (https://www.cve.org), under its terms of use (https://www.cve.org/Legal/TermsOfUse). CVE is a registered trademark of The MITRE Corporation; this product is not affiliated with the CVE Program."]}