SUSE delivers Raspberry Pi 5 support

It is finally happening. Raspberry Pi 5 users can now look forward to proper support in openSUSE Tumbleweed.

And it is not just about U-Boot, it is so much more. This is thanks to the hard work of many parties like SUSE Hardware Enablement team, RaspberryPi, Ideas on Board, Linaro, and many other engineers, along with Linux and U-Boot subsystem maintainers and many other engineers were patient enough to review our patches.

Many maybe wondering why it is taking so long to enable Raspberry Pi 5-based devices to work on anything other than Raspberry Pi OS; they no longer need to wonder.

About the boot process

First, let’s highlight the simplified OS-level boot architecture differences.

In Raspberry Pi OS, firmware located in the device’s EEPROM directly runs the vendor-developed Linux kernel.

In openSUSE, we use GRUB2. However, GRUB2 itself requires the machine to have UEFI firmware interfaces to be able to locate boot artifacts. Therefore, openSUSE uses the popular Das U-Boot bootloader to provide these interfaces.

This software combination works fine for (open)SUSE products. But this means we have had to add the missing RPi 5 features to U-Boot and the Linux kernel.

New RPi 5 hardware enhancements

Now, on the hardware side, there are some significant differences between the RPi 5 and all previous generations of devices.

Before the RPi 5, all controllers (like USB, Ethernet, SPI, I2C, GPIO, CSI, and so on) were part of the main SoC (BCM2835, BCM2836, BCM2835, BCM2710, BCM2711) and were more or less the same across different generations of these SoCs. Adding support for them in U-Boot and Linux was more or less straightforward.

On the RPi 5, things changed significantly. There is a new “south bridge” chip, the RP1, which contains all of the above controllers. The RP1 is connected to the main SoC (BCM2712) via a PCIe bus.

Fortunately, one thing has remained the same: The MicroSD card controller is still part of the main SoC. So, besides a few small differences in the SD controller’s internals, adding support for it to U-Boot and the Linux kernel was relatively easy.

Initial U-Boot support for bcm2712 SD controller

Add minimal boot support for Raspberry Pi 5

This led people to think that openSUSE was ready to run on this device.

But this was just the beginning of a long journey.

Let’s go back to PCIe. Older RPi’s also have a PCIe root complex, but the RPi 5’s is a little bit different. So, for U-Boot or Linux to be able to access all of the interesting controllers devices, we had to add support for it in U-Boot and the Linux kernel. This was done by this patch set:

Add PCIe support for bcm2712

There are a few other important pieces that landed in the Linux kernel:

• Add support for new MSI-X Interrupt Peripheral

• Add support for pin control driver for BCM2712 SoC

• Add support for clocks provided by RP1

• Implement RaspberryPi RP1 gpio support

After the PCI Express driver was working and Linux could see devices attached to the PCIe root complex, we had to port the driver that handles the new RP1 chip, behind which are the USB, Ethernet, and so on… This became a difficult task because many people had different views on how this should be implemented. But in the end, we got it merged:

Add support for RaspberryPi RP1 PCI device

Now Linux was able to see devices that were attached behind the RP1 chip. Of course, these controllers (Ethernet, for example) were a little bit different than those on the BCM2711, so a new set of patches was required:

Add support for Raspberry Pi RP1 ethernet controller

Of course, there were many more patches required to make this device usable. A really, really short list of them can be found below.

Currently openSUSE Tumbleweed is booting fine from SD card up to the graphical Desktop Environment using HDMI output.

What you should expect to be working once booted into Tumbleweed:

• Ethernet
• WiFi
• Bluetooth
• USB
• HDMI
• …

What is coming

Hopefully U-Boot will soon gain support for BCM2712 PCIe root complex controller. This will bring in ability device to boot from disk. Fixes for Ethernet controller are also on it is way.

Improve Raspberry Pi 5 support

Before you start

Before diving into your openSUSE on Raspberry Pi 5 adventure, make sure your device has the latest EEPROM update.

If you just received your Pi 5 without any system on it, you can prepare a MicroSD card with the EEPROM updater using Raspberry Pi Imager, or simply run the following commands from an existing image on your Pi 5:

sudo rpi-eeprom-update -a
sudo reboot

Do not skip the Debug Probe

If your RPi 5 seems to hang at the U-Boot stage when testing images, you are not alone. This is a known issue being tracked under:

boo#1250992.

This is a temporary workaround, and the issue is expected to be resolved soon.

Using the Debug Probe will save you a lot of time and frustration while experimenting with openSUSE on your RPi 5. It is also a handy tool to keep around for future embedded projects.

Really short list of RPi 5 related patches.

• Add DRM HDMI Codec framework

• Add support for BCM2712 HVS

• Add support for BCM2712 / Pi5 display hardware

• Add watchdog support for BCM2712

• Add Raspberry Pi’s RP1 ADC

What images should I try

You can now run most Raspberry Pi 4 compatible Tumbleweed appliance images or MicroOS if you prefer the immutable variant on your Raspberry Pi 5. openSUSE Leap and Leap Micro are currently out of scope for the effort, but are expected to gain full support in their next releases (16.1 and 6.3 released in late 2026).

Before you begin, make sure that you have the Debug Probe connected. Then write one of the Raspberry Pi images from openSUSE Tumbleweed appliances to your microSD card, and you should be ready to go.

If you can’t decide which image to start with, the Tumblweed Arm GNOME image for raspberrypi is a safe choice.

xzcat image.aarch64.raw.xz | dd of=/dev/sda bs=1M status=progress conv=fsync; sync

If you run into any issues, we highly recommend reaching out on the openSUSE Arm matrix channel or subscribing to the openSUSE Arm mailing list. Alternatively, you’re welcome to use forums.opensuse.org for general openSUSE questions. For general ARM information, visit the openSUSE ARM Portal.

Why run openSUSE on your RPi 5

The official Raspberry Pi OS offers a simple desktop experience, but it is mostly geared toward desktop use and does not include features like containers by default.

With SUSE’s hardware enablement work, you can now get the full openSUSE experience on your Pi. Personally, I enjoy running Cockpit with combination of automatic updates, and I even run containers with my private openSUSE mirror and Nextcloud AIO in containers on my RaspberryPi.

Time to celebrate

To celebrate the hard work of the SUSE Hardware Enablement team, we have sent Raspberry Pi 5 starter kits and Debug Probes to our friends Dale from LowTechLinux and Liam from The Register to share their first impressions with the community.

We also brought a smile to the face of Tomáš, one of last weekend’s openALT.cz attendees, who won a Raspberry Pi 5 and Debug Probe in our openSUSE Quiz. The quiz application, widely used by the openSUSE Booth crew around the world, now features an “openSUSE Arm” section that helps participants learn more about openSUSE’s Arm efforts.

Stay tuned and keep watching our Raspberry Pi 5 Hardware Compatibility page. We will share more updates once USB boot and PCIe are fully functional on the Raspberry Pi 5.

SUSE delivers Raspberry Pi 5 support

It is finally happening. Raspberry Pi 5 users can now look forward to proper support in openSUSE Tumbleweed.

And it is not just about U-Boot, it is so much more. This is thanks to the hard work of many parties like SUSE Hardware Enablement team, RaspberryPi, Ideas on Board, Linaro, and many other engineers, along with Linux and U-Boot subsystem maintainers and many other engineers were patient enough to review our patches.

Many maybe wondering why it is taking so long to enable Raspberry Pi 5-based devices to work on anything other than Raspberry Pi OS; they no longer need to wonder.

About the boot process

First, let’s highlight the simplified OS-level boot architecture differences.

In Raspberry Pi OS, firmware located in the device’s EEPROM directly runs the vendor-developed Linux kernel.

In openSUSE, we use GRUB2. However, GRUB2 itself requires the machine to have UEFI firmware interfaces to be able to locate boot artifacts. Therefore, openSUSE uses the popular Das U-Boot bootloader to provide these interfaces.

This software combination works fine for (open)SUSE products. But this means we have had to add the missing RPi 5 features to U-Boot and the Linux kernel.

New RPi 5 hardware enhancements

Now, on the hardware side, there are some significant differences between the RPi 5 and all previous generations of devices.

Before the RPi 5, all controllers (like USB, Ethernet, SPI, I2C, GPIO, CSI, and so on) were part of the main SoC (BCM2835, BCM2836, BCM2835, BCM2710, BCM2711) and were more or less the same across different generations of these SoCs. Adding support for them in U-Boot and Linux was more or less straightforward.

On the RPi 5, things changed significantly. There is a new “south bridge” chip, the RP1, which contains all of the above controllers. The RP1 is connected to the main SoC (BCM2712) via a PCIe bus.

Fortunately, one thing has remained the same: The MicroSD card controller is still part of the main SoC. So, besides a few small differences in the SD controller’s internals, adding support for it to U-Boot and the Linux kernel was relatively easy.

Initial U-Boot support for bcm2712 SD controller

Add minimal boot support for Raspberry Pi 5

This led people to think that openSUSE was ready to run on this device.

But this was just the beginning of a long journey.

Let’s go back to PCIe. Older RPi’s also have a PCIe root complex, but the RPi 5’s is a little bit different. So, for U-Boot or Linux to be able to access all of the interesting controllers devices, we had to add support for it in U-Boot and the Linux kernel. This was done by this patch set:

Add PCIe support for bcm2712

There are a few other important pieces that landed in the Linux kernel:

• Add support for new MSI-X Interrupt Peripheral

• Add support for pin control driver for BCM2712 SoC

• Add support for clocks provided by RP1

• Implement RaspberryPi RP1 gpio support

After the PCI Express driver was working and Linux could see devices attached to the PCIe root complex, we had to port the driver that handles the new RP1 chip, behind which are the USB, Ethernet, and so on… This became a difficult task because many people had different views on how this should be implemented. But in the end, we got it merged:

Add support for RaspberryPi RP1 PCI device

Now Linux was able to see devices that were attached behind the RP1 chip. Of course, these controllers (Ethernet, for example) were a little bit different than those on the BCM2711, so a new set of patches was required:

Add support for Raspberry Pi RP1 ethernet controller

Of course, there were many more patches required to make this device usable. A really, really short list of them can be found below.

Currently openSUSE Tumbleweed is booting fine from SD card up to the graphical Desktop Environment using HDMI output.

What you should expect to be working once booted into Tumbleweed:

• Ethernet
• WiFi
• Bluetooth
• USB
• HDMI
• …

What is coming

Hopefully U-Boot will soon gain support for BCM2712 PCIe root complex controller. This will bring in ability device to boot from disk. Fixes for Ethernet controller are also on it is way.

Improve Raspberry Pi 5 support

Before you start

Before diving into your openSUSE on Raspberry Pi 5 adventure, make sure your device has the latest EEPROM update.

If you just received your Pi 5 without any system on it, you can prepare a MicroSD card with the EEPROM updater using Raspberry Pi Imager, or simply run the following commands from an existing image on your Pi 5:

sudo rpi-eeprom-update -a
sudo reboot

Do not skip the Debug Probe

If your RPi 5 seems to hang at the U-Boot stage when testing images, you are not alone. This is a known issue being tracked under:

boo#1250992.

This is a temporary workaround, and the issue is expected to be resolved soon.

Using the Debug Probe will save you a lot of time and frustration while experimenting with openSUSE on your RPi 5. It is also a handy tool to keep around for future embedded projects.

Really short list of RPi 5 related patches.

• Add DRM HDMI Codec framework

• Add support for BCM2712 HVS

• Add support for BCM2712 / Pi5 display hardware

• Add watchdog support for BCM2712

• Add Raspberry Pi’s RP1 ADC

What images should I try

You can now run most Raspberry Pi 4 compatible Tumbleweed appliance images or MicroOS if you prefer the immutable variant on your Raspberry Pi 5. openSUSE Leap and Leap Micro are currently out of scope for the effort, but are expected to gain full support in their next releases (16.1 and 6.3 released in late 2026).

Before you begin, make sure that you have the Debug Probe connected. Then write one of the Raspberry Pi images from openSUSE Tumbleweed appliances to your microSD card, and you should be ready to go.

If you can’t decide which image to start with, the Tumblweed Arm GNOME image for raspberrypi is a safe choice.

xzcat image.aarch64.raw.xz | dd of=/dev/sda bs=1M status=progress conv=fsync; sync

If you run into any issues, we highly recommend reaching out on the openSUSE Arm matrix channel or subscribing to the openSUSE Arm mailing list. Alternatively, you’re welcome to use forums.opensuse.org for general openSUSE questions. For general ARM information, visit the openSUSE ARM Portal.

Why run openSUSE on your RPi 5

The official Raspberry Pi OS offers a simple desktop experience, but it is mostly geared toward desktop use and does not include features like containers by default.

With SUSE’s hardware enablement work, you can now get the full openSUSE experience on your Pi. Personally, I enjoy running Cockpit with combination of automatic updates, and I even run containers with my private openSUSE mirror and Nextcloud AIO in containers on my RaspberryPi.

Time to celebrate

To celebrate the hard work of the SUSE Hardware Enablement team, we have sent Raspberry Pi 5 starter kits and Debug Probes to our friends Dale from LowTechLinux and Liam from The Register to share their first impressions with the community.

We also brought a smile to the face of Tomáš, one of last weekend’s openALT.cz attendees, who won a Raspberry Pi 5 and Debug Probe in our openSUSE Quiz. The quiz application, widely used by the openSUSE Booth crew around the world, now features an “openSUSE Arm” section that helps participants learn more about openSUSE’s Arm efforts.

Stay tuned and keep watching our Raspberry Pi 5 Hardware Compatibility page. We will share more updates once USB boot and PCIe are fully functional on the Raspberry Pi 5.

SUSE delivers Raspberry Pi 5 support

It is finally happening. Raspberry Pi 5 users can now look forward to proper support in openSUSE Tumbleweed.

And it is not just about U-Boot, it is so much more. This is thanks to the hard work of many parties like SUSE Hardware Enablement team, RaspberryPi, Ideas on Board, Linaro, and many other engineers, along with Linux and U-Boot subsystem maintainers and many other engineers were patient enough to review our patches.

Many maybe wondering why it is taking so long to enable Raspberry Pi 5-based devices to work on anything other than Raspberry Pi OS; they no longer need to wonder.

About the boot process

First, let’s highlight the simplified OS-level boot architecture differences.

In Raspberry Pi OS, firmware located in the device’s EEPROM directly runs the vendor-developed Linux kernel.

In openSUSE, we use GRUB2. However, GRUB2 itself requires the machine to have UEFI firmware interfaces to be able to locate boot artifacts. Therefore, openSUSE uses the popular Das U-Boot bootloader to provide these interfaces.

This software combination works fine for (open)SUSE products. But this means we have had to add the missing RPi 5 features to U-Boot and the Linux kernel.

New RPi 5 hardware enhancements

Now, on the hardware side, there are some significant differences between the RPi 5 and all previous generations of devices.

Before the RPi 5, all controllers (like USB, Ethernet, SPI, I2C, GPIO, CSI, and so on) were part of the main SoC (BCM2835, BCM2836, BCM2835, BCM2710, BCM2711) and were more or less the same across different generations of these SoCs. Adding support for them in U-Boot and Linux was more or less straightforward.

On the RPi 5, things changed significantly. There is a new “south bridge” chip, the RP1, which contains all of the above controllers. The RP1 is connected to the main SoC (BCM2712) via a PCIe bus.

Fortunately, one thing has remained the same: The MicroSD card controller is still part of the main SoC. So, besides a few small differences in the SD controller’s internals, adding support for it to U-Boot and the Linux kernel was relatively easy.

Initial U-Boot support for bcm2712 SD controller

Add minimal boot support for Raspberry Pi 5

This led people to think that openSUSE was ready to run on this device.

But this was just the beginning of a long journey.

Let’s go back to PCIe. Older RPi’s also have a PCIe root complex, but the RPi 5’s is a little bit different. So, for U-Boot or Linux to be able to access all of the interesting controllers devices, we had to add support for it in U-Boot and the Linux kernel. This was done by this patch set:

Add PCIe support for bcm2712

There are a few other important pieces that landed in the Linux kernel:

• Add support for new MSI-X Interrupt Peripheral

• Add support for pin control driver for BCM2712 SoC

• Add support for clocks provided by RP1

• Implement RaspberryPi RP1 gpio support

After the PCI Express driver was working and Linux could see devices attached to the PCIe root complex, we had to port the driver that handles the new RP1 chip, behind which are the USB, Ethernet, and so on… This became a difficult task because many people had different views on how this should be implemented. But in the end, we got it merged:

Add support for RaspberryPi RP1 PCI device

Now Linux was able to see devices that were attached behind the RP1 chip. Of course, these controllers (Ethernet, for example) were a little bit different than those on the BCM2711, so a new set of patches was required:

Add support for Raspberry Pi RP1 ethernet controller

Of course, there were many more patches required to make this device usable. A really, really short list of them can be found below.

Currently openSUSE Tumbleweed is booting fine from SD card up to the graphical Desktop Environment using HDMI output.

What you should expect to be working once booted into Tumbleweed:

• Ethernet
• WiFi
• Bluetooth
• USB
• HDMI
• …

What is coming

Hopefully U-Boot will soon gain support for BCM2712 PCIe root complex controller. This will bring in ability device to boot from disk. Fixes for Ethernet controller are also on it is way.

Improve Raspberry Pi 5 support

As USB is connected through the RP1 on the PCIe bus we don’t support USB in U-Boot for now. This means you can’t use your USB keyboard in U-Boot or Grub2, as Grub uses the EFI implementation from U-boot. Please be patient.

Before you start

Before diving into your openSUSE on Raspberry Pi 5 adventure, make sure your device has the latest EEPROM update.

If you just received your Pi 5 without any system on it, you can prepare a MicroSD card with the EEPROM updater using Raspberry Pi Imager, or simply run the following commands from an existing image on your Pi 5:

sudo rpi-eeprom-update -a
sudo reboot

Do not skip the Debug Probe

If your RPi 5 seems to hang at the U-Boot stage when testing images, you are not alone. This is a known issue being tracked under:

boo#1250992.

This is a temporary workaround, and the issue is expected to be resolved soon.

Using the Debug Probe will save you a lot of time and frustration while experimenting with openSUSE on your RPi 5. It is also a handy tool to keep around for future embedded projects.

Really short list of RPi 5 related patches.

• Add DRM HDMI Codec framework

• Add support for BCM2712 HVS

• Add support for BCM2712 / Pi5 display hardware

• Add watchdog support for BCM2712

• Add Raspberry Pi’s RP1 ADC

What images should I try

You can now run most Raspberry Pi 4 compatible Tumbleweed appliance images or MicroOS if you prefer the immutable variant on your Raspberry Pi 5. openSUSE Leap and Leap Micro are currently out of scope for the effort, but are expected to gain full support in their next releases (16.1 and 6.3 released in late 2026).

Before you begin, make sure that you have the Debug Probe connected. Then write one of the Raspberry Pi images from openSUSE Tumbleweed appliances to your microSD card, and you should be ready to go.

If you can’t decide which image to start with, the Tumblweed Arm GNOME image for raspberrypi is a safe choice.

xzcat image.aarch64.raw.xz | dd of=/dev/sda bs=1M status=progress conv=fsync; sync

If you run into any issues, we highly recommend reaching out on the openSUSE Arm matrix channel or subscribing to the openSUSE Arm mailing list. Alternatively, you’re welcome to use forums.opensuse.org for general openSUSE questions. For general ARM information, visit the openSUSE ARM Portal.

Why run openSUSE on your RPi 5

The official Raspberry Pi OS offers a simple desktop experience, but it is mostly geared toward desktop use and does not include features like containers by default.

With SUSE’s hardware enablement work, you can now get the full openSUSE experience on your Pi. Personally, I enjoy running Cockpit with combination of automatic updates, and I even run containers with my private openSUSE mirror and Nextcloud AIO in containers on my RaspberryPi.

Time to celebrate

To celebrate the hard work of the SUSE Hardware Enablement team, we have sent Raspberry Pi 5 starter kits and Debug Probes to our friends Dale from LowTechLinux and Liam from The Register to share their first impressions with the community.

We also brought a smile to the face of Tomáš, one of last weekend’s openALT.cz attendees, who won a Raspberry Pi 5 and Debug Probe in our openSUSE Quiz. The quiz application, widely used by the openSUSE Booth crew around the world, now features an “openSUSE Arm” section that helps participants learn more about openSUSE’s Arm efforts.

Stay tuned and keep watching our Raspberry Pi 5 Hardware Compatibility page. We will share more updates once USB boot and PCIe are fully functional on the Raspberry Pi 5.

Lifelong learners and tech enthusiasts don’t view openSUSE Leap as just a stable operating system, but a launchpad for discovery.

Malcolm, who shared with the openSUSE community how his setup is helping to track aviation through the Mississippi Delta with FlightRadar24 and OpenSky Network, sees more use cases for Leap like turning a home lab into a personal academy for cloud-native systems and beyond.

Malcolm uses software-defined radio (SDR) tools that let users decode real-time transmissions. Using an RTL-SDR dongle connected to his Leap-powered systems, Malcolm can track far more than aircraft as SDR can be used to tune into a wide range of radio frequencies. Leap supports a wide variety of open-source software packages and this makes it easy to install and run software for radio signals, satellite data, and more.

Whether experimenting with SDR, or working with satellite data, Leap 16 provides a stable and secure foundation for experimenting.

People learn about container orchestration with Leap.

Tools like KVM or Boxes on openSUSE can create virtual clusters to simulate multi-server environments. People can use openSUSE images to explore the Kubernetes ecosystem. With k3s, RKE2, Longhorn and Rancher Desktop on openSUSE, people can train for certifications and build their skills. This prepares people to learn hands-on troubleshooting and managing cloud production environments.

With Leap 16 and Leap Micro 6.2, users can expand technical knowledge, experiment with new software stacks, and prepare for the challenges of tomorrow. Experimenting with projects helps in the development of core technical skills like those involved with networking, scripting and system tuning; these learned skills open doors for STEM education and DevOps training.

Stories like this highlight a common overlooked use case; continuous learning! A community platform like openSUSE enables learners to experiment, fail, and try again. Students, hobbyists, and professionals alike can build, break, and rebuild systems using Leap with confidence. Whether you’re tracking a balloon over the stratosphere or deploying your first Kubernetes cluster, openSUSE Leap provides a foundation for learning by doing.

Members of the openSUSE Project are trying to showcase how people use openSUSE . If you have a use cases for Leap 16 that you want to share, comment on the project’s mailing list.

Leap is built using the SUSE Linux Enterprise Server (SLE) sources and binaries. Its enterprise-grade stability sets it apart from typical community Linux distros. Leap 16.0 has an extended 24-month support period.

Dear Tumbleweed users and hackers,

My slacking off last week and taking some days for myself has the consequence that I have to cover two weeks without crushing you under too many boring updates. Let’s dive right in and cover the 11! snapshots published during this time (1016, 1017, 1018, 1020 – 1024, 1027, 1028, and 1029).

The most relevant changes were:

• Linux kernel 6.17.3, 6.17.4, and 6.17.5
• clamav 1.5.1
• python 3.13.9
• Mozilla Firefox 144.0 (no longer built for i586!)
• GStreamer 1.26.7
• gnome-shell & mutter 49.1
• Samba 4.22.5
• util-linux 2.41.2
• binutils 2.45
• KDE Plasma 6.5.0 & 6.5.1
• VirtualBox 7.2.4
• Mesa 25.2.5
• garphviz 14.0.0
• Java 25 openJDK
• Changes in Lua interpreter: luajit implementation has changed to the openresty fork (formerly luajit2 package)

The next snapshot is already building, and our testing areas are busy confirming these updates to be made available to you:

• Mozilla Firefox 144.0.2
• Linux kernel 6.17.6
• Mesa 25.2.6
• Switch from grub2 to grub2-bls
• transactional-update 5.5.0: enables soft-reboot if possible
• openSSL 3.6.0: regression detected, which causes nodejs22 testsuite to fail
• kernel hardening: prevent normal users from seeing dmesg

Software packages updating on openSUSE Tumbleweed continued at a brisk pace in October as snapshots arrived almost daily to deliver key software upgrades across desktop environments, development tools, and core system components.

KDE Gear 25.08.2 and Plasma 6.5 refined the KDE desktop with improved performance, accessibility, and stability, while GNOME 49.1 polished the user experience with better session handling and input reliability. Major updates also landed for Kernel Source 6.17.5, Mesa 25.2.5, and PipeWire 1.5.81, and more. Other notable package updates included PHP 8.4.14, curl 8.16.0, ClamAV 1.5.1, and GStreamer 1.26.7.

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 Gear 25.08.2: This release fixes video preview crashes with Dolphin and Kdenlive resolves crashes with effects, filter jobs, and sequence clips. Itinerary and Kitinerary expand transport and booking support with new scripts and more resilient parsing. Other highlights include a crash fix in Okular when saving password-protected files, refined behavior in KClock and KWeather, and QR permission fixes in Keysmith. NeoChat improves push notifications, Tokodon enhances interaction layouts, and backend libraries like K3b, Akonadi, and KMime receive compatibility and performance updates.

GNOME 49.1: This release updates several GNOME apps with bug fixes, accessibility improvements, and translation updates. Highlights include corrected currency rates in Calculator, refined UI and input handling in Control Center, and improved update notifications in GNOME Software. Sudoku resolves RTL input bugs, while System Monitor fixes memory leaks and metadata. The package formerly known as gnome-tour-minimal was renamed to opensuse-welcome, and a new donations page was added with links to both the GNOME Foundation and the Geeko Foundation. GDM fixes a shell lock-up bug and has safety checks for deleting / and /home, which now run in production builds, and Wayland availability detection is corrected. GNOME Characters improves language handling with alias support and has fixes for IBus checks, Flatpak language lists, and active window tracking. GNOME Session improves session reliability by fixing zombie process leaks, resolving option parsing regressions in gnome-session-inhibit, and refines how DBUS_SESSION_BUS_ADDRESS is detected for better operation outside systemd.

File Roller 44.6: The update improves archive handling and fixes multiple format-specific issues. It correctly parses LHA listings, resolves errors with large RAR files, and restores proper follow links behavior for 7zip archives. The update also allows StuffIt files to be opened via Unarchiver, fixes sensitivity issues in the “New Archive” and “Extract” dialogs, and corrects directory detection during compression. Updated translations were also made.

Plasma 6.5: This release provides a smoother, more intuitive experience. Highlights include automatic light/dark theme switching with matching wallpapers, pinned clipboard items, and rounded window corners. Usability improves with better Wi-Fi sharing (including passwords), smarter audio muting, and hibernation from the login screen. Accessibility gains a grayscale filter, Caps Lock announcements for screen readers, and fixes for photosensitive flashing. KRunnerintroduces fuzzy search, Sticky Notes become more flexible, and Wayland desktops can be reordered. Discover is faster with Flathub one-click installs, and Spectacle records popups, and Emoji Selector improves usability. Performance is boosted by faster startup, HDR tuning, and overlay plane support for efficient full-screen playback. Plasma 6.5 feels like the desktop KDE has been perfecting for 29 years now. Also released this month was the Plasma 6.5.1 bugfixe update. This update fixes a crash in Discover, corrected window corner rendering in Breeze-GTK, and had multiple stability improvements in KWin. The bugfix update also resolves issues in KRDp user management, Spectacle screenshot timestamps, and ensures proper firewall UI behavior in Plasma Firewall.

Mesa 25.2.4: The 3D Graphics package has fixes for AMD and Intel GPUs, addresses crashes in games such as FINAL FANTASY XVI, Elite Dangerous, and Call of the Wild: The Angler. Intel Xe2 hardware benefits from corrected display buffer handling and AMD users see improved reliability with shader compilation across uniform blocks. Vulkan video decoding and SPIR-V shader processing receive improvements, and memory management is better during screen shutdown.

curl 8.16.0: This release fixes two security issues; CVE-2025-9086 and CVE-2025-10148. New features include --follow, --out-null, and --parallel-max-host, decimal values for retry options, and caching negative DNS resolutions. TLS 1.2 is now the minimum default, and WebSockets support CURLOPT_READFUNCTION. Numerous fixes improve cookie handling, OpenSSL integration, QUIC/HTTP3 support, and WebSocket stability. Together, these changes enhance security, performance, and developer flexibility across HTTP, SMTP, and TLS use cases.

QEMU 10.1.1: The emulator sees corrections for vector extension handling with RISC-V and compressed instruction IOMMU table limits while SPARC gains more flexible instruction decoding. Migration stability improves with better error handling during postcopy. Memory management is hardened with clearer address space destruction. Build and test infrastructure are also refined to ensure smoother compilation and CI runs.

ClamAV 1.5.1: The malware detection package fixes handling of PE and TNEF files, has more accurate processing of ZIP, RAR, OOXML, and OLE2 documents, and improves fuzzy hashing for images. The update also raises limits for embedded file detection and refines VBA signature matching. The software package added URI metadata extraction for HTML/PDF, regex support for on-access exclusions, CVD signing with .sign files, FIPS-like restrictions on weak hashes, and new administrative controls in ClamD.

PHP 8.4.14: The update fixes property handling bypasses, crashes in closures and array flag inconsistencies. Key modules like curl, GD, MySQLnd, Soap, SimpleXML, and Zip receive stability improvements, while Opcache and JIT-related race conditions are resolved.

Key Package Updates

Kernel Source 6.17.0 through 6.17.5: Linux kernel 6.17.5 has stability improvements for Btrfs, Ext4, and F2FS, fixes for CIFS/SMB and NFS handling, and multiple sound driver quirks for Realtek and Intel hardware. Graphics updates address issues in AMDGPU and Xe drivers. The 6.17.3 update had networking improvements addressing bonding in broadcast mode, USB transport overflow, and multiple Wi-Fi driver issues. The release also fixes crashes and memory handling problems in AMDGPU, ext4, KVM, ksmbd, and LoongArch BPF, along with numerous NULL pointer dereferences across drivers (USB, PCI, RPC, and input). The 6.17.2 version adds support for new USB serial (SIMCom 8230C) and Bluetooth (D-Link AX9U) devices, while adjusting Wi-Fi drivers to avoid conflicts on RTL8192/8188 adapters. Rust subsystem documentation and driver references are corrected, and configuration updates refine console defaults and FIPS handling. The result is improved reliability, hardware support, and security. The 6.17.0 release updates configs that include enabling DEBUG_WX for stricter memory protections and refining platform-specific HID and debugging options. Documentation tooling has been adjusted to handle deprecated Python interfaces, and serial console handling in hvc_console has been improved with more reliable write behavior.

iproute2 6.17: The update to advanced networking package introduces support for new networking attributes, including netns-immutable, mcast_reprobes, and the extern_valid flag for neighbors. It adds mdb_offload_fail_notification to bridge tools and tc-bw in devlink-rate. Color handling was refined to better adapt to dark backgrounds.

python311 3.11.14: This security update strengthens parsing and archive handling. html.parser.HTMLParser was aligned with HTML5 standards, fixing multiple tag, attribute, and comment parsing issues and closing complexity-related vulnerabilities. The bundled Expat library fixed memory safety concerns, and tarfile now validates non-negative offsets to prevent crafted archive exploits.

gpg2 2.5.13: This release fixes compliance and security issues, including OCB handling with passwords, duplicate key detection, cv25519 encryption prefixes, and potential SHA1 downgrades in third-party signatures. It improves signature verification by erroring on unverified outputs, switches gpgsm encryption/decryption to the KEM interface, and fixes certificate locking glitches. Keybox handling was refined to improve locking and compression safety. Other updates include LDAP keyserver upload support, PIN change fixes, and retries for private key deletion to handle sharing violations.

Mesa 25.2.5: This update resolves rendering corruption in Age of Wonders 4 on Intel Arc GPUs, fixes a broken pipeline cache in AMD’s RADV Vulkan driver, and addresses failing tests on older Intel hardware. The release also corrects issues with occlusion queries on Qualcomm Adreno GPUs, improves handling of 3D image views in Vulkan render passes, and fixes memory leaks.

Mutter 49.1 & 49.1.1: This update improves Wayland stability, input handling, and window management. Wayland fixes include better handling of invalid or empty geometries, always sending configure events after popup repositioning, and requiring pointer interaction before allowing warps. There was a fix in the 49.1.1 version for broken menus in some Xwayland clients. Input reliability was enhanced with correct modifier state checks. Rendering and performance benefits were made and improvements were also made with frame clock scheduling. Additional fixes cover udev memory leaks, fallback cursor sizing and gesture handling crashes.

AppStream 1.1.1: This package introduces an option to disable man page creation and improves YAML handling with explicit string quoting and UTF-8 test coverage. Qt5 support has been fully dropped; the build system and spec file were cleaned accordingly.

SDL3 3.2.24: This release fixes multiple input and rendering issues, which includes fixes for crashes with Steam Controllers and webcams mistakenly detected as joysticks. Mouse capture in VMware and detached thread memory handling were corrected. Rendering gains support for up to 8-color target bindings, and letterboxing now uses clear coloring that improves consistency.

SELinux Policy 20251006: SSH policies are enhanced in this update with support for /usr/libexec/ssh, wtmpdb logging, and new default contexts, while guest and xguest domains gain better session handling. Policies now allow services like valkey-server, blueman, geoclue, apcupsd, and nfs-generator to use additional sockets or filesystem attributes. Kdump and EFI access are improved, and virt guests can conditionally read certificates in home directories.

webkit2gtk3 2.50.1: This update improves both webkit2gtk3 and webkit2gtk4. It fixes broken audio playback on Instagram, and corrects rendering issues with fractional transforms. It also resolves build problems on s390x and with video disabled, alongside multiple crash and rendering fixes. A critical security patch for CVE-2025-43343 is included, making this a recommended stability and security upgrade for both the GTK 4.1 and 6.0 backends.

WirePlumber 0.5.12:
This release introduces mono audio configuration support, automatic muting of ALSA devices when nodes are removed, a new notifications API module, and an expanded wpctl man page. It fixes shutdown race conditions in the permissions portal that prevent crashes from invalid devices during async operations, which fixes logging errors in device-info-cache, and improves device hook handling. A patch was added to suppress dispatcher errors when re-registering or removing hooks.

GStreamer 1.26.7: This update improves handling in cea608overlay. RTP handling was expanded with new linear audio payloaders/depayloaders and keepalive fixes in RTSP interleaved mode. Other fixes address Opus in MPEG-TS, memory leaks in Editing Services, improved threadshare latency, muxer EOS handling, and introspection annotations.

PipeWire 1.5.81: This is the first release candidate for the upcoming 1.6 branch; it remains API and ABI compatible with earlier 1.0.x through 1.4.x versions. The release brings a refactored link negotiation system for better default matching, improved loop locking with priority inversion handling for real-time performance and safer control stream parsing. It introduces new features such as MIDI 2.0 clip support, Bluetooth ASHA support for hearing aids, and ALSA tweaks to lower latency.

Binutils 2.45: This update introduces a new versioned libsframe.so.2, expands RISC-V and ARM architecture support, and adds new directives and predefined assembler symbols. On x86, support has been added for Intel Diamond Rapids AMX, AVX10.2, and new Zhaoxin instructions, while s390 tools now support SFrame v2 and the “z17” CPU. The release fixes multiple security issues.

Security Updates

Binutils 2.45:

• CVE-2025-1149: This fixes a memory leak when handling certain inputs.
• CVE-2025-1150: This fixes a memory leak under certain conditions that could potentially lead to resource exhaustion.
• CVE-2025-1151: A memory-handling issue may lead to leaks or instability.
• CVE-2025-1152: Another leak-type issue impacts linking behavior and potentially weakens system robustness.
• CVE-2025-1153: A crafted input could lead to memory corruption.
• CVE-2025-1176: A critical issue that under crafted conditions may lead to memory corruption or crash.
• CVE-2025-1178: A memory-safety issue may be triggered by malformed linking operations.
• CVE-2025-1179: Another memory-safety vulnerability that could possibly be exploitable under specific build/link workflows.
• CVE-2025-1180: A fix for a flaw classified as problematic that could affect linking behavior and system stability.
• CVE-2025-1181: A vulnerability may allow errant linking or crash the tool.
• CVE-2025-1182: Fixes an issue that could impact the tool chain and may have wide-ranging effects if exploited.
• CVE-2025-3198: A vulnerability classified as problematic that may lead to mis-linking or tool failure.
• CVE-2025-5244: A fix for a security flaw that could affect linking and build integrity; recommended to update.
• CVE-2025-5245: A fix for a bug affecting core linking functionality that may allow crash or unintended behavior.
• CVE-2025-7545: A fix for a problematic memory-safety issue resulting in linking failures.
• CVE-2025-7546: Another fix for a memory‐safety/leak vulnerability that could have compromised build reliability and system integrity.
• CVE-2025-8224: A fix for a vulnerability that could be exploited in build/link processes.
• CVE-2025-8225: A fix for another flaw that may lead to unstable linking or toolchain failure.
• CVE-2025-11083: A fix for a vulnerability affecting linking components that could impact system builds and integrity.
• CVE-2025-11495: A flaw related to linking logic that could cause crashes or unexpected behavior.

Unbound 1.24.0:

• CVE-2025-11411: A vulnerability that could allow an attacker to inject bogus DNS name-server records, which could trick a DNS resolver into updating delegation information and result in domain-hijacking.

java-21-openjdk 21.0.9.0:

• CVE-2025-53066: A vulnerability fix that could have allowed an unauthenticated attacker to gain unauthorized access to critical data over the network.
• CVE-2025-61748: A flaw that could have allowed an unauthenticated attacker to perform unauthorized update, insert or delete operations on accessible data via network API access.
• CVE-2025-53057: A weakness that could have allowed an unauthenticated attacker to create, delete or modify critical data remotely.

gimp:

• CVE-2025-10925: A fix for a stack-based buffer overflow where an attacker could craft a malicious image to execute code when it’s opened.
• CVE-2025-10922: A fix for a heap buffer overflow had the potential to allow remote code execution via a malicious file.
• CVE-2025-10920: A fix for an out-of-bounds write bug where specially crafted images may cause crashes or allow attackers to run arbitrary code.

curl 8.16.0:

• CVE-2025-9086: A flaw was fixed this may crash curl or allow a malicious site to override a “secure” cookie unexpectedly.
• CVE-2025-10148: A predictable pattern was fixed that could allow a malicious server to trick a proxy into treating malicious content as legitimate and pollute its cache.

Bind 9.20.15:

• CVE-2025-8677: A fix for a flaw that could potentially deny service to DNS resolvers.
• CVE-2025-40778: Attackers could inject forged DNS records into a resolver’s cache, redirecting future queries to malicious destinations.
• CVE-2025-40780: A weakness in the pseudo-random number generator allows attackers to predict the source port and query ID of DNS requests to make cache poisoning easier.

qt6-svg 6.10.0:

• CVE-2025-10728: A flaw in a graphics module that renders SVG files can cause recursive rendering leading to a stack overflow and crash.
• CVE-2025-10729: A use-after-free bug in the graphics module can lead to crashes or other memory corruption.

python-ldap 3.4.5:

• CVE-2025-61911: Passing a crafted list or dict for the assertion_value parameter when using escape_mode=1 can skip escaping special characters, which might let an attacker manipulate LDAP filters.
• CVE-2025-61912: A client can fail before sending a request to the LDAP server (client-side denial of service).

webkit2gtk3/4 2.50.1:

• CVE-2025-43343: A memory-handling flaw lets specially crafted web pages cause unexpected process crashes, potentially allowing attackers to disrupt the software or gain deeper access.

**libsoup **:

• CVE-2025-11021: A flaw could allow an attacker to craft a cookie with a specially formatted expiration date that triggers a memory read outside of the intended bounds and potentially exposes sensitive information.

libxslt:

• CVE-2025-11731: A flaw could wrongly treat a document node like an element node, which can lead to type confusion and unexpected memory reads and possible crashes (denial of service).

python311 3.11.14:

• CVE-2025-8194: A defect in the CPython tarfile module where processing specially-crafted tar archives with negative offsets can cause an infinite loop or deadlock and result in a denial of service.
• CVE-2025-6069: A vulnerability can trigger quadratic complexity and amplify a denial of service by consuming excessive CPU/time.

open-vm-tools 13.0.5:

• CVE-2025-41244: A vulnerability was fixed inside a VM that could exploit a flaw to gain root (administrator) privileges on the same VM.

Ruby 3.4.7:

• CVE-2025-61594: A vulnerability was fixed that could allow leaking of authentication details via crafted URIs.

poppler:

• CVE-2025-52885: The vulnerability can lead to dangling pointers when the vector is resized and may allow memory corruption or crashes.

ImageMagick 7.1.2.7:

• CVE-2025-62171: A flaw with BMP image decoder on 32-bit systems can trigger an integer overflow and cause a potential crash or denial of service.

** samba**:

• CVE-2025-10230: A command-injection flaw could allow an unauthenticated remote attacker to run arbitrary commands.
• CVE-2025-9640: A bug could allow a user to read leftover memory contents and potentially disclose sensitive data.

Mozilla Firefox 143.0.3, 144.0:

• CVE-2025-11152: A vulnerability allowing remote code execution via memory corruption.
• CVE-2025-11153: A miscompilation may enable attackers to execute arbitrary code.
• CVE-2025-11708: A use-after-free bug in the browser’s media subsystem that could let attackers crash the application or run code.
• CVE-2025-11709: A flaw where a webpage could trigger out-of-bounds reads or writes in a privileged process and risk data exposure or code execution.
• CVE-2025-11710: A compromised web process could use malicious inter-process messages to make the privileged browser process leak parts of its memory.
• CVE-2025-11711: A browser bug that allowed modification of JavaScript object properties, which were supposed to be non-writable.
• CVE-2025-11712: A webpage could use an OBJECT tag’s type attribute (when no content-type header was given) to override browser behavior and potentially enable XSS.
• CVE-2025-11714: A collection of memory-safety bugs that were fixed in recent browser versions because they could lead to crashes or code execution.
• CVE-2025-11715: More memory-safety fixes covering multiple components in the browser/Thunderbird stack to reduce risk of exploitation.

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

Conclusion

Tumbleweed closed October with near-daily snapshots that paired desktop polish with deep stack hardening. Plasma 6.5, KDE Gear 25.08.2 and GNOME 49.1 landed alongside kernel 6.17, Mesa 25.2.x and PipeWire 1.5.81, while developer and platform tools like PHP, curl, QEMU, GStreamer and Binutils delivered tested security fixes.

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.

Table of Contents

• 1) Introduction
• 2) Local DoS Issue via UNIX Domain Socket (CVE-2025-62875)
  • Memory Leak on Regular Connection Close
  • Workaround by Adjusting Socket Permissions
  • Reproducer
  • Affected Versions
  • Affected Systems
  • CVE Assignment
  • Upstream Bugfix
• 3) Notes on setuid and setgid Binaries
  • lockspool
  • smtpctl
• 4) Notes on the Network-Facing OpenSMTPD Code
• 5) Timeline
• 6) Links

1) Introduction

OpenSMTPD is an implementation of the server-side SMTP protocol offered by the OpenBSD project. A few months ago a SUSE colleague started packaging it for openSUSE Tumbleweed, which led to a code review of the package.

While looking into a local API offered by OpenSMTPD we discovered a trivial local Denial-of-Service (DoS) attack vector which allows unprivileged users to cause the shutdown of all smtpd services. The full details about the issue follow in section 2. Some additional remarks about setuid-root and setgid utilities contained in OpenSMTPD are found in section 3. A quick survey of the network-facing code of OpenSMTPD is provided in section 4.

Note that two source code repositories for OpenSMTPD exist. The most up-to-date code is found in the OpenBSD CVS repository, while the portable version is found on GitHub. The portable version offers cross platform support for various kinds of UNIX systems, including Linux and the other BSDs. This report is based on the portable OpenSMTPD version 7.7.0p0.

We reported the local DoS issue to upstream but did not get a response until two days before publication, due to communication issues. By now an upstream bugfix is available which will be part of a pending 7.8.0 release, but it seems an independent memory leak issue remains unaddressed.

2) Local DoS Issue via UNIX Domain Socket (CVE-2025-62875)

OpenSMTPD contains the smtpctl program, which communicates with the smtpd: control daemon instance via a UNIX domain socket in /var/run/smtpd.sock. While looking into the protocol used for this purpose, we noticed a trivial local Denial-of-Service attack vector affecting all of OpenSMTPD.

The UNIX domain socket smtpd.sock has file mode 0666 and is thus writable for all users in the system, allowing anybody to create local connections towards smtpd.

In the daemon’s code in mproc_dispatch() the process exits via fatal() in case anything goes wrong while handling such a UNIX domain socket connection. Two common error situations leading to this are bad returns from readv() in ibuf_read() or a bad message length value in the message header, which is detected in imsg_parse_hdr(). Similar error conditions exist in the msgbuf_read() call path which is used when file descriptor passing is enabled on the connection (see imsgbuf_read()).

As a result, sending a malformed message with a bad header length is enough for a client to provoke the invocation of fatal() on the daemon side. Once fatal() is called, the smtpd: control instance ends execution and causes the whole smtpd instance to be shut down along with it.

We learned from upstream that the reason for the call to fatal() is that smtpd.sock is used for two different purposes at the same time:

• connections from other, trusted smtpd daemon instances.
• connections from arbitrary other clients using the smtpctl program.

The call to fatal() is made with the first kind of connections in mind. These connections are established during startup, and if anything goes wrong while processing data from other smtpd daemon instances, then a bug in OpenSMTPD itself is assumed, and a shutdown of all daemon processes is a viable course of action.

The second kind of connections was left unconsidered in this logic, thus allowing unprivileged clients to trigger this code path which leads to the local DoS. The upstream bugfix consequently consists of an added if clause which excludes the second type of connections from the call to fatal().

Memory Leak on Regular Connection Close

While looking into a possible bugfix for the DoS issue, we noticed a comment in the code, which points to unsolved cleanup issues, when processing a connection fails:

ibuf_read_process(struct msgbuf *msgbuf, int fd)
{
    /* <<< SNIP >>> */
fail:
    /* XXX how to properly clean up is unclear */
    if (fd != -1)
        close(fd);
    return (-1);
}

This made us wonder, if the cleanup is unclear in error conditions, is it maybe also unclear during regular operation? After all, proper cleanup will be needed regardless of whether a connection ends gracefully or not. As it happens, the cleanup logic for a regular connection close and for an erroneous connection close indeed is equivalent in OpenSMTPD.

To this end, we tested what happens when a lot of UNIX domain socket connections towards smtpd are created and closed in succession. The outcome indeed is that the memory used by the smtpd: control instance continuously grows. Thus it seems there is a memory leak present here as well independently of the main issue described above. We did not analyze this in more detail, but upstream is aware of the issue and is analyzing it on their end.

This independent issue means that unprivileged clients can trigger the memory leak in the smtpd: control daemon, even after applying the upstream bugfix to fix the main issue in this report. The impact will also be a local DoS, it will take a much longer time to execute it, however, because the memory leak is small and in our tests only consumes about 100 megabytes within half an hour. The next section describes a possible temporary workaround to avoid this issue, as well.

Workaround by Adjusting Socket Permissions

We initially suggested a different patch to address the local DoS issue, tightening the permissions of the smtpd.sock UNIX domain socket. We wrongly assumed that there were no valid use cases for non-root users connecting to this socket. Shortly before publication we learned from upstream that there actually is a valid use case for this scenario: non-root users can enqueue mail using the sendmail interface, which makes use of this socket.

Even though our suggested patch causes a regression in this case, it reduces attack surface and provides protection against the memory leak described in the previous section. For some users of OpenSMTPD it can thus be a sensible option to use this patch if the described use case is not needed, at least until upstream provides a fix for the memory leak issue, as well.

Reproducer

We offer a simple Python script to reproduce the issue. The script creates a connection towards smtpd.sock and sends an excessive header length. If the reproducer works, the smtpd daemon processes will all exit immediately.

Affected Versions

In commit 3270e23a6eb, which first made its way into version 7.7.0, major changes to the message parsing code have been introduced, including the call to fatal(). Triggering the issue was easily possible in our tests for all packages based on this version.

It is unclear if older versions might be affected by some variant of this issue as well. We only verified that the trivial reproducer does not work against version 7.6.0 of OpenSMTPD.

Affected Systems

We verified that the issue affects the following systems, which all offer OpenSMTPD version 7.7.0:

• Arch Linux (fully updated on 2025-09-29)
• Debian 13
• Fedora 42
• Gentoo Linux using the 7.7.0p0 ebuild
• OpenBSD 7.7
• NetBSD 10.1 (using the package available from pkgsrc)

On FreeBSD 14.2, where only the older version 7.6.0 of OpenSMTPD is available, we could not reproduce the issue.

CVE Assignment

Without a formal confirmation from upstream we were reluctant to assign a CVE for the issue. The case seemed clear-cut, however, and when we were asked to provide a CVE on the distros mailing list, we assigned CVE-2025-62875 and also communicated this to upstream.

When contact to upstream was established shortly before the publication of this report, upstream picked up this CVE and used it to document their bugfix.

Upstream Bugfix

Upstream already published the bugfix commit for the main issue in this report. The release of OpenSMTPD version 7.8.0 containing this bugfix is expected soon, and was already announced on the upstream mailing list.

3) Notes on setuid and setgid Binaries

The original reason for reviewing OpenSMTPD in the first place was the presence of setuid and setgid binaries in the package. The following sub-sections give a short summary of the outcome of the review.

lockspool

/usr/libexec/opensmtpd/lockspool is a world-accessible setuid-root binary which is used to synchronize parallel access to a user’s spool.

The lockspool code found in the OpenSMTPD portable release is quite complex and is based on some assumptions that might not hold true. This code can allow for a minor local DoS in multi-user scenarios. The OpenBSD CVS repository already contains a simplified locking algorithm which is not affected by this.

We reached out to upstream about this separately from the UNIX domain socket DoS issue. In this instance we quickly got a reply and upstream merged the change from the CVS repository into the OpenBSD portable repository. This change will be part of the OpenSMTPD 7.8.0 release. We backported the change into the openSUSE packaging of OpenSMTPD as well.

smtpctl

/usr/sbin/smtpctl is a world-accessible setgid binary operating in _smtpq group context. The program uses these special group privileges to store mail in the directory
/var/spool/smtpd/offline, when the smtpd services are not running.

The _smtpq group privileges are only used for this well defined purpose and the extra privileges are also dropped as soon as they are no longer needed. We found no issues in this aspect of the program.

4) Notes on the Network-Facing OpenSMTPD Code

After we found the local security issues described in this report, we thought it a good idea to also have at least a cursory look at the actual network-facing SMTP protocol parsing code found in OpenSMTPD. We could not find any tangible security issues in these parts, still here is a short summary of our impression of the code:

• the protocol parsing is implemented in plain C and thus error prone. The implementation does have this under control, however, even though there is some redundancy in handling the various message types.
• a lot of parsing is done manually without the help of third party libraries, including things like domain name end email address verification.
• transmission of plaintext passwords is rejected on unencrypted connections, which is a good security stance.
• the daemon processing network data is running with limited service user credentials and is also placed into a chroot jail, which reduces attack surface.
• the daemon logs every bad SMTP protocol message by default, including attacker controlled data, which is a bit peculiar. The logging systems on the BSDs and Linux systems we looked into are able to deal with this in safe ways, however (e.g. terminal escape sequences are escaped or stripped).

5) Timeline

6) Links

• OpenSMTPD website
• OpenSMTPD portable Git repository
• Suggested patch to work around the issue (includes a possible regression!)
• Upstream bugfix of the issue (leaves a memory leak issue unaddressed)
• Python script to reproduce the issue
• openSUSE Bugzilla review bug for OpenSMTPD