Re: [REGRESSION] Silent SATA read corruption with dma-iommu on AMD 600-series AHCI (6.19 good, 7.0+ bad)

On 8/28/2026 11:13 AM, Vasant Hegde wrote:
> Can you please apply Commit 1e75a8255f11c81fb and retest. Also boot with
> `amd_iommu=pgtbl_v2`?
>
> @Mario, Can you look into this issue? Is this similar to the one you were
> debugging internally?

Hi Vasant,

Thanks for the quick response.

I checked before testing, and I believe that commit is already in my kernel.
CVE-2026-68329 lists it as fixed in 7.1.6 with 02f8cefa2ad95ea3754f0cfd6fbae7f866202ccb
(and in 7.2-rc5 with 1e75a8255f11c81fb07e81e5029cfd75804350a0, the one you
pointed at). I am running Fedora's 7.1.10-200.fc44, whose changelog says
"Linux v7.1.10", so the 7.1.y backport should be present.

And I have reproduced the corruption on kernels that already contain it. On
7.1.9 my journal has 119 corruption lines for a single boot on 2026-08-23, and
the 20-million-error run described in my first mail was on 7.1.10.

There is a second, independent reason to think it may not be my bug: that CVE
says the race was introduced in 3.0. My persistent journal goes back to
2026-02-27 and shows zero storage errors under 6.18.16 and 6.19.x, including two
full multi-TB backup reads of the same drive on 2026-04-01 and 2026-05-01. If I
were hitting the 2011 race, I would expect it to show there too. What I see
looks like something that appeared between 6.19 and 7.0.

I may of course be wrong about the Fedora build. If you want me to verify the
exact source, tell me what to check and I will.

On amd_iommu=pgtbl_v2: I can run it, and I will report numbers rather than
impressions -- bytes re-read, wall time and the exact workload. Two constraints,
so you know what to expect:

  - It is a production machine, and testing means removing the iommu=pt
    workaround. I also assume a misdirected DMA can land in RAM belonging to
    unrelated processes, not just in the read buffer, so I will stop all
    services for the test rather than run it live.

  - My only quantified data point in translated mode is a single failure after
    768 GiB / 3h25m of verification reads. To honestly call a setting clean I
    would want on the order of 15 TB re-read, which is roughly a day. I will
    not report "this fixes it" on a short clean run.

A 7 TB integrity verification is currently running on this machine and I would
rather let it finish before rebooting. Given the above, would you still like the
pgtbl_v2 run, or is there a cheaper test that would tell you more? I am equally
happy to try libaio instead of io_uring, iommu.strict=1, or amd_iommu=off, in
whatever order is most useful to you.

Mario -- if the issue you were debugging internally has a comparable signature,
I would be glad to compare. I have the raw btrfs csum lines showing eleven
consecutive 4 KiB blocks returned in exact reverse order around a pivot, plus
full dmesg, kernel config, lspci -nnvv and IOMMU domain dumps for both the
failing and the working configuration. I can also collect whatever specific
diagnostics you want, including with a debug patch if you provide one.

Thanks,
Mikael Etienne