RHSB-2026-011 Network Stack Privilege Escalations

A recent Red Hat Security Bulletin (RHSB) has been posted which covers the following high profile CVEs:

CVE-2026-80844 (DirtyAH6)

CVE-2026-81000 (TUNderflow)

CVE-2026-68121 (PPPoEject)

CVE-2026-74469 (DiagSpill)

It is important to note that these vulnerabilities all require local access to a system to be exploited, something that would require an issue with the running micro-services or associated services to have been exposed and exploited in the first instance. Or for a user with admin level access, who would already have sufficient permissions and access that they would not need to exploit any known vulnerabilities to carry out destructive actions. As such these are vulnerabilities are not considered ‘exploitable’ under practical operational conditions.

The following CVEs:

CVE-2026-80844 (DirtyAH6)

CVE-2026-81000 (TUNderflow)

CVE-2026-68121 (PPPoEject)

Are mitigated by default in all 4.x VQCM instances due to the preset user.max_user_namespaces value (0).

All 4.5.1 or later VQCMs are also protected against CVE-2026-74469 (DiagSpill) as the impacted module (sctp) is blacklisted by default. 

A playbook to mitigate CVE-2026-74469 (DiagSpill) has been put together to ensure the impacted module (sctp) is not loaded and that the default mitigation for CVE-2026-80844 (DirtyAH6), CVE-2026-81000 (TUNderflow) and CVE-2026-68121 (PPPoEject) is inplace.

Customers who are on VQCMs older than 4.5.1 or who believe the defaults within their VQCM VM may have been altered, please raise a support ticket (via support@vqcomms.com) to request access to the mitigation playbook. If customers are unsure if they need to raise a support ticket, they can run the following commands (via the CLI to check). These commands will require elevated privileges to run:

grep -E ‘^(blacklist sctp|install sctp /bin/false)’ /etc/modprobe.d/blacklist.conf

The above should return two lines:

blacklist sctp

install sctp /bin/false

If their is no return value, this is a finding and you need to raise a ticket with VQ Support

To ensure that the default mitigation is in place, please run:

sysctl user.max_user_namespaces

This should show 

user.max_user_namespaces = 0

If the value is anything different, this is a finding and you need to raise a ticket with VQ Support

If customers have any questions or concerns, please email security@vqcomms.com