https://vulnerability.circl.lu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Sun, 04 Oct 2026 18:32:05 +0000 https://vulnerability.circl.lu/vuln/cve-2026-43376 <p><strong>Affected:</strong> Linux</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>ksmbd: fix use-after-free by using call_rcu() for oplock_info</p> <p>ksmbd currently frees oplock_info immediately using kfree(), even though it is accessed under RCU read-side critical sections in places like opinfo_get() and proc_show_files().</p> <p>Since there is no RCU grace period delay between nullifying the pointer and freeing the memory, a reader can still access oplock_info structure after it has been freed. This can leads to a use-after-free especially in opinfo_get() where atomic_inc_not_zero() is called on already freed memory.</p> <p>Fix this by switching to deferred freeing using call_rcu().</p> <p><strong>Affected:</strong> Linux</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>ksmbd: fix use-after-free by using call_rcu() for oplock_info</p> <p>ksmbd currently frees oplock_info immediately using kfree(), even though it is accessed under RCU read-side critical sections in places like opinfo_get() and proc_show_files().</p> <p>Since there is no RCU grace period delay between nullifying the pointer and freeing the memory, a reader can still access oplock_info structure after it has been freed. This can leads to a use-after-free especially in opinfo_get() where atomic_inc_not_zero() is called on already freed memory.</p> <p>Fix this by switching to deferred freeing using call_rcu().</p> https://vulnerability.circl.lu/vuln/cve-2026-43376