Nixpkgs security tracker

Login with GitHub

Suggestion detail

Dismissed
(max. allowed matches exceeded)
Permalink CVE-2026-64015
7.8 HIGH
  • CVSS version (CVSS): 3.1
  • Attack Vector (AV): Local (L)
  • Attack Complexity (AC): Low (L)
  • Privileges Required (PR): Low (L)
  • User Interaction (UI): None (N)
  • Scope (S): Unchanged (U)
  • Confidentiality (C): High (H)
  • Integrity (I): High (H)
  • Availability (A): High (H)
  • Modified Attack Vector (MAV): Local (L)
  • Modified Attack Complexity (MAC): Low (L)
  • Modified Privileges Required (MPR): Low (L)
  • Modified User Interaction (MUI): None (N)
  • Modified Confidentiality (MC): High (H)
  • Modified Scope (MS): Unchanged (U)
  • Modified Integrity (MI): High (H)
  • Modified Availability (MA): High (H)
created 6 days, 2 hours ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
security/keys: fix missed RCU read section on lookup

In the Linux kernel, the following vulnerability has been resolved: security/keys: fix missed RCU read section on lookup Nicholas Carlini reports that the keyring code calls assoc_array_find() in find_key_to_update() without holding the RCU read lock, while the assoc_array_gc() code really is designed around removing the node from the tree and then freeing it after an RCU grace-period. The regular key handling doesn't see this because holding the keyring semaphore hides any lifetime issues, but the persistent key handling uses a different model. Instead of extending the keyring locking, just do the simple RCU locking that the assoc_array was designed for.

Affected products

Linux
  • <5659e6923cb72f8e18e8b539109ab512455fe195
  • <cefa4265b11176c897a7d9e8e54d89e3701c5584
  • =<6.18.*
  • <50bb3435a5e627bfbdc52eb4536f49f88b3486b8
  • =<7.0.*
  • =<6.12.*
  • =<6.1.*
  • =<*
  • =<6.6.*
  • <66288dcadf80974436250e9f70ed848836b835b5
  • <4c5d407ba3ff7f30561ff73ba1b07ed70c864edc
  • <43a1e3744548e6fd85873e6fb43e293eb4010694
  • ==3.13
  • <3.13