Linux Kernel CVE-2026-98122

Requires the VXLAN driver with MDB (multicast database) support in use, and local access to a host where an unprivileged user can create a new user namespace and network namespace (default on most modern distributions) - the description explicitly notes MDB operations are netns-scoped and thus performable by an unprivileged user in a new user+network namespace. The attacker must craft MDB netlink requests using the all-zeros address simultaneously as MDBE_ATTR_SOURCE and as a source-list member (which are validated by vxlan_mdb_is_valid_source), then issue an NLM_F_REPLACE (*,G) update with no source list to hit the vxlan_mdb_remote_srcs_replace sweep. LIMITING FACTORS: local access only (no remote/network reachability), and hosts that disable unprivileged user namespaces (e.g., sysctl kernel.unprivileged_userns_clone=0) block the unprivileged path, raising the required privilege to CAP_NET_ADMIN in the target netns.

This is a CWE-416 use-after-free with WRITE semantics (hlist_del dereferences and writes through ->pprev/->next of a freed vxlan_mdb source entry), confirmed by the KASAN trace in the description. The provided CVSS 3.1 vector (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H, 7.8) correctly identifies this as a LOCAL, low-complexity, low-privilege issue - consistent with the description's note that MDB operations are netns-scoped and thus reachable by an unprivileged user inside a new user+network namespace. However, the C:H/I:H rating is likely OVERSTATED: this is a list-pointer UAF write reached deterministically via a crafted RTM_NEWMDB netlink message, and the observable outcome is memory corruption/crash (denial of service), not confidentiality loss - so the 'Information Disclosure' tag conflicts with the actual mechanism. No EPSS score, no CISA KEV listing, and no public exploit are provided; the flaw was found internally by XBOW and triaged by their team, so this is 'no public exploit identified at time of analysis' rather than active exploitation. Net: real and patch-worthy because it is unprivileged-reachable and deterministic (not a race), but the real-world priority is a local DoS/corruption primitive on hosts where an attacker already has local code execution and user-namespace access - not a remote or widespread threat. Key conflict to verify: the input Tags say 'Information Disclosure' while the CVSS/mechanism indicate a UAF write (DoS/corruption, C:N).

A local unprivileged attacker creates a new user+network namespace (no CAP_NET_ADMIN needed in the root namespace), brings up a VXLAN device, and issues crafted MDB netlink requests that supply the all-zeros address both as MDBE_ATTR_SOURCE and as a source-list member so the derived (S,G) key aliases the (*,G) entry; a subsequent NLM_F_REPLACE with no source list frees the shared entry and then operates on it again, triggering a use-after-free write and kernel memory corruption. No public exploit code is identified (discovered/triaged internally by XBOW); exploitation is local and low-complexity per the CVSS vector.