[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20171024231927.GA32603@google.com>
Date: Tue, 24 Oct 2017 16:19:27 -0700
From: Eric Biggers <ebiggers@...gle.com>
To: David Howells <dhowells@...hat.com>
Cc: Ben Hutchings <ben.hutchings@...ethink.co.uk>,
stable@...r.kernel.org,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH 4.4 11/41] KEYS: fix writing past end of user-supplied
buffer in keyring_read()
On Thu, Oct 19, 2017 at 04:27:23PM +0100, David Howells wrote:
> Eric Biggers <ebiggers@...gle.com> wrote:
>
> > Hi Ben, thanks for pointing this out. I had assumed the "obvious" semantics,
> > but it turns out that's not what's documented.
>
> The manpage is correct. keyctl_read_alloc() in libkeyutils relies on the
> behaviour documented there with respect to the full size of the data always
> being returned, even if the buffer was too small.
>
> The keyring cannot be modified whilst it is being read, so that's not a
> concern.
>
> keyctl_read_alloc() doesn't care if the buffer actually gets written to or
> not, but it's best to honour the manpage.
>
> David
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?
Eric
Powered by blists - more mailing lists