I see a line in pathmgr that does

 msg_max_size = POSIX_PATH_MAX + sizeof (struct _connect)

Which I bet is 1568.  

David
> -----Original Message-----
> From: Colin Burgess [mailto:community-noreply@qnx.com] 
> Sent: March 25, 2009 1:44 PM
> To: ostech-core_os
> Subject: Re: Potential for memory corruption in handling of 
> _PROC_SPAWN_ARGS messages?
> 
> It's a calculate value in dispatch_create or some-such 
> location.  I did the cheesy route and loaded procnto up in 
> the debugger. :-)
> 
> Neil Schellenberger wrote:
> > Yeah, I figured that 512 was probably small enough to avoid any 
> > problems.  Just for my own edification, where did you find the 
> > msg_max_size of 1568?
> > 
> > On Tue, 2009-03-24 at 22:30 -0400, Colin Burgess wrote:
> >> It certainly does seem to be in error, but I'm not convinced it is 
> >> causing an issue, since ctp->msg_max_size is, in fact, 
> 1568, so the comment appears to be erroneous.
> >>
> >> sizeof(msg->spawn_args.i) is 16, so 16 * 16 is only 256, 
> which still gives you way more than 512 to work with.
> >>
> >> Still, it's obviously not intended behaviour... of course, nothing 
> >> about this code says "Obvious" :-)
> >>
> >> Neil Schellenberger wrote:
> >>> Fellows,
> >>>
> >>> While giving the kernel a once over with lint, I noticed this at 
> >>> procmgr_spawn.c:666 (no really!)
> >>>
> >>>    664    3317     xxxxx1   case _PROC_SPAWN_ARGS:
> >>>    665   16513     peterv       if(ctp->info.nd == 
> ND_LOCAL_NODE && (lcp = ProcessStartup(ctp->info.pid, 0)) != 
> (void *)-1) {
> >>>    666   16089     peterv           void        *buff = 
> &msg->spawn_args.i + sizeof msg->spawn_args.i;
> >>>    667   16089     peterv           unsigned    off = 0;
> >>>    668   16089     peterv           unsigned    len;
> >>>    669   16089     peterv 
> >>>    670   16089     peterv           
> while(msg->spawn_args.i.nbytes) {
> >>>    671   16199  sebastien               len = 
> min(msg->spawn_args.i.nbytes, 512); //ctp->ctrl->msg_max_size 
> - sizeof msg->spawn_args.i);
> >>>    672   16089     peterv               
> if(MsgRead(lcp->rcvid, buff, len, msg->spawn_args.i.offset) == -1) {
> >>>    673   16089     peterv                   return errno;
> >>>    674   16089     peterv               }
> >>>    675   16089     peterv               
> if(MsgWrite(ctp->rcvid, buff, len, off) == -1) {
> >>>    676   16089     peterv                   return errno;
> >>>    677   16089     peterv               }
> >>>    678   16089     peterv               off += len;
> >>>    679   16089     peterv               
> msg->spawn_args.i.offset += len;
> >>>    680   16089     peterv               
> msg->spawn_args.i.nbytes -= len;
> >>>    681    3317     xxxxx1           }
> >>>    682   16089     peterv           return EOK;
> >>>    683    3317     xxxxx1       }
> >>>    684   16089     peterv       break;
> >>>
> >>> This looks to me like a day zero bug: since the LHS of 
> the addition is not char * - it is struct _proc_spawn_args * 
> - surely that should read:
> >>>
> >>>   void * buff = & msg->spawn_args.i + 1;
> >>>
> >>> The comment for r16199 ("Temp fix for handling large 
> args") makes me wonder if this was the problem that was 
> intended to be fixed.  I wonder if this is in some way...