IOSharedDataQueue is used by OS X kernel drivers to implement a user/kernel queue in shared memory.
The memory which is mapped into userspace is represented by the variable-sized struct IODataQueueMemory:
typedef struct _IODataQueueMemory {
UInt32 queueSize;
volatile UInt32 head;
volatile UInt32 tail;
IODataQueueEntry queue[1];
} IODataQueueMemory;
This is allocated on the kernel heap with IOMallocAligned (the size is rounded up to the nearest page_size multiple.) This size is stored in the queueSize field.
Kernel code can call IOSharedDataQueue::getMemoryDescriptor to wrap these pages in an IOMemoryDescriptor which can then be mapped into the userspace task (via IOConnectMapMemory.)
When the IOSharedDataQueue is destructed its ::free method passes the queueSize to kmem_free, which simply removes the corresponding number of pages from the kernel_map. If userspace increased the value of the queueSize field this will remove more pages than were allocated - potentially removing other live allocations from the map.
This could be leveraged for code execution by, for example, forcing these free pages to be reallocated with controlled data before they are accessed.
The memory which is mapped into userspace is represented by the variable-sized struct IODataQueueMemory:
typedef struct _IODataQueueMemory {
UInt32 queueSize;
volatile UInt32 head;
volatile UInt32 tail;
IODataQueueEntry queue[1];
} IODataQueueMemory;
This is allocated on the kernel heap with IOMallocAligned (the size is rounded up to the nearest page_size multiple.) This size is stored in the queueSize field.
Kernel code can call IOSharedDataQueue::getMemoryDescriptor to wrap these pages in an IOMemoryDescriptor which can then be mapped into the userspace task (via IOConnectMapMemory.)
When the IOSharedDataQueue is destructed its ::free method passes the queueSize to kmem_free, which simply removes the corresponding number of pages from the kernel_map. If userspace increased the value of the queueSize field this will remove more pages than were allocated - potentially removing other live allocations from the map.
This could be leveraged for code execution by, for example, forcing these free pages to be reallocated with controlled data before they are accessed.
more here.............https://code.google.com/p/google-security-research/issues/detail?id=35