Date: Mon, 23 May 2016 01:41:35 +0200 From: Joerg Sonnenberger <joerg@bec.de> To: freebsd-hackers@freebsd.org Subject: Re: read(2) and thus bsdiff is limited to 2^31 bytes Message-ID: <20160522234135.GA27218@britannica.bec.de> In-Reply-To: <20160522230942.GP89104@kib.kiev.ua> References: <b2515cae-b75d-66e9-4207-3cf100ab3ab0@erdgeist.org> <CAG6CVpWb7nvX%2BLFpLizkSx8Y-deXfXiWi=rL56iGZ71YPhmLbw@mail.gmail.com> <20160522230942.GP89104@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, May 23, 2016 at 02:09:42AM +0300, Konstantin Belousov wrote: > On Sun, May 22, 2016 at 03:56:33PM -0700, Conrad Meyer wrote: > > On Sun, May 22, 2016 at 1:54 PM, Dirk Engling <erdgeist@erdgeist.org> wrote: > > > When trying to bsdiff two DVD images, I noticed it failing due to > > > read(2) returning EINVAL to the tool. man 2 read says, this would only > > > happen for a negative value for fildes, which clearly was not true. > > > > Actually, it's documented at the very bottom of the first section: > > > > ERRORS > > The read(), readv(), pread() and preadv() system calls will succeed > > unless: > > ... > > [EINVAL] The value nbytes is greater than INT_MAX. > > > > It does seem silly to me given nbytes is a size_t. I think it should > > error if nbytes is greater than SSIZE_T_MAX, but on platforms where > > size_t is larger than int (e.g. amd64) it shouldn't error for nbytes > > in [INT_MAX, SSIZE_T_MAX - 1]. > It does not look silly to me, due to the typical > if (read() < 0) > checks in the code. Even > if (read() == -1) > is vulnerable. But that code can already fail in a number of situations. Short reads as well as short writes can happen in any of a number of situations. Joerg
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20160522234135.GA27218>