AXP-Resurection/vendor/sunfish-a16/patches/009-kernel-hardening/uss5-1-README.md

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 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

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