The expiry time of a key is unconditionally overwritten during instantiation, defaulting to turn it permanent. This causes a problem for DNS resolution as the expiration set by user-space is overwritten to TIME64_MAX, disabling further DNS updates. Fix this by restoring the condition that key_set_expiry is only called when the pre-parser sets a specific expiry.
Fixes: 39299bdd2546 ("keys, dns: Allow key types (eg. DNS) to be reclaimed immediately on expiry") Signed-off-by: Silvio Gissi sifonsec@amazon.com cc: David Howells dhowells@redhat.com cc: Hazem Mohamed Abuelfotoh abuehaze@amazon.com cc: linux-afs@lists.infradead.org cc: linux-cifs@vger.kernel.org cc: keyrings@vger.kernel.org cc: netdev@vger.kernel.org cc: stable@vger.kernel.org --- security/keys/key.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/security/keys/key.c b/security/keys/key.c index 560790038329..0aa5f01d16ff 100644 --- a/security/keys/key.c +++ b/security/keys/key.c @@ -463,7 +463,8 @@ static int __key_instantiate_and_link(struct key *key, if (authkey) key_invalidate(authkey);
- key_set_expiry(key, prep->expiry); + if (prep->expiry != TIME64_MAX) + key_set_expiry(key, prep->expiry); } }
On Fri Mar 15, 2024 at 9:05 PM EET, Silvio Gissi wrote:
The expiry time of a key is unconditionally overwritten during instantiation, defaulting to turn it permanent. This causes a problem for DNS resolution as the expiration set by user-space is overwritten to TIME64_MAX, disabling further DNS updates. Fix this by restoring the condition that key_set_expiry is only called when the pre-parser sets a specific expiry.
Fixes: 39299bdd2546 ("keys, dns: Allow key types (eg. DNS) to be reclaimed immediately on expiry") Signed-off-by: Silvio Gissi sifonsec@amazon.com cc: David Howells dhowells@redhat.com cc: Hazem Mohamed Abuelfotoh abuehaze@amazon.com cc: linux-afs@lists.infradead.org cc: linux-cifs@vger.kernel.org cc: keyrings@vger.kernel.org cc: netdev@vger.kernel.org cc: stable@vger.kernel.org
security/keys/key.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/security/keys/key.c b/security/keys/key.c index 560790038329..0aa5f01d16ff 100644 --- a/security/keys/key.c +++ b/security/keys/key.c @@ -463,7 +463,8 @@ static int __key_instantiate_and_link(struct key *key, if (authkey) key_invalidate(authkey);
key_set_expiry(key, prep->expiry);
if (prep->expiry != TIME64_MAX)key_set_expiry(key, prep->expiry);
I checked the original commit and reflected to the fix:
Reviewed-by: Jarkko Sakkinen jarkko@kernel.org
David, I can pick this one too as I'm anyway sending PR for rc2?
[1] https://lore.kernel.org/keyrings/CZX77XLG67HZ.UAU4NUQO27JP@kernel.org/
BR, Jarkko
On Tue Mar 19, 2024 at 1:27 AM EET, Jarkko Sakkinen wrote:
On Fri Mar 15, 2024 at 9:05 PM EET, Silvio Gissi wrote:
The expiry time of a key is unconditionally overwritten during instantiation, defaulting to turn it permanent. This causes a problem for DNS resolution as the expiration set by user-space is overwritten to TIME64_MAX, disabling further DNS updates. Fix this by restoring the condition that key_set_expiry is only called when the pre-parser sets a specific expiry.
Fixes: 39299bdd2546 ("keys, dns: Allow key types (eg. DNS) to be reclaimed immediately on expiry") Signed-off-by: Silvio Gissi sifonsec@amazon.com cc: David Howells dhowells@redhat.com cc: Hazem Mohamed Abuelfotoh abuehaze@amazon.com cc: linux-afs@lists.infradead.org cc: linux-cifs@vger.kernel.org cc: keyrings@vger.kernel.org cc: netdev@vger.kernel.org cc: stable@vger.kernel.org
security/keys/key.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/security/keys/key.c b/security/keys/key.c index 560790038329..0aa5f01d16ff 100644 --- a/security/keys/key.c +++ b/security/keys/key.c @@ -463,7 +463,8 @@ static int __key_instantiate_and_link(struct key *key, if (authkey) key_invalidate(authkey);
key_set_expiry(key, prep->expiry);
if (prep->expiry != TIME64_MAX)key_set_expiry(key, prep->expiry);I checked the original commit and reflected to the fix:
Reviewed-by: Jarkko Sakkinen jarkko@kernel.org
David, I can pick this one too as I'm anyway sending PR for rc2?
[1] https://lore.kernel.org/keyrings/CZX77XLG67HZ.UAU4NUQO27JP@kernel.org/
I've applied this to my tree. Can drop on request but otherwise including to rc2 PR.
BR, Jarkko
linux-stable-mirror@lists.linaro.org
-
Jarkko Sakkinen -
Silvio Gissi