# US-S5-1 — SLAB freelist random (defconfig); Yama off like GOLDEN

**Track**: AXP Resurection Pro Magisk, unlocked sunfish.  
**On top of**: Stage1 + combo4 + FORTIFY + CVE clean-429 + hi-batch1–3.

## Why

High-offset KEEP CVEs are already on the ship pack. Remaining ge200 KEPT
items were **nf_tables** (`CVE-2023-3777`, `CVE-2024-26643`) — skipped on
purpose in batch3. Next attributable kernel depth without reopening CVE
quarantine:

| Knob | Before | After | Attribution |
|------|--------|-------|-------------|
| `CONFIG_SECURITY_YAMA` | unset (but `CONFIG_LSM` listed yama) | unset | GOLDEN 4.14.355 config: not set |
| `CONFIG_SLAB_FREELIST_RANDOM` | unset | `=y` | Graphene/AH slab hardening companion to existing `SLAB_FREELIST_HARDENED` |

Yama was `=y` from `162840Z` until 2026-10-10. With `apply_009_yama_ptrace.py`
init set `ptrace_scope=2`, which denies PairIP's self-ptrace. Wallapop then
died with SIGSEGV right after `libpairipcore.so` loaded. dmesg showed
`ptrace attach of "com.wallapop"[…] was attempted by "com.wallapop"[…]`.
With `persist.native_debug=true` (scope 0), LAB passed PairIP. GOLDEN has no
Yama, so AXP's init writes are inert there. The AXP init/sepolicy patch stays,
inert in the same way.

## Apply

```bash
bash vendor/sunfish-a16/patches/009-kernel-hardening/apply_uss5_1_defconfig.sh \
  kernel/google/msm-4.14
```

Wired into `scripts/009-bacon-axp-stage1-combo4-cve-hi-releasekeys.sh` after
Stage1+combo4+CVE apply.

## LAB verify

```text
zcat /proc/config.gz | grep 'CONFIG_SECURITY_YAMA is not set'
zcat /proc/config.gz | grep CONFIG_SLAB_FREELIST_RANDOM=y
ls /proc/sys/kernel/yama                 # expect: no such file
pidof magiskd                            # still up
```

## Out of scope here

- The original `CVE-2022-49980/ANY/0001.patch` remains denylisted. The next
  isolated bacon applies `ports/cve-2022-49980-lock-scope.patch` instead.
- nf_tables high-offset CVEs
- Stage1 slab FAIL patches (`0010`/`0018` still reject on this tree)
- `hardened_malloc` / bootloader lock