keyctl03 / keyctl05 / keyctl07 failed with Ubuntu 3.13 when running together

[Cypresslin]

These 3 test cases, keyctl03 / keyctl05 / keyctl07, will fail with Ubuntu Trusty 3.13 kernel if running altogether with the syscalls test suite (./runltp -f syscalls) or with the keyctl pattern (./runltp -s keyctl)

They will fail with the following error messages respectively:

• keyctl03.c:43: BROK: Failed to add key
• keyctl05.c:90: BROK: failed to join new session keyring: EDQUOT
• keyctl07.c:57: BROK: request_key() failed with unexpected error: EDQUOT

If you run them one-by-one, none of them will fail.

$ sudo ./runltp -s keyctl03

the test will pass without any issue:
<<<test_start>>>
tag=keyctl03 stime=1539677291
cmdline="keyctl03"
contacts=""
analysis=exit
<<<test_output>>>
incrementing stop
tst_test.c:1072: INFO: Timeout per run is 0h 05m 00s
keyctl03.c:51: PASS: Bug not reproduced

Summary:
passed 1
failed 0
skipped 0
warnings 0

$ sudo ./runltp -s keyctl05

<<<test_start>>>
tag=keyctl05 stime=1539679432
cmdline="keyctl05"
contacts=""
analysis=exit
<<<test_output>>>
incrementing stop
tst_test.c:1072: INFO: Timeout per run is 0h 05m 00s
keyctl05.c:135: INFO: Try to update the 'asymmetric' key...
keyctl05.c:148: PASS: updating 'asymmetric' key expectedly failed with EOPNOTSUPP
keyctl05.c:135: INFO: Try to update the 'dns_resolver' key...
keyctl05.c:148: PASS: updating 'dns_resolver' key expectedly failed with EOPNOTSUPP
keyctl05.c:183: INFO: Try to update the 'user' key...
keyctl05.c:192: PASS: didn't crash while racing to update 'user' key

Summary:
passed   3
failed   0
skipped  0
warnings 0

$ sudo ./runltp -s keyctl07
<<<test_start>>>
tag=cve-2017-12192 stime=1539679462
cmdline="keyctl07"
contacts=""
analysis=exit
<<<test_output>>>
incrementing stop
tst_test.c:1072: INFO: Timeout per run is 0h 05m 00s
keyctl07.c:74: INFO: trying to read from the negative key...
keyctl07.c:85: PASS: KEYCTL_READ on negative key expectedly failed with ENOKEY
keyctl07.c:100: PASS: didn't crash while reading from negative key

Summary:
passed   2
failed   0
skipped  0
warnings 0

https://bugs.launchpad.net/ubuntu-kernel-tests/+bug/1798045

[metan-ucw]

Well this looks like the quota for maximal numbers of keys is set too low.

The keyctl02 test adds and revokes keys in a loop and it temporarily increases the quota while it runs. So I suppose that there are pending revocations once the test exits and because the quota is set back to the original value at the end of the test, there possibly is more keys created on the system than the maximal quota at that point.

I do see several possible solutions to this. We can change the keyctl02 to loop in the cleanup, with a small usleep() until it happens to create a key. Another option, which is more robust, is to change all the keyctl test to retry, after short usleep(), if the call failed with EDQUOT.

[jstancek]

Agreed, this looks like a race on kernels that don't have this commit:
738c5d190f65 ("KEYS: Increase root_maxkeys and root_maxbytes sizes")

We could also check /proc/keys for ltptestkey. Or add KEYCTL_INVALIDATE for each key we created, which should garbage collect them immediately.

[jstancek]

Scratch last suggestion, invalidate doen't work for revoked keys.

[jstancek]

"loop in the cleanup, with a small usleep() until it happens to create a key" - but this won't tell you that all revoked keys have been garbage collected. What if we set gc_delay to 1 second, sleep and then restore gc_delay?

[metan-ucw]

@jstancek If we loop in the cleanup after we restored the quota until we happen to create key it should get us to a state where there is less keys on the system than the quota is, the rest of the tests use up to two keys, which should be fine. On the other hand the default expiration is five minutes, if I'm reading kernel source correctly, that is way too much.

Looking at gc_delay it looks like it could be even set to 0, but I do not thinkg that this would trigger intermediate action, the sysctl handler has only generic proc_dointvec_minmax handler and it looks like it would be taken into an account only the next time the key gc is triggered see linux/security/keys/gc.c.