CVE-2024-36031

What it actually does

The kernel unconditionally overwrites a key's expiration time during instantiation, defaulting to TIME64_MAX and making the key permanent even when user-space provided a finite expiry via the pre-parser.

Why it matters to the business

DNS resolution caches and other time-bound kernel keys stop receiving required updates, leading to stale data, failed resolutions, and potential service degradation across Linux systems until kernels are updated.

How an attack unfolds

An attacker supplies or triggers key instantiation (for example via DNS resolution paths) with a pre-parser that does not set an explicit expiry; the kernel then forces the key to TIME64_MAX, disabling subsequent updates and allowing continued use of an expired or attacker-controlled key value.

How to fix it

Upgrade the Linux kernel to a fixed version such as 5.10.217 or apply the commit ad2011ea787928b2accb5134f1e423b11fe80a8a (and equivalent stable backports) that restores the conditional call to key_set_expiry.

How to confirm the fix worked

Confirm the running kernel contains the fix commit or is at least version 5.10.217; test that user-space supplied DNS key expirations are preserved after instantiation and are no longer forced to TIME64_MAX.

Typical attack path

1. Identify a Linux system performing DNS or other user-space key operations
2. Trigger key instantiation through network or local activity that invokes the affected key type
3. Supply or cause a key whose pre-parser omits an explicit expiry value
4. Observe the key becoming permanent, preventing normal expiration-based rotation or invalidation

How to detect it

Review kernel audit logs and keyctl or request-key activity for unexpected permanent keys; correlate with DNS resolution failures or cache staleness on affected kernels; look for post-instantiation keys whose expiry equals TIME64_MAX when user-space intended otherwise.

What your security team should do

• Prioritize kernel upgrades on all internet-facing and DNS-resolving systems within the next patching cycle
• Monitor vendor advisories for additional affected stable branches and apply corresponding fixes
• Review any custom key-handling code or DNS resolver configurations that rely on key expiration