CVE-2026-98028

Executive Summary

CVE-2026-98028 is a logic defect in the Linux kernel's Netronome nfp Ethernet driver. When nfp_net_fs_add() fails to reprogram a replaced flow-steering rule, the old rule is left on nn->fs.list while the hardware entry has already been torn down and nn->fs.count has been decremented, permanently desynchronising the list from the counter. The impact is a kernel-side reporting inconsistency exposed through ETHTOOL_GRXCLSRLCNT/GRXCLSRLALL, which causes userspace to under-size its buffer — historically a one-u32 out-of-bounds write, now a permanent -EMSGSIZE that no code path ever resyncs.

Technical Analysis

The vulnerability lives in the flow-steering (ethtool RX classification rule) management path of the nfp driver. The relevant routines named in the description are:

• nfp_net_fs_add() — entry point that adds or replaces a rule. When replacing, it deletes the existing rule from hardware, decrements nn->fs.count, and programs the new rule.
• nfp_net_fs_add_hw() — hardware programming primitive that can fail.
• nn->fs.list — the in-kernel linked list of rule entries.
• nn->fs.count — the maintained count of installed rules, reported to userspace via ETHTOOL_GRXCLSRLCNT.

The defect is an error-handling asymmetry. On the success path, list_replace() swaps the old list node for the new one, keeping nn->fs.list and nn->fs.count consistent. On the failure path of nfp_net_fs_add_hw(), the function returns early: nn->fs.count has already been decremented (and the old hardware entry has already been destroyed), but the stale entry remains on nn->fs.list. The list therefore holds one more element than nn->fs.count advertises, and that surplus element references a hardware rule that no longer exists.

The security relevance is in how that inconsistency propagates to userspace. ETHTOOL_GRXCLSRLCNT reports nn->fs.count; userspace tools subsequently issue an ETHTOOL_GRXCLSRLALL walk to enumerate the rules. Because the walk is driven by the actual list contents rather than the advertised count, it attempts to write one more entry than the caller allocated. The description notes this used to result in a write of one u32 past the end of the allocation. In current code the walk is bounded, so the observable effect is a permanent -EMSGSIZE error instead of an out-of-bounds write — but the counter never resyncs, so the interface remains permanently broken for that device until it is reset or the driver state is rebuilt.

Two points warrant care when triaging:

1. The out-of-bounds write is historical. The description frames the one-u32 overwrite as the pre-bounding behaviour ("That used to overwrite one u32 past the allocation"). Analysts should not assume a memory-corruption primitive is present in current kernels without verifying the bounding logic in their specific tree.
2. The driver is hardware-specific. The affected code path is only reachable on systems with a Netronome nfp NIC and requires the operator to be manipulating ethtool RX classification rules.

Exploitation Scenarios

No public PoC or exploit code is available for this CVE. The attack chain below is inferred from the vulnerability class (state desynchronisation between a kernel list and its advertised count, surfaced to an unprivileged userspace reporting interface) and the explicit function/field names in the NVD description. No additional function names, endpoints, or parameters are asserted.

1. Reconnaissance / target identification. An attacker with a local account on a host that has a Netronome nfp network adapter identifies the device via standard interface enumeration and confirms that ethtool RX classification (flow steering) is in use. The requirement is less about discovery and more about access: this is a local attack surface gated on nfp hardware presence and on the ability to issue ETHTOOL_GRXCLSRLCNT / ETHTOOL_GRXCLSRLALL ioctls.

2. Triggering the flaw class. The attacker causes nfp_net_fs_add() to take the replace path — that is, to install a rule that supersedes an existing one — while inducing nfp_net_fs_add_hw() to fail. The failure mode is the crux: it can be driven by resource exhaustion, hardware/firmware state, or an invalid rule specification, but the data provided does not enumerate specific failure conditions, and none should be assumed. What matters is the outcome: the old entry is deleted from hardware, nn->fs.count is decremented, and the stale entry survives on nn->fs.list.

3. Execution / observation. The attacker (or any local user) then queries the rule count and rule list via the ethtool RX classification interface. The count advertised via ETHTOOL_GRXCLSRLCNT is one short of what the ETHTOOL_GRXCLSRLALL walk will attempt to emit. On affected kernels with bounding applied, the result is a permanent -EMSGSIZE; on older/unbounded implementations, the result was an out-of-bounds write of one u32 past the userspace buffer.

4. Post-exploitation impact. Where the out-of-bounds write is reachable, the theoretical escalation is arbitrary write of a single u32 past a userspace-controlled allocation in the context of the calling process — a self-corruption primitive whose severity depends entirely on allocator adjacency and the value written, neither of which is characterised in the available data. Where bounding applies, the impact is denial of service: the flow-steering reporting interface is permanently stuck returning an error, and the driver's rule bookkeeping remains internally inconsistent for the lifetime of the device state.

Exploitation prerequisites are significant. This is not remotely reachable, requires specific hardware, requires a local foothold, and — for the memory-safety variant — requires an affected (pre-bounding) kernel build. Treat it as a low-likelihood, local-only issue pending vendor confirmation of fixed versions.

Impact Assessment

The primary business impact is local denial of service / interface breakage on Netronome nfp-equipped Linux hosts, with a historical memory-safety concern that may or may not apply to a given kernel tree.

• Confidentiality: No direct impact. The flaw does not expose data; the desynchronised entry is kernel-internal and concerns a hardware rule pointer, not payload contents.
• Integrity: Low-to-moderate. Kernel driver bookkeeping (nn->fs.list vs. nn->fs.count) is left permanently inconsistent. The historical one-u32 out-of-bounds write is an integrity concern only if the unpacked branch is reachable.
• Availability: The dominant impact. ETHTOOL_GRXCLSRLCNT/GRXCLSRLALL operations on the affected device fail persistently with -EMSGSIZE, and the counter never resyncs. High availability impact is the reasonable inference if the flaw is triggered.
• Scope: Unchanged. Blast radius is limited to the local system and the nfp device's flow-steering subsystem.
• Privileges required: Local, likely low-privileged for the reporting path; rule programming may require elevated privileges depending on kernel configuration and namespace context.
• Exploitability: Low. No PoC, no KEV listing, no known in-the-wild exploitation, hardware-gated.

Affected systems are Linux hosts with Netronome nfp adapters actively using ethtool RX classification. General-purpose servers, cloud workloads, and containerised environments without nfp hardware are unaffected.

Detection Guidance

Sigma Rule

Sigma is host/event-log oriented and the Linux kernel does not emit structured telemetry for ethtool RX-classification ioctls by default. The following rule therefore targets auditd-based syscall telemetry for the ethtool ioctl path and should be treated as a best-effort approximation; efficacy depends on an audit policy that captures ioctl with argument logging, which is expensive and rarely enabled.

title: Local ethtool RX Classification Rule Enumeration on nfp Device (CVE-2026-98028)
id: 8f2c1d74-3b6e-4a90-9c15-7d2e5a1b0f43
status: experimental
description: Detects local execution of ethtool RX classification rule queries/counts, the userspace interface used to surface the nfp list/count desynchronisation described in CVE-2026-98028.
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2026-98028
author: valtersit.com
date: 2026/01/01
tags:
  - attack.t1068
logsource:
  product: linux
  service: auditd
detection:
  selection_proc:
    type: 'SYSCALL'
    exe|endswith:
      - '/ethtool'
  selection_args:
    comm: 'ethtool'
  selection_ioctl:
    type: 'SYSCALL'
    syscall: 'ioctl'
  filter_benign:
    auid: 4294967295
  condition: selection_proc and selection_args and not filter_benign
falsepositives:
  - Legitimate network administration and monitoring scripts that query RX classification rules
  - Configuration management tooling (Ansible, Puppet) managing flow steering
level: low

YARA Rule

This CVE does not produce a file-system artifact in the classic sense, so a meaningful YARA rule is not applicable to detection of the vulnerability itself. The rule below is intentionally scoped to flag kernel modules or crash artifacts referencing the affected nfp symbols; it is a triage aid, not a detection of exploitation. It should not be presented as a reliable indicator.

rule CVE_2026_98028_nfp_fs_symbols
{
    meta:
        description = "Flags Linux kernel artefacts referencing the nfp flow-steering symbols affected by CVE-2026-98028. Triage aid only; presence of these symbols is expected on all nfp-enabled kernels and is NOT an indicator of compromise."
        author = "valtersit.com"
        date = "2026-01-01"
        reference = "https://nvd.nist.gov/vuln/detail/CVE-2026-98028"
        confidence = "low"
        tlp = "WHITE"

    strings:
        $s1 = "nfp_net_fs_add" ascii
        $s2 = "nfp_net_fs_add_hw" ascii
        $s3 = "GRXCLSRLCNT" ascii wide
        $s4 = "GRXCLSRLALL" ascii wide
        $s5 = "EMSGSIZE" ascii

    condition:
        (uint32(0) == 0x464c457f or uint32(0) == 0x7f454c46) and
        any of ($s1, $s2) and
        any of ($s3, $s4, $s5)
}

Suricata IDS Rule

CVE-2026-98028 is triggered via local ioctl calls and has no network-observable protocol signature. There is no defensible Suricata network rule for this vulnerability; publishing one would generate pure false-positive noise. The rule below is included only to satisfy format requirements and is explicitly marked as non-production / non-detective.

# CVE-2026-98028: LOCAL ioctl-based flaw. NO network signature exists.
# This rule is a NON-PRODUCTION placeholder and must NOT be deployed to production sensors.
# It is intentionally disabled and will never alert.
alert ip any any -> any any (msg:"PLACEHOLDER - CVE-2026-98028 is local-only, no network signature applicable"; sid:9000028; rev:1; enabled:no; metadata:cve CVE-2026-98028;)

Elastic Detection

EQL operating on auditd/process events. Detects the ethtool invocation patterns associated with manual RX classification rule manipulation, which is the precondition for triggering this bug. This is behavioural, not signature-based, and will fire on legitimate administration.

process where event.action == "exec" and
  process.name == "ethtool" and
  process.args : "-N" and
  process.args : "rx-flow-hash"

Because the RX classification rule flags (-N/--config-nfc) and the count/list query are the relevant operations, a more targeted variant keyed on the actual ethtool flags for rule management should be tuned per environment by the deploying team.

Splunk SPL Query

Detects local execution of ethtool RX classification management and prior kernel-side errors, which are the observable precursors to the count/list desynchronisation. Requires auditd or endpoint telemetry forwarded to Splunk.

index=os sourcetype=auditd OR sourcetype=linux_secure OR sourcetype=syslog
| eval proc=coalesce(process_name, exe, comm)
| eval args=coalesce(process_args, cmdline, exe)
| where proc="ethtool" OR (proc="auditctl" AND match(args,"ioctl"))
| rex field=args "(?i)(-N|--config-nfc|rx-flow-hash|GRXCLSRLCNT|GRXCLSRLALL)"
| where isnotnull(match)
| stats count min(_time) as first_seen max(_time) as last_seen values(args) as commands by host, user
| where count > 0

Correlate host/user pairs that both issue RX-classification rule operations and subsequently generate repeated EMSGSIZE errors in kernel logs — the combination is far more specific than either signal alone.

Wazuh OSSEC Rule

<group name="cve-2026-98028,linux,kernel,audit,">
  <rule id="980280" level="3">
    <decoded_as>audit</decoded_as>
    <field name="audit.key">ethtool_nfc</field>
    <description>CVE-2026-98028: ethtool RX classification (NFC) rule operation observed on nfp-capable host</description>
    <mitre>
      <id>T1068</id>
    </mitre>
  </rule>

  <rule id="980281" level="6">
    <if_sid>980280</if_sid>
    <field name="audit.exe">/usr/sbin/ethtool</field>
    <description>CVE-2026-98028: ethtool invoked to manage RX classification rules - potential trigger for nfp fs.list/fs.count desynchronisation</description>
    <group>cve-2026-98028,</group>
  </rule>

  <rule id="980282" level="8" frequency="2" timeframe="300">
    <if_matched_sid>980281</if_matched_sid>
    <description>CVE-2026-98028: repeated ethtool RX classification operations with subsequent kernel -EMSGSIZE errors (possible exploitation / persistent driver desync)</description>
    <group>cve-2026-98028,</group>
  </rule>
</group>

These rules require an auditd configuration that records ethtool execution; without it they will not fire. The third rule intentionally correlates repeated activity with kernel error output as a proxy for the permanent-EMSGSIZE end state, and should be validated against the target kernel's actual log output before relying on it.

Mitigation & Patch Guidance

Patch confidence: 0/4 — UNPATCHED. No patch evidence has been identified from any tracked source, no vendor fix reference is available, and no affected/fixed version range has been published. The analysis below therefore consists of mitigations only; there is no upgrade target to name, and readers should not treat any version as "fixed" based on this report.

1. Immediate mitigations.

   • Restrict local access. Because the vulnerable path is local and requires interaction with the ethtool RX classification interface, limiting shell access and confining untrusted workloads (containers, namespaces, sandboxes) reduces reachability. Apply standard least-privilege and seccomp/namespace isolation so that untrusted local users cannot issue ioctl requests against the nfp device.
   • Where nfp flow-steering is not required, avoid configuring ethtool RX classification rules on affected adapters, and do not build tooling that performs replace-style rule reprogramming.
   • Monitor for persistent -EMSGSIZE errors from the RX classification query path on nfp hosts; treat this as the observable symptom of a triggered desynchronisation and plan a device/driver reset.
   • Track the upstream Linux kernel netdev mailing list and the stable tree for the fix. Do not assume a fix exists.

2. Patch / upgrade steps.

   • No patch reference or fixed version is currently available. The correct action at this time is to monitor the Linux kernel netdev patch series and the stable kernel release notes for a commit in the nfp driver that corrects error handling in nfp_net_fs_add() so that failure of nfp_net_fs_add_hw() removes the stale entry from nn->fs.list, keeping it consistent with nn->fs.count.
   • When a fix is published, apply it via your distribution's kernel update channel, or rebuild against a stable kernel tag containing the fix, then reboot to load the corrected module.
   • Verify the fix by confirming that list and count remain consistent after a forced reprogramming failure. As of this report, no such fix has been evidenced.

3. Long-term hardening.

   • Establish a kernel patch-tracking process aligned to stable releases for network drivers on specialised hardware (Netronome, SmartNIC classes), which frequently receive less attention than core networking paths.
   • Add unit/integration coverage for the rule-replacement failure path in driver test harnesses so that list/count invariants are asserted after injected hardware programming failures.
   • Prefer capability-scoped access to network device configuration; restrict CAP_NET_ADMIN to the smallest possible set of identities and avoid granting it to containerised workloads by default.
   • Feed kernel -EMSGSIZE and ethtool error patterns into SOC monitoring so that silent driver desynchronisation events are surfaced rather than ignored.

References

• NVD — CVE-2026-98028: https://nvd.nist.gov/vuln/detail/CVE-2026-98028
• Linux kernel netdev subsystem (nfp Ethernet driver source and upstream patch review), canonical upstream location for the fix to nfp_net_fs_add(): https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git
• Linux kernel stable release announcements (first place a backported fix would appear): https://www.kernel.org/category/releases.html
• ethtool / ETHTOOL_GRXCLSRLCNT and ETHTOOL_GRXCLSRLALL interface documentation (userspace side of the reporting path): https://www.kernel.org/doc/html/latest/networking/ethtool-netlink.html
• CISA Known Exploited Vulnerabilities catalog — not listed. No exploit-in-the-wild evidence, no public PoC, and no known threat actor campaign is associated with CVE-2026-98028 as of this report.