CVE-2026-43248

What it actually does

This is a Linux kernel memory corruption flaw in the vhost/vDPA subsystem. A bounds check for vDPA group assignment was missing or inconsistently enforced, allowing a valid Address Space Identifier (ASID) to be assigned to a group index equal to the number of groups. Because valid indexes should be less than the group count, this can cause an out-of-bounds write in kernel memory, specifically in paths involving vhost_vdpa/vdpa_sim behavior. A local attacker with sufficient privileges to interact with the affected vhost/vDPA interfaces could potentially corrupt kernel memory, leading to privilege escalation, kernel crash, or arbitrary code execution in kernel context depending on exploitability and system configuration.

Why it matters to the business

Successful exploitation could allow a local user or compromised workload on an affected Linux system to gain elevated privileges, tamper with host integrity, access sensitive data, or crash the system. The risk is highest on hosts that expose or use vhost/vDPA functionality, such as virtualization, container, networking, or high-performance I/O environments. Although the EPSS score is low and there is no known KEV listing or public exploit maturity indicated, the CVSS severity is high because exploitation may provide full confidentiality, integrity, and availability impact once local access is obtained.

How an attack unfolds

An attacker first obtains local access to an affected Linux system, typically through a low-privileged account, compromised service, container escape prerequisite, or access to virtualization-related device interfaces. They then interact with vhost/vDPA functionality in a way that causes an ASID to be assigned to a vDPA group value equal to the configured group count. Because the affected code path fails to reject that boundary case, the kernel writes outside the intended bounds of the group array or associated structure. If the out-of-bounds write is controlled and reliable, the attacker may corrupt adjacent kernel memory to alter privileges or control kernel execution. If exploitation is less controlled, the likely result is a kernel oops, panic, or denial of service. No named threat actors or active exploitation campaigns are currently indicated for this vulnerability.

How to fix it

Upgrade to a Linux kernel version that includes the upstream fix consolidating vDPA group bounds checking in vhost_vdpa and correcting the vdpa_sim out-of-bounds write condition. Because no exact fixed package versions were provided, use the fixed kernel versions supplied by the relevant Linux distribution, appliance vendor, cloud image provider, or embedded platform maintainer. Prioritize systems using virtualization, vhost, vDPA, virtio, software vDPA simulation, or high-performance network/storage offload features. If immediate patching is not possible, reduce exposure by disabling unused vDPA/vhost functionality, unloading unnecessary modules such as vdpa_sim where operationally safe, restricting access to virtualization device nodes, limiting untrusted local shell access, and enforcing least privilege for users and workloads that can interact with kernel device interfaces. Reboot into the updated kernel after installation; merely installing kernel packages is insufficient if the vulnerable kernel remains running.

How to confirm the fix worked

Confirm the running kernel, not only the installed kernel package, has been updated to a vendor-fixed build. Validate with commands such as uname -a and the distribution package manager, then compare against the vendor advisory for this CVE. Check whether vhost/vDPA-related modules or devices are present using lsmod, modinfo, sysfs under /sys/bus/vdpa, and device nodes under /dev where applicable. Confirm that unused vdpa_sim or vhost_vdpa modules are not loaded if mitigation depends on disabling them. After remediation, reboot and verify the active kernel version again. For exposure validation, review whether local users, containers, virtualization services, or management agents have permissions to open vhost/vDPA device interfaces. In test environments, kernel sanitizers or vendor regression tests for vDPA group boundary handling can be used to confirm the boundary condition no longer causes an out-of-bounds write or kernel fault.

Typical attack path

1. Gain local access to an affected Linux host with the ability to reach relevant vhost/vDPA interfaces.
2. Identify whether the kernel includes the vulnerable vhost/vDPA or vdpa_sim code path and whether device permissions permit interaction.
3. Trigger ASID assignment using a group index equal to the number of configured vDPA groups.
4. Cause an out-of-bounds kernel memory write due to the missing boundary enforcement.
5. Use the memory corruption condition to attempt privilege escalation, kernel code execution, or denial of service.
6. Cover tracks by removing local tooling and relying on limited kernel logging unless a crash or sanitizer event occurs.

How to detect it

To determine whether exploitation may have already occurred, review kernel logs and system journals for memory corruption, kernel oops, panic, KASAN, UBSAN, or general protection fault messages involving vhost_vdpa, vdpa_sim, vDPA, virtio, or related drivers. Useful sources include journalctl -k, dmesg logs, /var/log/kern.log, /var/log/messages, crash dumps, kdump/vmcore artifacts, auditd records, endpoint telemetry, and hypervisor or virtualization management logs. Look for suspicious local processes opening vhost/vDPA device nodes, loading vdpa_sim or vhost_vdpa modules unexpectedly, changing device permissions, or running custom binaries shortly before a kernel crash. Because exploitation is local and may only leave evidence when it crashes or triggers kernel diagnostics, absence of logs does not prove non-exploitation. If a crash occurred, preserve the vmcore and symbolized kernel logs to determine whether the faulting instruction or stack trace involves vhost_vdpa, vdpa_sim, or vDPA group/ASID handling. No public exploit-specific network signature is currently derivable from the provided information.

• vhost_vdpa
• vdpa_sim
• /sys/bus/vdpa
• /dev/vhost-vdpa
• BUG: KASAN: out-of-bounds
• BUG: KASAN: slab-out-of-bounds
• BUG: KASAN: global-out-of-bounds
• kernel BUG at drivers/vdpa
• general protection fault
• Oops:
• Kernel panic - not syncing
• ASID
• ngroups
• modprobe vdpa_sim
• modprobe vhost_vdpa

What your security team should do

• Inventory Linux systems using virtualization, vhost, vDPA, virtio, network offload, or vdpa_sim functionality and prioritize them for kernel updates.
• Patch affected systems using vendor-provided fixed kernels and reboot to ensure the fixed kernel is active.
• Restrict local access and device-node permissions for interfaces associated with vhost/vDPA, especially on shared servers, virtualization hosts, CI runners, and multi-tenant workloads.
• Disable or unload unused vdpa_sim, vhost_vdpa, or related modules where operationally safe until patching is complete.
• Review kernel logs for crashes, KASAN reports, oops messages, or suspicious local activity involving vDPA/vhost interfaces.
• Treat unexpected kernel crashes on affected systems as potentially security-relevant and preserve logs, vmcores, and audit records for investigation.
• Monitor vendor advisories for exact fixed package versions, backports, and any change in exploit maturity or KEV status.