The external methods IGAccelGLContext::unmap_user_memory and IGAccelCLContext::unmap_user_memory take an 8 byte struct input which is a user-space pointer previously passed to the equivilent map_user_memory method. The Context objects have inline IGHashTable members which store a mapping between those user pointers and the IGAccelMemoryMap object pointers to which they refer in the kernel. The unmap_user_memory method calls in order: ::contains, ::get, ::remove on the hashmap *before* taking the context's IOLock. This means we can race two threads and by passing them both a valid mapped user pointer they will both look up the same value in the hash map and return it. The first exploitable bug is that none of these methods are thread safe; it's quite possible for two threads to be in the ::remove method at the same time and call IOFree on the hash bucket list entry resulting in a double free. The second bug is that after the call to ::remove although a lock is taken on the Context by this point it's too late; both threads have a pointer to the same IGAccelMemoryMap which only has one reference. The first thread will call ::release which will free the object, then the thread will drop the lock, the second thread will acquire it and then use the free'd object before calling ::release again.
nvDevice::ReleaseDeviceTexture is external method 0x10a of userclient 5 of the geforce IOAccelerator. It takes a single uint argument. This code is reachable from most interesting sandboxes including the safari renderer and the chrome GPU process.
The ActionScript parameter conversion in the fix for issue 403 can sometimes access a parameter on the native stack that is uninitialized. If mc.swapDepths(); is called in ActionScript, a parameter array is allocated using alloca(0), which leads to a 16-byte (the minimum size length for alloca in the implementation) that does not get initialized. The conversion function in the UaF check then assumes that at least one parameter has been allocated, and attempts to convert the stack parameter to a string, even though it is a previous value (a UTF string 'fffff ... ' in the PoC).
The ActionScript parameter conversion in the fix for an issue in the December Flash bulletin can sometimes access a parameter on the native stack that is uninitialized. If a parameter array is allocated using alloca(0), which leads to a 16-byte (the minimum size length for alloca in the implementation) that does not get initialized, the conversion function in the UaF check then assumes that at least one parameter has been allocated, and attempts to convert the stack parameter to a string, even though it is a previous value (a UTF string “fffff ... ” in the PoC).
There is a use-after-free in Sprite Creation. If a Sprite is created, and then the handler for the frameConstructed event triggers a remove object action, the Sprite is then used after it has been freed.
It is possible for LZX compressed streams to exceed the size of the vector Lzx_Decoder->window which is initialized to a fixed size of 2^method bytes. Writes to the window buffer are bounds checked, but only after the write is completed. This means the overflow still occurs, resulting in memory corruption, and can be corrupted multiple times per stream as a single scan can contain multiple LZX compressed blobs.
A SQL injection vulnerability has been identified in MiCollab 7.0 which, if successfully exploited, could allow an attacker to access sensitive information in the MiCollab database. The vulnerability is due to the unsanitized 'language' parameter in the 'mywindow' and 'PortletSelector' scripts.
A vulnerability in CCTV DVRs of multiple vendors allows an attacker to execute arbitrary code remotely. The vulnerability is due to improper validation of user-supplied input in the web interface of the device. An attacker can exploit this vulnerability by sending a specially crafted HTTP request to the web interface of the device. Successful exploitation of this vulnerability could allow an attacker to execute arbitrary code on the vulnerable device.
The code responsible for loading a suid-binary following a call to the execve syscall invalidates the task port after first swapping the new vm_map into the old task object leaving a short race window where we can manipulate the memory of the euid(0) process before the old task port is destroyed.
CoolPlayer (Standalone) build 2.19 is vulnerable to a stack overflow vulnerability. An attacker can exploit this vulnerability by crafting a malicious .m3u file and sending it to the target user. When the target user opens the malicious file, the attacker can overwrite the EIP and point to ESP (iertutil.dll) to execute shellcode (calc.exe).
Services By CQR