There is a sensitive information disclosure vulnerability in the vision DSP kernel driver of S20 Exynos devices. The vulnerability can be used by malicious privileged applications to read the kernel’s and other application’s memory.
Vulnerability Details The Exynos DSP driver implements an ioctl call that allows applications to upload a custom model (graph) for the dsp device. The DSP_IOC_LOAD_GRAPH ioctl handler of the /dev/dsp device receives an array of Unix paths of the graph files to be loaded. This array has a complex structure, it begins with an array of integers that contains the length of each path. The array of lengths is followed by the actual path strings, one after the other, delimited by the length values.
There is a kernel virtual memory mapped IO buffer overflow vulnerability in the vision DSP kernel driver of S20 Exynos devices. The vulnerability could potentially be used by a malicious system application to compromise the kernel and gain further privileges.
The vulnerability is only triggerable via compromised system applications due to a second access control bypass issue. In addition to achieving code execution in the kernel, the access control bypass issue itself may also be used by compromised system applications to directly take complete control over the DSP device itself.
Vulnerability Details The Exynos DSP driver implements an ioctl call that allows applications to upload a custom model (graph) for the dsp device.
There is a vmalloc out of bounds write vulnerability in the vision DSP kernel driver of Samsung Exynos S20 devices. The vulnerability could potentially be used by a malicious system application to compromise the kernel and gain further privileges.
Vulnerability Details The Exynos DSP driver implements two distinct ioctl calls that are used to load images and graphs and boot the device. The DSP_IOC_BOOT ioctl loads the dsp’s firmware images, common libraries, an xml global kernel descriptor file and a linker file for linking libraries. The DSP_IOC_LOAD_GRAPH ioctl is responsible for creating a shared memory region between the dsp device and user space and for loading the custom graph models implemented in elf libraries.
There is an ION memory buffer type confusion vulnerability in the Exynos ION kernel driver. The vulnerability can cause zero initialised memory to be treated as a valid pointer and cause a kernel NULL pointer exception. Untrusted applications can abuse this bug to cause a kernel crash and carry out DOS attacks agains the device.
Vulnerability Details The vulnerable code is in ion_iovmm_map in drivers/staging/android/ion/ion_exynos.c, the function is used to map an ion buffer into the bus’s io address space, to make it available for dma capable external devices and returns this dma address. The function has a fast path for buffers marked with ION_FLAG_PROTECTED and returns their associated, preinitialised prot->dma_addr pointers.
There are a series of memory corruption vulnerabilities in Samsung Exynos kernels, due to improper error checks, after dma_buf_vmap calls. These bugs can be abused by various privileged processes to cause NULL pointer accesses and crash the kernel.
Vulnerability Details The kernel uses the dma_buf_vmap function if it needs to map a dma buffer into the kernel address space to access its content. This function returns a NULL pointer if it encounters an error during its execution. While some drivers employ a null check on the returned pointer, many call sites incorrectly use the IS_ERR macro which explicitly allows NULL pointers.
Summary Due to a race condition in input validation, the SCrypto implementation of the drTima secure driver (uuid ffffffffd0000000000000000000000a) was susceptible to a buffer overflow.
The drTima secure driver implements a fully featured crypto engine entirely in software, called SCrypto. The SCrypto APIs are callable by all Trustlets without restriction. SCrypto is in fact the OpenSSL’s FIPS compliant library with an abstraction layer added to facilitate the same APIs for crypto operations that are present between Trustlets and Secure Drivers.
The SCrypto command implements three kinds of functions: hashing (MD function family), encryption/decryption (3DES, AES, RSA), and signing (RSA).
The race condition vulnerability is in the ciphering command implementation of RSA decryption.
Summary Due to a race condition in input validation, the SCrypto implementation of the drTima secure driver (uuid ffffffffd0000000000000000000000a) was susceptible to a buffer overflow.
The drTima secure driver implements a fully featured crypto engine entirely in software, called SCrypto. The SCrypto APIs are callable by all Trustlets without restriction. SCrypto is in fact the OpenSSL’s FIPS compliant library with an abstraction layer added to facilitate the same APIs for crypto operations that are present between Trustlets and Secure Drivers.
The SCrypto command implements three kinds of functions: hashing (MD function family), encryption/decryption (3DES, AES, RSA), and signing (RSA).
The race condition vulnerability is in the ciphering command implementation of RSA encryption.
Summary Due to missing input validation, the SCrypto implementation of the drTima secure driver (uuid ffffffffd0000000000000000000000a) was susceptible to a buffer overflow.
The drTima secure driver implements a fully featured crypto engine entirely in software, called SCrypto. The SCrypto APIs are callable by all Trustlets without restriction. SCrypto is in fact the OpenSSL’s FIPS compliant library with an abstraction layer added to facilitate the same APIs for crypto operations that are present between Trustlets and Secure Drivers.
The SCrypto command implements three kinds of functions: hashing (MD function family), encryption/decryption (3DES, AES, RSA), and signing (RSA).
For each type, there are two types of implementations: