setrlimit read the guest rlimit struct directly, so a non-null pointer
into unmapped memory crashed the host. It now copies the struct in with
GuestCopyIn_nid_no_patch together with the existing null check, before
the resource check, as FreeBSD's sys_setrlimit copies in before
kern_setrlimit validates the resource, and fails with EFAULT.
Probe p87_libkernel lines 7-27: a payload process on a PS5 returns 0 and keeps the limits for a raised RLIMIT_DATA or RLIMIT_STACK hard limit, and reads back RLIMIT_CORE soft limits.
In a payload process on a PS5 (firmware 12.70), getrlimit returns
0x200000 for RLIMIT_STACK, infinity for RLIMIT_RSS and RLIMIT_MEMLOCK,
and 1604 for RLIMIT_NPROC, each as both soft and hard limit. These four
threw here. Whether a title process reads the same limits is not
measured.
setrlimit reads getrlimit first, so it now accepts RLIMIT_STACK,
RLIMIT_RSS and RLIMIT_MEMLOCK when the values do not change, as the
payload process does. RLIMIT_NPROC throws: in the payload process
setting it to its current value succeeds, but getrlimit then reads 1443,
and the limit is not stored here. Any other change still throws. The
getrlimit and setrlimit debt entries also record the payload process's
RLIMIT_DATA and RLIMIT_NOFILE readings, its 12555 clamp of RLIMIT_NOFILE
and its RLIMIT_NPROC reading after a same-value set.
AI-assisted: yes
Co-Authored-By: Claude Opus 5.5 <[email protected]>
Adrià