This vulnerability allows local attackers to escalate privileges on affected installations of Red Hat Enterprise Linux. An attacker must first obtain the ability to execute low-privileged code on the target system in order to exploit this vulnerability. The specific flaw exists within the handling of hfscclass objects. The issue results from the lack of validating the existence of an object prior to performing operations on the object. An attacker can leverage this vulnerability to escalate privileges and execute arbitrary code in the context of the kernel.

This vulnerability allows local attackers to escalate privileges on affected installations of Red Hat Enterprise Linux. An attacker must first obtain the ability to execute low-privileged code on the target system in order to exploit this vulnerability. The specific flaw exists within the handling of hfscclass objects. The issue results from the lack of validating the existence of an object prior to performing operations on the object. An attacker can leverage this vulnerability to escalate privileges and execute arbitrary code in the context of the kernel.

In the Linux kernel, the following vulnerability has been resolved:

net/sched: Always pass notifications when child class becomes empty

Certain classful qdiscs may invoke their classes' dequeue handler on an enqueue operation. This may unexpectedly empty the child qdisc and thus make an in-flight class passive via qlennotify(). Most qdiscs do not expect such behaviour at this point in time and may re-activate the class eventually anyways which will lead to a use-after-free.

The referenced fix commit attempted to fix this behavior for the HFSC case by moving the backlog accounting around, though this turned out to be incomplete since the parent's parent may run into the issue too. The following reproducer demonstrates this use-after-free:

tc qdisc add dev lo root handle 1: drr tc filter add dev lo parent 1: basic classid 1:1 tc class add dev lo parent 1: classid 1:1 drr tc qdisc add dev lo parent 1:1 handle 2: hfsc def 1 tc class add dev lo parent 2: classid 2:1 hfsc rt m1 8 d 1 m2 0 tc qdisc add dev lo parent 2:1 handle 3: netem tc qdisc add dev lo parent 3:1 handle 4: blackhole

echo 1 | socat -u STDIN UDP4-DATAGRAM:127.0.0.1:8888 tc class delete dev lo classid 1:1 echo 1 | socat -u STDIN UDP4-DATAGRAM:127.0.0.1:8888

Since backlog accounting issues leading to a use-after-frees on stale class pointers is a recurring pattern at this point, this patch takes a different approach. Instead of trying to fix the accounting, the patch ensures that qdisctreereducebacklog always calls qlennotify when the child qdisc is empty. This solves the problem because deletion of qdiscs always involves a call to qdiscreset() and / or qdiscpurgequeue() which ultimately resets its qlen to 0 thus causing the following qdisctreereducebacklog() to report to the parent. Note that this may call qlennotify on passive classes multiple times. This is not a problem after the recent patch series that made all the classful qdiscs qlennotify() handlers idempotent.

On Wed, Jun 04, 2025 at 09:52:43AM +0200, David Fernandez Gonzalez wrote: I think I implemented most of what Qualys described (of the parts relevant to systemd-coredump rather than only to apport), except that I simply use fork() rather than clone() (slower PID reuse) and I didn't implement usage of inotify (harder to win the race leading to password hashes in dump). I've been testing this after:

sysctl kernel.pidmax=2000 control unixchkpwd public # Undo SIG/Security hardening

With the PID range reduced from the default of 4M down to 2K, PID reuse is quick even with simple fork(). I am getting frequent unixchkpwd coredumps (without password hashes in them, which is as expected without inotify), but none of them are getting ACLs set for read by the user (unexpected - I thought I'd win this easier race once in a while), e.g.: The POC looks good to me overall but the issue is that the replacement is not really happening while the dump is being generated.

Since the signal from the SUID process is not handled when it exits, it will remain defunct for too long. Either SIGIGN or waitpid for the signal right after SIGKILL. Then you need to spawn the extra processes to replace the PID "fast enough". fork is too slow for this I think, you may need to use clone as Qualys mentioned, for me it always works with clone. After that, it should work! Good point, but this wasn't the issue. A wait() was reached before the replacement PID would have been reached by the loop anyway.

Rather, as Qualys pointed out to me off-list, the biggest issue was that I had the replacement process exit immediately. I had copy-pasted this from the first into the second loop and didn't re-think it through.

Simply fixing this (and tuning a few other things while at it) made the attack work on Rocky Linux 9.5, but I do still have to lower kernel.pidmax as above (or even lower) to have it succeed quickly.

I've attached the revised files. As written, the script will stop when it sees a constant string that's part of unixchkpwd in the core dump. I've also tried editing and running it until it finds password hashes, which it actually did quite a few times as well (that's even without any inotify magic suggested by Qualys). Always the user's, but often also other users' and root's.

Somehow in my testing the core dumps after winning the race only appear when the target PID is low, in the ~300 to ~425 range. I tried this on two different systems (one bare metal and one VM) and observed this same behavior. I don't know why. Also changes to kernel.pidmax and to CPU affinity didn't affect this lucky range in my experiments.

Anyway, this is good enough now as a non-weaponized PoC to confirm that the vulnerability is indeed present on RHEL 9.5 rebuilds and to confirm that its mitigations or fixes make a difference.

Alexander

End of life: 5/31/2035, End of support: 5/31/2030, Latest version: 10.2

For detailed information on changes in this release, see the Red Hat Enterprise Linux 10.0 Release Notes linked from the References section.

On 8/8/24 12:46 PM, Clemens Lang wrote: Hi,

Speaking of LTS distros: RHEL 6.10 supports TLS 1.2.

https://access.redhat.com/support/policy/updates/errata/#LifeCycleDates At what point is a distro not LTS, but a museum piece which we can ignore? What currently supported LTS distro does not support TLS 1.2? 2. Scanning or crawling a wide variety of systems, e.g. by a search engine indexer, an asset enumeration tool, a security scanner, or during a pentest. What good is a search engine index of a webpage no modern browser will connect to?

The other use cases sound like they’d be done with special tooling anyway, in which case that can continue to ship an older version of OpenSSL for this purpose. Regards,

Jens Timmerman

Hi Neil, On 6. Aug 2024, at 11:02, Neil Horman <nhorman () openssl org> wrote:

1) Are distributions/users comfortable with this approach in the time frame proposed? I don’t think this will be a problem for Fedora, CentOS Stream, and RHEL. They mostly disable TLS <1.2 without a simple way to bring it back already. 2) Would builders of OpenSSL consider using the default configuration (with TLS1.0/1.1 disabled in 4.0), or would they ship with these protocols re-enabled in their builds? I would strongly argue for keeping those disabled in Fedora. It’s already not simple to re-enabled them in CentOS Stream or RHEL. 3) If the deprecated protocols are re-enabled, what would constitute a reasonable warning mechanism to inform users that these protocols are going away at some point in the future to pressure users to update to a newer, more secure protocol? I believe the best you can do as a library is what you are already doing: Disabling by default, and possibly marking any TLS-1.0/1.1-specific APIs deprecated.

Logging to stderr from a library is out of the question. Logging to syslog can fail due to SELinux on distros that have it.

The only other good solution we’ve come up with is to add a USDT probe point to deprecated code paths and provide a utility for users to run on their system that will highlight any use of these code paths. That’s Linux-specific, and most users won’t run such a tool, though.

HTH, Clemens

-- Clemens Lang RHEL Crypto Team Red Hat

Important: pki-core security update

IBM Java SE version 8 includes the IBM Java Runtime Environment and the IBM Java Software Development Kit.<br>Security Fix(es):<br><li> IBM JDK: Object Request Broker (ORB) denial of service (CVE-2023-38264)</li> For more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and other related information, refer to the CVE page(s) listed in the References section.

Important: kpatch-patch security update

Important: thunderbird security update

Flatpak is a system for building, distributing, and running sandboxed desktopapplications on Linux.Security Fix(es): flatpak: sandbox escape via RequestBackground portal (CVE-2024-32462) For more details about the security issue(s), including the impact, a CVSSscore, acknowledgments, and other related information, refer the CVE page(s)listed in the References section.

Important: linux-firmware security update

Important: firefox security update

Important: bind, bind-dyndb-ldap, and dhcp security update

Important: ipa security update

Important: less security update

389 Directory Server is an LDAP version 3 (LDAPv3) compliant server. The base packages include the Lightweight Directory Access Protocol (LDAP) server and command-line utilities for server administration.<br>Security Fix(es):<br><li> 389-ds-base: potential denial of service via specially crafted kerberos AS-REQ request (CVE-2024-3657)</li> <li> 389-ds-base: Malformed userPassword may cause crash at domodify in slapd/modify.c (CVE-2024-2199)</li> For more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and other related information, refer to the CVE page(s) listed in the References section.

Important: glibc security update

Important: libreoffice security fix update

End of life: 5/31/2029, End of support: 5/31/2024, Latest version: 8.10

End of life: 5/31/2029, End of support: 5/31/2024, Latest version: 8.10

Important: thunderbird security update

Important: firefox security update

Important: rhc-worker-script security and enhancement update

Important: tigervnc security update

Important: shim security update