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
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
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
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
linux-stable-mirror@lists.linaro.org
-
Greg KH -
Guenter Roeck -
Zubin Mithra