en.wikipedia.org/wiki/Long_mode

This sentence overgeneralizes x86 UEFI.

On x86, UEFI exists in both 32-bit (IA-32) and 64-bit (x64) forms. Microsoft’s UEFI FAQ explicitly says: “Microsoft does support both 32 and 64 bit UEFI” and that the OS bitness must match the firmware bitness. That directly contradicts the claim that UEFI firmware and “any UEFI boot loader” all run in long mode.

The Linux kernel documentation also documents booting a 64-bit kernel from 32-bit EFI: protocol 2.13 added support for “booting a 64-bit kernel from 32-bit EFI.” That is further evidence that a UEFI environment on x86 is not inherently long mode.

So the accurate version is narrower: x64 UEFI firmware and x64 UEFI applications run in the x64 UEFI execution environment, but UEFI in general is not synonymous with long mode, because IA-32 UEFI implementations also exist. On systems using IA-32 UEFI, firmware and boot loaders run in 32-bit mode, not long mode; and if a 32-bit OS is booted, its kernel is not in long mode either.

This sentence is too absolute.

In x86-64 long mode, addresses outside the canonical range are invalid, but the resulting exception is not always a general-protection fault. Intel’s Software Developer’s Manual states that in 64-bit mode:

• #SS(0) occurs if a memory address referencing the SS segment is in a non-canonical form.
• #GP(0) occurs if the memory address is in a non-canonical form otherwise.

AMD’s manual says the same thing in different words: a stack reference using a non-canonical address causes #SS, while other non-canonical-address cases can cause #GP.

So the statement is inaccurate because it says all such attempts cause a general-protection fault. A more accurate phrasing would be that using a non-canonical address causes an exception such as #GP or, for stack references, #SS.