CVE-2026-43132

What it actually does

This is a local denial-of-service flaw in the Linux kernel device-mapper verity implementation, specifically in dm-verity forward error correction setup. When verity_fec_ctr() calls dm_bufio_client_create() and that allocation or initialization fails, the error pointer can later be passed to dm_bufio_client_destroy() as if it were a valid object. That invalid error-pointer dereference can trigger a kernel crash or panic, causing loss of availability for the affected system. The flaw does not provide confidentiality or integrity impact by itself and requires local access with sufficient ability to trigger dm-verity target setup paths.

Why it matters to the business

Successful exploitation can crash affected Linux systems, interrupting workloads, appliances, endpoints, containers, or embedded systems that rely on dm-verity for verified storage. The risk is primarily operational availability rather than data theft. The low EPSS score, lack of known exploited status, and no public exploit maturity indicate low current internet-scale exploitation likelihood, but systems where untrusted local users can interact with device-mapper or where automated provisioning repeatedly creates dm-verity devices may be more exposed.

How an attack unfolds

An attacker first obtains local access to an affected Linux system with privileges or delegated capabilities sufficient to interact with device-mapper verity target creation. They then attempt to create or manipulate a dm-verity configuration using forward error correction parameters in a way that causes dm_bufio_client_create() to fail, such as by exhausting relevant memory/resources or supplying conditions that force the constructor error path. Due to the bug, the kernel cleanup path later calls dm_bufio_client_destroy() on an ERR_PTR() value instead of a valid client pointer. This invalid pointer handling results in a kernel oops, panic, or crash, denying service to local users and workloads until the system recovers or is rebooted.

How to fix it

Upgrade to a Linux kernel build from the relevant distribution or vendor that includes the upstream fix for dm-verity handling of dm_bufio_client_create() failure in verity_fec_ctr(). No exact fixed package versions were provided, so use vendor advisories, kernel changelogs, and distribution security trackers to identify the corrected kernel for each supported platform. Where immediate patching is not possible, reduce exposure by limiting local shell access, restricting CAP_SYS_ADMIN and device-mapper access, preventing untrusted users or containers from creating device-mapper targets, and avoiding delegated access to dmsetup or equivalent storage management interfaces. Apply standard kernel hardening and ensure systems reboot into the patched kernel after installation.

How to confirm the fix worked

Confirm the running kernel, not just the installed package, has been updated to a vendor build containing the dm-verity fix. Validate with uname -a, package manager metadata, and vendor changelog references for the dm-verity FEC cleanup fix. Review whether untrusted users, containers, or automation have access to dmsetup, device-mapper control devices, CAP_SYS_ADMIN, or storage provisioning workflows. In test environments, verify dm-verity FEC setup failure paths no longer produce a kernel oops or panic. Confirm post-patch reboot completion and that the active kernel matches the expected fixed version.

Typical attack path

1. Gain local access to an affected Linux host.
2. Obtain or abuse privileges/capabilities that allow device-mapper target creation or manipulation.
3. Trigger dm-verity setup with forward error correction enabled.
4. Cause dm_bufio_client_create() to fail during verity_fec_ctr() initialization.
5. Kernel cleanup mishandles the error pointer and calls dm_bufio_client_destroy() incorrectly.
6. The system experiences a kernel oops, panic, crash, or forced reboot, resulting in denial of service.

How to detect it

Look for evidence of attempted or successful local denial-of-service through kernel logs, persistent journal logs, crash dumps, and audit records around device-mapper activity. Relevant sources include dmesg, /var/log/kern.log, /var/log/messages, journalctl -k, systemd-coredump or kdump/vmcore records, auditd logs for dmsetup execution, and container runtime logs showing privileged containers or CAP_SYS_ADMIN usage. Investigate kernel oops or panic events that mention dm-verity, verity_fec_ctr(), dm_bufio_client_create(), dm_bufio_client_destroy(), invalid pointer dereference, or device-mapper target construction failures. Correlate crashes with recent executions of dmsetup, cryptsetup, veritysetup, image verification tools, storage provisioning automation, or privileged container launches. Since no public exploit indicators or named threat actors are associated with this issue, detection should focus on crash artifacts and suspicious local device-mapper activity rather than network indicators.

• dm-verity
• verity_fec_ctr
• dm_bufio_client_create
• dm_bufio_client_destroy
• device-mapper: verity
• kernel BUG
• kernel panic
• Oops:
• BUG: unable to handle kernel
• general protection fault
• /dev/mapper/control
• dmsetup
• veritysetup
• cryptsetup
• CAP_SYS_ADMIN

What your security team should do

• Inventory Linux systems that use dm-verity, verified boot, immutable images, appliance-style deployments, or device-mapper based storage provisioning.
• Prioritize patching systems where local users, build agents, CI workloads, containers, or orchestration components can interact with device-mapper or hold CAP_SYS_ADMIN.
• Restrict access to /dev/mapper/control, dmsetup, and equivalent storage-management utilities to trusted administrators only.
• Review container and sandbox configurations to ensure untrusted workloads do not receive CAP_SYS_ADMIN or broad device access.
• Monitor for kernel oops, panic, or crash events referencing dm-verity, verity_fec_ctr, dm_bufio_client_create, or dm_bufio_client_destroy.
• Because this is not in KEV, has no known ransomware association, and has very low EPSS, handle as a normal kernel availability patch unless local multi-user exposure increases business risk.