CVE-2026-63998

What it actually does

This is a Linux kernel denial-of-service flaw in the ethtool netlink module-flashing path. When a module flash request fails validation after ethtool has already entered the operation context with ethnl_ops_begin(), the error path can skip the matching ethnl_ops_complete() cleanup call. That can leave kernel networking/ethtool operation state incompletely unwound, potentially causing subsequent ethtool or network-device management operations to hang, fail, or behave inconsistently. Exploitation is expected to require local ability to issue the relevant ethtool netlink operation, typically requiring elevated networking privileges such as CAP_NET_ADMIN.

Why it matters to the business

Successful exploitation could disrupt network interface management on affected Linux systems, potentially interfering with interface maintenance, transceiver/module firmware operations, or administrative networking workflows. The likely impact is localized service degradation or denial of service rather than data theft or remote code execution. EPSS is low, the issue is not in CISA KEV, and no mature public exploitation is indicated, so urgency is lower than for remotely exploitable kernel flaws, but internet-scale Linux prevalence means affected kernels should still be patched through normal kernel maintenance cycles.

How an attack unfolds

An attacker who already has local access and sufficient privileges to interact with ethtool netlink operations sends a crafted or invalid module flash request to a network device. The kernel begins the ethtool operation context, then validation fails. Because the vulnerable error path does not call the corresponding completion routine, cleanup is skipped. The incomplete cleanup can leave the affected ethtool/network-device operation path in a bad state, causing later administrative operations against the device or networking stack to block, fail, or require service restart or reboot to recover. There is no current indication that this flaw enables unauthenticated remote exploitation, privilege escalation, or arbitrary code execution.

How to fix it

Upgrade to a Linux kernel version that includes the fix ensuring ethnl_ops_complete() is called when module flash validation fails. Because no exact fixed package versions were provided, use vendor kernel advisories for the relevant distribution or appliance and install the latest security-maintained kernel. If immediate patching is not possible, restrict local shell access, tightly limit CAP_NET_ADMIN and equivalent container capabilities, prevent untrusted users from running ethtool or custom netlink tooling, and avoid granting privileged containers access to host networking devices. Reboot into the fixed kernel after installation; merely installing the package is not sufficient if the old kernel remains running.

How to confirm the fix worked

Confirm the running kernel, not only the installed kernel package, is updated to a vendor build containing the fix. On Linux systems, compare `uname -r` with the vendor advisory and package changelog for the CVE or the ethtool module-flash cleanup patch. Validate that untrusted users and containers do not have CAP_NET_ADMIN or privileged host-network access. Where safe, test administrative ethtool operations after patching to ensure module and interface management commands complete normally. Review vulnerability scanner results against the active kernel version and confirm the finding is closed only after a reboot into the patched kernel.

Typical attack path

1. Gain local access to a Linux system running an affected kernel.
2. Obtain or abuse privileges sufficient to perform ethtool netlink operations, commonly CAP_NET_ADMIN or equivalent administrative rights.
3. Identify a network interface/module that accepts ethtool module flash operations.
4. Submit a malformed or validation-failing module flash request through ethtool or a custom netlink client.
5. Trigger the kernel error path where ethnl_ops_begin() has run but ethnl_ops_complete() is skipped.
6. Cause ethtool or network-device management operations to become stuck, unreliable, or unavailable until the system or relevant subsystem is recovered.

How to detect it

Look for evidence of suspicious local use of ethtool or custom netlink clients attempting module firmware flash operations, especially repeated failures shortly before network-management hangs. Relevant sources include Linux audit logs, shell history, sudo logs, process accounting, EDR telemetry, kernel logs, and container runtime audit data showing privileged containers or CAP_NET_ADMIN usage. Search for executions of ethtool with module flashing options, abnormal failed administrative operations against network interfaces, and repeated netlink ethtool requests from unexpected users or processes. Kernel logs may show adjacent networking or driver errors rather than a clean CVE-specific message. Because the flaw is an error-path cleanup bug, exploitation may leave few definitive artifacts; absence of logs does not rule out an attempt. If suspected, collect process telemetry, audit records, kernel ring buffer output, ethtool command history, and container capability configuration before rebooting.

• /usr/sbin/ethtool
• /sbin/ethtool
• ethtool
• --flash-module-firmware
• ETHTOOL_MSG_MODULE_FW_FLASH_ACT
• CAP_NET_ADMIN
• --cap-add=NET_ADMIN
• --privileged
• --network host
• ethnl_ops_begin
• ethnl_ops_complete
• module flash

What your security team should do

• Patch affected Linux kernels through the normal kernel security update process and reboot into the fixed kernel.
• Prioritize systems where untrusted users, build jobs, containers, or shared workloads may obtain CAP_NET_ADMIN or privileged host networking access.
• Audit containers and services for unnecessary `--privileged`, host network mode, or added CAP_NET_ADMIN capability and remove those permissions where not required.
• Monitor for unusual or repeated ethtool module flash attempts, especially failed operations performed by non-standard administrative accounts or automation.
• Treat any unexplained networking management hangs after failed ethtool module operations as potential evidence of attempted exploitation and preserve logs before rebooting.
• If patching must be delayed, restrict ethtool usage to trusted administrators and limit local login access on multi-user systems.