causes loginwindow crashes

Number:rdar://36321050 Date Originated:2018-01-05
Status:Duplicate of 35364639 (Closed) Resolved:
Product:macOS + SDK Product Version:10.13.2
Classification:Bug Reproducible:Always

If /Library/Preferences/ exists, it becomes impossible to login. If the file is created after login it causes crashes in many binaries.

Steps to Reproduce:
1) Create /Library/Preferences/ The content is irrelevant.
2) Reboot, attempt to login.

Expected Results:
Everything works normally.

Actual Results:
Any process that uses HIToolbox.framework (which seems to be a lot of processes, I noticed crashes in loginwindow, efilogin-helper, mds, NotificationCenter and others) will crash with:

abort() called
*** error for object 0x7fff482587bb: Non-aligned pointer being freed

As this causes loginwindow to crash, it becomes impossible to login.

10.13.2 17C88

I've reproduced on multiple machines running 10.13.2. I haven't tested prior OS versions though I have reason to believe they aren't affected.

I can't attach a sysdiagnose as I have confidential software on this machine that I can't share and I don't have time to filter out the data. I /have/ attached crash logs for several system binaries to show the problem.

As the backtraces in each of these has a similar pattern I disassembled the HIToolbox binary and found the problem is caused by the GetInputSourceEnabledPrefs() and CreateReadableDataFromPlist() functions. The former calls the latter in two places, one with an allocated string from expanding a path with a tilde and the other with a hard-coded string (/Library/Preferences/, in the latter case when CreateReadableDataFromPlist() is called it creates a CFString using CFStringCreateWithCStringNoCopy passing NULL as the final argument. When this CFString is released at the end of the function it tries to dealloc() the original c-string. 

I imagine this could be easily fixed by passing kCFAllocatorNull as the final argument to CFStringCreateWithCStringNoCopy in CreateReadableDataFromPlist() and in the case where the path was created (using CreatePathByExpandingTidlePath) manually deallocing the string once it's no longer needed.


Please note: Reports posted here will not necessarily be seen by Apple. All problems should be submitted at before they are posted here. Please only post information for Radars that you have filed yourself, and please do not include Apple confidential information in your posts. Thank you!