https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Sun, 04 Oct 2026 21:23:43 +0000 https://cve.radiocsirt.org/vuln/cve-2026-89689 <p><strong>Affected:</strong> Linux</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>nfsd: don&#39;t free session slots that are still in use</p> <p>nfsd4_sequence() can free the very slot it is currently processing. When the session shrinker has reduced se_target_maxslots below se_fchannel.maxreqs, the shrink path checks three conditions before calling free_session_slots():</p> <p>1. se_target_maxslots &lt; maxreqs (shrink was advertised) 2. slot-&gt;sl_generation == se_slot_gen (slot is up-to-date) 3. seq-&gt;maxslots &lt;= se_target_maxslots (client acknowledges)</p> <p>However, seq-&gt;slotid is never checked against se_target_maxslots. A client using a slot in the range [se_target_maxslots, maxreqs) can satisfy all three conditions: its slot has the current generation (set by a prior SEQUENCE), and it sends sa_highest_slotid &lt;= se_target_maxslots to acknowledge the reduction.</p> <p>free_session_slots() then kfrees every slot at index &gt;= se_target_maxslots, including the caller&#39;s own slot. The function continues to write sl_seqid, sl_flags, sl_generation, and stores the dangling pointer in cstate-&gt;slot. Later, nfsd4_store_cache_entry() copies up to maxresp_cached bytes of the compound reply into the freed sl_data[] array, corrupting whatever slab object now occupies that address.</p> <p>Additionally, a concurrent thread processing SEQUENCE on a different high-numbered slot can have its slot freed out from under it. NFSD4_SLOT_INUSE is set under nn-&gt;client_lock before the lock is released, so any concurrent thread past SEQUEN…</p> <p><strong>Affected:</strong> Linux</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>nfsd: don&#39;t free session slots that are still in use</p> <p>nfsd4_sequence() can free the very slot it is currently processing. When the session shrinker has reduced se_target_maxslots below se_fchannel.maxreqs, the shrink path checks three conditions before calling free_session_slots():</p> <p>1. se_target_maxslots &lt; maxreqs (shrink was advertised) 2. slot-&gt;sl_generation == se_slot_gen (slot is up-to-date) 3. seq-&gt;maxslots &lt;= se_target_maxslots (client acknowledges)</p> <p>However, seq-&gt;slotid is never checked against se_target_maxslots. A client using a slot in the range [se_target_maxslots, maxreqs) can satisfy all three conditions: its slot has the current generation (set by a prior SEQUENCE), and it sends sa_highest_slotid &lt;= se_target_maxslots to acknowledge the reduction.</p> <p>free_session_slots() then kfrees every slot at index &gt;= se_target_maxslots, including the caller&#39;s own slot. The function continues to write sl_seqid, sl_flags, sl_generation, and stores the dangling pointer in cstate-&gt;slot. Later, nfsd4_store_cache_entry() copies up to maxresp_cached bytes of the compound reply into the freed sl_data[] array, corrupting whatever slab object now occupies that address.</p> <p>Additionally, a concurrent thread processing SEQUENCE on a different high-numbered slot can have its slot freed out from under it. NFSD4_SLOT_INUSE is set under nn-&gt;client_lock before the lock is released, so any concurrent thread past SEQUEN…</p> https://cve.radiocsirt.org/vuln/cve-2026-89689