UBUNTU-CVE-2026-99201: Medium severity vulnerability
In the Linux kernel, the following vulnerability has been resolved: netlink: avoid hashing the network namespace pointer The netlink rhashtable key includes a raw struct net pointer and a user-controlled port ID. Both /proc/net/netlink and socket diagnostics expose the table's bucket order. By binding and rebinding chosen NETLINKUSERSOCK port IDs, an unprivileged reader can distinguish equal buckets and recover the low bits of the Jenkins hash. Its 32-bit seed and the limited set of kernel-image slides can then be searched offline to recover the address of initnet. Use the namespace's unique, non-address netcookie in the comparison key instead. It is assigned before the per-net initializers run and remains unchanged for the namespace's lifetime. The lookup key and object hash are still built by netlinkcomparearginit(), keeping lookup, insertion, removal and rehashing consistent while preserving namespace separation. Neither public table walker needs to change. Reading the socket's namespace cookie in netlinkcompare() is safe under RCU, including during namespace teardown. netlinkrelease() removes the socket from the hash table and defers its final put with callrcu(). cleanupnet() runs the per-net exit methods and waits for outstanding RCU callbacks with rcubarrier() before freeing namespace storage. Unlike ns.nsid, netcookie is also available and initialized during setupnet() in older stable kernels, making the change straightforward to backport to v5.15 and later.
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Configuration
Use the network namespace's unique, non-address net_cookie instead of the raw struct net pointer in the netlink rhashtable comparison key; keep lookup, insertion, removal, and rehashing consistent through netlink_compare_arg_init().
Linux kernel netlink netlink comparison key namespace identifier = net_cookie
Event History
Frequently Asked Questions
Who can exploit this issue?
An unprivileged local user who can bind and rebind selected NETLINK_USERSOCK port IDs and read the exposed netlink table ordering through /proc/net/netlink or socket diagnostics can use the information leak.
What information could an attacker recover?
The attacker can distinguish hash-table bucket collisions, recover low bits of the Jenkins hash, and search the 32-bit hash seed together with possible kernel-image slides offline to recover the address of init_net.
Is a special netlink configuration required?
The described technique relies on NETLINK_USERSOCK sockets plus access to /proc/net/netlink or socket diagnostics. The data does not identify any additional configuration requirement.
What change resolves the exposure?
The resolution replaces the raw network-namespace pointer in the netlink rhashtable key with the namespace's stable net_cookie. This preserves namespace separation while preventing the hash key from incorporating the namespace address.