An in-the-wild exploit chain was discovered that exploits three vulnerabilities in Samsung exynos devices running kernel 4.14.113. It consisted of one userland exploit in Samsung’s custom clipboard provider, a kernel infoleak through their sec_log functionality, and finally a UAF in the Display Processing Unit (DPU) driver.

1. File read/write via Samsung clipboard provider The Samsung clipboard provider is accessible via the system server, and is typically used for images. It maintains a database of IDs to URI paths to the backing file to open. The problem is, a calling process can insert URIs into the database by using the clipboard’s content provider. By inserting your malicious URI via _data, you can obtain a raw file descriptor to any file the system server has access to, essentially giving you a privilege escalation as you can access files your regular process wouldn’t have access to.

2. Infoleak via sec_log Samsung has a custom logging file, /data/log/sec_log.log. Interestingly, this file is accessible to system_app context even though the normal kmsg is privileged off. Samsung copies kmsg contents into sec_log.log, and so by triggering a warning or any other action that dumps register contents to logs, kernel pointers could be obtained to defeat kASLR. They chained this with the first vulnerability to get a handle to sec_log.log, and triggered a warning in the Mali GPU driver via providing an invalid hwcnt ioctl.

3. UAF in DPU kernel driver Finally, the chain gets kernel read/write via a UAF in the decon_set_win_config() function for the display and enhancement controller. This function would create a DMA fence and install a file descriptor labelled as retire_fence. Once installed, its in the process FD table and thus can be accessed by anyone in the process. Later in this function, decon_create_release_fences() is called, which installs another FD with the same backing file for rel_fence. An attacker can close the installed file descriptor before decon_create_release_fences() is called, and cause a UAF on the backing file object.

The way this was exploited was to point the file’s private_data to the kernel addr_limit. They then used signalfd() to set the addr_limit and get arbitrary read/write via a pipe. While devices would have User-Access-Overwrite (UAO) and Privileged Access Never (PAN), since the attacker has arbitrary write to the addr_limit, they can set it as needed when passing data across and these mitigations are not effective in preventing arbitrary read/write.