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.
Guenter
