On Sat, Jun 13, 2026 at 09:40:10AM +0300, Onur Özkan wrote:
> +#[pinned_drop]
> +impl PinnedDrop for Srcu {
> + fn drop(self: Pin<&mut Self>) {
> + let ptr = self.inner.get();
> +
> + if crate::warn_on!(
> + // SAFETY: By the type invariants, `self` contains a valid and
> pinned `struct srcu_struct`
> + // and `srcu_readers_active()` only checks the active reader
> count.
> + unsafe { bindings::srcu_readers_active(ptr) }
> + ) {
> + // `cleanup_srcu_struct()` may return early if there are still
> active readers.
> + // This should only happen if a guard was leaked with
> `mem::forget`, which is
> + // "WRONG" code and may cause a UAF because Rust will free the
> `srcu_struct`
> + // while it is still referenced from the C side (e.g. by
> `call_srcu()` callbacks).
> + //
> + // Another consequence of leaking guards is that `call_srcu()`
> callbacks will
> + // never run because the grace period can never complete due to
> permanently
> + // active readers (i.e. leaked guards).
> + //
> + // If this ever happens, that means the guard was leaked by
> mistake and the
> + // caller must fix the bug. Sleeping here is intentional and
> less harmful
> + // than risking a UAF.
> + //
> + // SAFETY: By the type invariants, `self` contains a valid and
> pinned
> + // `struct srcu_struct`.
> + unsafe { bindings::synchronize_srcu(ptr) };
> + }
> +
> + // Ensure all SRCU callbacks have been finished before freeing.
> + // SAFETY: By the type invariants, `self` contains a valid and
> pinned `struct srcu_struct`.
> + unsafe { bindings::srcu_barrier(ptr) };
Hmm. It's not entirely clear to me that synchronize_srcu() is needed
here. If there are calls to srcu_read_lock() that do not have a matching
unlock due to use of mem::forget(), then either there is a pending
call_srcu() callback in the queue, in which case srcu_barrier() already
sleeps forever, or there are no such callbacks in which case I don't
think this actually leads to UAF.
Thoughts?
Alice
