Severity by source
CVSS:4.0/AV:L/AC:L/AT:P/PR:L/UI:N/VC:N/VI:N/VA:N/SC:N/SI:N/SA:H/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
Primary rating from GitHub Advisory.
CVSS VectorGitHub Advisory
CVSS:4.0/AV:L/AC:L/AT:P/PR:L/UI:N/VC:N/VI:N/VA:N/SC:N/SI:N/SA:H/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
Lifecycle Timeline
3DescriptionGitHub Advisory
lxc is a Linux container runtime. In the setuid helper lxc-user-nic, the delete path contains a logic flaw in the find_line() function that allows an unprivileged user to delete OVS-attached network interfaces belonging to other users. When lxc-user-nic delete scans its NIC database to authorize a deletion request, the interface name comparison can set the authorization flag based on a name match alone, even when the ownership, type, and link fields in that database entry belong to a different user. The vulnerable check sits after the goto next label handling, meaning it is reachable on lines where earlier ownership checks failed or were skipped. Because nothing downstream of this authorization signal re-verifies that the matched database line actually belongs to the caller, an unprivileged attacker with a valid lxc-usernet policy entry can trigger deletion of another user's OVS port on the same bridge.
This is limited to multi-tenant environments using lxc-user-nic with OpenVSwitch bridges. The impact is denial of service - one tenant can repeatedly disconnect networking from containers run by another tenant on shared infrastructure. This is patched in version 7.0.0.
AnalysisAI
Authorization bypass in LXC's setuid helper lxc-user-nic allows unprivileged users to delete OpenVSwitch-attached network interfaces belonging to other users. The vulnerability exists in the find_line() function's interface name comparison logic, which sets an authorization flag based on name match alone without re-verifying ownership, enabling a tenant to cause denial of service by disconnecting containers on shared infrastructure. This affects multi-tenant deployments using lxc-user-nic with OpenVSwitch bridges and is patched in LXC 7.0.0.
Technical ContextAI
LXC's lxc-user-nic is a setuid helper that manages per-user network interfaces by maintaining a database of NIC entries indexed by interface name, ownership, type, and link. The vulnerability resides in the delete path's find_line() function, which performs interface name lookups to authorize deletion requests. The flaw is a logic error (CWE-863: Incorrect Authorization) where the comparison reachable after the 'goto next' label allows a name-based match to satisfy authorization checks even when the matched database entry's ownership, type, or link fields belong to a different user. Because the authorization signal derived from this flawed match is not re-verified by downstream code before deletion is authorized, an unprivileged attacker with valid lxc-usernet policy can exploit this to target OVS ports on shared bridges. The vulnerability is specific to OpenVSwitch bridge configurations in multi-tenant setups where multiple unprivileged users manage containers on the same host.
RemediationAI
Upgrade LXC to version 7.0.0 or later, which patches the authorization logic in the find_line() function to properly re-verify database entry ownership before authorizing deletion. For environments unable to immediately upgrade, restrict lxc-user-nic policy entries to prevent cross-user interface access by carefully scoping lxc-usernet policy configuration to limit which interfaces each unprivileged user can manage - explicitly enumerate allowed interfaces by name and owner in the lxc-usernet policy file rather than using broad wildcards. Additionally, isolate multi-tenant workloads on separate physical bridges or use separate OpenVSwitch instances per tenant to prevent interface name collisions. These workarounds have operational trade-offs: restrictive policies may limit container flexibility, and bridge isolation increases infrastructure complexity. The recommended fix is patching to 7.0.0. See GitHub advisory GHSA-3m9j-g9gc-vcvq for verification steps.
Same weakness CWE-863 – Incorrect Authorization
View allSame technique Authentication Bypass
View allVendor StatusVendor
SUSE
Severity: Medium| Product | Status |
|---|---|
| openSUSE Tumbleweed | Fixed |
Share
External POC / Exploit Code
Leaving vuln.today
EUVD-2026-27497