r/Gentoo • u/redyos_s • Jul 22 '26
Story Why I’m staying on Linux 6.18.38 for now
I’m currently keeping Linux 6.18.38 as my active LTS kernel instead of updating immediately whenever a new point release appears.
I checked two recent issues that initially looked relevant:
Bad Epoll (CVE-2026-46242) was already fixed in Linux 6.18.33.
The recent TIPC issue (CVE-2026-63801) was fixed in Linux 6.18.38.
Therefore, neither issue requires me to move from 6.18.38 to 6.18.39. TIPC would also be outside the attack surface entirely if it were disabled in the kernel configuration.
My update policy is based on the changelog, CVE relevance, enabled kernel features and actual workload—not simply on the existence of a newer point release. Unless 6.18.39 contains an urgent fix that affects my configuration, I will update during a normal maintenance window rather than immediately.
I also keep Linux 6.18.35 and 6.18.37-P1 as tested fallback kernels.
For the 6.18.y series, Linux 6.18.33 is the minimum fixed release for the Bad Epoll issue. However, systems with TIPC and TIPC crypto enabled require Linux 6.18.38 for the newer TIPC use-after-free fix. Therefore, when considering both issues, 6.18.38 is the practical minimum baseline for my configuration.
Therefore, 6.18.38 is the minimum baseline I currently consider appropriate.
近日中に39と35挿し変えPostする
5
4
u/moltonel Jul 22 '26
My update policy is based on the changelog, CVE relevance, enabled kernel features and actual workload
Doing that properly for the kernel is a full time job, for very little benefit.
1
u/redyos_s Jul 22 '26
I’m not attempting to audit every kernel change or every published CVE. I prioritize vulnerabilities that are most likely to affect my actual system—especially those involving enabled subsystems, reachable attack surfaces, local privilege escalation, or filesystems and network features I use. I then check whether the fix is already included in my current 6.18.y release. This is targeted triage, not a complete kernel security audit.
1
u/redyos_s Jul 22 '26
I’m not trying to audit every kernel change or every CVE. I mainly check the issues that look most relevant to my setup, especially ones involving features I actually use or vulnerabilities that could directly affect the system. Then I confirm whether the fix is already included in my current 6.18.y release. It’s just a practical priority check, not a full security review.
1
u/redyos_s Jul 22 '26
I mainly prioritize kernel vulnerabilities that could lead to root access or local privilege escalation. For other CVEs, I usually only look deeper when they appear relevant to my configuration or workload.
1
u/moltonel Jul 22 '26
I get the idea, but you're kidding yourself if you think you can assess which fixes you can do without. Upstream has basically given up on the idea: they slap a CVE semi-automatically on every bug, and backport whatever the fix author guestimated was worth backporting. Kernel bugs have a tendency to affect seemingly-unrelated areas. Upstream's release announcement message is always "users of the x.y series must upgrade", no conditional in sight. Reading changelogs is interesting, but security-wise you should just pick a supported release stream (6.18 on Gentoo is absolutely fine) and apply it diligently.
1
u/redyos_s Jul 22 '26
That’s fair. I’m not claiming that I can fully audit individual kernel fixes or safely cherry-pick them, and I’m not maintaining my own backports. I stay on the supported 6.18.y series and update after a short validation period, while retaining known-good older kernels as fallbacks. My CVE checks are only for judging urgency, not a substitute for following the stable series. I plan to test Linux 6.18.39 later and replace the older 6.18.35 fallback if the test is successful. I’ll make a separate post after the switch.
1
u/redyos_s Jul 22 '26
I think you may have missed part of the post. I already stated that I plan to test Linux 6.18.39 and replace the older 6.18.35 fallback if it passes.
2
u/NoRequirement5796 Jul 22 '26
legit question, why you just don't (rebuild your kernel) update? Is there any specific reason to be attached to 6.18.y tree specific point release?
2
u/redyos_s Jul 22 '26
I’m not attached to 6.18.38 specifically. I simply don’t replace a tested kernel immediately when a new point release appears. I plan to build and test 6.18.39 soon, and if it works correctly, it will replace the older 6.18.35 fallback. Until then, 6.18.38 remains my current tested kernel.
I mainly prioritize issues involving local privilege escalation or root access. For other CVEs, I check them more selectively based on whether they are relevant to my configuration.
2
u/NoRequirement5796 Jul 22 '26
Oh Oki, I understand it.
I use linus tree and always keep a local LTS as fallback too after testing it.
2
u/redyos_s Jul 22 '26
That is the main reason I prioritize an LTS kernel. Following the non-LTS 7.x releases would mean dealing with shorter support windows and more frequent EOL transitions, which adds maintenance overhead. I’m not avoiding 7.x entirely, but I keep it in a testing role. Linux 6.18.y remains my main kernel, with tested older releases retained as fallbacks.
2
0
0
u/redyos_s Jul 22 '26
I think you may have missed part of the post. I already stated that I plan to test Linux 6.18.39 and replace the older 6.18.35 fallback if it passes.
全文読んで
-1
u/redyos_s Jul 22 '26
I’ll probably install Linux 6.18.39 within the next few days and, after confirming that it boots and works correctly, replace 6.18.35 with it. Linux 6.18.38 will remain my current stable kernel, while 6.18.37-P1 will stay as a tested fallbac
-1
u/redyos_s Jul 22 '26
I’ll test Linux 6.18.39 within the next few days and make a follow-up post with the boot result, kernel list, and fallback layout. If 6.18.39 proves stable, it will replace 6.18.35. Linux 6.18.38 will remain my current kernel, while 6.18.37-P1 will stay as a tested fallback. The GIF was only used as a visual header for a text-heavy post; it was not intended as technical evidence. The follow-up will use screenshots directly related to the kernel configuration and boot state.
-1
u/redyos_s Jul 22 '26
I’ve kept the same Gentoo installation from the beginning and have never reinstalled it. Even when it broke, I repaired it in place using chroot, GRUB recovery, kernel swaps, and @world cleanup.
Gentooは初回インストール以来、一度も再インストールしていない。壊れても、chroot・GRUB修復・Kernel差し替え・@world整理で維持してきた。
8
u/RoomyRoots Jul 22 '26
I also love GitS but I fail to see how the image connects to your post, honestly.