CVE-2026-89596

What it actually does

An off-by-one in the Linux kernel forcedeth (NVIDIA nForce Ethernet) driver causes nv_suspend() and nv_resume() to iterate one u32 past saved_config_space and past the ioremap'd MMIO window (base + register_size). That produces an out-of-bounds array access (adjacent to name_rx), a stray MMIO read on suspend, and a stray MMIO writel() on resume. With CONFIG_UBSAN_TRAP the access becomes a kernel trap that aborts the running path; otherwise it is a local integrity and availability defect in the power-management path. Confidentiality is not affected. VER3 devices index one past a 385-element u32 array; VER1/VER2 stay inside the array but still touch one dword past their mapped BAR window.

Why it matters to the business

Systems using the in-tree forcedeth NIC can fail, hang, or panic during sleep/wake (S3) instead of completing suspend/resume, causing downtime, lost in-flight work, and unstable networking after resume. Impact is concentrated on older NVIDIA MCP Ethernet hardware (for example MCP79-class machines), not modern NVIDIA GPUs or most cloud fleets. Exploitation maturity is none, EPSS remains ~0.0018 and flat over 30 days, the CVE is not in CISA KEV, and it is not associated with ransomware, so organizational urgency is patch-in-cycle rather than emergency unless hosts frequently suspend or run UBSAN_TRAP kernels. Published about five weeks ago with no named threat-actor use.

How an attack unfolds

A local, low-privileged user on a machine whose Ethernet is bound to forcedeth needs the suspend/resume code to run. They either wait for a normal sleep cycle or induce power management (for example writing a sleep state if policy allows). pci_pm_suspend calls nv_suspend, which walks non-PCI config with a <= bound and reads one dword past the mapped registers into/beyond saved_config_space; pci_pm_resume's matching loop writes that extra dword to base+0x604 (or one dword past smaller VER1/VER2 windows). Adjacent name_rx is notionally in the overflow slot but is rewritten before request_irq, so practical attacker-controlled corruption is limited; the reliable outcomes are UBSAN reports, a kernel trap when UBSAN_TRAP is on, or undefined MMIO side effects that can panic or corrupt device state. There is no remote entry, no known in-the-wild exploit, and no public exploit maturity.

How to fix it

Apply the upstream forcedeth fix that changes both save/restore loops from <= to < so exactly register_size bytes are copied, then deploy a kernel (or distro package) that includes that change. If a patched kernel is not yet available, avoid deep S3/suspend-to-RAM on forcedeth hosts, or unload/blacklist forcedeth only when that NIC is unused and an alternate interface exists. Do not rely on rewriting name_rx as a fix; the defect is the OOB access and unmapped MMIO. Track vendor kernel advisories for the exact stable-tree commit and package versions as they are published; no per-product fixed versions were supplied with this record.

How to confirm the fix worked

After patching, confirm the running kernel contains the forcedeth change (loop condition is i < np->register_size/sizeof(u32) in both nv_suspend and nv_resume) via package changelog, git log, or disassembly of the module. On a non-production host with the same NVIDIA MCP NIC, perform repeated S3 cycles with CONFIG_UBSAN and dmesg/journal collection; a fixed kernel must not report array-index-out-of-bounds at forcedeth.c suspend/resume lines and must not trap. Inventory exposure with lsmod, sysfs driver links, and PCI IDs bound to forcedeth. Unpatched UBSAN kernels typically report the issue only on the first suspend/resume after module load (source_location suppression), so a single clean cycle is not proof on older builds.

Typical attack path

1. Obtain local (non-remote) access on a Linux host whose NIC is driven by forcedeth (NVIDIA MCP/nForce Ethernet).
2. Confirm the forcedeth module is loaded and the device is a VER1/VER2/VER3 part that programs register_size and ioremaps only that window.
3. Trigger or wait for a PCI power-management suspend (deep S3 or equivalent), so nv_suspend runs the off-by-one save loop.
4. Allow resume so nv_resume performs the matching extra MMIO writel past the mapped BAR.
5. Rely on the out-of-bounds access, UBSAN_TRAP abort, or stray MMIO to crash the kernel or disrupt the NIC rather than achieve reliable code execution.

How to detect it

This is a local power-management bug, not a network worm; look for evidence of the OOB access during suspend/resume rather than C2. Search kernel logs (dmesg, journald, serial/console, crash dumps, pstore) for UBSAN array-index-out-of-bounds in drivers/net/ethernet/nvidia/forcedeth.c, especially around the historical suspend/resume line numbers, with a call chain through pci_pm_suspend, pci_pm_resume, dpm_run_callback, and device_suspend. Index 385 vs type u32 [385] is the VER3 signature. UBSAN reports each source location only once per module load, so later S3 cycles may be silent even if the access still happens—correlate with forcedeth loaded and S3 around the same time. Panic/oops with forcedeth on the stack during PM transitions, unexplained NIC loss after resume, or MMIO faults just past the BAR mapping are additional artifacts. No named APT campaigns or ransomware use are associated, so do not expect unique malware hashes.

• UBSAN: array-index-out-of-bounds in drivers/net/ethernet/nvidia/forcedeth.c
• index 385 is out of range for type 'u32 [385]'
• drivers/net/ethernet/nvidia/forcedeth.c:6225
• drivers/net/ethernet/nvidia/forcedeth.c:6240
• __ubsan_handle_out_of_bounds
• forcedeth
• pci_pm_suspend
• pci_pm_resume
• nv_suspend
• nv_resume

What your security team should do

• Inventory Linux hosts whose Ethernet is bound to forcedeth and prioritize those that use S3/suspend or UBSAN_TRAP kernels.
• Schedule kernel updates that include the forcedeth off-by-one fix; this is not a KEV/emergency item given EPSS ~0.0018, no known exploits, and local-only attack.
• Until patched, reduce suspend/resume on affected NICs and alert on forcedeth UBSAN or panic traces during pci_pm_suspend/pci_pm_resume.
• Do not treat this as ransomware or APT-driven; keep it in the normal kernel patch cadence unless you have many legacy NVIDIA MCP endpoints.
• Verify the related 2012 nv_get_regs() overflow fix is also present so all three register-walk sites are consistent.