PT-2026-106646 · Linux · Linux
CVE-2026-98317
·
Publicado
2026-10-06
·
Atualizado
2026-10-06
Nenhuma
Não há classificações de severidade ou métricas disponíveis. Quando houver, atualizaremos as informações correspondentes na página.
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.
Encontrou algum problema na descrição? Tem algo a acrescentar? Fique à vontade para nos escrever 👾
Identificadores relacionados
Produtos afetados
Linux