CVE-2022-48986

What it actually does

The vulnerability is an incomplete fix for handling device-map backed huge PUDs in get_user_pages_fast / gup_pud_range, allowing a general protection fault and kernel panic when DAX filesystems are accessed via direct I/O or io_uring without hugetlb configured.

Why it matters to the business

Systems using DAX storage with large page mappings may experience sudden kernel panics during write operations, leading to unplanned downtime for database, file server, or high-performance storage workloads; the issue has been public for over two years with no widespread exploitation observed.

How an attack unfolds

An attacker with local access triggers the bug by issuing direct writes or io_uring operations against a DAX-backed file that uses huge PUD mappings; the missing devmap check in gup_pud_range dereferences an invalid address, producing a fatal exception.

How to fix it

Update the Linux kernel to a version containing commit 8fe28cb58bcb235034b64cbbb7550a8a43fd88be or later; rebuild and reboot all affected systems; for environments that cannot immediately patch, restrict use of DAX with huge PUD mappings or disable direct I/O paths where feasible.

How to confirm the fix worked

Confirm the running kernel contains commit 8fe28cb58bcb235034b64cbbb7550a8a43fd88be via git log or uname output; attempt to reproduce the original panic scenario with DAX direct writes and verify the call trace no longer occurs.

Typical attack path

1. Obtain local code execution or shell access on a Linux system using DAX
2. Open a DAX file and prepare an iovec for direct or asynchronous I/O
3. Invoke io_uring or generic_file_direct_write that reaches gup_pud_range
4. Trigger the faulty pud_huge path resulting in non-canonical address fault and panic

How to detect it

Search kernel logs and crash dumps for the strings 'internal_get_user_pages_fast', 'gup_pud_range', 'general protection fault' combined with 'blkdev_direct_IO' or 'io_uring_enter'; examine any recent kernel panics on hosts using DAX.

What your security team should do

• Prioritize kernel upgrades on any production systems exposing DAX storage to untrusted local users
• Monitor for kernel panic reports matching the internal_get_user_pages_fast signature
• Review workloads using io_uring or O_DIRECT on DAX filesystems for exposure