OpenSSH vulnerability CVE-2024-6387

Upstream and Rocky released another fix for a variant of this mentioned issue (CVE-2024-6409)

I’ve used the SIG method to mitigate on day one. Now I get this error when trying to dnf upgrade/update:

 Problem: cannot install both openssh-8.7p1-38.el9_4.4.x86_64 from baseos and from @System
  - package from @System requires openssh =, but none of the providers can be installed
  - cannot install the best update candidate for package
  - problem with installed package
(try to add '--allowerasing' to command line to replace conflicting packages or '--skip-broken' to skip uninstallable packages or '--nobest' to use not only best candidate packages)

Seems like I have to remove, remove SIG/Security repo, dnf clean all and install openssh again.

Or indeed in dnf upgrade add --allowerasing

While I am grateful about the available patches, I am somewhat confused why they do not appear as security updates. I just had a short discussion with a colleague who was trying to convince me that the two openssh updates on Rocky were just normal updates without any relevance for security because they were not listed by dnf check-update --security.

What is the reason behind this? Am I missing something?

Repositories do have metadata. One optional bit in that is flagging some packages to show up with the “–security” filter. For comparison, CentOS did never have any such metadata. Hence a practice to simply run dnf up regularly.

Lack of evidence that something is a security patch is not the proof that it is not a security patch.

The question is thus why is the Rocky metadata “incomplete” and could there be a change to the build tooling that would improve that?

Our errata system has not been in a good state for many months and we (as volunteers) do not have sufficient time to fix the issues it has. PR’s welcome.

1 Like