Hi Linus,
Please pull these fixes for the Keys subsystem by Eric Biggers.
The following changes since commit 3a99df9a3d14cd866b5516f8cba515a3bfd554ab:
Merge branch 'for-linus' of
git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace
(2017-11-01 16:04:27 -0700)
are available
Hi James,
Can you pull this collection of fixes for Linux keyrings and pass them along
to Linus. They include:
(1) Fix a bunch of places where kernel drivers may access revoked user-type
keys and don't do it correctly.
(2) Fix some ecryptfs bits.
(3) Fix big_key to require CONFIG_CRYPT
+Cc tyhi...@canonical.com
Hi David,
On Tue, Oct 17, 2017 at 11:57:33PM +0100, David Howells wrote:
>
> (2) Fix some ecryptfs bits.
Sorry for the late notice, but just looking at it again I think the patch
"ecryptfs: fix out-of-bounds read of key payload" is broken because the
->private_key is
Hi James,
Can you pull this collection of fixes for Linux keyrings and pass them along
to Linus. They include:
(1) Fix a bunch of places where kernel drivers may access revoked user-type
keys and don't do it correctly.
(2) Fix some ecryptfs bits.
(3) Fix big_key to require CONFIG_CRYPT
On Thu, Sep 28, 2017 at 12:08:36PM +1000, James Morris wrote:
> On Wed, 27 Sep 2017, Eric Biggers wrote:
>
> > On Thu, Sep 28, 2017 at 09:14:58AM +1000, James Morris wrote:
> > > On Wed, 27 Sep 2017, David Howells wrote:
> > >
> > > > (2) Fixing big_key to use safe crypto from Jason A. Donenfeld
On Wed, 27 Sep 2017, Eric Biggers wrote:
> On Thu, Sep 28, 2017 at 09:14:58AM +1000, James Morris wrote:
> > On Wed, 27 Sep 2017, David Howells wrote:
> >
> > > (2) Fixing big_key to use safe crypto from Jason A. Donenfeld.
> > >
> >
> > I'm concerned about the lack of crypto review mentioned
On Thu, Sep 28, 2017 at 09:14:58AM +1000, James Morris wrote:
> On Wed, 27 Sep 2017, David Howells wrote:
>
> > (2) Fixing big_key to use safe crypto from Jason A. Donenfeld.
> >
>
> I'm concerned about the lack of crypto review mentioned by Jason -- I
> wonder if we can get this rewrite any m
On Wed, 27 Sep 2017, David Howells wrote:
> (2) Fixing big_key to use safe crypto from Jason A. Donenfeld.
>
I'm concerned about the lack of crypto review mentioned by Jason -- I
wonder if we can get this rewrite any more review from crypto folk.
Also, are there any tests for this code? If n
Hi James,
Can you pull these and pass them on to Linus. There are two sets of
patches here:
(1) A bunch of core keyrings bug fixes from Eric Biggers.
(2) Fixing big_key to use safe crypto from Jason A. Donenfeld.
There are more patches to come from Eric, but I haven't reviewed at them
yet, s
Please pull these fixes for the keys code.
>From David:
" (1) Fix mpi_powm()'s handling of a number with a zero exponent
[CVE-2016-8650].
(2) Fix double free in X.509 error handling.
Ver #3:
- Integrate my and Andrey's patches for mpi_powm() and use mpi_resize()
instead of RESIZE_IF_NEED
Please pull these fixes from David Howells:
(1) Fix a buffer overflow when displaying /proc/keys [CVE-2016-7042].
(2) Fix broken initialisation in the big_key implementation that can
result in an oops.
(3) Make big_key depend on having a random number generator available in
Kconfig
Please pull these fixes for the keys code.
>From David Howells:
" Here are three miscellaneous fixes:
(1) Fix a panic in some debugging code in PKCS#7. This can only happen
by explicitly inserting a #define DEBUG into the code.
(2) Fix the calculation of the digest length in the PE fil
On Thu, 2014-09-18 at 14:23 +0100, David Howells wrote:
> James Morris wrote:
>
> > > > No, if they go direct to Linus, they don't go into -next.
> > >
> > > Can you then sync your -next branch to Linus after Linus takes them
> > > please?
> >
> > Nope, I only want to sync on point releases u
James Morris wrote:
> > > No, if they go direct to Linus, they don't go into -next.
> >
> > Can you then sync your -next branch to Linus after Linus takes them please?
>
> Nope, I only want to sync on point releases unless absolutely necessary.
In that case, can you please just pull the reques
On Thu, 18 Sep 2014, David Howells wrote:
> James Morris wrote:
>
> > No, if they go direct to Linus, they don't go into -next.
>
> Can you then sync your -next branch to Linus after Linus takes them please?
Nope, I only want to sync on point releases unless absolutely necessary.
--
James M
James Morris wrote:
> No, if they go direct to Linus, they don't go into -next.
Can you then sync your -next branch to Linus after Linus takes them please?
David
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More
On Tue, 16 Sep 2014, David Howells wrote:
> > Can you please pull these fixes and send them on upstream:
>
> Can you also pull them into your next branch as I have stuff for your next
> branch that depends on those changes?
No, if they go direct to Linus, they don't go into -next.
--
James Mo
Hi James,
Can you please pull these fixes and send them on upstream:
(1) Reinstate the production of EPERM for key types beginning with '.' in
requests from userspace.
(2) Tidy up the cleanup of PKCS#7 message signed information blocks and fix a
bug this made more obvious.
They will
David Howells wrote:
>
> Can you please pull these fixes and send them on upstream:
>
> (1) Reinstate the production of EPERM for key types beginning with '.' in
> requests from userspace.
>
> (2) Tidy up the cleanup of PKCS#7 message signed information blocks and fix a
> bug this
> Can you please pull these fixes and send them on upstream:
Can you also pull them into your next branch as I have stuff for your next
branch that depends on those changes?
Thanks,
David
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord
Hi James,
Can you please pull these fixes and send them on upstream:
(1) Reinstate the production of EPERM for key types beginning with '.' in
requests from userspace.
(2) Tidy up the cleanup of PKCS#7 message signed information blocks and fix a
bug this made more obvious.
David
---
On Wed, 30 Oct 2013, David Howells wrote:
>
> Hi James,
>
> Could you pull these five commits into your next branch? They are a set of
> fixes, some for the commits you have there and some for the upstream kernel.
Thanks, pulled.
Again, please aim for around -rc4 in the future.
--
James Mo
Hi James,
Could you pull these five commits into your next branch? They are a set of
fixes, some for the commits you have there and some for the upstream kernel.
David
---
The following changes since commit 50b719f811583a47762ecb7e480d253abc2eb22f:
Merge branch 'smack-for-3.13' of git://git.
23 matches
Mail list logo
