https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Thu, 08 Oct 2026 02:59:40 +0000 https://cve.radiocsirt.org/vuln/cve-2024-50250 <p><strong>Affected:</strong> Linux</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>fsdax: dax_unshare_iter needs to copy entire blocks</p> <p>The code that copies data from srcmap to iomap in dax_unshare_iter is very very broken, which bfoster&#39;s recent fsx changes have exposed.</p> <p>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.</p> <p>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-&gt;pos is not aligned to a page, because daddr/saddr do not point to the same byte in the file as iter-&gt;pos. Hence we corrupt user data by copying it to the wrong place.</p> <p>If iter-&gt;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.</p> <p>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.</p> <p>We&#39;re not done yet -- there&#39;s no call to invalidate_inode_pages2_range, so programs that have the file range mmap&#39;d will continue accessing the old memory mapping after the file metadata updates have completed.</p> <p>Be careful with the return value -- if the unshare succeeds, we still need to return…</p> <p><strong>Affected:</strong> Linux</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>fsdax: dax_unshare_iter needs to copy entire blocks</p> <p>The code that copies data from srcmap to iomap in dax_unshare_iter is very very broken, which bfoster&#39;s recent fsx changes have exposed.</p> <p>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.</p> <p>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-&gt;pos is not aligned to a page, because daddr/saddr do not point to the same byte in the file as iter-&gt;pos. Hence we corrupt user data by copying it to the wrong place.</p> <p>If iter-&gt;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.</p> <p>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.</p> <p>We&#39;re not done yet -- there&#39;s no call to invalidate_inode_pages2_range, so programs that have the file range mmap&#39;d will continue accessing the old memory mapping after the file metadata updates have completed.</p> <p>Be careful with the return value -- if the unshare succeeds, we still need to return…</p> https://cve.radiocsirt.org/vuln/cve-2024-50250