macOS audit kernel bug triggers panic
Free public brief. The indicators, the detections with Splunk SPL already written (plus Elastic and KQL where they apply), and a Slack alert the next time this touches a vendor you run are in the app — free account, no card.
Researcher found an off-by-one read bug in macOS XNU's audit_arg_sockaddr() causing kernel panics, patched by Apple in 10.12.4.
Patrick Wardle of Objective-See details how benign user-mode code in his RansomWhere? tool inadvertently triggered a recurring macOS kernel panic. Investigation traced the crash to the audit_arg_sockaddr() function in XNU's BSD audit subsystem (bsd/security/audit/audit_arg.c), which is invoked whenever a user-mode process (such as RansomWhere? or Apple's praudit) enables kernel auditing. The bug is a classic off-by-one read: when calculating the length of an AF_UNIX socket path (sun_path), the code can read one byte past the end of a sockaddr_un structure. If that structure happens to be allocated at the very end of a memory page, the out-of-bounds read crosses into an unmapped page, causing an unhandled page fault and kernel panic (type 14). The author walks through full crash-dump and IDA-based root-cause analysis, including register and memory-layout reconstruction, and notes this off-by-one may be an intentional (if risky) pattern borrowed from similar Linux unix_mkname() handling that assumes guaranteed valid adjacent memory — an assumption that does not reliably hold on macOS.
The bug was reported to Apple and patched in macOS 10.12.4, released the same day as this post. As a read-only out-of-bounds access, the author assesses it as a denial-of-service issue (triggerable by any user-mode code enabling auditing) rather than directly exploitable for code execution, but notes malware could abuse it to crash audited systems. The article explicitly teases a second, more serious bug in the same function — a heap buffer overflow reachable via a bcopy() call using attacker-controlled sa->sa_len — which the author states is exploitable for arbitrary unsigned kernel code execution, to be detailed in Part II of the series. No CVE identifier is given in this article, no in-the-wild exploitation is reported, and defenders running macOS prior to 10.12.4 should ensure they are patched; the piece is primarily of interest to macOS security researchers and kernel extension/audit-event consumers.
Source reporting: https://objective-see.org/blog/blog_0x1A.html
What this brief leaves out
This page is the free tier: the write-up, the severity, the names. In the app the same report carries its extracted indicators, its detections (Splunk SPL already written, plus Elastic and Microsoft KQL where they apply), the actors and CVEs it names as live profiles, and the vendor research on the same campaign — the primary source the news paraphrased, cited and read directly.
It sits in a corpus of 13,853 reports from 146 sources, 616 of them written in the last seven days, and it grows through the day.
A new account starts with three days of all of it, no card, then keeps the government and CERT reporting free. Name the vendors you run and Slack hears about the reports that touch them — about forty a week that are yours, not the four hundred that are not.
Create a free account What it costs