CVE-2026-46115

What it actually does

This Linux kernel flaw is in the block layer logic that decides whether adjacent bio vector segments can be merged. The vulnerable code can incorrectly coalesce physically contiguous segments that belong to different dev_pagemap instances, causing the kernel to lose the correct page-to-pgmap association for the merged segment. In affected configurations using zone device memory or device-backed memory registered in multiple pgmap chunks, this can lead to incorrect memory accounting or handling in request merge, DMA mapping, or integrity paths. Depending on the surrounding driver and memory configuration, the impact may include kernel memory corruption, data integrity issues, denial of service through kernel crash, or potential privilege-impacting behavior. Although the assigned CVSS is critical, the description points to a kernel-internal memory handling issue that is likely configuration-dependent rather than a broadly exploitable remote service flaw.

Why it matters to the business

Systems running affected Linux kernels may be exposed to crashes, data corruption, or compromise of workloads that rely on block I/O paths involving device memory, persistent memory, CXL/device-dax-like configurations, or other zone device memory integrations. For organizations using Linux at scale, the operational risk is highest on storage-heavy, virtualization, HPC, AI/ML, database, and infrastructure platforms that use advanced memory or storage hardware. This issue is not listed in CISA KEV, is not known to be used in ransomware campaigns, has low EPSS, and has no reported exploit maturity, so remediation should be prioritized based on kernel exposure and use of relevant hardware features rather than treated as confirmed active exploitation.

How an attack unfolds

An attacker would need to cause the kernel to build a bio containing bvecs that cross dev_pagemap boundaries while appearing physically contiguous. If the vulnerable merge logic combines those bvecs, later block, DMA, or integrity handling can operate with an incorrect pgmap association. A practical exploit would likely require access to a code path that can submit crafted or attacker-influenced I/O involving zone device memory or device-backed pages, plus a platform configuration where multiple dev_pagemap chunks are present. The public description does not provide a weaponized exploit path, and there are no known named threat actors or campaigns associated with this issue. In realistic terms, exploitation is most plausible by a local attacker, malicious workload, compromised privileged process, or device/driver-facing path that can influence relevant I/O patterns, rather than by unauthenticated remote network traffic alone.

How to fix it

Upgrade to a kernel version that includes the fix adding a dev_pagemap equality check before merging zone device pages in biovec_phys_mergeable(). Because exact fixed versions were not provided, obtain patched kernel packages from the operating system vendor or kernel distribution and verify that the patch for the block-layer pgmap merge check is included. Where immediate patching is not possible, reduce exposure by limiting untrusted local workload execution on systems using zone device memory or device-backed memory, disabling or avoiding affected hardware/features where operationally feasible, and applying stricter workload isolation on systems with persistent memory, CXL, device-dax, HMM, or similar configurations. Reboot into the patched kernel after installation; simply installing kernel packages is not sufficient if the running kernel remains vulnerable.

How to confirm the fix worked

Confirm remediation by verifying the running kernel version, not only the installed package version, using standard OS tooling such as uname and vendor package inventory. Validate with the Linux vendor advisory or source package changelog that the running kernel contains the block-layer change preventing biovec merging across different dev_pagemap instances, commonly referenced by the addition of a zone_device_pages_have_same_pgmap() check in or near biovec_phys_mergeable(). On source-managed kernels, inspect the block-layer code or commit history to confirm the pgmap comparison is present. Also inventory systems for use of zone device memory, persistent memory, device-dax, CXL memory, HMM, or related drivers to determine whether vulnerable code paths are plausibly reachable.

Typical attack path

1. Identify a Linux system running an affected kernel with zone device memory, device-backed memory, or similar dev_pagemap-backed configurations.
2. Gain the ability to trigger or influence block I/O involving bvecs backed by pages from multiple dev_pagemap chunks.
3. Craft I/O patterns that place physically contiguous bvec segments from different pgmaps into the same bio.
4. Trigger request merge, DMA mapping, or integrity merge logic so the vulnerable biovec_phys_mergeable() path coalesces segments that should remain separate.
5. Abuse the resulting incorrect pgmap association to cause kernel instability, data corruption, or potentially more serious memory safety effects depending on the driver and kernel configuration.

How to detect it

There are no public, unique indicators proving exploitation from the vulnerability description alone. Detection should focus on evidence that the vulnerable kernel path was triggered or that resulting instability occurred. Review kernel logs, persistent journal logs, crash dumps, hypervisor host logs, storage subsystem logs, and hardware error logs on systems using dev_pagemap-backed memory. Look for kernel panics, oops reports, warnings, DMA mapping failures, block-layer merge errors, filesystem integrity errors, I/O corruption, unexpected device-dax or persistent-memory errors, and crashes referencing block bio handling, biovec merging, dev_pagemap, or zone device pages. If crash dumps are available, inspect stack traces for biovec_phys_mergeable(), bio_iov_iter_get_pages(), iov_iter_extract_bvecs(), blk_rq_merge, DMA mapping, or integrity merge paths. Correlate suspicious crashes with local workload activity, new container/VM deployments, storage stress tests, or access to device-memory-backed files/devices. Absence of these logs does not prove absence of exploitation because successful memory corruption may leave limited forensic artifacts.

• biovec_phys_mergeable
• zone_device_pages_have_same_pgmap
• bio_iov_iter_get_pages
• iov_iter_extract_bvecs
• page_pgmap
• dev_pagemap
• kernel BUG
• kernel NULL pointer dereference
• kernel panic
• Oops:
• WARNING: CPU:
• BUG: unable to handle page fault
• DMA-API:
• block integrity
• I/O error
• Buffer I/O error
• device-dax
• dax
• ZONE_DEVICE

What your security team should do

• Prioritize patching Linux systems that use advanced memory/storage features such as persistent memory, CXL/device memory, device-dax, HMM, or other zone device memory configurations.
• Verify the running kernel after maintenance windows; ensure systems have rebooted into the patched kernel.
• Ask Linux distribution vendors for the exact fixed kernel package versions if they are not already documented in advisories.
• For multi-tenant or untrusted workload platforms, restrict local code execution and device-memory access until patched.
• Monitor kernel logs for block-layer, DMA, memory-management, and filesystem integrity errors that may indicate triggering of the vulnerable path.
• Treat unexplained kernel panics or I/O corruption on systems using dev_pagemap-backed memory as potentially security-relevant until investigated.
• Because this issue is not KEV-listed and has low EPSS, balance urgency against asset criticality, but do not defer patching on systems with relevant hardware exposure.