Re: [PATCH 1/2] rust: pin-init: internal: init: remove `#[disable_initialized_field_access]`

["Gary Guo" <gary@garyguo.net>]

On Sat Feb 28, 2026 at 11:37 AM GMT, Benno Lossin wrote:
> Gary noticed [1] that the initializer macros as well as the `[Pin]Init`
> traits cannot support packed struct, since they use operations that

This is better read as "unaligned field", rather than "packed struct". The
packed struct can be initialized as a whole by moving it into place.

After all, a value of a packed struct is itself a valid initializer and is
sound.

If you have

#[derive(Zeroable)]
struct Foo {
   x: u8,
   y: u16,
   z: u8,
}

it is also valid to have `pin_init!(Foo { x: 1, ..Zeroable::zeroed() })`

> require aligned pointers. This means that any code using packed structs
> and pin-init is unsound.
> 
> Thus remove the `#[disable_initialized_field_access]` attribute from
> `init!`, which is the only safe way to create an initializer of a packed
> struct.
> 
> In the future, we can add support for packed structs by changing the
> trait infrastructure to include `UnalignedInit` or hopefully another
> mechanism.

I guess the comment can be reworded a bit, to hint that this won't be added
unless there's a compelling need, e.g.

    If support for in-place initializing packed structs is required in the
    future, we can ...

Personally I think this won't be neeeded, as there are many ways around
supporting unaligned fields, e.g. by creating and moving the entire packed
structs. Another way is to use `Unaligned<T>` type for fields that needs
pin-init, similar to what zerocopy have.

Best,
Gary

> 
> Reported-by: Gary Guo <gary@garyguo.net>
> Link: https://rust-for-linux.zulipchat.com/#narrow/channel/561532-pin-init/topic/initialized.20field.20accessor.20detection/with/576210658 [1]
> Fixes: ceca298c53f9 ("rust: pin-init: internal: init: add escape hatch for referencing initialized fields")
> Signed-off-by: Benno Lossin <lossin@kernel.org>
> ---
> This commit does not need backporting, as ceca298c53f9 is not yet in any
> stable tree.
> 
> However, the unsoundness still affects several stable trees, because it
> was unknowingly fixed in commit 42415d163e5d ("rust: pin-init: add
> references to previously initialized fields"). Before then, packed
> structs compiled without any issues with pin-init and thus all prior
> kernel versions with pin-init that do not contain that commit are
> affected.
> 
> We introduced pin-init in 90e53c5e70a6 ("rust: add pin-init API core"),
> which was included in 6.4. The affected stable trees that are still
> maintained are: 6.17, 6.16, 6.12, and 6.6. Note that 6.18 and 6.19
> already contain 42415d163e5d, so they are unaffected.
> 
> I will prepare a separate patch series to backport 42415d163e5d to each
> of the affected trees, including the second patch of this series that
> documents the fact that field accessors are load-bearing for soundness.
> 
> @asahi folks, let me know if I should prioritize a solution for packed
> structs. Otherwise I'd like not support it at the moment, as that
> requires some deeper changes to the internals of pin-init. I'm tracking
> the status of packed structs in:
> 
>     https://github.com/Rust-for-Linux/pin-init/issues/112
> ---
>  rust/pin-init/internal/src/init.rs | 39 ++++++------------------------
>  1 file changed, 8 insertions(+), 31 deletions(-)