CVE-2026-97597: ipv6: flowlabel: cap duplicate leases per socket
In the Linux kernel, the following vulnerability has been resolved:
ipv6: flowlabel: cap duplicate leases per socket
ipv6flowlabelget() allocates an ipv6flsocklist entry for every successful GET. The recheck path for a compatible existing flowlabel links another lease without applying any lease admission check. Repeated GET requests for one shareable label can therefore grow a socket's lease list without bound.
Reject a new unprivileged lease once the socket already holds FLMAXPERSOCK leases. Check this on the shared recheck path so reuse of a globally interned label, including the flintern() collision path, is covered as well. New-label admission remains under the existing memcheck() policy.
Use capable(CAPNETADMIN) rather than nscapable(), matching memcheck(). An unprivileged user must not bypass the cap by creating a user namespace and a netns where they have CAPNETADMIN, which would still consume host memory.
Check the capability only when the socket reaches the limit, so successful unprivileged GET requests below the cap do not generate a capability audit. Do the admission check before updating linger and expires so a rejected GET does not refresh the shared label, matching the existing socket-list allocation failure path.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
debian/linuxto a version that resolves this vulnerability.Fixed in 6.12.113-1 - Upgrade
Upgrade
debian/linuxto a version that resolves this vulnerability.Fixed in 7.2.7-1 - Upgrade
Upgrade
debian/linux-6.12to a version that resolves this vulnerability.Fixed in 6.12.113-1~deb12u1 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 6.1.191 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 6.6.160 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 6.12.112 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 6.18.53 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 7.2.7 - Upgrade
Upgrade
debian/linuxto a version that resolves this vulnerability.Fixed in 6.12.115-2Fixed in 7.2.12-1Fixed in 7.2.15-1 - 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 - Compensating control
In ipv6_flowlabel_get(), reject a new unprivileged lease when the socket already holds FL_MAX_PER_SOCK leases; perform the capable(CAP_NET_ADMIN) check only when the limit is reached, on the shared recheck path including the fl_intern() collision path, and before updating linger and expires.
Event History
Frequently Asked Questions
Who can trigger the unbounded growth?
An unprivileged user that can repeatedly issue successful IPv6 flow-label GET requests on a socket can grow that socket's lease list without bound when reusing a compatible shareable label. The growth consumes host memory.
What request pattern is required to exploit the issue?
The attacker must repeatedly obtain leases for one shareable flow label through the compatible-existing-label recheck path. This includes reuse of a globally interned label and the fl_intern() collision path.
Can an attacker bypass the intended restriction by creating a user and network namespace?
No. The resolved behavior uses capable(CAP_NET_ADMIN), rather than ns_capable(), so CAP_NET_ADMIN obtained in a user namespace and network namespace does not permit an unprivileged user to bypass the per-socket lease cap while consuming host memory.
Are privileged users subject to the new lease limit?
The new admission check rejects a lease at the per-socket limit only for unprivileged users. A caller with CAP_NET_ADMIN is not rejected by this specific limit check.