Message-ID: <1508923903.22379.77.camel@codethink.co.uk>
Subject: Re: [PATCH 4.4 11/41] KEYS: fix writing past end of user-supplied
 buffer in keyring_read()
From: Ben Hutchings <ben.hutchings@codethink.co.uk>
To: Eric Biggers <ebiggers@google.com>,
        David Howells <dhowells@redhat.com>
Cc: stable@vger.kernel.org,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        linux-kernel@vger.kernel.org
Date: Wed, 25 Oct 2017 11:31:43 +0200
In-Reply-To: <20171024231927.GA32603@google.com>
References: <20171016181206.GC121701@google.com>
         <20171003114219.900672076@linuxfoundation.org>
         <20171003114220.627158480@linuxfoundation.org>
         <1508168854.22379.25.camel@codethink.co.uk>
         <10708.1508426843@warthog.procyon.org.uk>
         <20171024231927.GA32603@google.com>
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit
Sender: stable-owner@vger.kernel.org

On Tue, 2017-10-24 at 16:19 -0700, Eric Biggers wrote:
[...]
> I'd like to fix this, but I still can't decide whether keyring_read() should
> fill the buffer or not.  In keyutils, keyctl_read_alloc() doesn't care, but
> keyctl_read() on a keyring is also called from dump_key_tree_aux().  And that
> *does* assume that the buffer was filled in the event of a short read ---
> although it can only happen if the keyring is added to concurrently, and even
> then it's still broken because dump_key_tree_aux() won't show everything in the
> keyring.
> 
> So do we really make it keep filling the buffer, even though that contradicts
> the man page?

I don't think any application is likely to care about this.  The
documentation should also be changed to say that if the buffer is too
small, "data may or may not be copied to the buffer" or "the contents
of the buffer are undefined".

Ben.

-- 
Ben Hutchings
Software Developer, Codethink Ltd.