<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<rss xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/" version="2.0">
  <channel>
    <title>Most recent entries from all</title>
    <link>https://cve.radiocsirt.org</link>
    <description>Contains only the most 10 recent entries.</description>
    <docs>http://www.rssboard.org/rss-specification</docs>
    <generator>python-feedgen</generator>
    <language>en</language>
    <lastBuildDate>Wed, 07 Oct 2026 04:54:20 +0000</lastBuildDate>
    <item>
      <title>CVE-2022-48986 — mm/gup: fix gup_pud_range() for dax</title>
      <link>https://cve.radiocsirt.org/vuln/cve-2022-48986</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Linux&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;mm/gup: fix gup_pud_range() for dax&lt;/p&gt;
&lt;p&gt;For dax pud, pud_huge() returns true on x86. So the function works as long
as hugetlb is configured. However, dax doesn&amp;#39;t depend on hugetlb.
Commit 414fd080d125 (&amp;#34;mm/gup: fix gup_pmd_range() for dax&amp;#34;) fixed
devmap-backed huge PMDs, but missed devmap-backed huge PUDs. Fix this as
well.&lt;/p&gt;
&lt;p&gt;This fixes the below kernel panic:&lt;/p&gt;
&lt;p&gt;general protection fault, probably for non-canonical address 0x69e7c000cc478: 0000 [#1] SMP
	&amp;lt; snip &amp;gt;
Call Trace:
&amp;lt;TASK&amp;gt;
get_user_pages_fast+0x1f/0x40
iov_iter_get_pages+0xc6/0x3b0
? mempool_alloc+0x5d/0x170
bio_iov_iter_get_pages+0x82/0x4e0
? bvec_alloc+0x91/0xc0
? bio_alloc_bioset+0x19a/0x2a0
blkdev_direct_IO+0x282/0x480
? __io_complete_rw_common+0xc0/0xc0
? filemap_range_has_page+0x82/0xc0
generic_file_direct_write+0x9d/0x1a0
? inode_update_time+0x24/0x30
__generic_file_write_iter+0xbd/0x1e0
blkdev_write_iter+0xb4/0x150
? io_import_iovec+0x8d/0x340
io_write+0xf9/0x300
io_issue_sqe+0x3c3/0x1d30
? sysvec_reschedule_ipi+0x6c/0x80
__io_queue_sqe+0x33/0x240
? fget+0x76/0xa0
io_submit_sqes+0xe6a/0x18d0
? __fget_light+0xd1/0x100
__x64_sys_io_uring_enter+0x199/0x880
? __context_tracking_enter+0x1f/0x70
? irqentry_exit_to_user_mode+0x24/0x30
? irqentry_exit+0x1d/0x30
? __context_tracking_exit+0xe/0x70
do_syscall_64+0x3b/0x90
entry_SYSCALL_64_after_hwframe+0x61/0xcb
RIP: 0033:0x7fc97c11a7be
	&amp;lt; snip &amp;gt;
&amp;lt;/TASK&amp;gt;
---[ end trace 48b2e0e67debcaeb ]---
RIP: 0010:intern…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Linux&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;mm/gup: fix gup_pud_range() for dax&lt;/p&gt;
&lt;p&gt;For dax pud, pud_huge() returns true on x86. So the function works as long
as hugetlb is configured. However, dax doesn&amp;#39;t depend on hugetlb.
Commit 414fd080d125 (&amp;#34;mm/gup: fix gup_pmd_range() for dax&amp;#34;) fixed
devmap-backed huge PMDs, but missed devmap-backed huge PUDs. Fix this as
well.&lt;/p&gt;
&lt;p&gt;This fixes the below kernel panic:&lt;/p&gt;
&lt;p&gt;general protection fault, probably for non-canonical address 0x69e7c000cc478: 0000 [#1] SMP
	&amp;lt; snip &amp;gt;
Call Trace:
&amp;lt;TASK&amp;gt;
get_user_pages_fast+0x1f/0x40
iov_iter_get_pages+0xc6/0x3b0
? mempool_alloc+0x5d/0x170
bio_iov_iter_get_pages+0x82/0x4e0
? bvec_alloc+0x91/0xc0
? bio_alloc_bioset+0x19a/0x2a0
blkdev_direct_IO+0x282/0x480
? __io_complete_rw_common+0xc0/0xc0
? filemap_range_has_page+0x82/0xc0
generic_file_direct_write+0x9d/0x1a0
? inode_update_time+0x24/0x30
__generic_file_write_iter+0xbd/0x1e0
blkdev_write_iter+0xb4/0x150
? io_import_iovec+0x8d/0x340
io_write+0xf9/0x300
io_issue_sqe+0x3c3/0x1d30
? sysvec_reschedule_ipi+0x6c/0x80
__io_queue_sqe+0x33/0x240
? fget+0x76/0xa0
io_submit_sqes+0xe6a/0x18d0
? __fget_light+0xd1/0x100
__x64_sys_io_uring_enter+0x199/0x880
? __context_tracking_enter+0x1f/0x70
? irqentry_exit_to_user_mode+0x24/0x30
? irqentry_exit+0x1d/0x30
? __context_tracking_exit+0xe/0x70
do_syscall_64+0x3b/0x90
entry_SYSCALL_64_after_hwframe+0x61/0xcb
RIP: 0033:0x7fc97c11a7be
	&amp;lt; snip &amp;gt;
&amp;lt;/TASK&amp;gt;
---[ end trace 48b2e0e67debcaeb ]---
RIP: 0010:intern…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/cve-2022-48986</guid>
    </item>
  </channel>
</rss>
