CVE-2026-45891

What it actually does

This is a Linux kernel memory-corruption flaw in the hns3 network driver affecting ring-parameter reconfiguration. During transmit ring setup, the driver can leave a stale tx_spare pointer in the original ring structure after preserving it for rollback. If a later allocation failure occurs, cleanup logic can free the same backup buffer twice. A successful trigger can corrupt kernel heap state, potentially causing a denial of service through kernel panic and, depending on allocator state and exploit reliability, could contribute to local privilege escalation or arbitrary kernel memory manipulation. The CVSS vector indicates local access with low attack complexity and low privileges, with no user interaction required.

Why it matters to the business

Systems using affected Linux kernels with the hns3 network driver may be exposed to local attacks that can crash the host or potentially allow an authenticated local user or compromised workload with sufficient network-configuration capability to gain elevated control. The most likely operational consequence is service disruption on physical or virtual infrastructure using supported hns3 hardware, but the high confidentiality, integrity, and availability impact means this should be treated as important for multi-user systems, container hosts, virtualization nodes, and servers where local privilege boundaries matter. EPSS is currently low and the issue is not listed in CISA KEV, so broad active exploitation is not indicated, but kernel memory-corruption flaws should still be remediated through normal kernel patch cycles.

How an attack unfolds

An attacker first obtains local access to a Linux system running an affected kernel and using the hns3 driver. They then cause the driver to execute the ring-parameter change path, commonly associated with network ring reconfiguration operations. The vulnerable path creates a rollback copy of ring state but leaves tx_spare in the active ring pointing to backup memory. If the attacker can force or race the setup path into an allocation failure, the error cleanup code treats the stale pointer as newly allocated memory and frees it again. This double free corrupts kernel heap allocator metadata or object state. In simple cases this results in a kernel crash; in more advanced scenarios, careful heap shaping could potentially turn the memory corruption into privilege escalation. No public exploit maturity is reported in the provided data, and exploitation is likely constrained by the need for local access, relevant driver exposure, and a controllable failure path.

How to fix it

Upgrade to a Linux kernel build that includes the hns3 driver fix clearing tx_spare when new tx_spare creation fails. Because exact fixed versions were not provided, use the fixed kernel versions supplied by the relevant Linux distribution, hardware vendor, cloud image provider, or kernel stable branch. Where immediate patching is not possible, reduce exposure by limiting local shell access, restricting CAP_NET_ADMIN and equivalent network-administration privileges, preventing untrusted containers from managing host network interfaces, and disabling or unloading the hns3 driver only if the hardware is not required. Avoid treating configuration restrictions as a permanent fix because the root issue is in kernel memory management.

How to confirm the fix worked

Confirm the running kernel package includes the vendor patch for the hns3 tx_spare double-free fix. Validate that the installed and booted kernel versions match the remediated package, since installing a kernel update is insufficient until the system is rebooted into it. Check whether the hns3 driver is present or loaded with commands such as lsmod, modinfo, or distribution package inventory tools. On systems with source or debug symbol access, confirm the hns3_set_ringparam() error path clears tx_spare appropriately. After remediation, perform a controlled reboot and verify that no affected older kernel remains selected as the default boot entry. If hns3 hardware is not present and the module is not loadable, practical exposure is substantially reduced, though kernel package remediation is still recommended.

Typical attack path

1. Gain local access to a Linux host running an affected kernel with the hns3 network driver loaded or available.
2. Obtain the ability to invoke network interface ring-parameter changes, such as through privileged network administration capabilities.
3. Trigger hns3 ring reconfiguration through the vulnerable hns3_set_ringparam() path.
4. Induce or wait for an allocation failure during hns3_init_all_ring() setup.
5. Cause the error cleanup path to free a stale tx_spare pointer, producing a double free.
6. Use the resulting kernel memory corruption to crash the system or attempt local privilege escalation.

How to detect it

Retrospective detection should focus on signs of attempted ring reconfiguration followed by kernel allocator errors or crashes. Review kernel logs, system journal, crash dumps, audit logs, sudo logs, and endpoint telemetry. Relevant log sources include journalctl -k, /var/log/kern.log, /var/log/messages, /var/crash, kdump/vmcore records, auditd execve events, and shell history where available. Look for hns3 driver messages close in time to ethtool ring-parameter changes, especially commands resembling ethtool -G or other interface tuning operations. Kernel memory-corruption evidence may appear as double-free, use-after-free, slab corruption, KASAN reports, general protection faults, kernel BUG/Oops messages, panic traces, or crashes with stack frames referencing hns3_set_ringparam(), hns3_init_all_ring(), or hns3 ring allocation/free routines. Because no known threat actors or public exploit artifacts were provided, detection should be behavior- and crash-artifact based rather than relying on network IOCs.

• hns3_set_ringparam
• hns3_init_all_ring
• tx_spare
• hns3
• ethtool -G
• KASAN: double-free
• double free
• Double free
• kernel BUG at mm/slub.c
• BUG: kernel NULL pointer dereference
• general protection fault
• slab corruption
• corrupted double-linked list
• kernel panic
• Oops:
• Call Trace:
• /var/crash
• vmcore
• kdump

What your security team should do

• Prioritize patching affected Linux kernels on systems using hns3 network adapters, virtualization hosts, container hosts, and multi-user servers.
• Inventory systems for loaded or available hns3 driver components and correlate with running kernel versions.
• Restrict CAP_NET_ADMIN, sudo rights to network tooling, and access to interface reconfiguration commands to trusted administrators only.
• Review container and orchestration policies to ensure untrusted workloads cannot alter host network interface ring parameters.
• Monitor for kernel crash, allocator corruption, KASAN, or hns3 driver errors that occur around network ring reconfiguration activity.
• Because the issue is not currently KEV-listed and EPSS is low, schedule remediation according to kernel vulnerability SLAs, but escalate if public exploit code or active exploitation emerges.