As Fedora configures the fedora and updates repo out of the box, do kernels from the fedora repo receive security updates?
I was thinking about blocking kernels from the updates repo to meet some kernel version requirements for software like VMWare Workstation as the compatibility table for F41 only mentions support for the base 6.11 kernel while the latest available is 6.16, just wanted to make sure the kernels in the base fedora repo still get attention
To get security updates install the latest kernels from the updates repos.
Fedora does not use LTS methodology.
Fedora kernels recieve updates within their lifecycle, whic is the current and the previous stable version.
If you want more stable long term updates consider CentOS Stream, Rocky, or Alma Linux.
VMware catches up with the kernel releases. But sometime you would need to stick on the last working kernel until VMware fixes their code. You are unlikely to be forced to stay on 6.11, for example, for very long.
If you update your system daily, you will not see 6.16.3-200.fc42.x86_64 when you do uname -r, which is your current kernel.
This essentially contains 5 information about your kernel:
Relevant are for this topic two: the first two.
The actual kernel is 6.16. However, after a kernel (such as 6.16) is released, it is usual that bugs are found that need to be fixed, this includes security-relevant bugs (=security vulnerabilities). Therefore, the kernel receives updates to fix these bugs (and security updates).
Therefore, there are security updates for your kernel: 6.16 .1 , 6.16 .2 , 6.16 .3 → you will not see from the name if it contains only normal bug fixes or security updates, but some kernels are marked as security updates, which means that when a system is set to update but only security updates, such kernel updates will be contained (for the record, although it is fine to save traffic/computation-power by doing only security updates daily, I suggest to still do at least weekly “full” updates too).
Keep in mind that kernels (such as 6.16 or 6.17) have a limited life cycle, and they receive only such updates for their life cycle. Once the life cycle in Fedora ends, you will automatically get the new kernel (such as the recent update from 6.15.10 to 6.16.3), so you do not need to do anything about it, just do your daily updates.
Some kernels become long-term supported kernels and their life cycle continues even when newer kernels are available, so the Linux community maintains several kernels at the same time. But officially for Fedora, we always stick with the most recent one. So even if 6.15 would have become a long-term supported kernel (which it did not become), we would no longer provide updates for it. Again, that shall be no problem, as you will automatically be updated to 6.16.X (I assume you have already:)
Hope that helps.
To expand on Chris’ excelent reply:
These .1, .2 etc kernels are releases from the linux kernel project.
lwn.net reports when these kernels are released for example https://lwn.net/Articles/1036785/
I think I’m right in saying that Fedora kernel team does not backport fixes except where fixes are critical.
The linux kernel team treats most bugs as potential security issues.
One persons feature bug is another persons security issue.
The recommendation from the linux kernel developers is to use the latest kernel you can.
Backported fixes are potentially not as reliable as the same fix in the lastest kernel for example.
I think I’m right in saying that Fedora kernel team does not backport fixes except where fixes are critical.
Well, that is subjective of course, but I see this regularly (though definitely not at each kernel update). E.g., if several users report to have an issue → If a fix is already available and sufficiently verified/tested upstream, and if it can be assumed this has already reached the point in which it can be assumed to end up in the next kernel anyway, they might backport it.
This can be seen in koji: it shows everything about the very kernel, including patches beyond the kernel community default. E.g., kernel-6.16.5-200.fc42 | Build Info | koji
- Thu Sep 04 2025 Justin M. Forbes jforbes@fedoraproject.org [6.16.5-0]
- cpufreq/amd-pstate: Fix a regression leading to EPP 0 after resume (Mario Limonciello (AMD))
- net: ipv4: fix regression in local-broadcast routes (Oscar Maes)
- Linux v6.16.5
So in 6.16.5, there are indeed two fixes that are not yet part of 6.16.5. But again, that might be a coincident. Backporting fixes is not “average” for each kernel. So Barry is right that this is generally to be seen as exception.
In any case, though the Fedora kernel is close to vanilla and documentation of the upstream kernel can be usually transferred 1:1 to Fedora, it is not equal: Linux community kernel + kernel-ark differences = Fedora kernel (also see koji about diffs) 
But that we just maintain the differences rather than a whole kernel should indicate the compatibility between the two Fedora is therefore one of the major distributions to test the kernel, and usually involved in each’s development/testing.
Are you sure that these are patches applied by Fedora and not simply something that Justin Forbes wanted to highlight?
Because I am also waiting for this particular fix and so I checked out the Changelog for 6.16.5. And it shows that it made it into the upstream release:
commit 018afe914b712fdb75a0f4999d7d3d1393a10d32
Author: Oscar Maes <oscmaes92@gmail.com>
Date: Wed Aug 27 08:23:21 2025 +0200
net: ipv4: fix regression in local-broadcast routes
If you grab the SRPM and check for patches in the .spec file you can see clearly which patches are applied to the linux kernel tarball by Fedora kernel maintainers.
Packages from the repo fedora does not get any updates at all after the release date. All updates are provides by the updates repo.
Are you sure that these are patches applied by Fedora and not simply something that Justin Forbes wanted to highlight?
Because I am also waiting for this particular fix and so I checked out the Changelog for 6.16.5. And it shows that it made it into the upstream release:
Interesting case. It is definitely not common, as this documentation is intended to be very precise and distinguish between what is the upstream kernel (which is mentioned to sum up its patches) and what “Fedora does to it”. E.g., the other mentioned patch “cpufreq/amd-pstate: Fix a regression leading to EPP 0 after resume” is not contained in 6.16.5’s change log, though I agree that the change logs upstream are likewise precise in what they contain and mention. I would rather presume an accident than an intended highlight, but I cannot say for sure what the background is.
“Use the source, Lars” 
I know, but I wanted to ask here anyway to get a clarification on the intent of the Koji Changelog. Because reading that is more convenient than dowloading the sources and checking myself.
Edit: I hope this didn’t come across as aggressive, it was just a fun way to paraphrase what you had written, @barryascott, and it’s a phrase that I have used for years with colleagues. Due to recent events, I am a bit more careful how people might react to my particular sense of humor.
“Use the source, Lars”
I love that one 
Sorry for the offtopic post 
OK, I already knew about the other one because I had actually read the Changelog yesterday when I saw 6.16.5 had been released. I did not check the second one you listed, sorry.
I was going to write that but resisted as the reference dosn’t aways work
I say to the kids at the dinner table,
“Use the forks”
Of course in open source, it could be applicable too.
Yeah, it works better if you give it your best Obi-Wan impression, which is kind of hard in writing.
Yes, those are patches applied, the changelog is actually auto generated from git. In that particular case I applied the patch, but stable also picked it up for 6.16.5 so by the time of build it is no longer a patch we carry. Sometimes that just works out, and we do prefer that fixes go out in stable to everyone.
Yes, as the default mode for kernel CVEs is now that they are not assigned until a fix is upstream, we typically get them automatically, but it is safe to assume that pretty much every kernel update fixes a number of CVEs. In the rare case of an exception to that policy, I do backport fixes and do special builds, but those are fairly rare now that upstream is the CNA.
If you want a list of CVEs on the kernel, Making sure you're not a bot! is worth a look, with most messages listing the kernel version the bug was introduced in and the versions it was fixed in.