Messages in this thread |  | | From | David Howells <> | Subject | Re: keys: GPF in request_key | Date | Wed, 01 Feb 2017 16:50:24 +0000 |
| |
Do you reboot the system between running individual programs? If not, the programs will be influencing each other. Further, only those calls with valid type and matching description values are relevant, I think. This means those that use:
static const char type_2[] = "user"; static const char desc_2[] = "syz\1";
so:
r25 = request_key(type_2, desc_2, ...); ... r26 = add_key(type_2, desc_2, ...); ... r24 = request_key(type_2, desc_2, ...); ... r25 = add_key(type_2, desc_2, ...); ... r25 = request_key(type_2, desc_2, ...); ... r26 = add_key(type_2, desc_2, ...);
The first request_key() call will fail because it doesn't find anything and the upcall process, if it is available, has no suitable handler and will negatively instantiate it.
The first add_key() call will then update the key to make it positively instantiated, after which subsequent request_key() calls will return the key and add_key() calls will update its contents.
So, it would appear that it's not the first call to request_key() of type_2, desc_2, but one subsequent to that. The type_4 request_key() calls should get weeded out very quickly in sys_request_key() by key_get_type_from_user() - which seems to happen (EPERM is returned).
Doing:
keyctl link @us @s
before running the program on Fedora allows the request_key() to find the add_key() results.
Do you run some of these in parallel? Running the combo program 100,000 times sequentially didn't produce a crash.
> The OS is debian/wheezy created with: > $ debootstrap --include=openssh-server,curl,tar,time,strace,sudo,less,psmisc > wheezy wheezy > > I did not do any additional setup. I don't know what is PAM, so I > guess I did not set it up. > The machine is GCE VM.
I would imagine that PAM is part of the core OS - it does things like controlling login service security. Jessie apparently has it. However, Debian didn't use to include pam_keyinit.
David
|  |