| CVE-2026-72389 (Bridge STP UAF) OpenVZ 7 kernel update planned? [message #53905] |
Thu, 10 September 2026 17:13  |
viadck
Messages: 6
Registered: January 2018
|
Junior Member |
|
|
Hi,
A new Linux kernel vulnerability, CVE-2026-72389, has been disclosed affecting the bridge STP code:
We are still running OpenVZ 7 production nodes and, after the recent GhostLock issue, I wanted to check whether an official OpenVZ 7 kernel update is planned for this CVE.
I have inspected the source of the OpenVZ 7 kernel we are currently running, based on:
3.10.0-1160.119.1.vz7.224.4
and the vulnerable code appears to be present.
In particular, br_topology_change_detection() does not contain the new IFF_UP check, and br_dev_delete() does not synchronously shut down the STP timers before unregistering the bridge device.
We also tested capability reachability inside a normal OpenVZ 7 container. The container has CAP_NET_ADMIN and was able to successfully create a Linux bridge with:
ip link add br-cve-test type bridge
We did not attempt to reproduce the UAF or run an exploit, but this seems sufficient to consider the issue relevant to OpenVZ 7 containers sharing the host kernel.
Could you please confirm:
- Is OpenVZ 7 considered affected by CVE-2026-72389?
- Is an updated vzkernel containing the fix planned?
- If so, will it first be published in the factory repository as happened with the recent GhostLock update?
Current production kernel in our case is based on .vz7.224.4.
Thanks again for your help with the previous GhostLock issue.
|
|
|
|
| Re: CVE-2026-72389 (Bridge STP UAF) OpenVZ 7 kernel update planned? [message #53906 is a reply to message #53905] |
Fri, 11 September 2026 12:53  |
wiredincode
Messages: 1
Registered: September 2026
|
Junior Member |
|
|
It appears that OpenVZ would be vulnerable to this. I didn't even know about the "Factory" repo, so glad you mentioned this as I made my own patch for Ghostlock.
Note current factory repo version is 3.10.0-1160.129.1.vz7.226.3, not .224.4.
From my initial investigation, it appears you can mitigate this by disabling the Bridge feature on your containers:
[root@chivz23-new ~]# vzctl exec 7570 'ip link add testbr type bridge && echo "EXPOSED" || echo "blocked"'
EXPOSED
[root@chivz23-new ~]# vzctl exec 7570 ip link del testbr
[root@chivz23-new ~]# vzctl set 7570 --features bridge:off --save --setmode restart
Unable to set features for the running Container
Restart the Container
Stopping the Container ...
[ ... ]
Container start in progress...
Saved parameters for Container 7570
[root@chivz23-new ~]# vzctl exec 7570 'ip link add testbr type bridge && echo "EXPOSED" || echo "blocked"'
RTNETLINK answers: Permission denied
blocked
I can't make any guarantees but there is some logic to the fact that if you can't open a bridge, you can't mess with the timers, so I am applying this mitigation to my containers while I test my kernel patch.
|
|
|
|
OpenVZ Forum
Members
Search
Help
Register
Login
Home
