CVE-2026-98317
NoneCVSS
—
EPSS
0.2%
Published
Oct 6, 2026
CISA due date
—
Cloudanix analysis
A missing check in the Linux kernel's network neighbor handling lets certain timing values be set incorrectly, which can make important network maintenance tasks run at the wrong time and affect connectivity.
- Exploitation
- Local Privilege
- Attacker needs
- Low Privilege
- Complexity
- Moderate
- Impact
- Denial Of Service
- Component
- OS kernel
- Class
- Improper Input Validation
- Remediation
- Patch
- Effort
- Medium
- Patch risk
- Low
What it actually does
Missing NLA validation and integer overflow handling in NDTPA_INTERVAL_PROBE_TIME_MS allows setting a probe interval of 0 or values that wrap to 0 via msecs_to_jiffies and NEIGH_VAR, causing immediate or negative timer expiry for NTF_MANAGED neighbor entries.
Why it matters to the business
Kernel-level network neighbor management can be driven into a misconfigured state that disrupts ARP/ND probing and may trigger unexpected immediate workqueue execution, leading to reduced network stability on systems using managed neighbor entries.
How an attack unfolds
An attacker with CAP_NET_ADMIN or equivalent rights issues a netlink RTM_SETNEIGHTBL command supplying an out-of-range interval-probe-time-ms value; the kernel silently accepts 0 or a 32-bit-wrapped large value, resulting in queue_delayed_work receiving a zero or wrapped delay and scheduling the probe work immediately or in the past.
How to fix it
Apply the upstream kernel commit that adds NLA_POLICY_FULL_RANGE validation limiting the parameter to one day and performs the same check on the sysctl path; rebuild and boot the fixed kernel.
How to confirm the fix worked
After patching, confirm that attempts to set interval-probe-time-ms outside the documented min/max range are rejected by the netlink interface and that the sysctl likewise enforces the bounds.
Typical attack path
- Obtain CAP_NET_ADMIN or root on the target host
- Craft a netlink message setting NDTPA_INTERVAL_PROBE_TIME_MS to 0 or 0x100000000
- Observe that the value is accepted without validation and the timer fires with zero delay
- Repeat or combine with traffic that relies on NTF_MANAGED entries to induce instability
How to detect it
Review netlink audit logs or system call traces for RTM_SETNEIGHTBL operations that supply interval-probe-time-ms values outside expected operational ranges; examine kernel logs for unusual immediate scheduling of neigh_timer_handler or delayed work related to managed neighbors.
What your security team should do
- Prioritize patching kernel packages on all systems that expose netlink neighbor table configuration to untrusted local users
- Audit any custom scripts or tools that directly manipulate NDTPA_INTERVAL_PROBE_TIME_MS
- Monitor for future stable kernel updates containing this fix
The record
In the Linux kernel, the following vulnerability has been resolved: neighbour: Enforce min/max to NDTPA_INTERVAL_PROBE_TIME_MS. NDTPA_INTERVAL_PROBE_TIME_MS sets .type and .min but misses .validation_type, so no validation is applied: # ynl --family rt-neigh --do setneightbl \ --json '{"name": "arp_cache", "parms": {"interval-probe-time-ms": 0}}' # ynl --family rt-neigh --dump getneightbl --output-json | \ jq '.[] | select(.name == "arp_cache" and has("config")) | .parms["interval-probe-time-ms"]' 0 Moreover, nla_get_msecs() uses msecs_to_jiffies(), and u64 is silently cast to u32, so a larger value can bypass the min check: e.g. 4294967296 == 0x100000000 # ynl --family rt-neigh --do setneightbl \ --json '{"name": "arp_cache", "parms": {"interval-probe-time-ms": 4294967296}}' # ynl --family rt-neigh --dump getneightbl --output-json | \ jq '.[] | select(.name == "arp_cache" and has("config")) | .parms["interval-probe-time-ms"]' 0 msecs_to_jiffies() returns MAX_JIFFY_OFFSET if the value is larger than INT_MAX. Also, INT_MAX ms overflows int NEIGH_VAR() when HZ > 1000 (Alpha, MIPS), and passing a negative integer to queue_delayed_work(unsigned long delay) causes sign extension, which wraps around the expiry time to the past, resulting in it being handled as 0 delay in the timer wheel. Let's use NLA_POLICY_FULL_RANGE() and limit the max to 1 day. The same max check is applied to sysctl as well. Note that this controls the probe interval for NTF_MANAGED entries, so the max of 1 day is unlikely to break any deployments.
Affected packages
| Ecosystem | Package | Introduced | Fixed |
|---|