Re: [PATCH 0/4] rust: add pointer projection infrastructure and convert DMA

["Benno Lossin" <lossin@kernel.org>]

On Sun Feb 15, 2026 at 1:47 AM CET, Miguel Ojeda wrote:
> On Sat, Feb 14, 2026 at 11:34 AM Danilo Krummrich <dakr@kernel.org> wrote:
>>
>> Miguel: If you don't mind I would like to take this one through the driver-core
>> tree as well, as it is not only the base for this fix, but also the base for the
>> upcoming I/O infrastructure work.
>
> Is there some code that is currently "actually" buggy, i.e. not just a
> soundness bug, but actually triggering UB or similar?

I investigated this a bit in the beginning and I don't think this can be
triggered by us at the moment.

Here is a comprehensive explanation (maybe Gary can pick this up for the
commit message?):

The unsoundness comes from the fact that in the current version of the
`dma_read!` macro does not prevent the field access from "going through
a deref". Here is an example of an expression experiencing UB:

    dma_read!(dma[0].derefable.field)

Given `dma: &CoherentAllocation<Derefable>` and

    struct Derefable {
        inner: KBox<Struct>,
    }

    impl Deref for Derefable {
        type Target = Struct;

        fn deref(&self) -> &Struct {
            self.inner.deref()
        }
    }

    struct Struct {
        field: Field,
    }

The `dma_read!` creates a raw pointer to the dma allocation at the
provided offset. It then offsets that pointer according to the macro
input:  `&raw const (*raw_ptr).derefable.field`. This is the step that
produces UB:
- the Rust compiler finds no field named `field` on the `Derefable`
  type. It thus checks if it implements `Deref`, which it does, so it
  proceeds to try the target type.
- The target type is `Struct`, which does have a field named `field`, so
  it desugars the raw pointer offset to this:

    &raw const Deref::deref(&(*raw_ptr).derefable).field

This thus creates a *reference* into the dma-coherent memory, which
AFAIK is UB. It then uses that to call the `Deref::deref` function,
which reads from dma without volatile and then dereferences the read
value again.

Now there is a lint called `dangerous_implicit_autorefs` [1], which
exists to warn specifically on these implicit reference conversions. It
was introduced as error-by-default in Rust 1.89, so as long as we test
with latest stable, we should catch these.

An additional "layer of defense" is that `CoherentAllocation` requires
the generic to implement the `FromBytes` trait, which is incompatible
with "being a pointer" (this impl is missing from the example code
above).

I discussed a related question on the rust-lang zulip in which we also
talked about this unsoundness. The recommendation from the Rust
developers was to **not** rely on a lint for soundness [2]. There are
several ways to disable lints and it's not guaranteed that the lint will
catch everything.

[1]: https://doc.rust-lang.org/rustc/lints/listing/deny-by-default.html#dangerous-implicit-autorefs
[2]: https://rust-lang.zulipchat.com/#narrow/channel/213817-t-lang/topic/dangerous_implicit_autorefs.20and.20Box/near/572196666

Cheers,
Benno