Hello! I hope this post finds everyone well! I’m opening this topic to discuss the above CVE as I didn’t spot one for it. CVE-2025-30156 - Red Hat Customer Portal
Understood, its true rocky doesn’t have a repo like RHELs RH-Ceph-Storage and CentosStreams Storage SIG, however there are packages available for ceph-fuse from upstream ceph at “download . ceph . com” so I think that is sufficient.
correct, I can confirm that kernel-ml is 7.X and does indeed have the required commit, so that path works, for me atleast though, I would prefer not to migrate to elrepo if possible.
understood, thank you for clarifying, I was under the impression that backports (or atleast some) were handled directly by the rocky maintainers. thanks for explaining this to me.
looks to be the solution is to sit tight for a RHEL backport then!
Rocky aims to be like for like with RHEL, therefore it relies on what RHEL has. There are instances where critical CVE’s needed fixing recently whereby we took an existing kernel and patched it. Those were all the LPE (local privilege escalation) that occurred recently, and those were available in the Rocky security repository until the official kernels were made available to stay in alignment with RHEL.
Red Hat has Ceph as a paid offering, so obviously they will fix that. If that means the kernel also needs to be patched, then obviously they will do that. Since that kernel is part of the main distribution, then obviously Rocky will also have that later.
Rocky fixes CVE’s that affect Rocky, not products outside of it’s ecosystem. As Rocky doesn’t include Ceph, then it means there is no CVE for Rocky to fix. The CVE issue would only affect Rocky if someone is using Ceph. In that instance it’s a special case situation for a certain usage case. But that could happen by using any other third-party products on a system - it doesn’t mean that Rocky is responsible for any of them. Could you imagine the huge amount of work required to backport for every single situation? It could be a huge amount of work.
The real question is though, since the fix was made in a 7.x kernel, are previous kernels actually vulnerable? The link you posted from RHEL seems to only suggest that RHEL10 has an affected kernel. It says RHEL9 isn’t affected, which would then mean Rocky 9 isn’t either and therefore nothing to fix or patch except Rocky 10 kernel.
Completely reasonable, and makes sense, apologies if I came across as demanding, just trying to understand exactly what the process to fix this will be. Thank you also for taking the time to explain.
So, Kernels are not “vulnerable” in the sense that a host running them can be exploited due to this CVE, to explain, the problem is rather that Ceph uses its own form of keys, so called “cephX” keys for authentication between cluster and clients.
The CVE allows for the arbitrary clientside manipulation of a client CephX key to have more permissions then it should, and thus potentially modify the Ceph cluster or other clients illegitimately, therefore the fix mandates that kernel and fuse clients must switch from a older CephX scheme (aes-128K) with a flawed implementation, to a new one (aes-256KRB5) shown in the kernel client commit I linked.
Thus, the problem is that if a ceph cluster “disallows” the old key type to protect itself and other clients, older kernel clients (4.X, 5.X, 6.X) without the commit and fuse clients that do not support the new key type, will be cut off.
happy to answer any other questions if you are curious!
Going by the information that Red Hat has so far published on the link you gave, it would suggest that RHEL9 (and thus Rocky9) is not vulnerable. That all depends on how complete and correct the info is on the page from Red Hat. I can only speculate based on that.
