The last few weeks have seen a significant spike in reports of security vulnerabilities in the Linux Kernel. CopyFail, DirtyFrag, and Fragnesia have all exposed a path for a malicious user to escalate their privileges on a system from a standard user to root, and it’s possible there are more vulnerabilities that will be found. The Fedora Project is committed to keeping its users secure and patched against vulnerabilities as quickly as possible when they are disclosed, so let’s talk about how we try to do that.
Recent developments in machine learning have lead to a veritable gold rush for security researchers who can now rely on LLMs to analyze massive code bases like the Linux Kernel and find vulnerabilities at a rate well above what was previously possible. LLMs are also being used to weaponize these vulnerabilities once they’ve been found, allowing attackers to significantly shorten the gap between vulnerability disclosure and exploitation in the wild (source). All this means that it’s more important than ever for Fedora to have a robust process for tracking these vulnerabilities and distributing fixes for them.
What Fedora is doing
There are a number of ways the Fedora Package Maintainers get notified of new security vulnerabilities, the simplest of which is through security bulletins. Many projects post about their security updates on places like the oss-security mailing list and several Fedora contributors monitor these mailing lists for relevant vulnerabilities. The Red Hat Product Security team will also often raise Bugzilla bugs against Fedora packages for CVEs they are tracking, allowing Fedora to take advantage of the work being done to support RHEL customers.
Often security updates will flow through the usual Fedora package update process. Fedora uses tools like Anitya and Packit to monitor for new releases of upstream packages and automatically prepare updates for them. This automation helps across all updates with achieving Fedora’s “First” foundation, but they’re especially helpful for security updates which can be extremely time-sensitive to publish. If everything works as designed, by the time a human gets involved in preparing the update, there could already be a pull request and scratch build ready for testing.
Once the Fedora Package Maintainers are aware of a security vulnerability in a package we distribute, we’ll evaluate the best way to make the patch available to users of supported Fedora releases. Often this just means publishing the latest version of the package, but sometimes this isn’t possible. If the fix has not yet been merged in the upstream project (as happened with the recent kernel vulnerabilities) or if the latest version is too far from the current package version in that Fedora release (more information), the fix may be applied as a standalone patch. This can lead to a situation where a fixed version of the package is available but the version number still shows the vulnerable version, so you can use the dnf changelog command to check the update history for the package and see if a patch has been applied.
Keeping your system secure
It may sound cliché, but for most users the best thing you can do to keep your system secure is regularly updating it. Security package updates in Fedora are tagged with their severity and CVE numbers, so you can keep track of when security updates are published into Bodhi (for example). You can also apply all the pending security updates on your system using the following command:
dnf update --security
Some desktop environments will proactively notify users if there are pending security updates for their system. For example, GNOME Software will periodically check for pending updates and send the user a toast notification like the one below prompting to install the updates.

If you’d like to automate patching vulnerable packages, dnf-automatic can be configured to automatically download and apply security updates on a schedule, although applying kernel upgrades will require rebooting the system. You can learn more about this in the documentation here.
Getting involved
If this kind of Open Source security sounds interesting to you, why not consider becoming a Fedora contributor? We’re always looking for more people to get involved with projects like the Security SIG and Kernel Maintenance!




Start the discussion at discussion.fedoraproject.org