| ns RequestMoveApplicationEntity eventually calls a func which: Loops through the input buffer. If any entry has value 6, it will call another func to copy data from state to output safely (uses the max_count param). Otherwise, it copies the input buffer to an outbuf (located on caller's stack) without any size validation (inlined memcpy), even though there is a max_count param.
+
+
Additional memwrites are also done to the above outbuf following the initial memcopy. This can be avoided if the buffer doesn't contain bytes with values 3-6 (if using values in that range is really needed, the cmd input StorageId param can be set to the required value so that the specified value doesn't trigger the memwrite). Value 6 shouldn't be used anyway (see above).
+
+
ns EstimateSizeToMove first calls the same func which does the copy above (outbuf is also located on stack), then it calls another func. Hence, same vuln here.
+
+
By corrupting just the first byte of x29 with EstimateSizeToMove, one can obtain infoleaks. This method with x29 essentially only works with [15.0.0+]. Pre-15.0.0 would require a different method with partial overwrite of retaddr, however it's unknown whether this would actually work for infoleak (would require [12.0.0+] for the stack layout change).
+
With EstimateSizeToMove where x29 is overwritten, the output u64 is the leaked ptr (can be codebin-region). Note that the cmd has to return Result=0 for this to work. x29 is used to load the value which is copied to the cmdreply rawdata.
+
+
As of [17.0.0+] an error is thrown if the input array count is larger than 8 (size of the stack dst-array).