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@xxxxxxxxxxxxxxxxxxx> 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
