This issue resides in the nt!ObpCreateSymbolicLinkName syscall for creating symbolic links. One of the first things it does is creates a user handle for the symbolic link object. This handle can be used by other symbolic link related syscalls, like nt!ObpDeleteSymbolicLinkName. Because of insufficient locking, as soon as the create syscall installs this handler, another thread can run and manipulate the symbolic link object before nt!ObpCreateSymbolicLinkName is finished with it. This leads to an race where the delete syscall can swap in a 0 for the DosDeviceDriverIndex field that’s used to access into an array later in the create syscall. When the create syscall decrements the index as part of it’s regular codepath, it accesses the drive table array out of bounds at -1.