CVE-2026-31464

What it actually does

This vulnerability is an out-of-bounds kernel memory access in the Linux kernel IBM Virtual Fibre Channel driver, ibmvfc. A malicious or compromised Virtual I/O Server can return an excessive num_written value in a discover-targets response. The guest kernel stores that value as the target count without validating it against the allocated buffer size, then later iterates past the end of the DMA-coherent discovery buffer. The out-of-bounds data can be copied into subsequent management datagrams sent back to the VIO server, causing kernel memory disclosure. Depending on memory layout and runtime conditions, the invalid access may also destabilize the guest kernel and cause a crash or denial of service.

Why it matters to the business

Organizations running Linux guests that use IBM Power Virtual I/O / Virtual Fibre Channel are exposed if the VIO server or virtualization control path is malicious, compromised, or misconfigured. Successful exploitation could leak sensitive kernel memory from guest systems to the VIO server and may also disrupt storage connectivity or crash affected guests, affecting availability of workloads that depend on virtual Fibre Channel storage. The CVSS score is high, but EPSS is currently low and there is no known CISA KEV listing or public exploit maturity in the provided data, so remediation should be prioritized for IBM Power environments using ibmvfc rather than treated as broadly internet-exploitable.

How an attack unfolds

An attacker first needs control over, or the ability to influence, the VIO server that services an affected Linux guest using the ibmvfc driver. During virtual Fibre Channel target discovery, the guest sends a discovery request and expects a bounded list of targets. The malicious VIO server returns a response where num_written is larger than the guest driver's max_targets allocation. The vulnerable driver trusts that value and saves it as the number of discovered targets. Later, while allocating or initializing targets, the driver loops using the attacker-controlled count and reads entries beyond the allocated discovery buffer. Those out-of-bounds bytes are incorporated into Implicit Logout and PLOGI management datagrams sent back to the VIO server, allowing the attacker-controlled VIO server to receive leaked kernel memory. If the out-of-bounds access touches invalid or sensitive memory regions, the guest may also log kernel memory errors, storage driver failures, or crash.

How to fix it

Upgrade to a Linux kernel version that includes the ibmvfc fix that clamps num_written to max_targets before storing or using it. If vendor-specific fixed package versions are not yet identified, track and apply the relevant kernel updates from the operating system vendor for the IBM Virtual Fibre Channel / ibmvfc driver. Reboot affected systems after kernel upgrade unless using a vendor-supported live patch that explicitly covers this flaw. Where immediate patching is not possible, reduce exposure by limiting use of ibmvfc to trusted VIO servers, hardening and patching VIO servers, restricting administrative access to virtualization management planes, and migrating critical guests away from untrusted or shared VIO paths where feasible. Disabling the ibmvfc driver or removing virtual Fibre Channel devices mitigates exposure only if those storage paths are not required for operations.

How to confirm the fix worked

Confirm whether systems load or use the ibmvfc driver by checking loaded modules, kernel configuration, device inventory, and boot logs. Validate remediation by verifying the running kernel package includes the vendor fix for this issue, not merely that an updated package is installed but not booted. After patching and rebooting, confirm the running kernel version matches the fixed vendor advisory and that ibmvfc remains stable during Fibre Channel discovery. For deeper validation in test environments, enable kernel debugging, KASAN, or driver tracing and verify that oversized discovery response counts are rejected or clamped rather than used as loop bounds. Also review VIO server trust boundaries and confirm only authorized administrators can manage or modify virtual Fibre Channel behavior.

Typical attack path

1. Gain administrative control of, compromise, or otherwise manipulate the IBM Virtual I/O Server or virtual Fibre Channel response path for an affected Linux guest.
2. Wait for or trigger an ibmvfc target discovery operation from the Linux guest.
3. Return a crafted discover-targets MAD response with num_written greater than max_targets.
4. Cause the guest kernel to store the oversized value as vhost->num_targets without clamping.
5. Allow ibmvfc_alloc_targets() or related target initialization logic to iterate past the allocated disc_buf[] entries.
6. Receive subsequent Implicit Logout or PLOGI MADs from the guest that contain data read from outside the intended buffer.
7. Use the leaked kernel memory for information disclosure and potentially to support follow-on attacks, or trigger guest instability through repeated malformed responses.

How to detect it

Retrospective detection is difficult because the core exploit primitive is a malformed virtual Fibre Channel management response and the leaked data is returned through low-level VIO/ibmvfc traffic that is not typically logged in full. Start by identifying guests that use the ibmvfc driver, then review guest kernel logs for ibmvfc discovery anomalies, SCSI transport errors, kernel warnings, KASAN out-of-bounds reports, oopses, panics, DMA allocation errors, or repeated target discovery failures. Correlate those events with VIOS administrative logs, hypervisor management audit logs, virtual Fibre Channel configuration changes, and any unusual maintenance or login activity on VIO servers. In environments with kernel tracing, crash dumps, or centralized journald/syslog collection, search for references to ibmvfc functions and out-of-bounds memory reports. If packet or trace-level VIO instrumentation exists, look for discover-targets responses where num_written exceeds the negotiated or allocated max_targets value. Absence of logs does not rule out exploitation, because a controlled leak may produce no visible guest-side artifact.

• ibmvfc
• ibmvfc_discover_targets_done
• ibmvfc_alloc_targets
• num_written
• max_targets
• disc_buf
• Implicit Logout
• PLOGI
• MAD response
• discover targets
• BUG: KASAN: out-of-bounds
• KASAN: slab-out-of-bounds
• KASAN: use-after-free
• kernel BUG at
• Oops:
• Kernel panic
• scsi: ibmvfc
• ibmvfc:
• DMA-coherent
• vhost->num_targets

What your security team should do

• Prioritize inventory of Linux systems running on IBM Power environments with Virtual I/O / Virtual Fibre Channel and the ibmvfc driver enabled.
• Patch affected Linux kernels through the relevant distribution or appliance vendor channel, and ensure systems are rebooted into the fixed kernel.
• Treat VIO servers as high-trust infrastructure: review administrative access, recent changes, authentication logs, and patch levels for VIOS and virtualization management components.
• If patching must be delayed, isolate affected guests to trusted VIO servers and restrict who can administer the virtual Fibre Channel configuration.
• Monitor Linux guest kernel logs for ibmvfc, SCSI, DMA, KASAN, oops, panic, or unexplained storage-path instability events.
• Monitor VIO server logs and management activity for unexpected changes to virtual Fibre Channel mappings or behavior around the time of guest discovery events.
• Because EPSS is low and no public exploitation is indicated in the provided data, focus first on environments where VIO server compromise would expose high-value or regulated workloads rather than broad emergency response across unrelated Linux systems.