Lucene search

K
osvGoogleOSV:GHSA-P4RX-7WVG-FWRC
HistoryJan 10, 2024 - 3:27 p.m.

CRI-O's pods can break out of resource confinement on cgroupv2

2024-01-1015:27:45
Google
osv.dev
13
cri-o
vulnerability
resource confinement
cgroupv2
annotation
kubernetes
scheduler
dos
patch
cgroupv1
software

CVSS3

7.5

Attack Vector

NETWORK

Attack Complexity

LOW

Privileges Required

NONE

User Interaction

NONE

Scope

UNCHANGED

Confidentiality Impact

NONE

Integrity Impact

NONE

Availability Impact

HIGH

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

AI Score

7.1

Confidence

High

EPSS

0.001

Percentile

24.1%

Impact

What kind of vulnerability is it? Who is impacted?
All versions of CRI-O running on cgroupv2 nodes.
Unchecked access to an experimental annotation allows a container to be unconfined. Back in 2021, support was added to support an experimental annotation that allows a user to request special resources in cgroupv2. It was supposed to be gated by an experimental annotation: io.kubernetes.cri-o.UnifiedCgroup, which was supposed to be filtered from the list of allowed annotations . However, there is a bug in this code which allows any user to specify this annotation, regardless of whether it’s enabled on the node. The consequences of this are a pod can specify any amount of memory/cpu and get it, circumventing the kubernetes scheduler, and potentially be able to DOS a node.

Patches

Has the problem been patched? What versions should users upgrade to?
1.29.1, 1.28.3, 1.27.3

Workarounds

Is there a way for users to fix or remediate the vulnerability without upgrading?
use cgroupv1

References

Are there any links users can visit to find out more?

CVSS3

7.5

Attack Vector

NETWORK

Attack Complexity

LOW

Privileges Required

NONE

User Interaction

NONE

Scope

UNCHANGED

Confidentiality Impact

NONE

Integrity Impact

NONE

Availability Impact

HIGH

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

AI Score

7.1

Confidence

High

EPSS

0.001

Percentile

24.1%