lkml.org 
[lkml]   [2017]   [Oct]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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@google.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

\
 
 \ /
  Last update: 2017-10-25 01:19    [W:0.072 / U:0.140 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site