When a docx parser encounters an end element, it assumes the pointer to the start element is already available and attempts to operate on it, leading to an out of bounds access immediate before the buffer.
The core issue is the use of MAP_FIXED flag with mmap.Basically `pthread_allocate_stack` for every thread it creates, starting its mapping a new `STACK_SIZE` memory segment to a fixed address (calculated relative to `THREAD_STACK_START_ADDRESS` and the number of threads already allocated)...
In responding to a static file request, the Crow HTTP framework would allocate a 16kb buffer and read the target file into it. It would then send the whole buffer to the client regardless of how many bytes were actually read.
A use-after-free vulnerability in the Crow HTTP Framework owing to the input reader being agnostic to HTTP Pipelining (sending more than one HTTP request without waiting for a response on the same connection) and asynchronous workers tracking state expecting one request per connection.
The two null-dereferences are pretty straight forward instances, the first being that when an error happens early on, a buffer is never assigned a value after the initial `NULL` assignment.In generic error handling code, it gets dereferenced assuming the error happened after it had been setup...
Plenty of background regarding even getting to a place to start hunting for bugs on this printer, leading up two heap based overflows in `pjcc_act_checkUserPassword2`, and some discussion about exploiting the DryOS heap allocator.
The majority of this post is going into background on Fuchsia and exploiting a fake vulnerability, there was one novel vulnerability that the author came across though.To obtain a KASLR bypass, the author thought to try and gain access to the kernel log for any pointers that might be leaked...
Three bugs for one guest-to-host escape.
On its own a pretty simple overflow.There exists a buffer for up to 32 elements to be read into, but the value that is used to determine how many elements to copy is not bounded and can be as high as 255...
Taking an unexpected reference to a `memoryview` object resulting in a use-after-free when the parent of said object is destroyed.Though this is a rather low impact bug because it requires control over the code being executed, so one could just write an `os.system(...)` call or something similar...