https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Fri, 02 Oct 2026 14:33:40 +0000 https://cve.radiocsirt.org/vuln/bdu:2025-06980 bdu:2025-06980 https://cve.radiocsirt.org/vuln/bdu:2025-06980 https://cve.radiocsirt.org/vuln/bell-cve-2024-50250 <p><strong>Affected:</strong> Alpaquita:25: linux-lts, Alpaquita:stream: linux-lts</p> <p><strong>Affected:</strong> Alpaquita:25: linux-lts, Alpaquita:stream: linux-lts</p> https://cve.radiocsirt.org/vuln/bell-cve-2024-50250 https://cve.radiocsirt.org/vuln/certfr-2024-avi-1031 certfr-2024-avi-1031 https://cve.radiocsirt.org/vuln/certfr-2024-avi-1031 https://cve.radiocsirt.org/vuln/euvd-2026-346346 EUVD-2026-346346 https://cve.radiocsirt.org/vuln/euvd-2026-346346 https://cve.radiocsirt.org/vuln/fkie_cve-2024-50250 <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>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/fkie_cve-2024-50250 https://cve.radiocsirt.org/vuln/ghsa-prf6-fvr5-qhc9 <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>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/ghsa-prf6-fvr5-qhc9 https://cve.radiocsirt.org/vuln/msrc_cve-2024-50250 msrc_CVE-2024-50250 https://cve.radiocsirt.org/vuln/msrc_cve-2024-50250 https://cve.radiocsirt.org/vuln/oesa-2024-2446 <p><strong>Affected:</strong> openEuler:24.03-LTS: kernel</p> <p>The Linux Kernel, the operating system core itself. Security Fix(es): In the Linux kernel, the following vulnerability has been resolved: btrfs: zoned: fix use-after-free in do_zone_finish() Shinichiro reported the following use-after-free triggered by the device replace operation in fstests btrfs/070. BTRFS info (device nullb1): scrub: finished on devid 1 with status: 0 ================================================================== BUG: KASAN: slab-use-after-free in do_zone_finish+0x91a/0xb90 [btrfs] Read of size 8 at addr ffff8881543c8060 by task btrfs-cleaner/3494007 CPU: 0 PID: 3494007 Comm: btrfs-cleaner Tainted: G W 6.8.0-rc5-kts #1 Hardware name: Supermicro Super Server/X11SPi-TF, BIOS 3.3 02/21/2020 Call Trace: &amp;lt;TASK&amp;gt; dump_stack_lvl+0x5b/0x90 print_report+0xcf/0x670 ? __virt_addr_valid+0x200/0x3e0 kasan_report+0xd8/0x110 ? do_zone_finish+0x91a/0xb90 [btrfs] ? do_zone_finish+0x91a/0xb90 [btrfs] do_zone_finish+0x91a/0xb90 [btrfs] btrfs_delete_unused_bgs+0x5e1/0x1750 [btrfs] ? __pfx_btrfs_delete_unused_bgs+0x10/0x10 [btrfs] ? btrfs_put_root+0x2d/0x220 [btrfs] ? btrfs_clean_one_deleted_snapshot+0x299/0x430 [btrfs] cleaner_kthread+0x21e/0x380 [btrfs] ? __pfx_cleaner_kthread+0x10/0x10 [btrfs] kthread+0x2e3/0x3c0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x31/0x70 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1b/0x30 &amp;lt;/TASK&amp;gt; Allocated by task 3493983: kasan_save_stack+0x33/0…</p> <p><strong>Affected:</strong> openEuler:24.03-LTS: kernel</p> <p>The Linux Kernel, the operating system core itself. Security Fix(es): In the Linux kernel, the following vulnerability has been resolved: btrfs: zoned: fix use-after-free in do_zone_finish() Shinichiro reported the following use-after-free triggered by the device replace operation in fstests btrfs/070. BTRFS info (device nullb1): scrub: finished on devid 1 with status: 0 ================================================================== BUG: KASAN: slab-use-after-free in do_zone_finish+0x91a/0xb90 [btrfs] Read of size 8 at addr ffff8881543c8060 by task btrfs-cleaner/3494007 CPU: 0 PID: 3494007 Comm: btrfs-cleaner Tainted: G W 6.8.0-rc5-kts #1 Hardware name: Supermicro Super Server/X11SPi-TF, BIOS 3.3 02/21/2020 Call Trace: &amp;lt;TASK&amp;gt; dump_stack_lvl+0x5b/0x90 print_report+0xcf/0x670 ? __virt_addr_valid+0x200/0x3e0 kasan_report+0xd8/0x110 ? do_zone_finish+0x91a/0xb90 [btrfs] ? do_zone_finish+0x91a/0xb90 [btrfs] do_zone_finish+0x91a/0xb90 [btrfs] btrfs_delete_unused_bgs+0x5e1/0x1750 [btrfs] ? __pfx_btrfs_delete_unused_bgs+0x10/0x10 [btrfs] ? btrfs_put_root+0x2d/0x220 [btrfs] ? btrfs_clean_one_deleted_snapshot+0x299/0x430 [btrfs] cleaner_kthread+0x21e/0x380 [btrfs] ? __pfx_cleaner_kthread+0x10/0x10 [btrfs] kthread+0x2e3/0x3c0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x31/0x70 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1b/0x30 &amp;lt;/TASK&amp;gt; Allocated by task 3493983: kasan_save_stack+0x33/0…</p> https://cve.radiocsirt.org/vuln/oesa-2024-2446 https://cve.radiocsirt.org/vuln/opensuse-su-2024:14500-1 <p>kernel-devel-6.11.8-1.1 on GA media</p> <p>kernel-devel-6.11.8-1.1 on GA media</p> https://cve.radiocsirt.org/vuln/opensuse-su-2024:14500-1 https://cve.radiocsirt.org/vuln/suse-su-2024:4314-1 <p>Security update for the Linux Kernel</p> <p>Security update for the Linux Kernel</p> https://cve.radiocsirt.org/vuln/suse-su-2024:4314-1 https://cve.radiocsirt.org/vuln/ubuntu-cve-2024-50250 <p><strong>Affected:</strong> Ubuntu:16.04:LTS: linux-hwe-edge, Ubuntu:18.04:LTS: linux-aws-5.0, Ubuntu:18.04:LTS: linux-aws-5.3, Ubuntu:18.04:LTS: linux-azure, Ubuntu:18.04:LTS: linux-azure-5.3, Ubuntu:18.04:LTS: linux-azure-edge, Ubuntu:18.04:LTS: linux-gcp, Ubuntu:18.04:LTS: linux-gcp-5.3, Ubuntu:18.04:LTS: linux-gke-4.15, Ubuntu:18.04:LTS: linux-gke-5.4 and 101 more</p> <p>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&#39;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-&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. 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. 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&#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. Be careful with the return value -- if the unshare succeeds, we still need to return the num…</p> <p><strong>Affected:</strong> Ubuntu:16.04:LTS: linux-hwe-edge, Ubuntu:18.04:LTS: linux-aws-5.0, Ubuntu:18.04:LTS: linux-aws-5.3, Ubuntu:18.04:LTS: linux-azure, Ubuntu:18.04:LTS: linux-azure-5.3, Ubuntu:18.04:LTS: linux-azure-edge, Ubuntu:18.04:LTS: linux-gcp, Ubuntu:18.04:LTS: linux-gcp-5.3, Ubuntu:18.04:LTS: linux-gke-4.15, Ubuntu:18.04:LTS: linux-gke-5.4 and 101 more</p> <p>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&#39;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-&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. 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. 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&#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. Be careful with the return value -- if the unshare succeeds, we still need to return the num…</p> https://cve.radiocsirt.org/vuln/ubuntu-cve-2024-50250 https://cve.radiocsirt.org/vuln/wid-sec-w-2024-3397 <p>Ein lokaler Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um einen nicht näher spezifizierten Angriff durchzuführen.</p> <p>Ein lokaler Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um einen nicht näher spezifizierten Angriff durchzuführen.</p> https://cve.radiocsirt.org/vuln/wid-sec-w-2024-3397