From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: From: erik quanstrom Date: Thu, 30 Jul 2009 07:27:10 -0400 To: 9fans@9fans.net In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: Re: [9fans] Race condition in /sys/src/9/pc/trap.c? Topicbox-Message-UUID: 31ef6df2-ead5-11e9-9d60-3106f5b1d025 On Thu Jul 30 00:05:45 EDT 2009, elly1@andrew.cmu.edu wrote: > My familiarity with the kernel source code is superficial to say the > least, but it seems to me that this code (from /sys/src/9/pc/trap.c) > contains a race condition: > > 702 if(sp<(USTKTOP-BY2PG) || sp>(USTKTOP-sizeof(Sargs)-BY2WD)) > 703 validaddr(sp, sizeof(Sargs)+BY2WD, 0); > 704 > 705 up->s = *((Sargs*)(sp+BY2WD)); > > We verify that the address is correct; is there any reason another thread > in the same address space cannot start running after line 703 completes > and unmap that memory, causing us to access unmapped memory at line 705? > The system call entry is itself an interrupt gate, but line 689 is > spllo(), and we appear to hold no locks at this point. plan 9 threads are cooperatively scheduled. so the correct term is proc. but you are correct, another proc sharing memory with this one could be running. however, that proc would not have access to this proc's stack. (rfork doesn't allow shared stack.) and even if it did, plan 9 stacks don't shrink. let's suppose that the address is invalid later. the kernel always moves data to/from user buffers outside of any locks because even valid targets may be paged out. if the address is truely invalid, waserror() will be true and the else branch starting at 714 will be executed - erik