Skip to main content

SMB Flaws in macOS

· 3 min read
Alex Radocea
Dave G

Supernetworks macOS SMB Client Vulnerabilities

What to Know​

Supernetworks identified several vulnerabilities in macOS Sequoia’s SMB client code.
The worst of which can result in remote kernel code execution via an SMB URL delivered through any application that allows clickable URLs (e.g. messaging apps. Browsers, email client). This isn’t necessarily a one click attack, as a user may need to click through some UI elements to trigger the exploit. A privileged network position could also be used to carry out a man-in-the-middle attack against a user that typically uses SMB shares. It goes without saying that this also operates as a local privilege escalation from a non privileged user to kernel code execution.

Executive Summary​

SMBClient is the codebase responsible for handling file sharing connections to remote file servers. This codebase contains a mix of userland and kernel code to allow users to mount Windows and macOS file servers. A significant portion of the SMB protocol management occurs exclusively in the smbfs kernel extension, which in turn means that SMB represents a kernel attack surface to attackers.

While iOS does have SMB support via Files.app, it does not appear to be impacted by any of these vulnerabilities and implements some portion of SMB in userland in addition to not supporting the compression feature.

CVE-2025-24269​

This vulnerability is due to a heap overflow within the smb compression code, where an untrusted length value is read from the server and never validated. The flaw relates to the same part of the protocol implementation flaw that affected SMBGhost (CVE-2020-0796) Windows vulnerability.

CVE-2025-24269 is also the kind of flaw an LLM happens to be decent at discovering. The commented out code path has a helpful prompt stating developer exasperation.

#if 0
                    /*
                     * Oddly, Windows server will send a compress length that
                     * is bigger than the decompressed length which will cause
                     * this check to fail. Why they dont just send the non
                     * compressed data?
                     *
                     * Sanity check the compress length
                     */
                    if (compress_len > (originalCompressedSegmentSize - CurrentDecompressedDataSize)) {  [2]
                        SMBERROR("Algorithm %d compress_len %d > remaining to decompress len %d? \n",
                                 algorithm, compress_len,
                                 (originalCompressedSegmentSize - CurrentDecompressedDataSize));
                        error = EINVAL;
                        goto bad;
                    }
#endif
…

As the buffer is in a data zone, exploitation will require finding kernel space data buffers worth corrupting remotely, or a bypass of Apple's heap zone hardening countermeasures.

Other vulnerabilities​

Our testing also uncovered:

  • KerberosHelper: Remote _asn1_free() on uninitialized stack variable in _KRBDecodeNegTokenInit (CVE-2025-24235)
  • Smbfs.kext: Session_list corruption via smb_sm_lookupint (CVE-2025-30444)
  • Smbfs.kext: Unprivileged SIGTERM via SMBIOC_UPDATE_NOTIFIER_PID (No CVE)

On Linux Doyensec found a substantial series of flaws with ksmbd, which Sean Heelan has also been using to evaluate o3 and other LLM's bug finding abilities. After SMBleed and SMBGhost, more flaws keep popping up in Microsoft's implementation as well.

Remediation​

These issues were fixed in macOS 15.4.

Technical Details​

The technical details for these vulnerabilities can be found at:

https://www.supernetworks.org/advisories/smbclient-2025.html.