1 /*
2 * Copyright (c) 2017 Google, Inc.
3 *
4 * This program is free software: you can redistribute it and/or modify
5 * it under the terms of the GNU General Public License as published by
6 * the Free Software Foundation, either version 2 of the License, or
7 * (at your option) any later version.
8 *
9 * This program is distributed in the hope that it will be useful,
10 * but WITHOUT ANY WARRANTY; without even the implied warranty of
11 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
12 * GNU General Public License for more details.
13 *
14 * You should have received a copy of the GNU General Public License
15 * along with this program, if not, see <http://www.gnu.org/licenses/>.
16 */
17
18 /*
19 * Regression test for two related bugs:
20 *
21 * (1) CVE-2017-15299, fixed by commit 60ff5b2f547a ("KEYS: don't let add_key()
22 * update an uninstantiated key")
23 * (2) CVE-2017-15951, fixed by commit 363b02dab09b ("KEYS: Fix race between
24 * updating and finding a negative key")
25 *
26 * We test for the bugs together because the reproduction steps are essentially
27 * the same: repeatedly try to add/update a key with add_key() while requesting
28 * it with request_key() in another task. This reproduces both bugs:
29 *
30 * For CVE-2017-15299, add_key() has to run while the key being created by
31 * request_key() is still in the "uninstantiated" state. For the "encrypted" or
32 * "trusted" key types (not guaranteed to be available) this caused a NULL
33 * pointer dereference in encrypted_update() or in trusted_update(),
34 * respectively. For the "user" key type, this caused the WARN_ON() in
35 * construct_key() to be hit.
36 *
37 * For CVE-2017-15951, request_key() has to run while the key is "negatively
38 * instantiated" (from a prior request_key()) and is being concurrently changed
39 * to "positively instantiated" via add_key() updating it. This race, which is
40 * a bit more difficult to reproduce, caused the task executing request_key() to
41 * dereference an invalid pointer in __key_link_begin().
42 */
43
44 #include <errno.h>
45 #include <stdbool.h>
46 #include <stdlib.h>
47 #include <sys/wait.h>
48
49 #include "tst_test.h"
50 #include "lapi/keyctl.h"
51
52 static char *opt_bug;
53
54 static struct tst_option options[] = {
55 {"b:", &opt_bug, "-b Bug to test for (cve-2017-15299 or cve-2017-15951; default is both)"},
56 {NULL, NULL, NULL}
57 };
58
test_with_key_type(const char * type,const char * payload,int effort)59 static void test_with_key_type(const char *type, const char *payload,
60 int effort)
61 {
62 int i;
63 int status;
64 pid_t add_key_pid;
65 pid_t request_key_pid;
66 bool info_only;
67
68 TEST(keyctl(KEYCTL_JOIN_SESSION_KEYRING, NULL));
69 if (TST_RET < 0)
70 tst_brk(TBROK | TTERRNO, "failed to join new session keyring");
71
72 TEST(add_key(type, "desc", payload, strlen(payload),
73 KEY_SPEC_SESSION_KEYRING));
74 if (TST_RET < 0 && TST_ERR != EINVAL) {
75 if (TST_ERR == ENODEV) {
76 tst_res(TCONF, "kernel doesn't support key type '%s'",
77 type);
78 return;
79 }
80 tst_brk(TBROK | TTERRNO,
81 "unexpected error checking whether key type '%s' is supported",
82 type);
83 }
84
85 /*
86 * Fork a subprocess which repeatedly tries to "add" a key of the given
87 * type. This actually will try to update the key if it already exists.
88 * Depending on the state of the key, add_key() should either succeed or
89 * fail with one of several errors:
90 *
91 * (1) key didn't exist at all: either add_key() should succeed (if the
92 * payload is valid), or it should fail with EINVAL (if the payload
93 * is invalid; this is needed for the "encrypted" and "trusted" key
94 * types because they have a quirk where the payload syntax differs
95 * for creating new keys vs. updating existing keys)
96 *
97 * (2) key was negative: add_key() should succeed
98 *
99 * (3) key was uninstantiated: add_key() should wait for the key to be
100 * negated, then fail with ENOKEY
101 *
102 * For now we also accept EDQUOT because the kernel frees up the keys
103 * quota asynchronously after keys are unlinked. So it may be hit.
104 */
105 add_key_pid = SAFE_FORK();
106 if (add_key_pid == 0) {
107 for (i = 0; i < 100 * effort; i++) {
108 usleep(rand() % 1024);
109 TEST(add_key(type, "desc", payload, strlen(payload),
110 KEY_SPEC_SESSION_KEYRING));
111 if (TST_RET < 0 && TST_ERR != EINVAL &&
112 TST_ERR != ENOKEY && TST_ERR != EDQUOT) {
113 tst_brk(TBROK | TTERRNO,
114 "unexpected error adding key of type '%s'",
115 type);
116 }
117 TEST(keyctl(KEYCTL_CLEAR, KEY_SPEC_SESSION_KEYRING));
118 if (TST_RET < 0) {
119 tst_brk(TBROK | TTERRNO,
120 "unable to clear keyring");
121 }
122 }
123 exit(0);
124 }
125
126 request_key_pid = SAFE_FORK();
127 if (request_key_pid == 0) {
128 for (i = 0; i < 5000 * effort; i++) {
129 TEST(request_key(type, "desc", "callout_info",
130 KEY_SPEC_SESSION_KEYRING));
131 if (TST_RET < 0 && TST_ERR != ENOKEY &&
132 TST_ERR != ENOENT && TST_ERR != EDQUOT) {
133 tst_brk(TBROK | TTERRNO,
134 "unexpected error requesting key of type '%s'",
135 type);
136 }
137 }
138 exit(0);
139 }
140
141 /*
142 * Verify that neither the add_key() nor the request_key() process
143 * crashed. If the add_key() process crashed it is likely due to
144 * CVE-2017-15299, while if the request_key() process crashed it is
145 * likely due to CVE-2017-15951. If testing for one of the bugs
146 * specifically, only pay attention to the corresponding process.
147 */
148
149 SAFE_WAITPID(add_key_pid, &status, 0);
150 info_only = (opt_bug && strcmp(opt_bug, "cve-2017-15299") != 0);
151 if (WIFEXITED(status) && WEXITSTATUS(status) == 0) {
152 tst_res(info_only ? TINFO : TPASS,
153 "didn't crash while updating key of type '%s'",
154 type);
155 } else if (WIFSIGNALED(status) && WTERMSIG(status) == SIGKILL) {
156 tst_res(info_only ? TINFO : TFAIL,
157 "kernel oops while updating key of type '%s'",
158 type);
159 } else {
160 tst_brk(TBROK, "add_key child %s", tst_strstatus(status));
161 }
162
163 SAFE_WAITPID(request_key_pid, &status, 0);
164 info_only = (opt_bug && strcmp(opt_bug, "cve-2017-15951") != 0);
165 if (WIFEXITED(status) && WEXITSTATUS(status) == 0) {
166 tst_res(info_only ? TINFO : TPASS,
167 "didn't crash while requesting key of type '%s'",
168 type);
169 } else if (WIFSIGNALED(status) && WTERMSIG(status) == SIGKILL) {
170 tst_res(info_only ? TINFO : TFAIL,
171 "kernel oops while requesting key of type '%s'",
172 type);
173 } else {
174 tst_brk(TBROK, "request_key child %s", tst_strstatus(status));
175 }
176 }
177
do_test(void)178 static void do_test(void)
179 {
180 /*
181 * Briefly test the "encrypted" and/or "trusted" key types when
182 * availaible, mainly to reproduce CVE-2017-15299.
183 */
184 test_with_key_type("encrypted", "update user:foo 32", 2);
185 test_with_key_type("trusted", "update", 2);
186
187 /*
188 * Test the "user" key type for longer, mainly in order to reproduce
189 * CVE-2017-15951. However, without the fix for CVE-2017-15299 as well,
190 * WARNs may show up in the kernel log.
191 *
192 * Note: the precise iteration count is arbitrary; it's just intended to
193 * be enough to give a decent chance of reproducing the bug, without
194 * wasting too much time.
195 */
196 test_with_key_type("user", "payload", 20);
197 }
198
199 static struct tst_test test = {
200 .test_all = do_test,
201 .forks_child = 1,
202 .options = options,
203 };
204