.NET is a managed-software framework. It implements a subset of the .NET framework APIs and several new APIs, and it includes a CLR implementation.<br>New versions of .NET that address a security vulnerability are now available. The updated versions are .NET SDK 8.0.117 and .NET Runtime 8.0.17.Security Fix(es):<br><li> dotnet: .NET Remote Code Vulnerability (CVE-2025-30399)</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.

.NET is a managed-software framework. It implements a subset of the .NET framework APIs and several new APIs, and it includes a CLR implementation.<br>New versions of .NET that address a security vulnerability are now available. The updated versions are .NET SDK 9.0.107 and .NET Runtime 9.0.6.Security Fix(es):<br><li> dotnet: .NET Remote Code Vulnerability (CVE-2025-30399)</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.

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

Important: thunderbird security update

Important: nodejs22 security update

Important: varnish security update

GStreamer is a streaming media framework based on graphs of filters which operate on media data. The gstreamer1-plugins-bad-free package contains a collection of plug-ins for GStreamer.Security Fix(es): GStreamer: GStreamer H265 Codec Parsing Stack-based Buffer Overflow Remote Code Execution Vulnerability (CVE-2025-3887) 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: thunderbird security update

Important: firefox security update

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

Important: yggdrasil security update

Moderate: ghostscript security update

.NET is a managed-software framework. It implements a subset of the .NET framework APIs and several new APIs, and it includes a CLR implementation.New versions of .NET that address a security vulnerability are now available. The updated versions are .NET SDK 8.0.116 and .NET Runtime 8.0.16.Security Fix(es): dotnet: .NET and Visual Studio Spoofing Vulnerability (CVE-2025-26646) 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.

.NET is a managed-software framework. It implements a subset of the .NET framework APIs and several new APIs, and it includes a CLR implementation.New versions of .NET that address a security vulnerability are now available. The updated versions are .NET SDK 9.0.106 and .NET Runtime 9.0.5.Security Fix(es): dotnet: .NET and Visual Studio Spoofing Vulnerability (CVE-2025-26646) 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: xz security update

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

OpenShift Data Foundation is software-defined storage integrated with and optimized for the Red Hat OpenShift Data Foundation. Red Hat OpenShift DataFoundation is a highly scalable, production-grade persistent storage for stateful applications running in the Red Hat OpenShift Container Platform. In addition to persistent storage, Red Hat OpenShift Data Foundation provisions a multi-cloud data management service with an S3 compatible API.<br>Security Fix(es):<br><li> go-retryable<a href="http:" target="blank">http:</a> url might write sensitive information to log file (CVE-2024-6104)</li> <li> PostCSS: Improper input validation in PostCSS (CVE-2023-44270)</li> <li> golang.org/x/crypto/ssh: Misuse of ServerConfig.PublicKeyCallback may cause authorization bypass in golang.org/x/crypto (CVE-2024-45337)</li> <li> golang.org/x/net/html: Non-linear parsing of case-insensitive content in golang.org/x/net/html (CVE-2024-45338)</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.

A vulnerability was found in aap-gateway. A Cross-site Scripting (XSS) vulnerability exists in the gateway component. A malicious user could use it to perform actions to impact users by using the "?next=" in a URL and hence redirecting, injecting malicious script, stealing session and data.

A flaw was found in libvirt. A refactor of the code fetching the list of interfaces for multiple APIs introduced a corner case on platforms where allocating 0 bytes of memory results in a NULL pointer. This corner case would lead to a NULL-pointer dereference and subsequent crash of virtinterfaced. This issue could allow clients connecting to the read-only socket to crash the virtinterfaced daemon.

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