CVE-2024-50250

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