Re: [Nbd] BUG: oversized 64b offset wrap not detected when offset + len > 64bit and thus wraps
- To: Goswin von Brederlow <goswin-v-b@...186...>
- Cc: nbd-general@lists.sourceforge.net
- Subject: Re: [Nbd] BUG: oversized 64b offset wrap not detected when offset + len > 64bit and thus wraps
- From: folkert <folkert@...421...>
- Date: Tue, 5 Mar 2013 21:46:54 +0100
- Message-id: <20130305204654.GB7515@...855...>
- In-reply-to: <20130305124827.GA345@...1266...>
- References: <20130305092330.GJ14619@...855...> <20130305124827.GA345@...1266...>
> > if:
> > offset = 64bit - 2KB
> > len = 4KB
> > then the server will allow the read/write because the check
> > if (((ssize_t)((off_t)request.from + len) > client->exportsize))
> > will never trigger as client->exportsize will be compared with... offset
> > 2KB!
> >
> > +++ nbd-3.2/nbd-server.c 2013-03-05 10:04:41.000000000 +0100
> > if (((ssize_t)((off_t)request.from + len) > client->exportsize)) {
>
> ssize_t? Doesn't that cast to 32bit signed on 32bit cpus and therefore
> overflow much much earlier?
Quickly grepping through /usr/include it looks as if it is an int.
printf("%d\n", sizeof(ssize_t));
says 8 bytes on a 64b system
On a 32b system that (((ssize_t)((off_t)request.from + len) >
client->exportsize)) indeed fails dramatically.
So my fix was not complete :-)
Folkert van Heusden
--
www.TrustedTimestamping.com is a service that enables you to show that
at a certain point in time, you had access to a hash-value reflecting
the contents of a file (this file can be a word document, a jpeg
image, everything).
----------------------------------------------------------------------
Phone: +31-6-41278122, PGP-key: 1F28D8AE, www.vanheusden.com
Reply to: