Dirty Cred: What You Need to Know

Dirty Cred: What You Need to Know

Dirty Cred are (now) two `use-after-free` privilege escalation vulnerabilities (CVE-2021-4154 and CVE-2022-2588) in the Linux kernel which can also be utilized for container escape.

The CVE-2021-4154 exploitation was first presented at the Black Hat USA 2022 conference. The researchers demonstrated how the exploit can be used to escalate privileges from unprivileged user to privileged one (root) on Centos 8 and Ubuntu 20.04 machines. 

Type of use-after-free

Objects that are allocated in memory need to be freed so the memory will not be in use after finishing operating. 

Dynamic objects can be freed in two ways:

  1. The memory is freed by the program
  2. The program terminates

Attackers that have no privileges, can allocate an unprivileged object in memory, free the object while still keeping access to this memory section (will be explained later). Then, wait until a privileged object will be allocated in this piece of memory and operate on the new object.

Think about it like selling a house to someone: a fraudster can free their house, sell it to someone and keep the keys for themselves (assuming the new people in the house did not replace the cylinder). They can then use their key to access the house without any permission.

Linux Credentials

Objects in Linux have credentials stored in dedicated caches.

The credentials contain information about the object, for example: SUID, GUID, Permissions, etc.

In task objects, the credentials are held in a structure type ‘struct cred’ called ‘task_cred’, each task points to its credentials by a pointer called ‘cred’ in its task_struct.

In file objects, the credentials are held in a structure type ‘struct cred’ called ‘f_cred’ in place of f_uid and f_gid, each file points to its credentials like this: file->f_cred->fsuid and file->f_cred->fsgid instead of directly file->f_uid and file->f_gid.

Each attack that successfully unexpectedly changes the credentials structure information is a privilege escalation one.

How does the exploit work?

The use-after-free can be utilized for both task credentials and open file credentials.

When using tasks or opening files, an object is created and a section in memory is allocated to host this object.

The object points to its credentials and stays in the allocated memory section until it is freed or until the program is terminated.

Task Credentials

Attackers can run an unprivileged task, free the object from the memory after a while, but still hold it until a new privileged one takes its place and then keep operating as a privileged user.

The disadvantage of this attack is that attackers need to wait for another privileged task to be executed, however, they can try generating privileged tasks and wait for it to take its memory place (use of sudo for example).

File Open Credentials

Attackers can open an unprivileged file for reading or writing, wait for the file permissions to be accessed by the system, and then free the object from its memory place before the file is written to disk. 

Then, the attacker has a window (between privilege checks and writing on disk) in which the file needs to be swapped with another privileged file.

If the files will be able to swap in this time, the attacker will be able to operate on those privileged files.

The disadvantage of this attack is that the time between privilege checks and writing on disk is very short, however, attackers can use some methods to extend this time.

Affected Environments

Only Linux and Android systems are affected by Dirty Cred because these are kernel vulnerabilities.






Red Hat 




Upgrade Oracle:8 kernel-uek to version 0:5.4.17-2136.310.7.el8uek or higher.





Red Hat 



The exploit that was revealed on Black Hat is shared here with an affected environment.


Upgrade the kernel to a patched version according to the relevant OS (see Affected Environments section)


Mitigation requires isolating privileged memory from unprivileged memory. By doing so, most of the kernel privilege escalation vulnerabilities will not be relevant anymore.

Code for patching the kernel was released by the same group here.

Check Exploitability

If you want to check if you are affected by Dirty Cred, you can install our MI-X open source tool and execute the following command:

python3 am_i_exploitable.py –vulnerability_identifier dirty_cred

Reduce your patching efforts by
85% or more in less than 10 minutes