1

When I insert a USB, macOS system (running High Sierra, Mavericks, Mojave) restarts or freezes with a panic report:

Panic Report:

panic(cpu 0 caller 0xffffff801e4ba207): "a freed zone element has been modified in zone kalloc.16: 
expected 0x3f0011b64302a888 but found 0x3f0011b64302a800, bits changed 0x88, at offset 0 of 16 in element 0xffffff8030ed5ac0, 
cookies 0x3f0011b64302a888 0x5352105058b7571"
@/BuildRoot/Library/Caches/com.apple.xbs/Sources/xnu/xnu-4570.71.2/osfmk/kern/zalloc.c:1122

What exactly does "a freed zone element has been modified in zone kalloc.16" mean and how we get it resolved?

the kernel is getting panic when I am using a third party kernel extension to which I have modified and that deals with USB control. could you please suggest me any of debugging method of kext too.

bhardwaj_himanshu
  • 21
  • Explaining what a kernel panic is far too broad for an answer here without some very specific assumptions on experience level. Why not focus on how to triage / resolve this? One question per question is best practice here. – bmike Apr 23 '19 at 08:31
  • 1
    See What is a Kernel Panic and what does it mean? for a useful starting point. – Graham Miln Apr 23 '19 at 08:46
  • @bmike i am using a third party extension that can be a cause to system panic but i am not figuring out this panic is because of the memory or not as reported in panic report,for debugging this issue i use two machine debugging method but still not get any clue – bhardwaj_himanshu Apr 23 '19 at 10:22
  • @bhardwaj_himanshu - might be helpful to illustrate what's going on w/ the freed zone bit - https://objective-see.com/blog/blog_0x1C.html – slm Apr 23 '19 at 12:28
  • Because this question is marked as a duplicate (which is questionable as the duplicate is very broad) - I cannot provide you with the answer as a real answer unfortunately. However, I can in short terms describe the meaning of the kernel panic for you here in a comment: Basically the operating system kernel manages the memory (RAM) in the computer in order to ensure that two seperate tasks do not use the same piece of memory, which would lead to bugs. For memory used internally by the kernel, it does this by managing a number of zones. A zone is simply a block of memory that the kernel (cont) – jksoegaard Apr 23 '19 at 14:13
  • (cont) wishes to set off for a specific purpose. In this case the zone name is "kalloc.16", which means it is for kernel internal allocations, and that the zone is intended to be used only for allocating blocks of 16 bytes of memory. This is done so that the kernel can quickly get to small blocks of 16 byte size for various temporary contents during operation. Because the blocks are all 16 bytes, it is faster to handle and you do not get memory fragmentation that you would see with differently sized allocations mixed together. In order to know which block sof memory was allocated, it (cont) – jksoegaard Apr 23 '19 at 14:15
  • (cont) maintains a list of memory blocks. Each list element contains pointers (memory adresses) for the next block at the start and end, in addition when an element is freed (i.e. given back to the OS by the task that originally allocated it), it is overwritten with 0xdeadbeef. When the memory is to be allocated again, the OS checks if this value is still written inside, and whether the pointers are still valid (i.e. start and end pointer are the same, etc.). If these requirements are not fulfilled, it means that something tampered with the memory - and you get a kernel panic like the (cont) – jksoegaard Apr 23 '19 at 14:20
  • (cont) one you have there. By the looks of what has been changed, I would guess that you're seeing a so-called "use-after-free" bug. This means that a task allocates the memory, uses it for something and then frees it (gives it back to the OS) - but then tries to use it again afterwards. This is not allowed and indicates a bug in whatever task was using the memory. Usually these kernel panics and bugs of this type are due to third party kernel extensions, such as peripheral device drivers, or software such as VirtualBox, SoundFlower, etc. I would check if you have for example VirtualBox (cont) – jksoegaard Apr 23 '19 at 14:22
  • (cont) installed, and then try uninstalling that to see if it helps the problem. The reason I say VirtualBox is that virtualisation systems usually hook into USB in a manner where they are triggered no matter what kind of USB device is plugged in. It could also be VMware, Parallels Desktop, or another kernel extension. If you find the right one and it works after uninstalling it - then check for updates for that software. – jksoegaard Apr 23 '19 at 14:24
  • @jksoegaard Thanks for this detailed explanation, you are right kernel is getting panic when I am using a third party kernel extension to which I have modified and that deals with USB control. could you please suggest me any of debugging method of kext. – bhardwaj_himanshu Apr 29 '19 at 05:26
  • Well, that would have been useful information to include in your question... please why you modified it, what you modified and how you modified it. – jksoegaard Apr 29 '19 at 06:29
  • @jksoegaard I have modified kext that can interact with userspace from where we can do USB controling – bhardwaj_himanshu Apr 30 '19 at 05:58
  • Which kext did you modify? Why did you modify it? You seem to be intentionally withholding information - why? – jksoegaard Apr 30 '19 at 08:58
  • @jksoegaard I have modified sample kext KauthORama for protecting data theft from my system that can be caused by using any of USB device. – bhardwaj_himanshu May 02 '19 at 06:20
  • It definitely sounds like the wrong approach for protecting against data theft. This sounds like an XY problem in that regard. I would advise opening a separate question on how to beat protect yourself against data theft. Alternative if you insist on your kext: you have simply made a memory management bug in your kext. Put the source code online and we can help debug. Otherwise install a kernel debugger and proceed in that manner. – jksoegaard May 02 '19 at 09:33

0 Answers0