CVE-2026-98317: neighbour: Enforce min/max to NDTPA_INTERVAL_PROBE_TIME_MS.
In the Linux kernel, the following vulnerability has been resolved:
neighbour: Enforce min/max to NDTPAINTERVALPROBETIMEMS.
NDTPAINTERVALPROBETIMEMS sets .type and .min but misses .validationtype, so no validation is applied:
# ynl --family rt-neigh --do setneightbl \ --json '{"name": "arpcache", "parms": {"interval-probe-time-ms": 0}}'
# ynl --family rt-neigh --dump getneightbl --output-json | \ jq '.[] | select(.name == "arpcache" and has("config")) | .parms["interval-probe-time-ms"]' 0
Moreover, nlagetmsecs() uses msecstojiffies(), 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": "arpcache", "parms": {"interval-probe-time-ms": 4294967296}}'
# ynl --family rt-neigh --dump getneightbl --output-json | \ jq '.[] | select(.name == "arpcache" and has("config")) | .parms["interval-probe-time-ms"]' 0
msecstojiffies() returns MAXJIFFYOFFSET if the value is larger than INTMAX. Also, INTMAX ms overflows int NEIGHVAR() when HZ > 1000 (Alpha, MIPS), and passing a negative integer to queuedelayedwork(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 NLAPOLICYFULLRANGE() 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 NTFMANAGED entries, so the max of 1 day is unlikely to break any deployments.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
ubuntu/linux-hwe-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-42.42~24.04.1 - Upgrade
Upgrade
ubuntu/linux-riscv-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-42.42.1~24.04.1 - Upgrade
Upgrade
ubuntu/linuxto a version that resolves this vulnerability.Fixed in 7.0.0-42.42 - Upgrade
Upgrade
ubuntu/linux-awsto a version that resolves this vulnerability.Fixed in 7.0.0-1016.17 - Upgrade
Upgrade
ubuntu/linux-gcpto a version that resolves this vulnerability.Fixed in 7.0.0-1016.18 - Upgrade
Upgrade
ubuntu/linux-ibmto a version that resolves this vulnerability.Fixed in 7.0.0-1017.17 - Upgrade
Upgrade
ubuntu/linux-oem-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1017.17 - Upgrade
Upgrade
ubuntu/linux-oracleto a version that resolves this vulnerability.Fixed in 7.0.0-1015.16 - Upgrade
Upgrade
ubuntu/linux-riscvto a version that resolves this vulnerability.Fixed in 7.0.0-42.42.1 - Configuration
Enforce a maximum interval-probe-time-ms value of 1 day, including for the corresponding sysctl, and apply the same min/max validation to this parameter.
Linux kernel rt-neigh neighbour table NDTPA_INTERVAL_PROBE_TIME_MS / interval-probe-time-ms = maximum 1 day
Event History
Frequently Asked Questions
What access is needed to trigger the issue?
An attacker needs the ability to set neighbour-table parameters through the RT-neigh netlink interface, specifically the interval-probe-time-ms parameter. The provided examples use the arp_cache neighbour table.
How can I check whether an unsafe value has been accepted?
Query the neighbour-table configuration and inspect interval-probe-time-ms for the affected table. The provided examples show that both 0 and 4294967296 can be accepted and subsequently reported as 0.
Are all systems affected in the same way by large values?
Large values can be converted by msecs_to_jiffies() to MAX_JIFFY_OFFSET when they exceed INT_MAX. On systems with HZ greater than 1000, including Alpha and MIPS as noted, INT_MAX milliseconds can also overflow the integer neighbour variable.