{"vulnerability": "CVE-2024-50250", "sightings": [{"uuid": "a2049913-3a57-4056-baa1-b7097288b5d4", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-50250", "type": "seen", "source": "https://infosec.exchange/users/cve/statuses/113453018614318747", "content": "", "creation_timestamp": "2024-11-09T12:34:40.043136Z"}, {"uuid": "712a589c-c5be-4db1-b79f-5eac2d0a4efe", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-50250", "type": "seen", "source": "https://t.me/cvedetector/10333", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-50250 - Linux Kernel Fsdax Data Integrity Corrupting Vulnerability\", \n  \"Content\": \"CVE ID : CVE-2024-50250 \nPublished : Nov. 9, 2024, 11:15 a.m. | 40\u00a0minutes ago \nDescription : 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. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"09 Nov 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-11-09T13:18:33.000000Z"}]}