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

DISCUSSION Zubin Mithra 3 participants 4 messages Mar 14, 2019 Stable branch

lore

Share & tools

lore

Zubin Mithra

author

2019-03-14 16:30 UTC #0 lore raw

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

Greg KH

maintainer

2019-03-14 17:11 UTC #1 lore raw

Quoted 11 lines · 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

Quoted 5 lines

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

Guenter Roeck

2019-03-14 17:18 UTC #2 lore raw

Quoted 17 lines · Greg KH

Quoted 15 lines · 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")

Quoted 7 lines

Quoted 1 line
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

Greg KH

maintainer

2019-03-14 17:22 UTC #3 lore raw

Quoted 22 lines · Guenter Roeck

Quoted 21 lines · Greg KH
Quoted 11 lines · 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
Quoted 5 lines
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?

Quoted 8 lines

Quoted 3 lines
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