The NvStreamKms.sys driver calls PsSetCreateProcessNotifyRoutineEx to set up a process creation notification routine. In this particular routine, wcscpy_s is used incorrectly here, as the second argument is not the size of |Dst|, but rather the calculated size of the filename. |Dst| is a stack buffer that is at least 255 characters long. The the maximum component paths of most filesystems on Windows have a limit that is <= 255 though, so this shouldn't be an issue on normal filesystems. However, one can pass UNC paths to CreateProcessW containing forward slashes as the path delimiter, which means that the extracted filename here can be "a/b/c/...", leading to a buffer overflow. Additionally, this function has no stack cookie.
The DxgkDdiEscape handler for 0x600000D passes an unchecked user provided pointer as the destination for a memcpy call, leading to kernel memory corruption. The PoC requires WDK for D3DKMTEscape and can be reproduced by compiling the PoC as a x64 binary and running it. It looks like many of the other escape handlers in the same function has similar issues with writing to user provided pointers in an unchecked way.
The DxgkDdiEscape handler for 0x7000194 doesn't do bounds checking with the user provided lengths it receives. When these lengths are passed to memcpy, overreads and memory corruption can occur. The PoC provided causes an OOB read, but it should be possible to pass an input that results in the third memcpy being executed instead of the first two, which leads to kernel memory corruption (OOB write).
The DxgkDdiEscape handler for 0x700010d accepts a user provided pointer as the destination for a memcpy call, without doing any checks on said pointer. This can lead to a SYSTEM_SERVICE_EXCEPTION (3b) when a write to 0x4141414141414141 is attempted. To reproduce, compile the PoC as a x64 binary (requires linking with setupapi.lib, and WDK for D3DKMTEscape), and run.
ExAllocatePoolWithTag is called with a user provided size to allocate a buffer, but the subsequent copying of said buffer to the user provided pointer doesn't make sense since the buffer is never initialised with any values. This means that a user mode program can leak uninitialised memory from arbitrarily-sized pool allocations.
When the kernel process this ool ports descriptor in ipc_kmsg_copyin_ool_ports_descriptor it will kalloc a buffer large enough for all the ports and then copyin and convert them all. It does this using the init_port_set.count value, not init_port_setCnt. The generated MIG code however calls mach_ports_register like this without verifying that In0P->init_port_setCnt is equal to init_port_set.count, which leads to a buffer overflow vulnerability.
IOSurfaceRootUserClient stores a task struct pointer (passed in via IOServiceOpen) in the field at +0xf0 without taking a reference. By killing the corrisponding task we can free this pointer leaving the user client with a dangling pointer. We can get this pointer used by calling the create_surface_fast_path external method which will try to read and use the memory map off of the free'd task struct. This bug could be leveraged for kernel memory corruption and is reachable from interesting sandboxes including safari and chrome.
A vulnerability in Serendipity 2.0.4 allows an attacker to inject malicious JavaScript code into the 'Entry Body' input field. This code is then stored in the database and executed when the page is viewed by other users.
Stack-based buffer overflow in the PlayMacro function in ObjectXMacro.ObjectXMacro in WdMacCtl.ocx in Micro Focus Rumba 9.x before 9.3 HF 11997 and 9.4.x before 9.4 HF 12815 allows remote attackers to execute arbitrary code via a long MacroName argument.
The application interface allows users to perform certain actions via HTTP requests without performing any validity checks to verify the requests. This can be exploited to perform certain actions with admin privileges if a logged-in user visits a malicious web site.
Services By CQR