Security-only updates with dnf on Rocky/Alma

What dnf updateinfo tells you

dnf updateinfo reads the advisory metadata that your enabled repositories publish and matches it against the packages installed on your server. That metadata is what dnf upgrade --security uses to install the fixes for known security problems and leave every other update alone. On Rocky Linux 9 and AlmaLinux 9 the advisories are named RLSA and ALSA, the number matches the Red Hat advisory each rebuild came from, and dnf-automatic with upgrade_type = security runs exactly the same filter on a timer.

The manual workflow is short. Read the summary, list the security advisories, read one, preview the transaction, apply it, then decide whether to reboot.

dnf updateinfo
dnf updateinfo list --security
dnf updateinfo info ALSA-2025:2627
dnf check-update --security
sudo dnf upgrade --security
sudo dnf needs-restarting -r

Every command here except the two with sudo works as a normal user, because reading metadata changes nothing on the system. The rest of this guide is what each step shows you, and what it means when a step shows nothing.

Where the updateinfo metadata comes from

A dnf repository is a directory of RPMs plus a repodata/ folder. The index file repodata/repomd.xml lists the metadata files the repository offers: the package list, the file lists, the comps groups, and, if the publisher provides it, a file of type updateinfo. That file, updateinfo.xml, is a list of advisories. Each advisory has an id, a type (security, bugfix, enhancement or newpackage), a severity, a description, the CVE ids it fixes, and the exact package versions that carry the fix.

dnf downloads updateinfo.xml with the rest of the metadata. It knows nothing about security on its own. If a repository publishes no updateinfo, every package in it is invisible to --security, however serious the fix.

You can check what a repository offers without dnf. Rocky Linux 9 BaseOS, fetched on 2026-09-20:

curl -s https://dl.rockylinux.org/pub/rocky/9/BaseOS/x86_64/os/repodata/repomd.xml | grep -A 4 'type="updateinfo"'

<data type="updateinfo">
    <checksum type="sha256">54b5f36107a1e0285aef9612186714b02663ca10bf1de2de846afecdd880a9a3</checksum>
    <open-checksum type="sha256">213d4afd98ddd7834e5d152403c1551e8bb6ccb56fa6a4c5f0ea8bc7a0acd19a</open-checksum>
    <location href="repodata/54b5f36107a1e0285aef9612186714b02663ca10bf1de2de846afecdd880a9a3-updateinfo.xml.gz"/>
    <timestamp>1789883145</timestamp>

date -u -d @1789883145 turns that timestamp into 05:45 UTC on 2026-09-20, so the file was rebuilt that morning. The AlmaLinux 9 BaseOS index at https://repo.almalinux.org/almalinux/9/BaseOS/x86_64/os/repodata/repomd.xml carried an updateinfo entry stamped 2026-09-19 on the same day. Run the same check against any third-party repository you have added. A repomd.xml with no updateinfo element is the usual reason a package never shows up under --security.

On your own server, the downloaded copies sit in the dnf cache:

sudo dnf makecache
sudo find /var/cache/dnf -name '*-updateinfo.xml*'

One path per repository that publishes advisories. A repository with no line here contributes nothing to dnf updateinfo. EPEL does publish advisories, and they appear with a FEDORA-EPEL- prefix beside the RLSA or ALSA ones; EPEL and CRB on Rocky and AlmaLinux covers what else that repository changes.

Both distributions build updateinfo.xml from the Red Hat advisory that each rebuilt package came from. The Rocky Linux errata wiki page says the data is generated by a system called Apollo, working with the Peridot build system, and published at errata.rockylinux.org. The AlmaLinux errata documentation says its advisories are published at errata.almalinux.org, as updateinfo.xml in the repositories and mirrors, and also as JSON and OVAL files for scanners.

Read the summary with dnf updateinfo

dnf updateinfo

With no arguments the command prints a summary of the advisories that apply to newer versions of packages you have installed. That is the available view, and it is the default. The Rocky wiki shows this output from one of its own hosts (a Rocky 8 box, so the versions end in el8; yours end in el9):

Updates Information Summary: available
    1 New Package notice(s)
    5 Security notice(s)
        4 Important Security notice(s)
        1 Moderate Security notice(s)
    1 Bugfix notice(s)
    1 Enhancement notice(s)
Security: kernel-core-4.18.0-372.19.1.el8_6.x86_64 is an installed security update
Security: kernel-core-4.18.0-372.9.1.el8.x86_64 is the currently running version

Read the counts first. They count advisories, and one advisory usually covers several packages, so five security notices can mean twenty package updates. The indented lines split the security notices by severity, which is the value you will use later with --sec-severity.

The two Security: lines at the end appear when a kernel carrying a security advisory is installed but the server is still running an older kernel. Someone applied the update and never rebooted. That is the reboot question this guide returns to at the end.

Four words change which advisories the summary counts. available is the default. installed counts advisories for the versions you already have, so it tells you what has been applied. updates counts only advisories where an upgrade exists. all counts every advisory that names any version of an installed package. dnf updateinfo installed is how you answer the question "did we already patch that".

List only the security advisories

dnf updateinfo list --security

list prints one line per package per advisory. Three columns: the advisory id, the type with its severity, and the package version that carries the fix. The same Rocky wiki host, unfiltered with dnf updateinfo list, printed lines like these (trimmed):

RLSA-2022:6159              Moderate/Sec.  curl-7.61.1-22.el8_6.4.x86_64
FEDORA-EPEL-2022-42c9410b12 bugfix         koji-1.30.0-1.el8.noarch
RLSA-2022:5819              Important/Sec. kernel-4.18.0-372.19.1.el8_6.x86_64
RLSA-2022:5819              Important/Sec. kernel-core-4.18.0-372.19.1.el8_6.x86_64
RLSA-2022:6206              Important/Sec. systemd-239-58.el8_6.4.x86_64
RLSA-2022:6206              Important/Sec. systemd-libs-239-58.el8_6.4.x86_64

Adding --security drops the bugfix and enhancement lines and keeps the ones marked /Sec.. The advisory id repeats because RLSA-2022:5819 fixes both kernel and kernel-core, and list is per package. For one line per advisory, keep the first column and deduplicate it:

dnf -q updateinfo list --security | awk '{print $1}' | sort -u

The AlmaLinux wiki writes the same command as dnf updateinfo --list. Both spellings work in dnf 4.

Two flags are useful with list. --installed shows the security advisories you have already applied, which is what an auditor asks for. --with-cve adds the CVE ids to each line, so you can grep for one.

dnf updateinfo list --security --installed
dnf updateinfo list --security --with-cve

Read one advisory with dnf updateinfo info

Take an id from your list and ask for the full text:

dnf updateinfo info ALSA-2025:2627

The output is one block per advisory, framed by lines of = signs. The title comes first, then labelled fields: Update ID, Type, Updated, Bugs, CVEs, Description, Severity and Installed. The CVEs field lists one id per line. For ALSA-2025:2627, which errata.almalinux.org publishes as "Important: kernel security update" dated 2025-03-14, that field holds six CVEs, among them CVE-2024-50302 and CVE-2024-53197, and the package list is the whole kernel-5.14.0-503.31.1.el9_5 set. On Rocky the same fix ships under the RLSA prefix with the same number: the Rocky CVE hygiene guide states that RLSA advisories mirror the upstream RHSA and share its number, with only the prefix changed.

You can also start from a CVE id and find the advisory that fixes it:

dnf updateinfo info --cve CVE-2024-6119

If that prints nothing, add --installed. The default available view only shows advisories for versions newer than the one you have, so a CVE you already patched is silent until you ask for installed advisories. If it still prints nothing, either the distribution has not shipped a fix for that CVE, or the fix shipped and the metadata does not mention it yet. The verification section below tells those two apart.

Preview with dnf check-update --security

dnf check-update --security
echo $?

check-update prints the packages that would be upgraded and exits with code 100 when there is something to do, 0 when there is nothing, and 1 on an error. With --security it only counts packages named in a security advisory. The exit code is the useful part: a cron job or a monitoring check can run dnf -q check-update --security and alert on 100 without parsing any text.

Apply only the security updates

sudo dnf upgrade --security

dnf builds a transaction from every installed package that has a newer version named in a security advisory, then resolves dependencies as it always does. Read the transaction summary before you type y. The filter chooses the targets, and dependency resolution can add packages with no advisory of their own because a target requires them. That is correct behaviour, but it means "security only" describes the reason for the transaction, not every package in it.

upgrade takes each target to the newest version available. If you want the smallest possible change, upgrade-minimal takes each package only to the nearest version that carries the fix:

sudo dnf upgrade-minimal --security

The same flags select the other advisory types. --bugfix, --enhancement and --newpackage each add their type to the filter, and the flags combine, so --security --bugfix installs the union of both.

sudo dnf upgrade --bugfix
sudo dnf upgrade --security --bugfix

If a security update breaks something, the transaction is in dnf history, and dnf history undo can roll it back as one unit.

Target one advisory or one CVE

sudo dnf upgrade --advisory=ALSA-2025:2627
sudo dnf upgrade --cve=CVE-2024-50302
sudo dnf upgrade --sec-severity=Critical,Important

--advisory and --cve install only the packages that fix what you named. Both take a comma-separated list, and both can be repeated. --sec-severity accepts Critical, Important, Moderate and Low, and it matches exactly, so Critical alone does not include Important. List every level you want.

Verify afterwards from the metadata, and then from the package itself:

dnf updateinfo list --cve CVE-2024-50302 --installed
rpm -q --changelog kernel-core | grep CVE-2024-50302

The first command should now list the advisory next to the installed version. The second reads the RPM changelog, which the packager writes and which does not depend on updateinfo.xml, so it confirms the fix is in the binary you installed. The Rocky documentation warns that binary RPM changelogs can be truncated, so an empty grep is not proof of absence. When you need a full accounting of what is fixed and what is not, checking your server for known CVEs against the OVAL data both distributions publish is the thorough method.

How dnf-automatic uses the same metadata

dnf-automatic is a timer that runs dnf for you. Its configuration file is /etc/dnf/automatic.conf, and one line selects security-only mode:

[commands]
upgrade_type = security
apply_updates = yes

The documented meaning of security is "only those with an issued security advisory". In the source, that setting makes dnf-automatic call add_security_filters with the type security and then upgrade_all. dnf upgrade --security calls the same function with the same argument. There is no second list and no second opinion. Whatever dnf updateinfo list --security shows you today is what the timer would install tonight, and whatever is missing from the metadata, the timer also misses.

sudo dnf install -y dnf-automatic
sudo systemctl enable --now dnf-automatic-install.timer

The timer unit you enable decides whether updates are only downloaded or also installed. upgrade_type is read from the file in every case. Automatic updates with dnf-automatic on Rocky and AlmaLinux covers the timers and the email and motd reports in detail.

RLSA, ALSA, and what to verify on the day

Both distributions use one prefix per advisory type:

• RLSA on Rocky and ALSA on AlmaLinux: security
• RLBA and ALBA: bug fixes
• RLEA and ALEA: enhancements

Security advisories are ranked Critical, Important, Moderate or Low, the same scale Red Hat uses, and the number after the colon is the Red Hat advisory number the rebuild was made from.

Whether the metadata is complete on a given day is not something to assume. Rocky's wiki says its errata "generally attempts to match the advisories provided by Red Hat", which is a statement of intent rather than a guarantee. On 2025-04-02 the Rocky release engineering forum opened a request for comment on the Apollo errata system, stating that the Red Hat Hydra API it pulled advisories from "is not always 100% accurate" and proposing a move to Red Hat's CSAF VEX data for security advisories. In September 2025 a user reported that the Rocky 9.6 BaseOS updateinfo.xml had not changed since December 2024, and a reply confirmed it as a known issue under investigation. The AlmaLinux errata documentation makes no statement about completeness at all.

So verify, with two checks that take a minute each:

dnf check-update
dnf check-update --security

Every package in the first list that the errata site shows under a security advisory should also be in the second list. If a package such as curl appears only in the first list, and errata.rockylinux.org or errata.almalinux.org shows an RLSA or ALSA for that exact version, the metadata and the website disagree. A user reported that exact situation on the Rocky forum in November 2023 for RLSA-2023:5763, and the thread closed with no answer. Upgrade that package by name, sudo dnf upgrade curl, and do not wait for --security to notice.

The second check is the updateinfo timestamp from the repomd.xml command earlier. Compare it with the date of the newest advisory on the errata site for your release. A file that is weeks older than the newest published advisory cannot contain that advisory, so --security cannot install it.

Decide whether the security update needs a reboot

A patched library on disk protects nothing while the old copy is still mapped into a running process. needs-restarting, from the dnf-plugins-core package, compares running processes with the files that were replaced:

sudo dnf needs-restarting -r
echo $?

If the server needs a reboot, the output names the packages and ends with Reboot is required to fully utilize these updates., and the exit code is 1. If it does not, it prints No core libraries or services have been updated since boot-up. followed by Reboot should not be necessary., and exits 0. The reboot decision comes from a fixed list of packages that includes kernel, kernel-core, glibc, systemd, dbus and linux-firmware. A security update to any of those means reboot.

For everything else, -s lists the systemd services that still hold old files, and you restart those instead:

sudo dnf needs-restarting -s

If dnf answers No such command: needs-restarting, install the plugin package with sudo dnf install -y dnf-plugins-core. needs-restarting after updates on Rocky and AlmaLinux goes through the service restart step in detail, including the services the tool says must not be restarted.

Failure modes, with the strings you will see

dnf upgrade --security ends with Nothing to do. while dnf check-update lists updates. None of the pending packages is named in a security advisory that dnf has. Run dnf updateinfo and look at the counts. If it shows bugfix and enhancement notices but no security notices, the pending updates are simply not security fixes, and the filter is doing its job. If it shows no notices at all, either no enabled repository publishes updateinfo (check with the find command above) or the metadata is stale (check the timestamp).

A package from a third-party repository never appears under --security. Its repomd.xml has no updateinfo element. The filter cannot see what nobody published. Upgrade those packages on a normal dnf upgrade schedule instead.

dnf updateinfo info --cve prints nothing for a CVE you read about. Three possibilities, in order of likelihood. The fix is already installed and you are in the default available view, so add --installed. The distribution has not yet shipped the rebuilt package, which the errata site will show. The package shipped but the advisory has not reached updateinfo.xml, which the check-update comparison above shows.

The advisory on the website lists a package that dnf updateinfo list does not show. updateinfo only reports advisories for packages you have installed. An advisory for kernel-rt is silent on a server running the standard kernel, and that is correct.

FAQ

What is the difference between dnf updateinfo and dnf check-update?

dnf check-update lists newer versions of installed packages, whatever the reason for the new version. dnf updateinfo reads the advisory metadata and reports why an update exists: security, bugfix, enhancement or new package, with a severity for the security ones. dnf check-update --security is the same package list filtered through that metadata, and it exits with code 100 when a security update is pending.

Why does dnf upgrade --security say Nothing to do when updates are available?

Because none of the pending updates is listed in a security advisory that dnf downloaded. Either the pending updates are bugfix or enhancement releases, or the repository they come from publishes no updateinfo.xml. A third case is the distribution's metadata being behind its errata website. Run dnf updateinfo to see the counts, then compare dnf check-update against the errata site for your distribution.

How do I install the fix for one CVE on Rocky or AlmaLinux?

sudo dnf upgrade --cve=CVE-2024-50302 installs only the packages that the advisory metadata names for that CVE. Then confirm with dnf updateinfo list --cve CVE-2024-50302 --installed, and with rpm -q --changelog <package> | grep CVE-2024-50302. If dnf finds no packages for the CVE, check errata.rockylinux.org or errata.almalinux.org to see whether a fix has been published for your release.

Does dnf-automatic with upgrade_type = security use different data?

No. It calls the same add_security_filters function that dnf upgrade --security uses, with the same security type, and then runs upgrade_all. Anything that dnf updateinfo list --security cannot see, dnf-automatic cannot install. Verify the metadata the same way for both.

Do I need to reboot after a security update?

Run sudo dnf needs-restarting -r. Exit code 1 with Reboot is required to fully utilize these updates. means yes, which is always the case for the kernel, glibc, systemd and dbus. Exit code 0 means the update can be finished by restarting the services that sudo dnf needs-restarting -s lists.