4aa68e07d845 ("KEYS: restrict /proc/keys by credentials at open time")

4aa68e07d845 ("KEYS: restrict /proc/keys by credentials at open time")

[Zubin Mithra]

Hello,

Syzkaller has triggered a kernel BUG when fuzzing a 4.4 kernel with the following stacktrace.
Call Trace:
 [<ffffffff818568d5>] construct_alloc_key security/keys/request_key.c:388 [inline]
 [<ffffffff818568d5>] construct_key_and_link security/keys/request_key.c:479 [inline]
 [<ffffffff818568d5>] request_key_and_link+0x49b/0x8c5 security/keys/request_key.c:594
 [<ffffffff8184fb08>] SYSC_request_key security/keys/keyctl.c:213 [inline]
 [<ffffffff8184fb08>] SyS_request_key+0x1ac/0x2a2 security/keys/keyctl.c:158
 [<ffffffff832bec3a>] entry_SYSCALL_64_fastpath+0x31/0xb3

Could the following patches be applied to v4.4.y?
* 4aa68e07d845 ("KEYS: restrict /proc/keys by credentials at open time")
* ede0fa98a900 ("KEYS: always initialize keyring_index_key::desc_len")

Note: queue-4.4 currently has a backport for "keys-always-initialize-keyring_index_key-desc_len.patch".

This request is to apply the 2 patches above instead of just one, to 4.4.y,
as the first patch is a bugfix as well. They apply cleanly if applied one after another.

Tests:
* Chrome OS tryjob
* Syzkaller reproducer
* Test to check if 4aa68e07d845 works as intended


Thanks,
- Zubin

Re: 4aa68e07d845 ("KEYS: restrict /proc/keys by credentials at open time")

[Greg KH]

On Thu, Mar 14, 2019 at 09:30:42AM -0700, Zubin Mithra wrote:
> Hello,
> 
> Syzkaller has triggered a kernel BUG when fuzzing a 4.4 kernel with the following stacktrace.
> Call Trace:
>  [<ffffffff818568d5>] construct_alloc_key security/keys/request_key.c:388 [inline]
>  [<ffffffff818568d5>] construct_key_and_link security/keys/request_key.c:479 [inline]
>  [<ffffffff818568d5>] request_key_and_link+0x49b/0x8c5 security/keys/request_key.c:594
>  [<ffffffff8184fb08>] SYSC_request_key security/keys/keyctl.c:213 [inline]
>  [<ffffffff8184fb08>] SyS_request_key+0x1ac/0x2a2 security/keys/keyctl.c:158
>  [<ffffffff832bec3a>] entry_SYSCALL_64_fastpath+0x31/0xb3
> 
> Could the following patches be applied to v4.4.y?
> * 4aa68e07d845 ("KEYS: restrict /proc/keys by credentials at open time")
> * ede0fa98a900 ("KEYS: always initialize keyring_index_key::desc_len")
> 
> Note: queue-4.4 currently has a backport for "keys-always-initialize-keyring_index_key-desc_len.patch".

As the queue already has this second patch, no need to add it, right?

And 4aa68e07d845 doesn't apply cleanly, but your 4.9.y backport did, so
I'll take that one, is that ok?

thanks,

greg k-h

Re: 4aa68e07d845 ("KEYS: restrict /proc/keys by credentials at open time")

[Guenter Roeck]

On Thu, Mar 14, 2019 at 10:11 AM Greg KH <gregkh@linuxfoundation.org> wrote:
>
> On Thu, Mar 14, 2019 at 09:30:42AM -0700, Zubin Mithra wrote:
> > Hello,
> >
> > Syzkaller has triggered a kernel BUG when fuzzing a 4.4 kernel with the following stacktrace.
> > Call Trace:
> >  [<ffffffff818568d5>] construct_alloc_key security/keys/request_key.c:388 [inline]
> >  [<ffffffff818568d5>] construct_key_and_link security/keys/request_key.c:479 [inline]
> >  [<ffffffff818568d5>] request_key_and_link+0x49b/0x8c5 security/keys/request_key.c:594
> >  [<ffffffff8184fb08>] SYSC_request_key security/keys/keyctl.c:213 [inline]
> >  [<ffffffff8184fb08>] SyS_request_key+0x1ac/0x2a2 security/keys/keyctl.c:158
> >  [<ffffffff832bec3a>] entry_SYSCALL_64_fastpath+0x31/0xb3
> >
> > Could the following patches be applied to v4.4.y?
> > * 4aa68e07d845 ("KEYS: restrict /proc/keys by credentials at open time")
> > * ede0fa98a900 ("KEYS: always initialize keyring_index_key::desc_len")
> >
> > Note: queue-4.4 currently has a backport for "keys-always-initialize-keyring_index_key-desc_len.patch".
>
> As the queue already has this second patch, no need to add it, right?
>
> And 4aa68e07d845 doesn't apply cleanly, but your 4.9.y backport did, so
> I'll take that one, is that ok?
>

This is just a matter of ordering and personal preference. You can
either drop the existing patch from the 4.4 queue and apply both
patches from upstream, or apply the 4.9 backport on top of the
existing queue. Result should be the same.

Guenter

Re: 4aa68e07d845 ("KEYS: restrict /proc/keys by credentials at open time")

[Greg KH]

On Thu, Mar 14, 2019 at 10:18:00AM -0700, Guenter Roeck wrote:
> On Thu, Mar 14, 2019 at 10:11 AM Greg KH <gregkh@linuxfoundation.org> wrote:
> >
> > On Thu, Mar 14, 2019 at 09:30:42AM -0700, Zubin Mithra wrote:
> > > Hello,
> > >
> > > Syzkaller has triggered a kernel BUG when fuzzing a 4.4 kernel with the following stacktrace.
> > > Call Trace:
> > >  [<ffffffff818568d5>] construct_alloc_key security/keys/request_key.c:388 [inline]
> > >  [<ffffffff818568d5>] construct_key_and_link security/keys/request_key.c:479 [inline]
> > >  [<ffffffff818568d5>] request_key_and_link+0x49b/0x8c5 security/keys/request_key.c:594
> > >  [<ffffffff8184fb08>] SYSC_request_key security/keys/keyctl.c:213 [inline]
> > >  [<ffffffff8184fb08>] SyS_request_key+0x1ac/0x2a2 security/keys/keyctl.c:158
> > >  [<ffffffff832bec3a>] entry_SYSCALL_64_fastpath+0x31/0xb3
> > >
> > > Could the following patches be applied to v4.4.y?
> > > * 4aa68e07d845 ("KEYS: restrict /proc/keys by credentials at open time")
> > > * ede0fa98a900 ("KEYS: always initialize keyring_index_key::desc_len")
> > >
> > > Note: queue-4.4 currently has a backport for "keys-always-initialize-keyring_index_key-desc_len.patch".
> >
> > As the queue already has this second patch, no need to add it, right?
> >
> > And 4aa68e07d845 doesn't apply cleanly, but your 4.9.y backport did, so
> > I'll take that one, is that ok?
> >
> 
> This is just a matter of ordering and personal preference. You can
> either drop the existing patch from the 4.4 queue and apply both
> patches from upstream, or apply the 4.9 backport on top of the
> existing queue. Result should be the same.

Ok, great, thanks for confirming, all should now be queued up.  If I
messed something up, please let me know.

thanks,

greg k-h