The 6.14.0 kernel release contains a number of important fixes across the tree.
Updates may require up to 24 hours to propagate to mirrors. If the following command doesn't work, please retry later:
sudo dnf upgrade --refresh --advisory=FEDORA-2025-254062023c
Please log in to add feedback.
| 0 | 7 | Test Case kernel regression |
This update has been submitted for testing by jforbes.
This update's test gating status has been changed to 'waiting'.
This update's test gating status has been changed to 'waiting'.
This update's test gating status has been changed to 'passed'.
This update has been submitted for stable by bodhi.
This update has been pushed to stable.
Works for me.. The enabled Default and Performance tests pass OK.
Note the performance logs did not upload "the data value transmitted exceeds the capacity limit" FYI Log size was 29.3k. I've hit this a few times.
Work Station, Asus prime mobo - AMD Ryzen5 5600g/iGPU, 400 Series Chipset, (UEFI) Secure boot, SSD's > RAID1 (ext4)
Looks good to me. Default tests passed. AMD Ryzen 7, iGPU, Secure boot.
default & performance tests pass (KVM)
This issue is still happening with this update.
https://bugzilla.redhat.com/show_bug.cgi?id=2353984
None of my USB3 hubs work. Reverting back to kernel-6.13.7-200.fc41.x86_64 fixes the problem.
Works across around 20 aarch64 devices
both default and performance tests passed
Working for me, tests passing.
Dell Precision T5610 2 x Intel(R) Xeon(R) CPU E5-2603 v2 @ 1.80GHz (8 cores total) NVIDIA Corporation GK104 [GeForce GTX 760] (rev a1)
Working fine on baremetal
Fedora 42 running inside KVM, VM has enabled kdump Bootable but it has exception.
[ 100.007372] ------------[ cut here ]------------ [ 100.007864] UBSAN: array-index-out-of-bounds in arch/x86/kernel/crash.c:283:14 [ 100.008645] index 0 is out of range for type 'range [*]' [ 100.009577] CPU: 4 UID: 0 PID: 9754 Comm: kexec Not tainted 6.14.0-63.fc42.x86_64 #1 [ 100.009582] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS edk2-20241117-5.fc41 11/17/2024 [ 100.009585] Call Trace: [ 100.009589] <TASK> [ 100.009595] dump_stack_lvl+0x5d/0x80 [ 100.009604] ubsan_epilogue+0x5/0x30 [ 100.009609] __ubsan_handle_out_of_bounds.cold+0x46/0x4b [ 100.009614] crash_setup_memmap_entries+0x2ee/0x310 [ 100.009622] setup_boot_parameters+0xf9/0x650 [ 100.009625] ? srso_return_thunk+0x5/0x5f [ 100.009633] bzImage64_load+0x424/0x4e0 [ 100.009636] ? locate_mem_hole_callback+0xe2/0x130 [ 100.009652] kimage_file_alloc_init+0x1ef/0x3e0 [ 100.009658] __do_sys_kexec_file_load+0x13a/0x2e0 [ 100.009663] do_syscall_64+0x7f/0x170 [ 100.009668] ? srso_return_thunk+0x5/0x5f [ 100.009671] ? terminate_walk+0x61/0x100 [ 100.009675] ? srso_return_thunk+0x5/0x5f [ 100.009681] ? path_openat+0x133/0x2b0 [ 100.009693] ? __pfx_lru_add+0x10/0x10 [ 100.009699] ? srso_return_thunk+0x5/0x5f [ 100.009702] ? do_filp_open+0xd5/0x180 [ 100.009706] ? srso_return_thunk+0x5/0x5f [ 100.009709] ? audit_filter_rules.isra.0+0x352/0xcb0 [ 100.009716] ? srso_return_thunk+0x5/0x5f [ 100.009719] ? __audit_filter_op+0xc7/0x130 [ 100.009722] ? srso_return_thunk+0x5/0x5f [ 100.009725] ? mntput_no_expire+0x4a/0x260 [ 100.009730] ? srso_return_thunk+0x5/0x5f [ 100.009733] ? audit_reset_context+0x298/0x300 [ 100.009737] ? srso_return_thunk+0x5/0x5f [ 100.009740] ? syscall_exit_to_user_mode_prepare+0x14a/0x180 [ 100.009745] ? srso_return_thunk+0x5/0x5f [ 100.009748] ? syscall_exit_to_user_mode+0x10/0x210 [ 100.009752] ? srso_return_thunk+0x5/0x5f [ 100.009754] ? do_syscall_64+0x8c/0x170 [ 100.009757] ? srso_return_thunk+0x5/0x5f [ 100.009760] ? do_user_addr_fault+0x36a/0x620 [ 100.009765] ? srso_return_thunk+0x5/0x5f [ 100.009768] ? exc_page_fault+0x7e/0x1a0 [ 100.009772] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 100.009777] RIP: 0033:0x7f4775d50a8d [ 100.009799] Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 4b 63 0f 00 f7 d8 64 89 01 48 [ 100.009802] RSP: 002b:00007ffe212dc358 EFLAGS: 00000246 ORIG_RAX: 0000000000000140 [ 100.009806] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f4775d50a8d [ 100.009808] RDX: 00000000000002b9 RSI: 0000000000000004 RDI: 0000000000000003 [ 100.009810] RBP: 00007ffe212dc4c0 R08: 0000000000000002 R09: 00007ffe212dcdeb [ 100.009815] R10: 0000555fd12c5a50 R11: 0000000000000246 R12: 0000000000000003 [ 100.009817] R13: 0000000000000003 R14: 0000000000000004 R15: 0000555fad18a940 [ 100.009823] </TASK> [ 100.009831] ---[ end trace ]---
I think there is a regression in regard to either encryption or plymouth on x86. EFI (FAT32) and /boot (BTRFS) on unencrypted partitions, / on LUKS encrypted drive with BTRFS. kernel-6.14.0-63.fc42 crashes when plymouth should be displayed kernel-6.14.0-0.rc3.29.fc42 works without issues.