The 5.18.5 stable kernel update contains mitigation for the processor MMIO stale-data vulnerabilities. These are covered by CVE-2022-21166 CVE-2022-21125 and CVE-2022-21123
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-2022-391e24517d
Please login to add feedback.
0 | 9 | 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 'failed'.
This update's test gating status has been changed to 'waiting'.
This update's test gating status has been changed to 'failed'.
Works for me..
It's been up for a couple of hours now with no issues noticed. The enabled Default and Performance tests pass OK.
This update's test gating status has been changed to 'passed'.
Works for me: all using the Mate Desktop Environment.
sirius: desktop 16GB Intel i7-3770 CPU desktop (SSD + 5 hard drives in RAID-6) real:10m14.790s user:4m38.172s sys:5m5.651s
sedna: laptop 8GB Intel i5-2520M CPU Lenovo T420 (SSD only) real:105m19.977s user:70m44.825s sys:34m53.782s // This is way longer than it should be, 5.18.4 was under 11 minutes!
mercury: laptop 32GB AMD Ryzen 7 5700U with Radeon 5500 Graphics (SSD only) rea1:19m13.122s user:9m34.715s sys:7m41.189s // Prior to 5.18, it used to take about 14 minutes!
*** I’m intensely curious as to the reason for why sedna seems to randomly fluctuate between short (normally under 11 minutes) & extremely long (100+ minutes) elapsed times for the performance test!
This kernel is working well in Fedora 36 both native and as a VM guest using VirtualBox from RPM Fusion.
As a VM guest, BZ#2097165 is still fixed, and the e1000 driver is loaded and working, and networking is fine.
Regression tests passing native although in a VM sometimes timer-overhead is failing, but that isn't unusual for VMs it seems.
This update has been submitted for stable by bodhi.
This update has been pushed to stable.
Default and performance regression tests both PASS on a Dell XPS 13 9350 laptop (i7-6560U CPU @ 2.20GHz × 4) and on two NUC6i5SYK (i5-6260U @ 1.80GHz × 4). Working fine.
Default & performance tests pass (KVM)
Works for me. HP EliteBook 840 G3 Intel i5-6300U (4) @ 3.000GHz Intel Skylake GT2 [HD Graphics 520]
Works for me. HP EliteBook 840 G3 Intel i5-6300U (4) @ 3.000GHz Intel Skylake GT2 [HD Graphics 520]
Works on Acer Aspire Intel® Core™ i7-3632QM CPU @ 2.20GHz Memory: 15.4 GiB of RAM Graphics Processor: Mesa DRI Intel® HD Graphics 4000. Passed all kernel regression tests. wi-fi: Qualcomm Atheros AR9485 Wireless Network Adapter vendor: Lite-On driver: ath9k v: kernel pcie: speed: 2.5 GT/s lanes: 1
For me this update breaks Asus USB-N10 Nano Wi-Fi adapter with Realtek 8188EUS. I can still see it in lsusb, but Settings says "No Wi-Fi Adapter Found". I have "r8188eu 2-3:1.0: _rtw_init_xmit_priv failed" in dmesg, if it helps. Wi-Fi works fine in 5.17.13
@drfvd this update does not break it, it was broken in 5.17.15 (and 5.18.4). Follow https://bugzilla.redhat.com/show_bug.cgi?id=2097526 for fixes. I am guessing short term, the bad patch will be reverted, but it is broken upstream still so a proper fix needs to appear at some point.
@jforbes Thanks for info! I didn't get 5.17.15, nor 5.18.4, so to me it looked like if this update is responsible. Sorry!
ok for me
Been using it for 10+ hours. No regression noticed. Game performance has been improved compared to 5.17 for me. Using on Ryzen 3200G and 5500 XT 8GB GPU (wayland).
@drfvd
It's impossible for this kernel to have this regression - it has changes only in regard to Intel CPUs. The regression might have appeared earlier or you're looking at a HW issue.
@name that's not true actually. Refer to BX#2097526 more carefully. There is even a patched 5.18.5 that reverts the commit that brought the problem to the driver, and it works. In my case it broke my TP-Link TL-WN725N (same chip-set).
Unfortunately this seems to have broken bluetooth mouse reconnection after resume from suspend: https://bugzilla.redhat.com/show_bug.cgi?id=2100761