Bug 203332
| Summary: | Fatal trap 12: rctl_enforce() at rctl_enforce | ||
|---|---|---|---|
| Product: | Base System | Reporter: | Jimmy Olgeni <olgeni> |
| Component: | kern | Assignee: | Mateusz Guzik <mjg> |
| Status: | Closed FIXED | ||
| Severity: | Affects Only Me | CC: | mjg |
| Priority: | --- | ||
| Version: | 10.2-STABLE | ||
| Hardware: | amd64 | ||
| OS: | Any | ||
|
Description
Jimmy Olgeni
2015-09-25 11:28:57 UTC
This looks like a use-after-free I mentioned some time ago. do_fork makes newproc runnable and fork1 does not pin it in any way, thus by the time do_fork returns the process could have already exited. Interestingly do_fork itself has this problem. Here faulting address 0xa8 matches what would be linked list access in a struct racct if read pointer was null. Pointer in question is nullified on process exit and initialized on fork. I'll ponder a reasonable fix. (In reply to Mateusz Guzik from comment #1) Quick data point: I never saw this again so far (following -STABLE). Got something related today:
FreeBSD olgeni 10.3-PRERELEASE FreeBSD 10.3-PRERELEASE #4 r296610: Thu Mar 10 11:09:56 CET 2016 root@olgeni:/usr/obj/usr/src/sys/KERNEL amd64
#0 doadump (textdump=1) at pcpu.h:219
#1 0xffffffff8096f557 in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:486
#2 0xffffffff8096f955 in vpanic (fmt=<value optimized out>, ap=<value optimized out>) at /usr/src/sys/kern/kern_shutdown.c:889
#3 0xffffffff8096f7e3 in panic (fmt=0x0) at /usr/src/sys/kern/kern_shutdown.c:818
#4 0xffffffff80da757b in trap_fatal (frame=<value optimized out>, eva=<value optimized out>) at /usr/src/sys/amd64/amd64/trap.c:858
#5 0xffffffff80da787d in trap_pfault (frame=0xfffffe046a799860, usermode=<value optimized out>)
at /usr/src/sys/amd64/amd64/trap.c:681
#6 0xffffffff80da6efa in trap (frame=0xfffffe046a799860) at /usr/src/sys/amd64/amd64/trap.c:447
#7 0xffffffff80d8c8e2 in calltrap () at /usr/src/sys/amd64/amd64/exception.S:236
#8 0xffffffff8096637c in rctl_enforce (p=0xfffff80412f379e0, resource=6, amount=0) at /usr/src/sys/kern/kern_rctl.c:350
#9 0xffffffff80964f1a in racct_proc_fork_done (child=0xfffff80412f379e0) at /usr/src/sys/kern/kern_racct.c:967
#10 0xffffffff8093785b in fork1 (td=<value optimized out>, flags=<value optimized out>, pages=Cannot access memory at address 0x4
) at /usr/src/sys/kern/kern_fork.c:964
#11 0xffffffff809378ff in sys_vfork (td=0xfffff80101576960, uap=<value optimized out>) at /usr/src/sys/kern/kern_fork.c:153
#12 0xffffffff80da7f4f in amd64_syscall (td=0xfffff80101576960, traced=0) at subr_syscall.c:141
#13 0xffffffff80d8cbcb in Xfast_syscall () at /usr/src/sys/amd64/amd64/exception.S:396
#14 0x00000008017fa65d in ?? ()
Previous frame inner to this frame (corrupt stack?)
Current language: auto; currently minimal
Had a look with kgdb - it stops in "LIST_FOREACH(link, &p->p_racct->r_rule_links, rrl_next)":
#1 0xffffffff8096f557 in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:486
486 doadump(TRUE);
#2 0xffffffff8096f955 in vpanic (fmt=<value optimized out>, ap=<value optimized out>) at /usr/src/sys/kern/kern_shutdown.c:889
889 kern_reboot(bootopt);
#3 0xffffffff8096f7e3 in panic (fmt=0x0) at /usr/src/sys/kern/kern_shutdown.c:818
818 vpanic(fmt, ap);
#4 0xffffffff80da757b in trap_fatal (frame=<value optimized out>, eva=<value optimized out>) at /usr/src/sys/amd64/amd64/trap.c:858
858 panic("%s", trap_msg[type]);
#5 0xffffffff80da787d in trap_pfault (frame=0xfffffe046a799860, usermode=<value optimized out>)
at /usr/src/sys/amd64/amd64/trap.c:681
681 trap_fatal(frame, eva);
#6 0xffffffff80da6efa in trap (frame=0xfffffe046a799860) at /usr/src/sys/amd64/amd64/trap.c:447
447 (void) trap_pfault(frame, FALSE);
#7 0xffffffff80d8c8e2 in calltrap () at /usr/src/sys/amd64/amd64/exception.S:236
236 call trap
Current language: auto; currently asm
#8 0xffffffff8096637c in rctl_enforce (p=0xfffff80412f379e0, resource=6, amount=0) at /usr/src/sys/kern/kern_rctl.c:350
350 LIST_FOREACH(link, &p->p_racct->r_rule_links, rrl_next) {
Current language: auto; currently minimal
#9 0xffffffff80964f1a in racct_proc_fork_done (child=0xfffff80412f379e0) at /usr/src/sys/kern/kern_racct.c:967
967 rctl_enforce(child, RACCT_NPROC, 0);
#10 0xffffffff8093785b in fork1 (td=<value optimized out>, flags=<value optimized out>, pages=Cannot access memory at address 0x4
) at /usr/src/sys/kern/kern_fork.c:964
964 racct_proc_fork_done(newproc);
#11 0xffffffff809378ff in sys_vfork (td=0xfffff80101576960, uap=<value optimized out>) at /usr/src/sys/kern/kern_fork.c:153
153 error = fork1(td, flags, 0, &p2, NULL, 0);
#12 0xffffffff80da7f4f in amd64_syscall (td=0xfffff80101576960, traced=0) at subr_syscall.c:141
141 error = (sa->callp->sy_call)(td, sa->args);
#13 0xffffffff80d8cbcb in Xfast_syscall () at /usr/src/sys/amd64/amd64/exception.S:396
396 call amd64_syscall
Current language: auto; currently asm
#14 0x00000008017fa65d in ?? ()
batch change: For bugs that match the following - Status Is In progress AND - Untouched since 2018-01-01. AND - Affects Base System OR Documentation DO: Reset to open status. Note: I did a quick pass but if you are getting this email it might be worthwhile to double check to see if this bug ought to be closed. I never saw this again since 2016 on both 10 and 11, so I guess this can be closed unless something else comes up. |