UBUNTU-CVE-2026-99201: Medium severity vulnerability

Published Oct 28, 2026
·
Updated

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.

  1. 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

Oct 28, 2026
CVE Published
via OSV·12:00 AM
Data Sourced
via OSV·12:00 AM
DescriptionSeverityAffected Software

Frequently Asked Questions

1

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.

2

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.

3

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.

4

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.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203