Resources

People often ask me "How did you learn how to hack?" The answer: by reading. This page is a collection of the blog posts and other articles that I have accumulated over the years of my journey. Enjoy!

When programming in multi-threaded applications, concurrent access can cause many security bugs. A protection for this is to add a lock to the data to ensure that only one thread can use this variable at a time. The other thread must wait for this to occur.

Mutexes and locks do have the chance to setup dead locks, where the thread is completely stuck in its state. Additionally, where should the lock go on a variable? In functions deeper down the stack? Up top? There is no census on this.

As a result, a user may want to call a function that locks a variable they have already set a lock on. In order to fix this problem, the thread will temporarily drop the lock to let the function using the variable to lock it. However, this leaves a very small window of opportunity for something else to claim this memory or do something malicious to it.

Considering this is an obvious code-smell, this is not the first or last time you will see this bug. In this case, when inp_join_group needs to create a new membership entry, it briefly releases the sockets lock. Since this pointer is passed into a local variable, when the lock gets drop, a concurrent call to this function could make the pointer in the local variable invalid.

The race condition can lead to a use after free vulnerability that is likely exploitable. This same bug exists in the IPv6 stack as well.

Overall, this is an interesting bug that was found via code review. Going forward, this is a code smell that I will look for on multi-threaded applications.