From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f42.google.com (mail-wm1-f42.google.com [209.85.128.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C404C3BB13A for ; Sun, 30 Aug 2026 18:20:31 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.42 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788114033; cv=none; b=TbyPex2PwemQ7ZKvJ3xiU8LTQD9ViZRHT0Ko0k7RXKjOIduSYu0Awt38QXWTJOh3Ufu0IUNnA5Nu0TRZmcQcRhqvASkvNqkv+SqVS4LYbRB53sWCuRS0YvRoRROvkyT/bCX9P7ustvQdLpshTYw5mQZFfoMaPY1eiW/LEA3UAl8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788114033; c=relaxed/simple; bh=TVCyLwZDMmVp0hAurQYMH3T2j5DMGrsKI0ZW+vcU8T4=; h=From:To:Cc:Subject:Date:Message-Id:MIME-Version; b=XCIObvKVCw+Yh76IDi1hYRwQs7PLUS2lsJAa8GVhMb1BlsaQDkHHvl+KC1/P1u/d0dUKypU0DL9dge1MlGmnS+uhOCixEF/Kmau/HkVZPyAPsJfNlJgd3ft9btWakVNoFmKI9rFD7WQvlBynQ4+Ogxu0WxdFsqlxbDgbdDqIfnA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=VKmLibdZ; arc=none smtp.client-ip=209.85.128.42 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="VKmLibdZ" Received: by mail-wm1-f42.google.com with SMTP id 5b1f17b1804b1-49a97714f5dso20353045e9.0 for ; Sun, 30 Aug 2026 11:20:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1788114030; x=1788718830; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to:content-type; bh=Rco2GCRhLFay115dRTUgmepuW15efqnKFUOomZek2ow=; b=VKmLibdZ2hzJjmcmtqZhbmpzR2rX3cJB7sKEUjaMQ4PflODCN0/VedqcwTI6bYGBji SyFEdoRBlylb0MbOZs/84j629JUiWxLkvdkC8LvueJXfPQQhDkEY80rt8oO/fOCsHcWo MLehDz7MTz2ijFlekXeRDAJ3coNK0gTw5o+NGC5OXFFn95QFfsyJvCHxEbsX10yWd3Gw I5Ebf8ZmhZUf/6nskQNviZS9ds+TVmY8eBwtdOJFNhdPRdl7UH0JC7I/5/HhWTStyfbD RzZQYNVdR5D2yqUo7IcVTYdF6YSja4tCCI1s16MlCJvm+VPWnPKqOk54+YZeTf+8CZoV Mxlg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788114030; x=1788718830; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to:content-type; bh=Rco2GCRhLFay115dRTUgmepuW15efqnKFUOomZek2ow=; b=OUfAlxK4WCKXvyK91zQ7mLYDc0vxEF5hh8RZcruvAckxxa6VxwYVwbliIQ4LYEIXn0 xqp6q3B/E6f/IARTzuqQqOZOqNrACPSGUkrxfgCuyO7IZ82ciAl1ptIASLjEDsFVgzYC TKxH05s3TD+jiicugcnxsrpevwWaH9k6kMEcUrCrOWjzrVFx9q7PHGDUMEbrvda/3o/w qDTJJ62pFBBtMvKkMMpEKzUxLVh48q6hkzvgosVa5SLZXfKM4man2LAWLmxlfGeBLEoB l8+fm3AJtCr2FaGHvdncW1nUtwTJ0i6bhyfXER7TNFmGyky1wTE4ca9imgUE5Jqq835Z yeNw== X-Forwarded-Encrypted: i=1; AHgh+Rr5TBEQxQ/b4UPoblQCbYCKTHtaO4Wcdxfmh/BgX7kYDGenlYjz2pBi02yIh5Ltb3PXHOYGnNbNlRx+X6PcS6GlfZOSK7A=@vger.kernel.org X-Gm-Message-State: AFuF++kqHQopUtErypXQZk+jhU7foLrnqmKnsj/6et95oa0FUp5LqoYT Gw/rVvTUhRiacDnoQpBravGIO3q/9Iqy6t8ThSm7btiw78BZH0pXO0nF X-Gm-Gg: AR+sD12YABCop1pOYcS/TRpcjWAHflfwEFacoz8zjyikvleX6uf1pjSONEsIis43Z4q GAUojU6v4mB+ewcEl30FCZjUyhBG9M/LiHeNrgrCQXKC950Zxlr0ndaTbIzO5lfGf7ZhwP+JakL LYmnIYK/CDdHSeCrKkLTucSGzmj+JPic5pG8WZQVjg3/uys/NFh+fVoVU/K7xXAw7wPA/fUzEBB MVCHNSD3A+2aiFAQF/dM93f2+CCPeSmAZs9rrD4VhUextken4Iw0sh3CS/jFAxej4RJhu23k1D4 OxB2UXtQWnNBk9Ya6ZycatifaycrXhB5KLXUJjwisMLlnjS4vlRYqb6st1wq7Ls7+wYlY5WDs+U 4N6vmBayNT6QPiAUOAfi/h+ZTfrM/8w9yLGjT00QmERRNMfXPsO4FMEhaQ9tLG9FQyGGystEMSp CnScaXUR/Ts7YrpK3I6BvYOJgx2b877q9fqBNcyLVabZuRzXwX1YwAQmmxVZ7tpi01x1sjQlnXw 9eDIpT9aM0KfYzeNv3T+jEjKgaDnkI+mJGC+fX9QT+LQTu+YZMYzhnM6PpTbOnuMsDnPE87fipC 6U1XYgz4olJ0ucLpygdUfIlZOrSBqPneC+Ynnk3shbZRVBv7Ftu73WwvxZkF2mUHbCIh1MjFWEO UQbNQcUJA8IczVKwxGCO+Jw== X-Received: by 2002:a05:600c:8b86:b0:493:f5bf:4dc6 with SMTP id 5b1f17b1804b1-49b91c2777emr366315815e9.7.1788114029578; Sun, 30 Aug 2026 11:20:29 -0700 (PDT) Received: from MacBook-Pro-von-Karl.localdomain (dynamic-2a02-3100-adda-dc01-edc7-8a6f-c6f3-73e0.310.pool.telefonica.de. [2a02:3100:adda:dc01:edc7:8a6f:c6f3:73e0]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49b94dc0f57sm252584505e9.2.2026.08.30.11.20.28 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256); Sun, 30 Aug 2026 11:20:29 -0700 (PDT) From: Karl Mehltretter To: David Howells , Jarkko Sakkinen Cc: Karl Mehltretter , Paul Moore , James Morris , "Serge E. Hallyn" , keyrings@vger.kernel.org, linux-security-module@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH] keys: set persistent keyring timeout before destination linking Date: Sun, 30 Aug 2026 20:20:26 +0200 Message-Id: X-Mailer: git-send-email 2.39.5 (Apple Git-154) Precedence: bulk X-Mailing-List: linux-security-module@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit keyring_alloc() links a newly created persistent keyring into the namespace's hidden register with TIME64_MAX expiry. key_get_persistent() sets the configured timeout only after linking the keyring into the caller's destination. If the destination rejects the link, the registered keyring retains infinite expiry. It is exempt from key quota and can remain until namespace teardown or reboot even though the syscall returned an error. At most one such keyring exists per UID per namespace. Repeated failures for the same UID therefore strand only one small allocation. This is reachable from unprivileged userspace: KEYCTL_RESTRICT_KEYRING on the destination makes key_link() return -EPERM via restrict_link_reject(), after key_create_persistent() has already registered the keyring. Set the timeout immediately after creating and registering the keyring. A later permission or destination-link failure then leaves a collectible persistent keyring. The successful path may refresh the same timeout again without changing its semantics. Fixes: f36f8c75ae2e ("KEYS: Add per-user_namespace registers for persistent per-UID kerberos caches") Assisted-by: LLM Signed-off-by: Karl Mehltretter --- Tested with QEMU 10.2.1 TCG. The reproducer set /proc/sys/kernel/keys/persistent_keyring_expiry to 60 seconds, restricted the destination with KEYCTL_RESTRICT_KEYRING, and then called KEYCTL_GET_PERSISTENT. No LSM policy was loaded. syscall result /proc/keys expiry i386 baseline -EPERM perm i386 patched -EPERM 1m x86_64 patched -EPERM 1m Full kernel builds completed for i386 and ARM926, and for x86_64 with CONFIG_PROVE_LOCKING=y. The x86_64 reproducer completed without lockdep reports, warnings, or bugs. security/keys/persistent.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/security/keys/persistent.c b/security/keys/persistent.c index 97af230aa4b22..0eca8c5758434 100644 --- a/security/keys/persistent.c +++ b/security/keys/persistent.c @@ -63,6 +63,12 @@ static key_ref_t key_create_persistent(struct user_namespace *ns, kuid_t uid, if (IS_ERR(persistent)) return ERR_CAST(persistent); + /* Set the expiry now: if the caller then fails to link the keyring to + * its destination, the register is left holding a collectible key + * rather than a permanent, quota-exempt one. + */ + key_set_timeout(persistent, persistent_keyring_expiry); + return make_key_ref(persistent, true); } base-commit: 08dbfad3f5040f5bdb6c529da20d6d4e81fefd72 -- 2.53.0