From: Daehyeon Ko <4ncienth@gmail.com>
To: David Howells <dhowells@redhat.com>, Jarkko Sakkinen <jarkko@kernel.org>
Cc: Paul Moore <paul@paul-moore.com>,
James Morris <jmorris@namei.org>,
"Serge E . Hallyn" <serge@hallyn.com>,
"Jason A . Donenfeld" <Jason@zx2c4.com>,
keyrings@vger.kernel.org, linux-security-module@vger.kernel.org,
linux-kernel@vger.kernel.org, stable@vger.kernel.org
Subject: [PATCH v2] keys: big_key: Remove the redundant quota reservation
Date: Sun, 18 Oct 2026 00:21:23 +0900 [thread overview]
Message-ID: <20261017152123.1200429-1-4ncienth@gmail.com> (raw)
In-Reply-To: <atK186hMPBhYyPCN@kernel.org>
A big_key is charged a fixed 16 bytes of key quota, regardless of its
payload size. big_key_update() nevertheless reserves the new raw payload
length before destroying the old payload, and generic_key_instantiate()
then reserves the fixed quota length.
For an update shorter than 16 bytes, the first reservation temporarily
returns quota. Another key operation by the same user can consume that
quota before generic_key_instantiate() reserves it again. If the second
reservation fails, the key remains positive after its old payload has been
destroyed. Reading a buffer-backed key or revoking a shmem-backed key then
dereferences a NULL payload pointer.
On a KASAN build, reading a buffer-backed key reports:
BUG: KASAN: null-ptr-deref in big_key_read+0x110/0x310
Read of size 64 at addr 0000000000000000
Revoking a shmem-backed key reports, with oops=panic:
KASAN: null-ptr-deref in range [0x68-0x6f]
RIP: vfs_truncate+0xa2/0x730
big_key_revoke+0xbd/0xe0
Kernel panic - not syncing: Fatal exception
The first reservation is unnecessary. A positive big_key already has a
16-byte reservation from successful instantiation, so the reservation in
generic_key_instantiate() has zero delta and cannot fail after the old
payload is destroyed. A negative key has no old payload to destroy, and
generic_key_instantiate() performs the required reservation before
publishing the new payload.
Remove the redundant reservation so that the update path adjusts quota only
once and cannot expose a temporary quota gap.
Fixes: b6f61c314649 ("keys: Implement update for the big_key type")
Cc: stable@vger.kernel.org
Assisted-by: LLM
Signed-off-by: Daehyeon Ko <4ncienth@gmail.com>
---
Changes since v1:
- Remove the redundant first reservation instead of changing its length,
leaving generic_key_instantiate() as the single quota reservation on the
update path, as suggested by Jarkko.
- Verify full-quota positive and negative updates separately. A positive
update keeps a zero quota delta; a negative update can still return
-EDQUOT before publishing a payload and succeeds after quota is released.
security/keys/big_key.c | 6 ------
1 file changed, 6 deletions(-)
diff --git a/security/keys/big_key.c b/security/keys/big_key.c
index 268f702df380e..ef707f2a81a98 100644
--- a/security/keys/big_key.c
+++ b/security/keys/big_key.c
@@ -193,12 +193,6 @@ void big_key_destroy(struct key *key)
*/
int big_key_update(struct key *key, struct key_preparsed_payload *prep)
{
- int ret;
-
- ret = key_payload_reserve(key, prep->datalen);
- if (ret < 0)
- return ret;
-
if (key_is_positive(key))
big_key_destroy(key);
base-commit: 58161ead29e50d70a317ea26b472e0c7508e69da
--
2.55.0
next prev parent reply other threads:[~2026-10-17 15:21 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-16 4:00 [PATCH] keys: big_key: Reserve the final quota before destroying the payload Daehyeon Ko
2026-10-16 4:07 ` sashiko-bot
2026-10-16 23:33 ` Jarkko Sakkinen
2026-10-16 23:40 ` Jarkko Sakkinen
2026-10-17 15:21 ` Daehyeon Ko [this message]
2026-10-17 15:28 ` [PATCH v2] keys: big_key: Remove the redundant quota reservation sashiko-bot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20261017152123.1200429-1-4ncienth@gmail.com \
--to=4ncienth@gmail.com \
--cc=Jason@zx2c4.com \
--cc=dhowells@redhat.com \
--cc=jarkko@kernel.org \
--cc=jmorris@namei.org \
--cc=keyrings@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=paul@paul-moore.com \
--cc=serge@hallyn.com \
--cc=stable@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.