In Snapdragon (Automobile ,Mobile) in version MSM8996AU, SD 425, SD 427, SD 430, SD 435, SD 450, SD 625, SD 650/52, SD 820, SD 820A, SD 835, SDA660, SDM429, SDM439, SDM630, SDM632, SDM636, SDM660, Snapdragon_High_Med_2016, a crafted HLOS client can modify the structure in memory passed to a QSEE application between the time of check and the time of use, resulting in arbitrary writes to TZ kernel memory regions.
In Snapdragon (Automobile, Mobile, Wear) in version MDM9206, MDM9607, MDM9615, MDM9640, MDM9650, MDM9655, MSM8996AU, SD 210/SD 212/SD 205, SD 410/12, SD 425, SD 427, SD 430, SD 435, SD 450, SD 600, SD 615/16/SD 415, SD 617, SD 625, SD 650/52, SD 820, SD 820A, SD 835, SD 845, SD 850, SDA660, SDM429, SDM439, SDM630, SDM632, SDM636, SDM660, SDX20, Snapdragon_High_Med_2016, when sending an malformed XML data to deviceprogrammer/firehose it may do an out of bounds buffer write allowing a region of memory to be filled with 0x20.
Due to Improper Access Control of NAND-based EFS in Snapdragon Automobile, Snapdragon Mobile and Snapdragon Wear, From fastboot on a NAND-based device, the EFS partition can be erased. Apps processor then has non-secure world full read/write access to the partition until the modem boots and configures the EFS partition addresses in its MPU partition.
In Android before 2018-04-05 or earlier security patch level on Qualcomm Snapdragon Mobile MDM9635M, MDM9645, MDM9650, MDM9655, SD 210/SD 212/SD 205, SD 400, SD 410/12, SD 425, SD 427, SD 430, SD 435, SD 450, SD 615/16/SD 415, SD 617, SD 625, SD 650/52, SD 810, SDM630, SDM636, SDM660, and Snapdragon_High_Med_2016, stopping of the DTR prematurely causes micro kernel to be stuck. This can be triggered with a timing change injectable in RACH procedure.
In Android before 2018-04-05 or earlier security patch level on Qualcomm Snapdragon Mobile SD 210/SD 212/SD 205, SD 410/12, SD 425, SD 427, SD 430, SD 435, SD 450, SD 615/16/SD 415, SD 617, SD 625, SD 650/52, SD 808, SD 810, SD 820, SD 835, SD 845, SDM630, SDM636, SDM660, SDX20, and Snapdragon_High_Med_2016, the 'proper' solution for this will be to ensure that any users of qsee_log in the bootchain (before Linux boots) unallocate their buffers and clear the qsee_log pointer. Until support for that is implemented in TZ and the bootloader, enable tz_log to avoid potential scribbling. This solution will prevent the linux kernel memory corruption.