Fedora 26 Kernel panic with the last two kernels

Until recently I was using Fedora 26 with kernel 4.13.16-202.fc26.x86_64 without problems. But the last two kernel upgrades (4.14.4-200.fc26.x86_64 and 4.14.5-200.fc26.x86_64) are giving me kernel panic. This is the only thing I was able to get before the screen froze:

 [0.061000] ? acpi_sleep_proc_init+0x2a/0x2a
 [0.061000] ? set_debug_rodata+0x1?/0x1?
 [0.061000] acpi_bus_scan+0x?f/0x90
 [0.061000] acpi_scan_init+0xea/0XZZC
 [0.061000] ? acpi_sleep_proc_init+0x2a/0x2a
 [0.061000] acpi_init+0x2f8/0x356
 [0.061000] d0_one_initcall+0x50/0x190
 [0.061000] kernel_init_freeable+0x1a8/0x245
 [0.061000] ? rest_init+0xb0/0xb0
 [0.061000] kcrne1_init+0xe/0x101
 [0.061000] ret_from_fork+0x25/0x30
 [0.061000] Code: c? 01 00 00 00 00 ?4 le 7? Oh 41 83 £0 08 75 58 0f b6 03 ch
   18 41 83 fc 20 ?4 10 41 83 fc 40 75 4? 48 8b 03 ch 0? 0f b7 03 ch 02 <8b> 03 48
   89 01 ch 36 41 83 fc 10 ?4 23 7? 0d 41 83 fc 08 75 28
 [0.061000] RIP: acpi_ex_sgstem_memorg_space_handler+0x16f/0x1c1 RSP: ffffb?0 140006640
 [0.061000] CR2: ffffb701406a6000
 [0.061000] ---[ end trace be3326226d4700d? ]â~@~Tâ~@~Tâ~@~T
 [0.061010] Kernel panic â~@~T not syncing: attempted to kill init! exitcode=0x00 000009
 [0.061010]
 [0.061169] ---[ end Kernel panic - not syncing: Attempted to kill init! exit code=0x00000009
 [0.061169]

Suggestions?

The kernel crashed because the init process is terminating which isn't supposed to happen and would leave kernel data structures in a corrupt state.

That means the problem isn't necessarily caused by the kernel itself. Try booting with an older kernel version that has been working in the past.

What to do next depends on whether the problem turns out to be caused by the kernel version or something else.

If it isn't a kernel problem

Boot into a shell by passing init=/bin/bash or init=/bin/sh as argument for the kernel. Then start looking for clues in logfiles.

If it is a kernel problem

Boot the latest working kernel version. Download the sources of the latest working kernel version and the first broken kernel version. Verify that you get the same results when using a kernel that you build directly from those sources. Next start looking at the differences between the two versions to identify which of the differences actually apply to your system. (Changes in drivers for hardware that you don't have would be an obvious example of something unlikely to be relevant).

If you feel up to the task you can try creating a separate source tree with some files from the working version and some from the broken version to identify which file was causing the breakage.