CVE-2022-48986

mm/gup: fix gup_pud_range() for dax

MEDIUM

5.5

CVSS Score

Published: October 21, 2024 at 08:06 PM UTC

Updated: August 5, 2026 at 09:24 AM UTC

1 product affected across 1 vendorLinux Kernel

Using Linux by Linux?

Get instant alerts when new vulnerabilities affect Linux - before attackers find them.

Real-time alertsTrack your software stackFree plan available

Start Free Sign In

Severity

MEDIUM5.5

Exploit prediction

EPSS 0.3%

SSVC

No known exploit

Description

In the Linux kernel, the following vulnerability has been resolved: mm/gup: fix gup_pud_range() for dax For dax pud, pud_huge() returns true on x86. So the function works as long as hugetlb is configured. However, dax doesn't depend on hugetlb. Commit 414fd080d125 ("mm/gup: fix gup_pmd_range() for dax") fixed devmap-backed huge PMDs, but missed devmap-backed huge PUDs. Fix this as well. This fixes the below kernel panic: general protection fault, probably for non-canonical address 0x69e7c000cc478: 0000 [#1] SMP < snip > Call Trace: <TASK> 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 < snip > </TASK> ---[ end trace 48b2e0e67debcaeb ]--- RIP: 0010:internal_get_user_pages_fast+0x340/0x990 < snip > Kernel panic - not syncing: Fatal exception Kernel Offset: disabled

Affected

Our own answer: ranges merged, affected separated from platform-only, with confidence and review flags.

Linux Kernel · Linux

95%

v ≥ 4.14.108v ≥ 4.19.31v ≥ 4.9.1654.14.108 ≤ v < 4.154.19.31 ≤ v < 4.204.9.165 ≤ v < 4.105.0 ≤ v < 5.10.1595.0 ≤ v < 5.15.835.0 ≤ v < 5.4.2275.0 ≤ v < 6.0.135.0 ≤ v < 6.15.11 ≤ v < 5.15.835.16 ≤ v < 6.0.135.5 ≤ v < 5.10.1594.14.108 4.19.31 4.9.165414fd080d125408cb15d04ff4907e1dd8145c8c7538162d21ac877b060dc057c89f13718f5caffc56.1 rc1 6.1 rc2 6.1 rc3 6.1 rc4 6.1 rc5 6.1 rc6 6.1 rc7 6.1 rc88b1a7762e0dac5db42a003009fdcb425f10baa07c133d8eb894cb280f331608c6f1962ba9fbfe6b0

Vendor states this is fixed in 04edfa3dc06ecfc6133a33bc7271298782dee875 (fixed)

Vendor states this is fixed in 3ac29732a2ffa64c7de13a072b0f2848b9c11037 (fixed)

Vendor states this is fixed in e06d13c36ded750c72521b600293befebb4e56c5 (fixed)

Vendor states this is fixed in f1cf856123ceb766c49967ec79b841030fa1741f (fixed)

Vendor states this is fixed in fcd0ccd836ffad73d98a66f6fea7b16f735ea920 (fixed)

Affected range stops below 4.10, so it looks safe — our inference, not a vendor statement

Affected range stops below 4.15, so it looks safe — our inference, not a vendor statement

Affected range stops below 4.20, so it looks safe — our inference, not a vendor statement

Vendor states this is fixed in 5.0 (unaffected)

Vendor states this is fixed in 5.10.159 (unaffected)

Vendor states this is fixed in 5.15.83 (unaffected)

Vendor states this is fixed in 5.4.227 (unaffected)

Vendor states this is fixed in 6.0.13 (unaffected)

Vendor states this is fixed in 6.1 (unaffected)

Remediation

No guide yet

No remediation guidance has been written for this CVE yet. What the record does show:

Patch and advisory references