19
edits
Changes
Jump to navigation
Jump to search
Line 470:
Line 470: − + − + − + + − +
no edit summary
derrek's original 32c3 presentation for memchunkhax2 commented that a GPU-based attack was possible, but would be difficult. However, memchunkhax2.1 showed that it was possible to do fairly reliably.
derrek's original 32c3 presentation for memchunkhax2 commented that a GPU-based attack was possible, but would be difficult. However, memchunkhax2.1 showed that it was possible to do fairly reliably.
| ARM11 kernel code execution
| ARM11 kernel code execution
| None
| [[11.0.0-33|11.0.0-X]], via the new [[Memory_Management#MemoryBlockHeader|memchunkhdr]] MAC which prevents modifying memchunkhdr data with DMA.
| [[10.4.0-29|10.4.0-X]]
| [[11.0.0-33|11.0.0-X]]
|
|
| derrek, aliaspider
| derrek, aliaspider
|-
|-
| memchunkhax2
| memchunkhax2
|
| When allocating a block of memory, the "next" pointer of the [[Memory_Management#MemoryBlockHeader|memchunkhdr]] is accessed without being checked after being mapped to userland.
This allows a race condition, where the process can change the next pointer just before it's accessed. By pointing the next pointer to a crafted memchunckhdr in the kernel SlabHeap, some of the SlabHeap is allocated to the calling process, allowing to change vtables of kernel objects.
| ARM11 kernel code execution
| ARM11 kernel code execution
| [[10.4.0-29|10.4.0-X]] (partially)
| [[10.4.0-29|10.4.0-X]] (partially, see memchunkhax2.1)
| [[10.4.0-29|10.4.0-X]]
| [[10.4.0-29|10.4.0-X]]
|
|