Re: x86: missing FRED #PF event data?

["H. Peter Anvin" <hpa@zytor.com>]

On August 10, 2026 1:58:18 AM PDT, Sergey Senozhatsky <senozhatsky@chromium.org> wrote:
>On (26/08/10 16:38), Sergey Senozhatsky wrote:
>> [..]
>> > All the crashes are reported as NULL ptr derefs, however, I believe this
>> > is not exactly the case.  In all crashes CR2 is 0x1000 aligned (we always
>> > crash accessing first byte of a page).  It seems that csum_partial() calls
>> > load_unaligned_zeropad() and we hit what load_unaligned_zeropad() comment
>> > describes as very unlikely) case: "word being a page-crosser and the
>> > next page not being mapped").  So instead of reading 4 remaining bytes
>> > of the page and zeroes for trailing 4 bytes, we panic().  It appears that
>> > FRED #PF is set to 0 while CR2 points to a correct page address.  I added
>> > a simple printk to exc_page_fault:
>> > 
>> >         address = cpu_feature_enabled(X86_FEATURE_FRED) ? fred_event_data(regs) : read_cr2();
>> >         /* Fall back to CR2 if FRED event data was empty */
>> >         if (unlikely(!address)) {
>> >                 address = read_cr2();
>> >                 pr_err(":: fixed up address to %lx [[fred: %lx cr2: %lx]]\n", address, fred_event_data(regs), read_cr2());
>> >         }
>> > 
>> > and got the following while running my tests (and well, we don't crash
>> > anymore):
>> > 
>> > [  254.040223] :: fixed up address to ffff9c4d64af4000  [[fred: 0 cr2: ffff9c4d64af4000]]
>> > ...
>> > [ 1821.904563] :: fixed up address to ffff9c4e9dd0a000  [[fred: 0 cr2: ffff9c4e9dd0a000]]
>> > 
>> > Does any of this make sense to you?
>> 
>> I think the explanation is some pKVM shenanigans.  Sorry for the noise.
>
>No, I think we are back at square one.  I thought that maybe pKVM
>was disabling FRED and that was causing issues.  But I actually see
>that both cpu_feature_enabled(X86_FEATURE_FRED) and (cr4 & X86_CR4_FRED)
>claim FRED is enabled, yet fred #PF data is 0 while CR2 holds the correct
>address.

What is pKVM? Paravirtualized KVM? In that case, it is most likely pKVM not filling in the relevant fields in the FRED stack frame, which would be a very serious bug.

I cannot think of any other way that that could possibly happen otherwise; on bare metal those fields are set by hardware and Linux only consumes them.