Is Rocky affected by CVE-2025-6019?

Rocky Linux Help & Support
, ,
1

Greetings,

About a week ago, two significant vulnerabilities were disclosed: CVE-2025-6018 and CVE-2025-6019. From what I understand, CVE-2025-6018 does not impact RHEL-based distributions such as Rocky Linux. However, I’m uncertain about the implications of CVE-2025-6019.

Since I haven’t seen much discussion around this specific CVE in the context of Rocky Linux, I wanted to ask for clarification here.

To the best of my knowledge, libblockdev is not installed by default in minimal or server installations. Please forgive me if this is a basic or obvious question—I’m relatively new to this and just want to make absolutely sure I understand the situation correctly.

Thank you in advance for any guidance.

Best regards

2

Rocky Linux strives for full compatibility with RHEL. This means that their vulnerabilities will also be ours.

The CVE you’re referencing was fixed in RHEL and subsequently Rocky Linux in the following versions:

  • Rocky Linux 8: No fix available yet
  • Rocky Linux 9: libblockdev-2.28-14.el9_6
  • Rocky Linux 10: libblockdev-3.2.0-4.el10_0

There are certain packages you may or may not install that will require libblockdev either directly or indirectly, or just by happenstance because of some other dependency that needed it. For example, gdisk and mdadm requires udisks2, where that needs libblockdev.

[root@cm02 ~]# dnf repoquery -q --whatrequires udisks2
cockpit-storaged-0:334.1-1.el9_6.noarch
gnome-disk-utility-0:40.2-2.el9.x86_64
gvfs-0:1.48.1-6.el9.i686
gvfs-0:1.48.1-6.el9.x86_64
udisks2-iscsi-0:2.9.4-11.el9.x86_64
udisks2-lsm-0:2.9.4-11.el9.x86_64
udisks2-lvm2-0:2.9.4-11.el9.x86_64
[root@cm02 ~]# dnf repoquery -q --whatrequires libblockdev
libblockdev-plugins-all-0:2.28-14.el9_6.x86_64
libblockdev-tools-0:2.28-14.el9_6.x86_64
python3-blockdev-0:2.28-14.el9_6.x86_64
udisks2-0:2.9.4-11.el9.x86_64
[root@cm02 ~]# dnf repoquery -q --whatrequires gdisk
. . .
libblockdev-part-0:2.28-14.el9_6.i686
libblockdev-part-0:2.28-14.el9_6.x86_64
. . .
udisks2-0:2.9.4-11.el9.x86_64

If these are things you don’t need, then you likely won’t need libblockdev installed. It’s up to you to determine that based on your system configuration and needs. Either way, the updates for 9 and 10 are released, so if you happen to have them installed, dnf update and it will be resolved.

2 Likes
3

Thank you for the detailed response.

To avoid opening a new topic next time—can I safely assume that once RHEL releases an updated package, the corresponding update will be made available in the Rocky Linux repositories shortly afterward?

Also, is there a page or source where such updates(From rocky) are published, or a recommended way to stay informed about them? I’d appreciate any guidance on how to monitor this more effectively.

4

Yes. When upstream releases an update (this can be RHEL or CentOS Stream, depending on the update), we will also try to build that update ourselves. It is released typically between 24 and 48 hours in the general case. Our wiki explains this as well.

One way is to monitor the RSS feeds we have available. Our wiki has information about them. This will give you the most accurate representation of updates we release as they are updated fairly rapidly. Each feed monitors a given repository - The most common ones to monitor would be BaseOS, AppStream, and CRB. When an update is released, the feeds will soon represent that update as soon as the next run completes.

5

From the RH info on this, it shouldn’t be too much of a problem:

Assuming that policy kit is the default from installation, then it shouldn’t be a problem. For now I guess we just wait for an update to appear for RHEL8 and then RL8 and we’re done.