[ad_1]
tl;dr: It is a bug in Apple’s SMB driver KEXT (`com.apple.filesystems.smbfs`).
To see why, let’s look at the panic report:
com.apple.filesystems.smbfs(5.1)[C22A6A50-F264-363E-A2FA-98362C75B80C]@0xfffffe001b609ed0->0xfffffe001b6756d3
The SMB KEXT was loaded into kernel tackle area with a VM allocation vary of 0xfffffe001b6[09ed0–756d3].
Panic(cpu 2 caller 0xfffffe0018bf4840): kfree: addr
0xfffffe4454684000, dimension 444 (offs:0) not present in any zone
@kalloc.c:2668
A synchronous panic was induced by way of the kernel library’s panic() name from throughout the kfree() routine (loaded into 0xfffffe0018bf4840).
What does the backtrace inform us concerning the purpose for the panic?
lr: 0xfffffe00183fe9a8 fp: 0xfffffe8e1c4fef00
lr: 0xfffffe001854382c fp: 0xfffffe8e1c4fef70
lr: 0xfffffe0018541c98 fp: 0xfffffe8e1c4ff060
lr: 0xfffffe00183af8cc fp: 0xfffffe8e1c4ff070
lr: 0xfffffe00183fe29c fp: 0xfffffe8e1c4ff420
lr: 0xfffffe0018bf1cc4 fp: 0xfffffe8e1c4ff440 // 4. panic()
lr: 0xfffffe0018bf4840 fp: 0xfffffe8e1c4ff4c0 // 3. kfree()
lr: 0xfffffe001840fbe8 fp: 0xfffffe8e1c4ff500 // 2. The kernel routine calls kfree()
--> lr: 0xfffffe001b644b30 <-- fp: 0xfffffe8e1c4ff9c0 // 1. SMB calls right into a kernel routine
lr: 0xfffffe001861ae98 fp: 0xfffffe8e1c4ffa20
lr: 0xfffffe001860cd30 fp: 0xfffffe8e1c4ffc40
lr: 0xfffffe00188b2520 fp: 0xfffffe8e1c4ffc80
lr: 0xfffffe0018918944 fp: 0xfffffe8e1c4ffd90
lr: 0xfffffe0018a0ece0 fp: 0xfffffe8e1c4ffe20
lr: 0xfffffe0018541dc8 fp: 0xfffffe8e1c4fff10
lr: 0xfffffe00183af8cc fp: 0xfffffe8e1c4fff20
What that is saying is that the SMB code was attempting to launch a 444-byte area of reminiscence that has already been launched. Which means that one thing misplaced monitor of a useful resource, which is clearly unsuitable, and since the kernel is aware of it is unsuitable, it initiates a panic to forestall any continued operation in a identified inconsistent state.
Double-frees are a basic programming error. They’re simpler to make in kernel code, which is written in an older model of C++ that doesn’t have intrinsic safety mechanisms towards these kinds of errors like extra trendy and higher-level languages do.
It is also not shocking that it is being hit in a driver for SMB, which is code that can solely run when attempting to hook up with a Home windows fileserver. This code path is probably going not examined as extensively in Apple’s automation suites as different items of code, just like the Finder or the Cocoa frameworks: One would want to arrange a bunch of Home windows machines with numerous configurations after which community them to a bunch of Macs in numerous methods, in an effort to hit all of the totally different doable department factors of code execution and circulation sequences. In apply it is vitally tough to realize 100% protection for giant codebases. The result’s that you simply often run into an error like this, and since it is in kernel code, the outcome is not simply an app crashing however the entire system panicking.
The answer is to:
- Improve to the newest macOS, and
- If the issue nonetheless happens, file a bug report with Apple.
[ad_2]