Off-by-one issue as the bounds check if (written_out > max_out) will continue for one extra iteration after it has written max_out number of integers.

The root of the issue is that XSLTC (turns XSLT into a Java Class to be executed for better performance) does not account for that fact that the constant_pool_count in a Java class is only 16bits. An attacker can create an XSLT document containing too many constants, all of which will be written to the class file, but the count will be truncated to 16bits, leading to some of those constants being interpreted as part of the classfile containing things like field and method descriptions for the class.

The whole post gets deep into the background how XSLT is exposed through SAML assertions and verifying signatures (so part of the unauthenticated attack-surface) and into the details of actually crafting a valid classfile abusing this integer truncation.

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.