From: Andreas Hindborg <a.hindborg@kernel.org>
To: "Danilo Krummrich" <dakr@kernel.org>
Cc: "Miguel Ojeda" <ojeda@kernel.org>,
"Alex Gaynor" <alex.gaynor@gmail.com>,
"Boqun Feng" <boqun.feng@gmail.com>,
"Gary Guo" <gary@garyguo.net>,
"Björn Roy Baron" <bjorn3_gh@protonmail.com>,
"Benno Lossin" <benno.lossin@proton.me>,
"Alice Ryhl" <aliceryhl@google.com>,
"Trevor Gross" <tmgross@umich.edu>,
"Joel Becker" <jlbec@evilplan.org>,
"Christoph Hellwig" <hch@lst.de>,
rust-for-linux@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 3/4] rust: configfs: introduce rust support for configfs
Date: Thu, 06 Feb 2025 13:33:55 +0100 [thread overview]
Message-ID: <87a5azjlqk.fsf@kernel.org> (raw)
In-Reply-To: <20250131-configfs-v1-3-87947611401c@kernel.org> (Andreas Hindborg's message of "Fri, 31 Jan 2025 14:30:10 +0100")
"Andreas Hindborg" <a.hindborg@kernel.org> writes:
> This patch adds a rust API for configfs, thus allowing rust modules to use
> configfs for configuration. The implementation is a shim on top of the C
> configfs implementation allowing safe use of the C infrastructure from
> rust.
>
> The patch enables the `const_mut_refs` feature on compilers before rustc
> 1.83. The feature was stabilized in rustc 1.83 and is not required to be
> explicitly enabled on later versions.
>
> Signed-off-by: Andreas Hindborg <a.hindborg@kernel.org>
>
> ---
[...]
> + /// # Safety
> + ///
> + /// If `this` does not represent the root group of a `configfs` subsystem,
> + /// `this` must be a pointer to a `bindings::config_group` embedded in a
> + /// `Group<PAR>`.
> + ///
> + /// Otherwise, `this` must be a pointer to a `bindings::config_group` that
> + /// is embedded in a `bindings::configfs_subsystem` that is embedded in a
> + /// `Subsystem<PAR>`.
> + ///
> + /// `item` must point to a `bindings::config_item` within a
> + /// `bindings::config_group` within a `Group<CHLD>`.
> + unsafe extern "C" fn drop_item(
> + this: *mut bindings::config_group,
> + item: *mut bindings::config_item,
> + ) {
> + // SAFETY: By function safety requirements of this function, this call
> + // is safe.
> + let parent_data = unsafe { get_group_data(this) };
> +
> + // SAFETY: By function safety requirements, `item` is embedded in a
> + // `config_group`.
> + let c_child_group_ptr =
> + unsafe { kernel::container_of!(item, bindings::config_group, cg_item) };
> + // SAFETY: By function safety requirements, `c_child_group_ptr` is
> + // embedded within a `Group<CHLD>`.
> + let r_child_group_ptr = unsafe { Group::<CHLD>::container_of(c_child_group_ptr) };
> +
> + if PAR::HAS_DROP_ITEM {
> + PAR::drop_item(
> + parent_data,
> + // SAFETY: We called `into_foreign` to produce `r_child_group_ptr` in
> + // `make_group`. There are not other borrows of this pointer in existence.
> + unsafe { PCPTR::borrow(r_child_group_ptr.cast_mut()) },
> + );
> + }
> +
> + // SAFETY: By C API contract, `configfs` is not going to touch `item`
> + // again.
> + unsafe { bindings::config_item_put(item) };
This turned out to be wrong. We _do_ have to let go of a refcount here,
but we are not allowed to free the item.
> +
> + // SAFETY: We called `into_foreign` on `r_chilc_group_ptr` in
> + // `make_group`.
> + let pin_child: PCPTR = unsafe { PCPTR::from_foreign(r_child_group_ptr.cast_mut()) };
> + drop(pin_child);
So this is wrong and will cause UAF. We have to wait for a call to
ct_item_ops.release and do the cleanup there. I will address this in the
next version. Removing directories is likely to cause trouble with this
patch.
Best regards,
Andreas Hindborg
next prev parent reply other threads:[~2025-02-06 12:34 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-31 13:30 [PATCH 0/4] rust: configfs abstractions Andreas Hindborg
2025-01-31 13:30 ` [PATCH 1/4] rust: types: add `ForeignOwnable::PointedTo` Andreas Hindborg
2025-02-05 19:59 ` Fiona Behrens
2025-02-06 12:18 ` Alice Ryhl
2025-01-31 13:30 ` [PATCH 2/4] rust: sync: change `<Arc<T> as ForeignOwnable>::PointedTo` to `T` Andreas Hindborg
2025-02-05 20:02 ` Fiona Behrens
2025-01-31 13:30 ` [PATCH 3/4] rust: configfs: introduce rust support for configfs Andreas Hindborg
2025-02-01 0:56 ` Charalampos Mitrodimas
2025-02-01 6:56 ` Andreas Hindborg
2025-02-05 21:19 ` Fiona Behrens
2025-02-06 11:37 ` Andreas Hindborg
2025-02-06 12:33 ` Andreas Hindborg [this message]
2025-01-31 13:30 ` [PATCH 4/4] MAINTAINERS: add entry for configfs Rust abstractions Andreas Hindborg
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87a5azjlqk.fsf@kernel.org \
--to=a.hindborg@kernel.org \
--cc=alex.gaynor@gmail.com \
--cc=aliceryhl@google.com \
--cc=benno.lossin@proton.me \
--cc=bjorn3_gh@protonmail.com \
--cc=boqun.feng@gmail.com \
--cc=dakr@kernel.org \
--cc=gary@garyguo.net \
--cc=hch@lst.de \
--cc=jlbec@evilplan.org \
--cc=linux-kernel@vger.kernel.org \
--cc=ojeda@kernel.org \
--cc=rust-for-linux@vger.kernel.org \
--cc=tmgross@umich.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.