Error Loading Kext in Mojave

You might want to post the exact command you're using to load, whether you're running it as root, and whether a command like kextutil -tn <kext> complains about anything

What TyngJJ said plus…

• Exactly which version of 10.14.x you’re using (later versions have notarisation requirements)?

• Whether your KEXT is notarised?

• Whether you have SIP enabled?

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@apple.com"

Hi,

The error I'm having is the following

Code Block ssh
Error making temporary directory: 1
Memory allocation failure.
Unable to stage kext (kext.kext) to secure location.

But I managed to solve it with this solution:

Code Block 
Based on the temporary directory error, can you check the permissions and flags for the following:
 `/private/var/db/KernelExtensionManagement` should be 0755 with the "restricted" flag set, and the `com.apple.rootless` attribute set to `KernelExtensionManagement` (you can check the value of the attribute with `xattr -l`)
 `/private/var/db/KernelExtensionManagement/Staging` should be 0755 with the "restricted" flag set.

Full answer can be found in this Github Issue

Hello guys,

We are having the exact same problem with a growing number of our users.
We have identified that the error is caused by the missing "restricted" flag on /private/var/db/KernelExtensionManagement, and we have verified that restoring this flag does fix the issue (requires booting in recovery mode, as explained in the github issue mentioned by 0x0A9).

Sadly, the story is not over: some users have reported that the problem was back after installing or updating our product.

What we are trying to understand now is what causes the "restricted" flag to be removed.
The /private/var/db/KernelExtensionManagement folder is protected by SIP, we should not be able to change it by mistake during the installation process. So I guess it is a side effect of what we are doing to install or update our kext.

Did anything change in the way Apple handles the installation or update of a kernel extension recently, maybe as part of the security updates that were published in the past months for 10.15, 10.14 and 10.13 ? Is there any change in the recommended procedure for that ?

We have reports of several of our customers having this issue. Have you any idea of what could cause this problem? This folder is protected by SIP so no one except Apple should be allowed to modify flags of this folder, right?

Hi guys and @eskimo,

We are also having the exact same problem with a growing number of our users.

For the recent customer, his macOS is 10.14.6, SIP enabled, our KEXT is notarized and can be loaded after customer reinstall 10.14.6.
Customer mentioned that he apply mac security update "2020-005" before issue occurred.
But from the release note, it should not be related to missing "restricted" flag.

Do you have any idea?

Thank you!

Hello All,

We are also having this issue.

Setting "restricted" flag to /private/var/db/KernelExtensionManagement has worked so far.

Code Block 
drwxr-xr-x@ 3 root  wheel      -    KernelExtensionManagement
drwxr-xr-x@ 3 root  wheel    restricted   KernelExtensionManagement

Thank you to 0x0A9

We're seeing exactly the same issue at Malwarebytes. Specifically, we're seeing some customers where:

1. kext activation fails

2. /private/var/db/KernelExtensionManagement is missing the restricted flag

3. Adding the restricted flag to the folder from recovery mode fixes the issue

We have seen this happening for users on High Sierra and Mojave. We have no idea at this point if it also affects Catalina, as we don't use a kext on Catalina anymore, and haven't for months.

On affected systems, the results of kextutil -tn /Library/Application\ Support/Malwarebytes/MBAM/Kext/MB_MBAM_Protection.kext 2>&1 are as follows:

Code Block 
Error making temporary directory: 1
Memory allocation failure.
Unable to stage kext (/Library/Application Support/Malwarebytes/MBAM/Kext/MB_MBAM_Protection.kext) to secure location.

Our kext is notarized, and the affected users all have SIP enabled.

I've filed a bug report (FB8812838).