When the stack freelists are empty, stack_alloc_internal() allocates a new kernel stack However, I believe that this can also be used to disclose kernel heap memory. The returned data seems to come from the previous syscall: Just leaking stack data from a previous syscall seems to mostly return the upper halfes of some kernel pointers. The following test results come from a Macmini7,1 running macOS 10.13 (17A405), Darwin 17.0.0. This padding is not initialized, but is copied to userspace. User64_long_t ru_maxrss // max resident set size Struct user64_timeval ru_stime // system time used Struct user64_timeval ru_utime // user time used #define _STRUCT_USER64_TIMEVAL struct user64_timeval `struct user64_rusage` contains four bytes of struct padding behind each `tv_usec` element: timeval changes size, so utime and stime need special handlingĪ_user_rusage_p->ru_sec = a_rusage_p->ru_sec Ī_user_rusage_p->ru_usec = a_rusage_p->ru_usec Ī_user_rusage_p->ru_sec = a_rusage_p->ru_sec Ī_user_rusage_p->ru_usec = a_rusage_p->ru_usec Munge_user64_rusage(struct rusage *a_rusage_p, struct user64_rusage *a_user_rusage_p) `munge_user64_rusage()` performs the conversion by copying individual fields: Return (copyout(retbuf, uap->rusage, retsize)) Size_t retsize = sizeof(rubuf) // default: 32 bitsĬaddr_t retbuf = (caddr_t)&rubuf // default: 32 bits Getrusage(struct proc *p, struct getrusage_args *uap, _unused int32_t *retval) For 64-bit processes, the getrusage() syscall handler converts a `struct rusage` to a `struct user64_rusage` using `munge_user64_rusage()`, then copies the `struct user64_rusage` to userspace:
0 kommentar(er)
