June brought a fresh wave of updates across openSUSE’s rolling release. There were major feature enhancements, performance improvements, and several critical security fixes.

KDE Plasma 6.4 as a the forefront of these updates alongside KDE Frameworks 6.15.0 and KDE Gear 25.04.2. The Linux kernel had a few updates and packages like GNU Compiler Collection 15, Mesa 25.1.3 and PipeWire 1.4.6 enhanced use of modern hardware, improved rendering capabilities and enhanced audio processing. Among the most crucial updates this month were those addressing security vulnerabilities.

A significant number of packages received important security patches this month. From libsoup, Mozilla Firefox, Python, libssh, Salt, ClamAV, gdm and more, multiple Common Vulnerabilities and Exposures (CVEs) were addressed to keep users and developers happy..

As always, be sure to roll back using snapper if any issues arise.

For more details on the change logs for the month, visit the openSUSE Factory mailing list.

New Features and Enhancements

KDE Plasma 6.4: This version brings a smoother and more customizable desktop experience. Key updates include flexible tiling layouts for each virtual desktop, enhanced window management, and a redesigned Spectacle for better screenshots and annotations. Accessibility sees keyboard navigation and Wayland enhancements. UI changes boost contrast and readability, especially in dark mode. Notifications now support direct update installs, full-screen “Do Not Disturb” mode, and mic-mute alerts. Widgets highlight new apps, media playback controls, and disk repair tools. Digital artists benefit from improved stylus configuration and relative mode support. The system also does a better job managing screen colors and performance with modern hardware. KRunner now visualizes color codes, while System Monitor adds GPU tracking and sensor data. Other tweaks improve file dragging, browser integration and Wayland protocol support.

KDE Frameworks 6.15.0: A major improvement in this version is the switch to QDoc, a modern documentation tool that is clearer and easier to for developers working with components like KArchive, Baloo, and Bluez Qt. Bug fixes across modules such as KArchive and KTextEditor improve stability and performance. User-interface frameworks like KWidgetsAddons and Kirigami received visual and functionality improvements. Accessibility features have also been enhanced. If you use KDE text editors like Kate and KWrite, you’ll see better support for different programming languages like Cap’n Proto and FreeFem.

KDE Gear 25.04.2: Kdenlive benefits from this update with fixes for several crashes, including fixing issues for gradients, histograms, and rendering. The update enhances NeoChat mobile support with better space switching and room management. Calligra improves formula handling to prevent crashes, and Akonadi now correctly handles tag editing and deletion. KDE Connect gains better compatibility with Qt 6.9, and the Konsole terminal app also got fixes..

ceph 18.2.7: This major update includes numerous architectural changes, performance improvements, and new features. One of the most notable changes is the deprecation of FileStore, which signals a full transition to BlueStore for all new deployments. There were enhancements for RADOS, include the introduction of a read balancer and the deprecation of cache tiering in favor of more modern storage strategies. The perf dump and perf schema commands have also been replaced with counter dump and counter schema for improved counter management. Additional updates include IPv6 fixes, orchestrator stability improvements, and updated Python binding patches for mgr modules. This release also disables ceph-mgr-cephadm and includes various build and compatibility patches to ensure smooth integration with modern toolchains and Python versions.

python-psutil 7.0.0: This major update has some significant changes. Support for Python 2.7 has been officially dropped and aligns with broader ecosystem shifts. A crash related to extremely high memory usage in Process.memory_maps() has been resolved and improves the stability for processes handling hundreds of gigabytes.

python-rich 14.0.0: This major version update introduces new features and behavioral changes that impact terminal output and error handling. A notable addition is the TTY_COMPATIBLE environment variable, which allows users to manually control TTY support detection. This is especially useful in headless or unusual terminal environments where automatic detection may fail. Notable changes include how Rich interprets color control variables and it now displays exception notes added via Exception.add_note() that enhances debugging clarity.

Key Package Updates

webkit2gtk3 2.48.3: This update brings stability and performance enhancements for GTK-based web applications and browsers like Epiphany. A major crash fix addresses issues introduced by the new threaded rendering system using the Skia graphics Application Programming Interface; users who experienced instability with recent rendering updates will see improvements. Rendering performance has also been refined by optimizing how dirty regions are processed across worker threads, which leads to smoother visuals and lower CPU usage. Dirty regions are parts of the screen or user interface that have changed and need to be redrawn during rendering. This update enhances both the usability and reliability in WebKit-based applications on GNOME and other GTK environments.

python313 3.13.5: This update provides security fixes and stability improvements. Notable changes include patching CVEs related to tarfile extraction vulnerabilities, fixing a use-after-free in the unicode-escape decoder, and restoring correct behavior for random.getrandbits() with integer-like objects. Library updates improve the handling of IPv6 addresses, email parsing, and zipfile operations. Some generator-related changes from 3.13.4 were rolled back to maintain backward compatibility. Upgrading is recommended for all users to ensure security and stability.

iproute2 6.15: An addition in this release is the support for 64-bit hardware packet counters in tc_util, which enables more precise monitoring of high-throughput interfaces that exceed 32-bit limits. The iprule utility now allows users to specify ports in hexadecimal notation and it improves compatibility and readability when working with low-level network protocols or masks. All backported patches from previous versions have been dropped in favor of upstream-clean code.

kernel-source 6.15.0 and 6.15.3: The 6.15.3 addresses a PCIe hotplug issue where late-arriving device detection signals (Presence Detect Changed) caused unnecessary errors . It also improves how background tasks are handled in I/O scheduling and resolves regressions in WiFi driver compatibility . The update fixes target power management, cryptographic operations, and file system handling (including btrfs and gfs2 ) for better data integrity and performance. The 6.15.0 Kernel reverts the “x86/smp: Eliminate mwait_play_dead_cpuid_hint()” commit to address stability issues and enables support for the Haoyu Microelectronics HYM8563 RTC module that is widely used on ARM64 platforms like Rockchip SoCs. Several patches were integrated to improve ACPI build handling and a number of critical bug fixes from the 6.14.8 update were carried forward, particularly in memory management, DMA engine handling, and I/O subsystems, improving reliability under complex workloads and reducing memory leaks in error paths.

gcc 15: This update introduces new language support and adds packages for Modula-2 and Cobol, which expands its already broad range of supported programming languages. The main toolchain now defaults to GCC 15, the -build flavor remains at version 13 to ensure compatibility and stability for environments requiring a proven compiler backend. The release also includes performance gains, better diagnostics and expanded offloading support, which makes it a recommended upgrade for developers.

fwupd 2.0.12: This update adds support for HP Portable USB-C hubs, more Foxconn 5G modems, and Intel Arc Battlemage GPUs. Some new features include Thunderbolt host controller emulation, enforcement of immutable device enumeration and improved handling of UEFI secure boot variables.

Mesa 25.1.3: Notable changes in this version include fixes for rendering issues in games like DOOM: The Dark Ages and improved driver behavior across Vulkan and OpenGL implementations. Support for osmesa has been dropped as it’s now considered redundant with EGL surfaceless contexts. Several patches were updated or removed, including adjustments to build fixes, SPIR-V translation, and Clover OpenCL handling.

gpg2 2.5.8: This release has a key improvement in the ability to show revocation reasons directly in standard key listings (-k), making it easier to track why a key was revoked without needing additional queries. The update also ensures better interoperability with external tools by emitting revocation reasons as comments in “pub” records and improving compatibility with systems that parse GnuPG key outputs. Two critical regressions were addressed; one affecting decryption and the other impacting the export of SSH keys from smart cards. Additionally, gpg --fetch-key no longer requires a keyserver to be configured, allowing direct key retrieval from URLs or local files, which simplifies key management workflows.

cryptsetup 2.8.0: This release has a key addition that enables better performance by using hardware sectors with additional metadata space. It makes all keyslot types self-contained and improves re-encryption workflows with options like --key-description, --new-key-description, and support for resuming re-encryption using tokens or volume keys. The update also enhances memory handling for Argon2 KDF (used in LUKS2), and improves error reporting for low-memory scenarios. It also optimizes metadata writes in LUKS2 and expands veritysetup capabilities with options like --error-as-corruption.

pipewire 1.4.6: This update fixes crasher bugs in the filter-chain and Advanced Linux Sound Architecture plugin. Latency reporting has been improved in module-combine-stream, and the module-filter-chain now better handles activation and deactivation to avoid crashes. A new option allows users to disable RAOP (Remote Audio Output Protocol) via a context property, offering more control over audio routing.

Bug Fixes and Security Updates

Several key security vulnerabilities were addressed this month. Common Vulnerabilities and Exposures this month are:

Security Updates

libsoup:

• CVE-2025-32911: Fixed a buffer over-read in libsoup’s chunked transfer parser.
• CVE-2025-32910: Resolved out‑of‑bounds access in libsoup’s header parsing.
• CVE-2025-32906: Patched insufficient validation in libsoup’s cookie handling.
• CVE-2025-32912: Fixed HTTP/2 session hijacking vulnerability in libsoup.
• CVE-2025-32909: Addressed memory leak in libsoup’s multipart parser.
• CVE-2025-4948: Fixed wolfSSL QUIC SSL peer verification bypass in libcurl.
• CVE-2025-4969: Patched buffer overflow in libcurl’s dynbuf API.
• CVE-2025-4945: Fixed an out-of-bounds read in the Linux kernel’s USB subsystem leading to potential information disclosure.

Mozilla Firefox 139:

• CVE-2025-5263: Prevented cross-origin script execution leakage in Firefox.
• CVE-2025-5264: Fixed newline-escaping flaw in “Copy as cURL” feature that allowed code execution.
• CVE-2025-5265: Patched similar “Copy as cURL” code-execution bug in Firefox.
• CVE-2025-5266: Fixed event leak from script elements across origins.
• CVE-2025-5267: Fixed clickjacking flaw that exposed saved payment card details.
• CVE-2025-5268: Addressed multiple memory safety bugs in Firefox/Thunderbird.
• CVE-2025-5270: [Reserved: details pending public disclosure.]
• CVE-2025-5271: [Reserved: details pending public disclosure.]
• CVE-2025-5272: [Reserved: details pending public disclosure.]
• CVE-2025-49709: Patched memory corruption in canvas surfaces.
• CVE-2025-49710: Fixed unspecified memory safety issue in Firefox 139.0.4.

python313 3.13.5:

• CVE-2024-12718: Patched Python 3.12+ tarfile filter bug allowing metadata or permission changes outside the extraction directory.
• CVE-2025-4138: Fixed a buffer overflow in libarchive’s ZIP filter handling that could lead to memory corruption.
• CVE-2025-4330: Patched out-of-bounds read in SQLite’s JSON extension when parsing invalid JSON input.
• CVE-2025-4517: Resolved a race condition in OpenSSL’s session cache causing potential use-after-free scenarios.
• CVE-2025-4516: Fixed a use-after-free in CPython’s bytes.decode("unicode_escape", errors="ignore|replace"), preventing memory corruption.

python311:

• CVE-2025-4516: Fixed a use-after-free in CPython’s bytes.decode("unicode_escape", errors="ignore|replace") that could lead to memory corruption.

libssh

• CVE-2025-4877: Write beyond bounds in binary to base64 conversion functions.
• CVE-2025-4878: Use of uninitialized variable in privatekey_from_file().
• CVE-2025-5318: Likely read beyond bounds in sftp server handle management.
• CVE-2025-5351: Double free in functions exporting keys.
• CVE-2025-5372: ssh_kdf() returns a success code on certain failures.
• CVE-2025-5449: Likely read beyond bounds in sftp server message decoding.
• CVE-2025-5987: Invalid return code for chacha20 poly1305 with OpenSSL backend.

Salt:

• CVE-2024-38822: Fixed improper access control in Salt file client functionality.
• CVE-2024-38823: Addressed command injection risk from untrusted pillar data.
• CVE-2024-38824: Patched insecure deserialization in Salt event system.
• CVE-2024-38825: Resolved directory traversal via improperly sanitized paths.
• CVE-2025-22240: Fixed remote command execution through crafted Salt minion returns.
• CVE-2025-22236: Salt minions could overwrite unintended files under specific conditions.
• CVE-2025-22241: Addressed denial-of-service caused by malformed Salt return payloads.
• CVE-2025-22237: Resolved issue where Salt master logs sensitive return data.
• CVE-2025-22238: Patched exposure of minion keys in debug logs.
• CVE-2025-22239: Addressed misconfigured ACLs leading to privilege escalation.
• CVE-2025-22242: Fixed input validation issue in Salt’s ssh module.

xorg-x11-server:

• CVE-2025-49176: Fixed an integer overflow vulnerability bypassing the size check.

libtpms 0.10.1:

• CVE-2025-49133: Fixed an out-of-bounds read vulnerability in the CryptHmacSign function of libtpms, which could be triggered by malicious commands to a TPM 2.0/vTPM, causing service disruption.

ClamAV:

• CVE-2025-20260: PDF parser buffer overflow allowing DoS or remote code execution with large scan limits.
• CVE-2025-20234: UDF parser buffer overflow that may leak data or cause denial-of-service.

gdm:

• CVE-2025-6018: Security risk from use of pam_env in authentication stack.

pam_pkcs11:

• CVE-2025-6018: Same issue as in gdm — use of pam_env in auth stack.

jq 1.8.0:

• CVE-2024-23337: Signed integer overflow in jvp_array_write and jvp_object_rehash.
• CVE-2024-53427: Reject NaN with payload while parsing JSON.
• CVE-2025-48060: Heap buffer overflow in jv_string_vfmt.

pam 1.7.1:

• CVE-2024-10963: pam_access improperly resolves display tokens as hostnames.
• CVE-2025-6020: Privilege escalation in pam_namespace.

xwayland 24.1.7:

• CVE-2025-49175: Fixed an out-of-bounds access issue in the X Rendering extension related to animated cursors.
• CVE-2025-49176: Prevented integer overflow in the Big Requests Extension.
• CVE-2025-49177: Prevented data leaks in the XFIXES extension.
• CVE-2025-49178: Ensured proper handling of input buffer bytes to ignore.
• CVE-2025-49179: Addressed integer overflows in the X Record extension.
• CVE-2025-49180: Fixed integer overflows in the RandR extension, preventing potential crashes or memory corruption.

yelp 42.3:

• CVE-2025-3155: Patched a JavaScript execution flaw in the Yelp help viewer that allowed arbitrary file reads via crafted help documents.

perl-CryptX 0.87.0:

• CVE-2025-40914: Fixed CryptX that embeds a version of the libtommath library that is susceptible to integer overflow.

glib2 2.84.3:

• CVE-2025-6052: Patched integer overflow in GLib’s GString expansion (g_string_maybe_expand), preventing potential buffer overflows.

Users are advised to update to the latest versions to mitigate these vulnerabilities.

Conclusion

June had multiple vulnerability fixes and also had multiple firmware packages that were updated to version 20250613. This includes improvements for Qualcomm, Mediatek, Realtek, and Cirrus sound chips, along with a Bluetooth firmware upgrade and better symlink handling. There were also multiple Xfce panel plugins updates (mailwatch, mount, mpc, netload, notes, places, and sensors) to new versions. These package updates were for transitioning builds to Meson, replacing deprecated dependencies like Exo with libxfce4ui 4.21.0, automating copyright management, improving code structure, fixing build warnings and updating translations. Security was a major theme this month, with critical vulnerabilities patched across Firefox, Python, Salt, ClamAV, libssh, and more. Happy updating!.

Slowroll Arrivals

Please note that these updates also apply to Slowroll and arrive between an average of 5 to 10 days after being released in Tumbleweed snapshot. This monthly approach has been consistent for many months, ensuring stability and timely enhancements for users. Updated packages for Slowroll are regularly published in emails on openSUSE Factory mailing list.

Contributing to openSUSE Tumbleweed

Stay updated with the latest snapshots by subscribing to the openSUSE Factory mailing list. For those Tumbleweed users who want to contribute or want to engage with detailed technological discussions, subscribe to the openSUSE Factory mailing list . The openSUSE team encourages users to continue participating through bug reports, feature suggestions and discussions.

Your contributions and feedback make openSUSE Tumbleweed better with every update. Whether reporting bugs, suggesting features, or participating in community discussions, your involvement is highly valued.

Today, SUSE has released a new fine-tuned version of the language model, Cavil-Qwen3-4B, as open source on openSUSE’s Hugging Face in order to make legal compliance automation more accessible to developers across the open-source ecosystem.

The release is built on the excellent Qwen3-4B base model and uses a LoRA adapter (Low-Rank Adaptation) to detect legally relevant text like license declarations in code and documentation. The model stems from openSUSE’s compliance tool Cavil, which provides transparent and collaborative open-source legal tooling.

The 4B parameter model size offers a great balance between performance and deployability, since it provides strong language understanding and is compatible with consumer-grade GPUs. All Qwen3 variants are using the OSI-approved Apache 2.0 license, which allows commercial use and redistribution as long as licensing requirements are met.

“This model brings enterprise-grade legal classification to the broader developer community,” said Sebastian Riedel, a contributor to the project. “It’s a practical tool for any project that wants to stay ahead of compliance risks without heavyweight infrastructure.”

The project’s approach uses a 150,000-sample dataset and the Alpaca instruction format to train the model on identifying license headers and similar legal text. Evaluated against several open models, Cavil-Qwen3-4B demonstrated high accuracy with quantization options for efficient use on smaller devices.

The dataset and validation tools used to create the model will also be available via Hugging Face to allow researchers and developers to reproduce and extend the work.

The team welcomes ongoing feedback and contributions. Developers are encouraged to use the model and Hugging Face to share insights, suggested improvements or to get involved. huggingface.co/openSUSE. Developers can also be found on the openSUSE Factory mailing list.

Dear Tumbleweed users and hackers,

Week 25 of 2025 brought us five snapshots — 0612, 0613, 0614, 0616, and 0617 — packed with updates and fixes from all corners of the project. It’s awesome to see everyone’s work coming together to keep things fresh and smooth. Let’s take a quick look at what landed this week and get ready to keep pushing openSUSE forward!

The most relevant changes were:

• qemu 10.0.2
• audit 4.0.2
• Linux kernel 6.15.2
• rdma-core 57.0
• Nano 8.5
• Mozilla Firefox 139.0.4
• GCC 15 is now the default compiler. Package maintainers: please check the status of your packages in the devel projects. We are not planning to rebuild the entire Factory project this time around
• FreeRDP 3.16.0

Things that are currently brewing in the staging areas or are being tested by QA are:

• KDE Plasma 6.4.0
• KDE Frameworks 6.15.0
• Graphviz 12.2.1
• xwayland 24.1.7
• PAM 1.7.1
• Using grub2-bls as the default bootloader on UEFI systems
• CMake 4.0
• Ceph 18.2.7
  

Grace Hopper to Boost Tumbleweed Armv9 Builds

The openSUSE Project is preparing to expand its hardware capabilities with a high-performance system designed to accelerate support for the next generation of processor architecture.

As part of a collaboration between SUSE and NVIDIA, a high-performance NVIDIA Grace Hopper Superchip system has been shipped and is being installed for use in the openSUSE’s Build Service (OBS).

This system will enable Armv9-based builds of Tumbleweed. This is a critical step in expanding the platform’s architecture reach and future-proofing its development infrastructure.

The collaboration reflects a shared commitment to open-source innovation and the need for cutting-edge build capabilities. The addition of the Grace Hopper, which is named after the computer programming trailblazer. aims to meet increasing performance demands in development and testing. Tumbleweed drives progress and supports development through fast iteration in the open-source ecosystem.

The Grace Hopper system, based on the NVIDIA GH200 Superchip, delivers a breakthrough unified CPU-GPU memory model with massive bandwidth and compute capabilities.

This design is built for accelerated computing, large-scale artificial intelligence, and high-performance computing (HPC) applications, which makes it an ideal candidate for OBS as it targets Armv9 optimizations.

Experts from both NVIDIA and arm identified the importance of native Armv9 hardware within OBS to fully realize potential performance gains and validate builds optimized for this architecture. The openSUSE Project’s rolling release is a natural candidate for experimentation on emerging hardware platforms and will improve build speeds for arm-based architectures.

The GH200 system slated for deployment combines an arm-based Grace CPU with a Hopper GPU, linked by NVIDIA’s NVLink-C2C interface. Unlike traditional setups that require constant memory copying between processing units, this architecture allows both processors to access data in place. The result is significantly faster compilation, reduced latency in complex workloads, and better efficiency across OBS pipelines.

The new system is expected to provide openSUSE contributors with faster package build times, lower energy consumption for long-running tasks, and an enhanced development experience, particularly for Armv9 targets.

The June syslog-ng newsletter is now on-line:

• Installing nightly syslog-ng arm64 packages on a Raspberry Pi

• Working with One Identity Cloud PAM Linux agent logs in syslog-ng

• Testing the new syslog-ng wildcard-file() source options on Linux

It is available at https://www.syslog-ng.com/community/b/blog/posts/the-syslog-ng-insider-2025-06-arm64-pam-testing

Dear Tumbleweed users and hackers,

I’m again spanning two weeks, as the Swiss summer weather prevents me from working too long on Friday afternoons (and a couple of holidays on Thursdays), and thus I miss writing the reviews. However, the changes seem manageable, and it should be possible to provide you with an overview of what has happened and what is to come..After the infrastructure issues mentioned in my last review, we could increase the cadence a bit again and have managed to publish 8 snapshots in the past two weeks (0531, 0601, 0602, 0604, 0605, 0606, 0610, and 0611)

The most relevant changes delivered as part of those snapshots were:

• Mozilla Firefox 138.0.4 & 139..01
• cURL 8.14.0 & 8.14.1
• GCC 14.3.0
• GNOME 48.2
• Qt 5.15.17 & Qt 6.9.1
• Samba 4.22.1 & 4.22.2
• libzypp: enable curl2 and parallel download by default
• Linux kernel 6.15.0 & 6.15.1
• LLVM 20.1.6
• Systemd 257.6
• KDE Gear 25.04.2
• GStreamer 1.26.2
• util-linux 2.41
• Virtualbox 7.1.10
• Mesa 25.1.3
• PostgreSQL 17.5
• MariaDB 11.8.2
• SQLite 3.50.1

I admit, the list became longer than I had expected at first. As usual, Tumbleweed does not stop here, and the next snapshot is already being tested with more requests submitted and piled up. The changes we can predict for the foreseeable future are:

• QEmu 10.0.2
• Linux kernel 6.15.2
• Go 1.25
• KDE Plasma 6.4 (6.3.91 is currently being tested)
• Using grub2-bls as default bootloader on UEFI systems
• GCC 15 as distro compiler, see https://build.opensuse.org/staging_workflows/openSUSE:Factory/staging_projects/openSUSE:Factory:Staging:Gcc7
• CMake 4.0 is not yet submitted, but please help fix issues, See https://lists.opensuse.org/archives/list/factory@lists.opensuse.org/thread/FHM4V3PGI3GX65LG6ZIAGJ6QQD5O57WN/

The openSUSE Project has rolled out a new web-based quiz application aimed at engaging conference attendees and open-source enthusiasts around the world.

The quiz platform, available at quiz.opensuse.org, offers a colorful, friendly interface with multiple curated challenges including “Kernel Ninja,” “Chameleon Fun for Kids!,” “The Ultimate YaST Challenge,” and an evolving “openSUSE Expert” mode. The app is designed for use at openSUSE booths during tech conferences, but it’s also accessible for daily use by the broader community.

Quizzes used to mean reprinting a thousand sheets when there was a typo or error, wrote Luboš Kocman in an email to the project mailing list. The change to putting the quiz online makes it sustainable, and far more fun.

Organizers can easily launch dedicated quiz instances for their events by submitting a pull request to the openSUSE/quiz GitHub repository. They can customize content, remove irrelevant quizzes, and avoid PR merges to keep deployments simple. Daily stats and winner selection are available via a built-in /stats endpoint, with optional /bingo functionality to ensure fairness in prize distributions, which will be offered at the openSUSE Conference.

The app supports offline use via npm start, which enables local quiz hosting over a private hotspot. Data is stored in local JSON files and allows event organizers to restart quizzes without losing participant scores. All content is open source, with translations managed through openSUSE’s Weblate platform. People are encouraged to contribute quiz questions and translations.

“The goal is to make the ‘Expert’ quiz never-ending and truly global,” Kocman said.

The openSUSE community plans to showcase the quiz at DevConf.cz today and the openSUSE Conference 2025 in a couple weeks.

Table of Contents

• 1) Introduction
• 2) Overview of sslh
• 3) Security Issues
  • 3.1) File Descriptor Exhaustion Triggers Segmentation Fault (CVE-2025-46807)
  • 3.2) Misaligned Memory Accesses in OpenVPN Protocol Probe (CVE-2025-46806)
• 4) Other Findings and Remarks
  • 4.1) Missing Consideration of Short Reads on TCP Streams
  • 4.2) Likelihood of False Positive Probe Results
  • 4.3) Parsing of Potentially Undefined Data in is_syslog_protocol()
• 5) Resilience of sslh Against High Network Load Attacks
• 6) Summary
• 7) Timeline
• 8) References

1) Introduction

sslh is a protocol demultiplexer that allows to provide different types of services on the same network port. To achieve this, sslh performs heuristic analysis of the initial network data arriving on a connection, and forwards all further traffic to a matching service on the local system. A typical use case is to serve both SSL and SSH connections (hence the name) on port 443, to accommodate corporate firewall restrictions.

In April 2025 we conducted a review of sslh, mostly due to the fact that it processes all kinds of network protocols and is implemented in the C programming language, which is known to be prone to memory handling errors. For this review we looked into release v2.2.1 of sslh. Bugfixes for the issues described in this report can be found in release v2.2.4.

The next section provides an overview of the sslh implementation. Section 3) describes two security relevant Denial-of-Service issues we discovered during our review. Section 4) discusses some non-security relevant findings and remarks we gathered during our review. Section 5) looks into the general resilience of sslh against high network load attacks. Section 6) provides a summary of our assessment of sslh.

2) Overview of sslh

sslh implements so-called probes to determine the type of service when a new TCP or UDP session is initiated. These probes inspect the first few bytes of incoming data until a positive or a negative decision can be made. Once a specific service type has been determined, all following traffic will be forwarded to a dedicated service running on localhost, without interpreting further data. sslh will only probe for those protocols that are actively configured, no other probes will be invoked without need.

sslh supports three different I/O models for handling network input. The choice of what model to use is made at compile time, which is why there can exist multiple sslh binaries, one for each I/O flavor. The following models exist:

• a fork model implemented in sslh-fork.c. In this model, a separate process is forked for each newly incoming TCP connection. The forked process obtains ownership of the TCP connection, handles related I/O, and exits when the connection ends. UDP protocols are not supported in this model.
• a select model implemented in sslh-select.c. In this model, file descriptors are monitored in a single process using the select() system call. This model also supports UDP protocols: for this purpose, all data originating from the same source address are considered to be part of the same session. A dedicated socket is created for each new session sslh detects.
• an implementation based on libev implemented in sslh-ev.c. This variant outsources the I/O management details to the third party library. This also supports UDP protocols in a similar way to the select model described earlier.

The different probes implemented in sslh were one of the focus areas during our review. sslh runs with lowered privileges and systemd hardenings enabled, thus privilege escalation attack vectors will only have limited impact. An area that is still important in spite of these protections is Denial-of-Service, which we looked into as well.

3) Security Issues

3.1) File Descriptor Exhaustion Triggers Segmentation Fault (CVE-2025-46807)

As part of our investigation of Denial-of-Service attack vectors, we looked into what happens when a lot of connections are created towards sslh and, as a result, file descriptors are exhausted. While the sslh-fork variant manages file descriptor exhaustion quite well, the other two variants have issues in this area. This especially affects UDP connections that need to be tracked on application level, since there is no concept of a connection on protocol level.

For each connection, sslh maintains a timeout after which the connection is terminated if the type of service could not be determined. The sslh-select implementation only checks UDP timeouts when there is network activity, otherwise the file descriptors that are created for each UDP session stay open. Due to this, an attacker can create enough sessions to exhaust the 1024 file descriptors supported by default by sslh, thereby making it impossible for genuine clients to connect anymore.

Even worse, when the file descriptor limit is encountered, sslh crashes with a segmentation fault, as it attempts to dereference new_cnx, which is a NULL pointer in this case. Therefore, this issue represents a simple remote Denial-of-Service attack vector. The segmentation fault also happens when the admin configures the udp_max_connections setting (or command line switch), as the NULL pointer dereference is reached in this context as well.

To reproduce this, we tested the openvpn probe configured for UDP. On the client side we created many connections where each connection only sends a single 0x08 byte.

We did not check the sslh-ev implementation very thoroughly, because it depends on the third party libev library. The behaviour is similar to the sshl-select variant, though. UDP sockets are seemingly never closed again.

Bugfix

Upstream fixed this issue in commit ff8206f7c which is part of the v2.2.4 release. While the segmentation fault is fixed with this change, UDP sockets potentially still stay open for a longer time until further traffic is processed by sslh, which triggers the socket timeout logic.

3.2) Misaligned Memory Accesses in OpenVPN Protocol Probe (CVE-2025-46806)

In the UDP code path of is_openvpn_protocol(), if clauses like this can be found:

    if (ntohl(*(uint32_t*)(p + OVPN_HARD_RESET_PACKET_ID_OFFSET(OVPN_HMAC_128))) <= 5u)

This dereferences a uint32_t* that points to memory located 25 bytes after the start of the heap allocated network buffer. On CPU architectures like ARM this will cause a SIGBUS error, and thus represents a remote DoS attack vector.

We reproduced this issue on a x86_64 machine by compiling sslh with
-fsanitize=alignment. By sending a sequence of at least 29 0x08 bytes, the following diagnostic is triggered:

probe.c:179:13: runtime error: load of misaligned address 0x7ffef1a5a499 for type 'uint32_t', which requires 4 byte alignment
0x7ffef1a5a499: note: pointer points here
 08 08 08  08 08 08 08 08 08 08 08  08 08 08 08 08 08 08 08  08 08 08 08 08 08 08 08  08 08 08 08 08
              ^
probe.c:185:13: runtime error: load of misaligned address 0x7ffef1a5a49d for type 'uint32_t', which requires 4 byte alignment
0x7ffef1a5a49d: note: pointer points here
 08 08 08 08 08 08 08  08 08 08 08 08 08 08 08  08 08 08 08 08 08 08 08  08 08 08 08 08 08 08 08  08

Bugfix

The usual fix for this problem in protocol parsing is to memcpy() the integer data into a local stack variable instead of dereferencing the pointer into the raw network data. This is what upstream did in commit 204305a88fb3 which is part of the v2.2.4 release.

4) Other Findings and Remarks

4.1) Missing Consideration of Short Reads on TCP Streams

A couple of probes don’t consider short reads when dealing with the TCP protocol. For example in is_openvpn_protocol() the following code is found in the TCP code path:

    if (len < 2)
        return PROBE_AGAIN;

    packet_len = ntohs(*(uint16_t*)p);
    return packet_len == len - 2;

If less than two bytes have been received, then the function indicates PROBE_AGAIN, which is fine. After the supposed message length has been parsed into packet_len, the probe only succeeds if the complete message has been received by now, otherwise the function returns 0 which equals PROBE_NEXT.

Similar situations are found in is_teamspeak_protocol() and is_msrdp_protocol(). While it may be unlikely that such short reads occur often with TCP, it is still formally incorrect and could lead to false negative protocol detection in a number of cases.

Bugfix

Based on experience upstream believes that this is not an issue in practice currently, since no bug reports in this area have appeared. For this reason this is not a priority for upstream at the moment.

4.2) Likelihood of False Positive Probe Results

A couple of probe functions rely on very little protocol data to come to a positive decision. For example is_tinc_protocol() indicates a match if the packet starts with the string
" 0". In is_openvpn_protocol() any packet that stores the packet length in the first two bytes in network byte order is considered a match, which is probably the case for quite a few network protocols.

Security-wise this is not relevant, because the services these packets are being forwarded to have to be able to deal with whatever data is sent to them, even if it is destined for a different type of service. From a perspective of correct probe implementation it could lead to unexpected behaviour in some situations, however (especially when a lot of protocols are multiplexed over the same sslh port). We suggested upstream to try and base probe decisions on more reliable heuristics to avoid false positives.

Bugfix

Similar to section 4.1) upstream does not believe that this is a major issue for users at the moment, hence there are no immediate changes to the code base to address this.

4.3) Parsing of Potentially Undefined Data in is_syslog_protocol()

The following code is found in is_syslog_protocol():

    res = sscanf(p, "<%d>", &i);
    if (res == 1) return 1;

    res = sscanf(p, "%d <%d>", &i, &j);
    if (res == 2) return 1;

The sscanf() function does not know about the boundaries of the incoming network data here. Very short reads like a 1 byte input will cause sscanf() to operate on undefined data, found in the buffer allocated on the heap in defer_write().

Bugfix

For a quick bugfix we suggested to explicitly zero terminate the buffer by allocating an extra byte after the end of the payload. Running sscanf() to parse integers found in untrusted data could be considered a bit on the dangerous side, however, thus we suggested to generally try and change this into more careful code.

Upstream fixed this in commit ad1f5d68e96, which is part of the v2.2.4 release. The bugfix is along the lines of our suggestion and also adds an additional sanity check for the integer which is parsed from the network data.

5) Resilience of sslh Against High Network Load Attacks

A general-purpose network service like sslh can be sensitive to resource depletion attacks, such as the aforementioned file descriptor exhaustion issue. The sslh-fork implementation spawns a new process for each incoming TCP connection, which brings to mind the possibility to consume excessive resources not only on a per-process scope, but also on a system-wide scope. By creating a large amount of connections towards sslh, a “fork bomb” effect could be achieved. When a “fork bomb” is executed locally on Linux then this often still causes an inaccessible system even today, when there are no strict resource limits in place. Achieving something like this remotely would be a major DoS attack vector.

sslh-fork implements a timeout for each connection, which is based on the select() system call. If the probing phase does not come to a decision before the timeout occurs, then the connection is closed again. By default this timeout is set to five seconds. Since sslh-fork creates a new process for each newly incoming connection, there is no limit of 1024 file descriptors being opened by sslh. In theory an attacker could attempt to exceed the system-wide file descriptor and/or process limit by creating an excessive amount of connections.

The default timeout enforcement of five seconds means that the attack is quite limited, however. During our tests we were not able to create more than about 5,000 concurrent sslh-fork processes. This creates quite a bit of system load, but does not expose any critical system behaviour on an average machine.

Even though the current situation is acceptable, it could be considered to offer an application level limit for the amount of parallel connections. For UDP there exists a udp_max_connections setting already, but not for TCP.

Bugfix

In discussions with upstream it was agreed that proper protection from such Denial-of-Service attacks is best achieved on the end of the administrator, who can for example configure Linux cgroup constraints. Upstream is still considering to add a tcp_max_connections setting to limit the maximum amount of parallel TCP connections in the future.

6) Summary

Overall we believe sslh is in good shape. There is little attack surface, and hardenings are in place by default. With the two remote DoS vectors 3.1) and 3.2) fixed, it should be safe to use sslh in production. Users that are worried about more complex DoS attacks should additionally consider customizing their setup to enforce resource consumption limits on operating system level.

There is some danger of false positive or false negative probe outcomes as outlined in sections 4.1) and 4.2). These seem not to have occurred a lot in practice yet, and it is a trade-off towards simplicity and efficiency in the current implementation of sslh.

7) Timeline

8) References

• sslh GitHub project
• SUSE Bugzilla review bug for sslh
• sslh release v2.2.1 (reviewed version)
• sslh release v2.2.4 (fixed version)

openSUSE.Asia Summit 2026: Call For Host

The openSUSE.Asia Summit is an annual conference that brings together openSUSE contributors and enthusiasts from across Asia. It serves as a valuable platform for face-to-face collaboration, knowledge sharing, and community building. The summit primarily highlights the openSUSE distribution, exploring its applications in both personal and enterprise environments, while also promoting the broader open source culture.

As part of its mission to promote openSUSE across Asia, the openSUSE.Asia Summit Organizing Committee invites local communities to take on the exciting challenge of hosting the 2026 summit. The committee is committed to supporting you every step of the way to ensure a successful and impactful event.

Important Dates

• August 1: Deadline for application
• August 30: Presentation at openSUSE.Asia Summit 2025
• October 31: Announcement of the following host

We will invite you to join our regular online meetings, giving you the opportunity to observe and learn the process of organizing the event. Additionally, you will be expected to present your proposal at the upcoming summit in Faridabad, India. The submitted proposals will be reviewed by the organizing committee. During this process, the committee may reach out with additional questions or requests for further information.

How to Submit?

Please email your proposal to both summit@lists.opensuse.org and opensuseasia-summit@googlegroups.com. Because the former address does not allow attachments, you need to upload your proposal somewhere and share the link to it.

The proposal should contain:

• Venue
• How to reach your city and venue
• Budget Estimation
  • Conference Venue
  • T-shirt
  • Tea break, Lunch, Dinner, Conference Tour, etc.
  • Introduction to your community who will organize the summit
• Introduction to your community that will organize the summit

Please refer to openSUSE.Asia Summit Tips for Organizers before writing your proposal.

We are looking forward to hearing from you soon!