On Mon, 12 Sep 2005 16:41:19 EDT, Assar said: > [email protected] writes: > > > To my reading, the 2.6.13 code does not copy the 4 bytes of length to > > > rcvbuf. > > > > Hmm... it still does this: > > kaddr[len+rcvbuf->page_base] = '\0'; > > which still has a possible off-by-one? (Was that why you have -1 -4?) > > The check is different. 2.6.13 is using ">=" instead of ">", so hence > I think that's fine. Argh. Where's my reading glasses? ;) Yes, a >= check works there.... > + if (len > rcvbuf->page_len - sizeof(*strlen) - 1) > + len = rcvbuf->page_len - sizeof(*strlen) - 1; OK, looks saner to me, but Trond and Marcelo probably get to make the final decision ;)
Attachment:
pgpoEHG2ijyJY.pgp
Description: PGP signature
- References:
- [PATCH] nfs client, kernel 2.4.31: readlink result overflow
- From: Assar <[email protected]>
- Re: [PATCH] nfs client, kernel 2.4.31: readlink result overflow
- From: [email protected]
- Re: [PATCH] nfs client, kernel 2.4.31: readlink result overflow
- From: Assar <[email protected]>
- Re: [PATCH] nfs client, kernel 2.4.31: readlink result overflow
- From: [email protected]
- Re: [PATCH] nfs client, kernel 2.4.31: readlink result overflow
- From: Assar <[email protected]>
- [PATCH] nfs client, kernel 2.4.31: readlink result overflow
- Prev by Date: Re: [PATCH 2.6.13.1] Patch for invisible threads
- Next by Date: Re: 2.6.13-mm3
- Previous by thread: Re: [PATCH] nfs client, kernel 2.4.31: readlink result overflow
- Next by thread: Re: [PATCH] nfs client, kernel 2.4.31: readlink result overflow
- Index(es):