Re: x86: missing FRED #PF event data?

From: Sergey Senozhatsky

Date: Mon Aug 10 2026 - 03:38:44 EST


On (26/08/10 15:49), 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.