Buffer overflows have been abused in order to compromise software systems for the better part of the last 25 years. In recent years, many restricted solutions to curb their negative effect (stack canaries, frontlink/backlink verification for heap implementations, reordering of local variables) have been proposed and implemented in most popular compilers and operating systems. What is commonly overlooked is that the 'general' problem is the ability of attackers to trigger behaviour that is 'undefined' by the ANSI C99 standard, not the (relatively small) subclass of 'buffer overflow'. A common programming mistake is a situation where under some exceptional conditions a local variable is not initialized prior to its first use. As the local variables are usually allocated on the stack, the memory thus used is not zeroed and may contain values 'left over' from other parts of the program. Most discussions of this topic imply that these values cannot be controlled by an attacker in a meaningful manner, and thus use of uninitialized variables means no security risk beyond a denial-of-service (e.g. application crash). This talk proposes methods with which an attacker can determine the set of functions in a program that are accessing the same memory range that will later on be re-used by the faulty function. By constructing several specialized graphs from the disassembly of a program, it is possible to determine the set of functions that might be used to control the 'uninitialized' values.