From owner-freebsd-hackers@freebsd.org Sun May 22 23:30:46 2016 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1671BB3BF2A for ; Sun, 22 May 2016 23:30:46 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: from mail-oi0-f52.google.com (mail-oi0-f52.google.com [209.85.218.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DACEF1155; Sun, 22 May 2016 23:30:45 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: by mail-oi0-f52.google.com with SMTP id b65so109643112oia.1; Sun, 22 May 2016 16:30:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :date:message-id:subject:from:to:cc; bh=kPAoLZczWozA9V4FS0juplv9hj2g/1NogpZUa30OasY=; b=B+yIYPHtMZO1pRWeG26TJ2QcNvpl4p0q19XdaUmsoeJm/9mQKanm+4KHrWzlEw6Mzt awSjXe5HS7uLaBVOvU9v/5GPhbS3tx/3beOWO8Wt0CZBXPkM4qxrAMBaaKqCOovdZXFI GUTgKFZwWJUo8ZOUoYorGvI6xdykDWbn8ggS71w8oOvb2wYo6+4OffladA5HHGG51Otz 7hZGgqjUv81Lydf77JAkrRHfEYqtkSJhNoHwfELEGjldImaGtrImfF+ponOmerNn5yxO P31J0OV04bSeSmIpLtgZAAJhDhwnfPgBgzzqOaTHg+FVWv5nbQL8RjoDhYGpRbV9vrVI 8ZtQ== X-Gm-Message-State: AOPr4FX5CdaHzJSIwjUleJqWAEdR00iXE7FaN2X34NJpiU2ng7Cj4/iPWrIixqKTVp/1bA== X-Received: by 10.157.57.138 with SMTP id y10mr7847457otb.64.1463959413684; Sun, 22 May 2016 16:23:33 -0700 (PDT) Received: from mail-io0-f181.google.com (mail-io0-f181.google.com. [209.85.223.181]) by smtp.gmail.com with ESMTPSA id 90sm9039692otx.14.2016.05.22.16.23.33 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 22 May 2016 16:23:33 -0700 (PDT) Received: by mail-io0-f181.google.com with SMTP id p64so90806462ioi.2; Sun, 22 May 2016 16:23:33 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.36.81.209 with SMTP id s200mr10867214ita.34.1463959412852; Sun, 22 May 2016 16:23:32 -0700 (PDT) Reply-To: cem@FreeBSD.org Received: by 10.36.205.70 with HTTP; Sun, 22 May 2016 16:23:32 -0700 (PDT) In-Reply-To: <20160522230942.GP89104@kib.kiev.ua> References: <20160522230942.GP89104@kib.kiev.ua> Date: Sun, 22 May 2016 16:23:32 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: read(2) and thus bsdiff is limited to 2^31 bytes From: Conrad Meyer To: Konstantin Belousov Cc: Conrad Meyer , Dirk Engling , FreeBSD Hackers Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 May 2016 23:30:46 -0000 On Sun, May 22, 2016 at 4:09 PM, 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 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. read(2) returns ssize_t; SSIZE_MAX is not a negative result. I agree that nbytes in [SSIZE_MAX+1, SIZE_MAX] should be disallowed (negative ssize_t value after cast from size_t). > >> >> As far as I can tell, this INT_MAX behavior is not required by POSIX. > From POSIX page for read(): > RETURN VALUE > Upon successful completion, these functions shall return a non-negative integer indicating the > number of bytes actually read. Otherwise, the functions shall return -1 and set errno to indicate > the error. There is a difference between int and ssize_t. They have different ranges on e.g. amd64. Best, Conrad