Bug 2355276

Same here on Dell Inspiron 16 Plus 7640. In this case, version 1.13.0. Downgrade to 1.12.0 fixed the issue.
It occurred on various kernels from 6.12.6 to 6.13.7 and USB also didn't help.
journalctl doesn't show anything at all between the previous successful boot and the related shutdown a week ago and my current first successful boot after the downgrade.

According to a post on the Dell forums it also occurred with a linux mint USB as well as on fedora and for yet another model / bios variant with an update from the similar point in time / reason for the critical update (CVE-2024-38796). https://www.dell.com/community/en/conversations/inspiron/dell-bios-update-breaks-linux-installs/67d09c66c5ead74c2bf65cd5

Same here on Alienware m16 R2. I upgraded version 1.1.10+. I cannot downgrade back to 1.9.0 which is the last version that worked. I cannot boot openSUSE TW, Linux Mint or any Fedora ISO via Fedora USB Installer or Ventoy.

Created attachment 2087940 [details]
Dell Support help

I contacted Dell via Facebook Messenger and they following is what they had me try with no success.

I don't know anything about kernel debugging, so I suspect that this won't be helpful at all. But, I booted the Fedora 42 installer with parameters "acpi=off earlyprintk=efi earlycon=efifb nosmp nowatchdog console=" and was able to get some diagnostic output on a new XPS 9640 with the 1.12.0 BIOS. The issue happens around here:

```
Booting paravirtualized kernel on bare hardware
BUG: unable to handle page fault for address: ffffffffff5fc330
#PF: supervisor read access in kernel mode
#PF: error_code(0x0000) - not-present page
```

The key call trace lines look like they are:

```
? asm_exc_page_fault+0x26/030
? native_apic_mem_read+0x6/0x20
? intel_thermal_supported+0x5/0x30
? therm_lvt_init+0x23/0x30
```

But here's a report from someone else that looks pretty different: https://lore.kernel.org/lkml/Z-aD1ughy6fd8Ask@archimedes.dunstkreis.ch/T/#u . I think they didn't use "acpi=off", which might be the cause of the difference?

I am having this issue too, with the m16 r2 bios 1.1.10

(In reply to Peter Williams from comment #4)
> The issue happens around here:
> 
> ```
> Booting paravirtualized kernel on bare hardware
> BUG: unable to handle page fault for address: ffffffffff5fc330
> #PF: supervisor read access in kernel mode
> #PF: error_code(0x0000) - not-present page


I have the exact same error on my Alienware M16 R2 (1.11.0 firmware) 6.14.4-300.fc42, booting with those options appended:

My first call trace:

? therm_lvt_init+0x23/0x30
? setup_arch+0x87c/0x8c0
? start_kernel+0x64/0x490
? x86_64_start_reservations+0x24/0x30
? x86_64_start_kernel+0xed/0xf0
? common_startup_64+0x13e/0x141

I'll take a photo and attach it too.

Created attachment 2089090 [details]
Screenshot of boot attempt

It could be related to this EDK2 patch. 
https://github.com/tianocore/edk2/security/advisories/GHSA-xpcr-7hjq-m6qm
https://www.dell.com/support/kbdoc/en-uk/000270384/dsa-2025-044

Also: the people experiencing this issue are reporting that Ubuntu and OpenSUSE kernels can boot successfully, FWIW. So it's not an issue that's universal to *all* Linux kernel builds.

I have a Dell Inspiron Plus 7640 with the same issue trying to install first Rocky Linux and then Fedora 42.
In the grub screen I added a line with "set debug=all" after the initrd line and I got this output:

script/lexer.c:336:lexer token 259 text []
script/lexer.c:336:lexer token 0 text []
(same 2 lines once more)
loader/efi/linux.c:236:linux kernel_address: 0x10000000 handover_offset: 0x1015e70 params: 0x5251e000
loader/efi/linux.c:252:nx: Setting attributes for 0x10000000-0x5adefff to r-x
loader/efi/linux.c:252:nx: permissions for 0x10000000 are ---
loader/efi/linux.c:252:nx: Setting attributes for stack at 0xNumberA-0xNumberB to rw-
loader/efi/linux.c:252:nx: permissions for 0xNumberA are ---

*NumberA and NumberB is just me simplifying the numbers because I'm copying them manually.

I hope this helps

I suppose the real task is to figure out why OpenSUSE kernel works and ours does not.

(In reply to Justin M. Forbes from comment #11)
> I suppose the real task is to figure out why OpenSUSE kernel works and ours
> does not.

I couldn't get openSUSE TW to boot a few weeks ago. Might need to figure out why Ubuntu will boot.

Dell's release notes for BIOS update 1.10.0 (available at https://www.dell.com/support/kbdoc/en-us/000270384/dsa-2025-044) indicate that this update addresses security vulnerability DSA-2025-044. This vulnerability is further detailed in the Tianocore EDK2 security advisory: https://github.com/tianocore/edk2/security/advisories/GHSA-xpcr-7hjq-m6qm.

It appears that the fix implemented in BIOS version 1.10.0 (for Alienware M16 R2), while addressing the security vulnerability, has introduced a regression that prevents the operating system kernel from booting.

above fix for https://www.dell.com/support/kbdoc/en-us/000270384/dsa-2025-044 was also pushed to XPS 16 9640 with a BIOS update.