The Linux kernel vulnerability CVE-2022-0185 was recently discovered. The vulnerability is caused by an integer underflow condition that is found in the FIlesystem Context system in the legacy_parse_param function. Attackers can exploit this vulnerability to launch DDoS attacks or escape from containers. This allows the attackers to escalate their privileges on vulnerable hosts. This topic describes the impacts, affected versions, and fixes of this vulnerability.

CVE-2022-0185 is rated as high severity and its Common Vulnerability Scoring System (CVSS) score is 7.8. For more information about the vulnerability, see CVE-2022-0185.

Affected versions

The CVE-2022-0185 vulnerability was found in the 5.1-rc1 kernel version that was released in March 2019. The Linux community has fixed this vulnerability and released the patched version on January 18, 2022. For more information, see v5.17-rc1.

  • If the nodes in your Container Service for Kubernetes (ACK) cluster do not run Alibaba Cloud Linux3, your business is not affected by this vulnerability.
  • You can also run the following command to check whether the kernel version of your cluster nodes is affected by this vulnerability:
    kubectl get nodes -o jsonpath='{range .items[*]}{}{"\t"}{.status.nodeInfo.kernelVersion}{"\n"}{end}'


In multi-tenant scenarios, attackers that have the permissions to deploy pods or attackers that have the pod exec permission can exploit this vulnerability and bypass the authentication to perform out-of-bounds write operations on the memory. This crashes the operating system of the nodes and results in service interruptions. In addition, attackers can run malicious code to escape from containers and gain root privileges on the host.


  1. We recommend that you pay attention to the announcement on the patched image version of Alibaba Cloud Linux3 and upgrade the kernel version of the nodes that are affected by this vulnerability.
  2. We recommend that you use the default seccomp profile of the container runtime to prevent pods from using the unshare system call. For more information, see Restrict a Container's Syscalls with seccomp. In addition, do not deploy privileged pods or add the CAP_SYS_ADMIN capability to pods. For more information, see CAP_SYS_ADMIN.