https://vulnerability.circl.lu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Thu, 01 Oct 2026 20:27:58 +0000 https://vulnerability.circl.lu/vuln/cve-2025-68299 <p><strong>Affected:</strong> Linux</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>afs: Fix delayed allocation of a cell&#39;s anonymous key</p> <p>The allocation of a cell&#39;s anonymous key is done in a background thread along with other cell setup such as doing a DNS upcall. In the reported bug, this is triggered by afs_parse_source() parsing the device name given to mount() and calling afs_lookup_cell() with the name of the cell.</p> <p>The normal key lookup then tries to use the key description on the anonymous authentication key as the reference for request_key() - but it may not yet be set and so an oops can happen.</p> <p>This has been made more likely to happen by the fix for dynamic lookup failure.</p> <p>Fix this by firstly allocating a reference name and attaching it to the afs_cell record when the record is created. It can share the memory allocation with the cell name (unfortunately it can&#39;t just overlap the cell name by prepending it with &#34;afs@&#34; as the cell name already has a &#39;.&#39; prepended for other purposes). This reference name is then passed to request_key().</p> <p>Secondly, the anon key is now allocated on demand at the point a key is requested in afs_request_key() if it is not already allocated. A mutex is used to prevent multiple allocation for a cell.</p> <p>Thirdly, make afs_request_key_rcu() return NULL if the anonymous key isn&#39;t yet allocated (if we need it) and then the caller can return -ECHILD to drop out of RCU-mode and afs_request_key() can be called.</p> <p>Note that the anonymous key is kind of neces…</p> <p><strong>Affected:</strong> Linux</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>afs: Fix delayed allocation of a cell&#39;s anonymous key</p> <p>The allocation of a cell&#39;s anonymous key is done in a background thread along with other cell setup such as doing a DNS upcall. In the reported bug, this is triggered by afs_parse_source() parsing the device name given to mount() and calling afs_lookup_cell() with the name of the cell.</p> <p>The normal key lookup then tries to use the key description on the anonymous authentication key as the reference for request_key() - but it may not yet be set and so an oops can happen.</p> <p>This has been made more likely to happen by the fix for dynamic lookup failure.</p> <p>Fix this by firstly allocating a reference name and attaching it to the afs_cell record when the record is created. It can share the memory allocation with the cell name (unfortunately it can&#39;t just overlap the cell name by prepending it with &#34;afs@&#34; as the cell name already has a &#39;.&#39; prepended for other purposes). This reference name is then passed to request_key().</p> <p>Secondly, the anon key is now allocated on demand at the point a key is requested in afs_request_key() if it is not already allocated. A mutex is used to prevent multiple allocation for a cell.</p> <p>Thirdly, make afs_request_key_rcu() return NULL if the anonymous key isn&#39;t yet allocated (if we need it) and then the caller can return -ECHILD to drop out of RCU-mode and afs_request_key() can be called.</p> <p>Note that the anonymous key is kind of neces…</p> https://vulnerability.circl.lu/vuln/cve-2025-68299