Re: [9fans] dns

2012-08-27 Thread erik quanstrom 
On Mon Aug 27 22:11:14 EDT 2012, cinap_len...@gmx.de wrote:
> no.
> 
> just look at all the call sites for announce() and dial().

ah, you're right about dial.  i misread that.  i incorrectly considered
the Conn and not the DS.  both dial and announce could use a parameter
declaring the size of the buffer.

- erik

Re: [9fans] dns

2012-08-27 Thread cinap_lenrek 
no.

just look at all the call sites for announce() and dial().

ghost drivers! ghost drivers everywhere!

--
cinap

Re: [9fans] dns

2012-08-27 Thread erik quanstrom 
if (ds->dir) {
>   strncpy(ds->dir, conn->dir, NETPATHLEN);
>   ds->dir[NETPATHLEN] = '\0';

i think this is okay, since the definition is

chardir[NETPATHLEN+1];

- erik

Re: [9fans] dns

2012-08-27 Thread cinap_lenrek 
very good. thanks.

one wired thing is that the string pointer (0xfb900) it 
tried to free (char *domain) points in the middle of the
querylck array of a allocated DN.

thats not a valid alloc block indeed.

there migh'v been a block there, but it got accidently freed
and then the space reused for that DN, or the pointer itself
got corrupted (only possible from our current process as its
stored on the stack which is private to our proc).

theres a block (0xfb9a0) after it that satisfies the requirement
of being the real thing (alloc callerpc is right after the smprint(),
still valid ip address string).

the char *domain pointer is stored on the stack at 0x74(SP).
char conndir[40] starts at 0x4c(SP). 0x4c+40 = 0x74 so if
dial overflows conndir (off by one error?) it could indeed
trash that pointer overriding the lsb of char *domain resulting
in bogus 0xfb900 address instead of 0xfb9a0.

acid: dump(0xdfffc8b4, 44/4, "X")
0xdfffc8b4: 0x74656e2f <- char conndir[40]
0xdfffc8b8: 0x7063742f 
0xdfffc8bc: 0x392f 
0xdfffc8c0: 0x 
0xdfffc8c4: 0x 
0xdfffc8c8: 0x 
0xdfffc8cc: 0x 
0xdfffc8d0: 0x 
0xdfffc8d4: 0x 
0xdfffc8d8: 0x 
0xdfffc8dc: 0x000fb900 <- char *domain

/sys/include/libc.h:480: #define NETPATHLEN 40

from sources /sys/src/libc/9sys/dial.c

static int
fillinds(DS *ds, Dest *dp)
{
Conn *conn;

if (dp->winner < 0)
return -1;
conn = &dp->conn[dp->winner];
if (ds->cfdp)
*ds->cfdp = conn->cfd;
if (ds->dir) {
strncpy(ds->dir, conn->dir, NETPATHLEN);
ds->dir[NETPATHLEN] = '\0'; < fuck!
}
return conn->dfd;
}

this bug was introduced with the new parallel dial implementation.
the old sequential dial doesnt have this bug so 9front systems are
not affected.

someone make a patch.

--
cinap

Re: [9fans] dns

2012-08-27 Thread arisawa 
Hello,

I got a broken dns snapshot.

You can download from:
http://plan9.aichi-u.ac.jp/dns.snap.gz

Kenji Arisawa

Re: [9fans] rfork(RFPROC|RFNOMNT)

2012-08-27 Thread cinap_lenrek 
small additional note. RFPROC|RFNOMNT alone makes no difference
of course as parent and child will share the same pgrp. but
with RFNAMEG or RFCNAMEG it makes a difference.

the number of programs that use this combination is probably
very small. it was triggered with irc7 which is not part of
the plan9 distribution.

--
cinap

[9fans] rfork(RFPROC|RFNOMNT)

2012-08-27 Thread cinap_lenrek 
aiju found a bug in port/sysproc.c sysrfork(). in the
RFPROC|RFNOMNT case, it sets up->pgrp->noattach
instead of p->pgrp->noattach setting the *parents*
noattach flag instead of the childs pgrp.

http://code.google.com/p/plan9front/source/detail?r=7bbd45940626e92d4caf11620423a96a3fdc58ad

--
cinap