Table of Contents

• 1) Introduction
• 2) Overview of the Unauthenticated scx_loader D-Bus Service
• 3) Passing Arbitrary Parameters to Schedulers
  • The --pin-root-path Option
  • The --kconfig Option
  • The --btf-custom-path Option
  • The --bpf-token-path Option
• 4) On the Verge of a Local Root Exploit
• 5) Affected Linux Distributions
• 6) Suggested Fixes
  • Restrict Access to a Group on D-Bus Level
  • Use Polkit for Authentication
  • Making the API more Robust
  • Use systemd Sandboxing
• 7) Missing Upstream Bugfix
• 8) CVE Assignment
• 9) Timeline
• 10) Links

1) Introduction

The scx project offers a range of dynamically loadable custom schedulers implemented in Rust and C, which make use of the Linux kernel’s sched_ext feature. An optional D-Bus service called scx_loader provides an interface accessible to all users in the system, which allows to load and configure the schedulers provided by scx. This D-Bus service is present in scx up to version v1.0.17. As a response to this report, scx_loader has been moved into a dedicated repository.

A SUSE colleague packaged scx for addition to openSUSE Tumbleweed, and the D-Bus service it contained required a review by our team. The review showed that the D-Bus service runs with full root privileges and is missing an authentication layer, thus allowing any user to nearly arbitrarily change the scheduling properties of the system, leading to Denial-of-Service and other attack vectors.

Upstream declined coordinated disclosure for this report and asked us to handle it in the open right away. In the discussion that followed, upstream rejected parts of our report and presented no clear path forward to fix the issues, which is why there is no bugfix available at the moment.

Section 2 provides an overview of the scx_loader D-Bus service and its lack of authentication. Section 3 takes a look into problematic command line parameters which can be influenced by unprivileged clients. Section 4 looks into attempts to achieve a local root exploit using the scx_loader API. Section 5 lists affected Linux distributions. Section 6 discusses possible approaches to fix the issues found in this report. Section 7 takes a look at the upstream efforts to fix the issues.

This report is based on version 1.0.16 of scx.

2) Overview of the Unauthenticated scx_loader D-Bus Service

The scx_loader D-Bus service is implemented in Rust and offers a completely unauthenticated D-Bus interface on the system bus. The upstream repository contains configuration files and documentation advertising this service as suitable to be automatically started via D-Bus requests. Thus arbitrary users in the system (including low privilege service users or even nobody) are allowed to make unrestricted use of the service.

The service’s interface offers functions to start, stop or switch between a number of scx schedulers. The start and switch methods also offer to specify an arbitrary list of parameters which will be directly passed to the binary implementing the scheduler.

Every scheduler is implemented in a dedicated binary and found e.g. in /usr/bin/scx_bpfland for the bpfland scheduler. Not all schedulers that are part of scx are accessible via this interface. The list of schedulers supported by scx_loader in the reviewed version is:

scx_bpfland scx_cosmos scx_flash scx_lavd
scx_p2dq scx_tickless scx_rustland scx_rusty

We believe the ability to more or less arbitrarily tune the scheduling behaviour of the system already poses a local Denial-of-Service (DoS) attack vector that might even make it possible to lock up the complete system. We did not look into a concrete set of parameters that might achieve that, but it seems likely, given the range of schedulers and their parameters made available via the D-Bus interface.

3) Passing Arbitrary Parameters to Schedulers

The ability to pass arbitrary command line parameters to any of the supported scheduler binaries increases the attack surface of the D-Bus interface considerably. This makes a couple of concrete attacks possible, especially when the scheduler in question accepts file paths as input. Apart from parameters that influence scheduler behaviour, all schedulers offer the generic “Libbpf Options”, of which the following four options stick out in this context:

--pin-root-path <PIN_ROOT_PATH>      Maps that set the 'pinning' attribute in their definition will have
                                     their pin_path attribute set to a file in this directory, and be
                                     auto-pinned to that path on load; defaults to "/sys/fs/bpf"
--kconfig <KCONFIG>                  Additional kernel config content that augments and overrides system
                                     Kconfig for CONFIG_xxx externs
--btf-custom-path <BTF_CUSTOM_PATH>  Path to the custom BTF to be used for BPF CO-RE relocations. This custom
                                     BTF completely replaces the use of vmlinux BTF for the purpose of CO-RE
                                     relocations. NOTE: any other BPF feature (e.g., fentry/fexit programs,
                                     struct_ops, etc) will need actual kernel BTF at /sys/kernel/btf/vmlinux
--bpf-token-path <BPF_TOKEN_PATH>    Path to BPF FS mount point to derive BPF token from. Created BPF token
                                     will be used for all bpf() syscall operations that accept BPF token
                                     (e.g., map creation, BTF and program loads, etc) automatically within
                                     instantiated BPF object. If bpf_token_path is not specified, libbpf will
                                     consult LIBBPF_BPF_TOKEN_PATH environment variable. If set, it will be
                                     taken as a value of bpf_token_path option and will force libbpf to
                                     either create BPF token from provided custom BPF FS path, or will
                                     disable implicit BPF token creation, if envvar value is an empty string.
                                     bpf_token_path overrides LIBBPF_BPF_TOKEN_PATH, if both are set at the
                                     same time. Setting bpf_token_path option to empty string disables
                                     libbpf's automatic attempt to create BPF token from default BPF FS mount
                                     point (/sys/fs/bpf), in case this default behavior is undesirable

libbpf is a userspace support library for BPF programs found in the Linux source tree. The following sub-sections take a look at each of the attacker-controlled paths passed to this library in detail.

The --pin-root-path Option

The --pin-root-path option potentially causes libbpf to create the parent directory of this path in bfp_object__pin_programs(). We are not entirely sure under which conditions the logic is triggered, however, and if these conditions are controlled by an unprivileged caller in the context of the scx_loader D-Bus API.

The --kconfig Option

The file found in the --kconfig path is completely read into memory in libbpf_clap_opts.rs line 91. This makes a number of attack vectors possible:

• pointing to a device file like /dev/zero leads to an out of memory situation in the selected scheduler binary.
• pointing to a private file like /etc/shadow causes the scheduler binary to read in the private data. We did not find a way for this data to leak out into the context of an unprivileged D-Bus caller, however. This technique still allows to perform file existence tests in locations that are normally not accessible to unprivileged users.
• pointing to a FIFO named pipe will block the scheduler binary indefinitely, breaking the D-Bus service. Also, by feeding data to such a PIPE, nearly all memory can be used up, keeping the system in a low-memory situation and possibly leading to the kernel’s OOM killer targeting unrelated processes.
• by pointing to a regular file controlled by the caller, crafted KConfig information can be passed into libbpf. The impact of this appears to be minimal, however.

The following command line is an example reproducer which will cause the scx_bpfland process to consume all system memory until it is killed by the kernel:

user$ gdbus call -y -d org.scx.Loader -o /org/scx/Loader \
    -m org.scx.Loader.SwitchSchedulerWithArgs scx_bpfland \
    '["--kconfig", "/dev/zero"]'

The --btf-custom-path Option

The --btf-custom-path option offers similar attack vectors as the --kconfig option discussed above. Additionally, crafted binary symbol information can be fed to the scheduler via this path, which will be processed either by btf_parse_raw() or btf_parse_elf() found in libbpf. This can lead to integrity violation of the scheduler / the kernel, the impact of which we cannot fully judge as we lack expertise in this low level area and did not want to invest more time than necessary for the analysis.

The --bpf-token-path Option

The --bpf-token-path, if it refers to a directory, will be opened by libbpf and the file descriptor will be passed to the bpf system call like this:

bpf(BPF_TOKEN_CREATE, {token_create={flags=0, bpffs_fd=20}}, 8) = -1 EINVAL (Invalid argument)

This does not seem to achieve anything, however, because the kernel code rejects the caller if it lives in the initial user namespace (which the privileged D-Bus service always does). The path could maybe serve as an information leak to test file existence and type, if the behaviour of the scheduler “start” operation shows observable differences depending on the input.

4) On the Verge of a Local Root Exploit

With this much control over the command line parameters of many different scheduler binaries, which offer a wide range of options, we initially assumed that a full local root exploit would not be difficult to achieve. We tried hard, however, and did not find any working attack vector so far. It could be that we overlooked something in the area of the low level BPF handling regarding the attacker-controlled input files discussed in the previous section, however.

scx_loader is saved from a trivial local root exploit merely by the fact that only a subset of the available scx scheduler binaries is accessible via its interface. The scx_chaos scheduler, which is not among the schedulers offered by the D-Bus service, supports a positional command line argument referring to a “Program to run under the chaos scheduler”. Would this scheduler be accessible via D-Bus, then unprivileged users could cause user controlled programs to be executed with full root privileges, leading to arbitrary code execution.

From discussions with upstream it sounds like the exclusion of schedulers like scx_chaos from the D-Bus interface does not stem from security concerns, but rather from functional restrictions, because some schedulers are not supported in all contexts, or are not stable yet.

5) Affected Linux Distributions

From our investigations and communication with upstream it seems that only Arch Linux is affected by the problem in its default installation of scx. Gentoo Linux comes with an ebuild for scx, but for some reason there is no integration of scx_loader into the init system and also the D-Bus autostart configuration file is missing. Thus it will only be affected if an admin manually invokes the service.

Otherwise we did not find a packaging of scx_loader on current Fedora Linux, Ubuntu LTS or Debian Linux. Due to the outcome of this review we never allowed the D-Bus service into openSUSE, which is therefore also not affected.

6) Suggested Fixes

Restrict Access to a Group on D-Bus Level

A quick fix for the worst aspects of the issue would be to restrict the D-Bus configuration in org.scx.Loader.conf to allow access to the interface only for members of a dedicated group like scx. This at least prevents random unprivileged users from abusing the API.

We offer a patch for download which does exactly this.

Use Polkit for Authentication

By integrating Polkit authentication, the use of this interface can be restricted to physically present interactive users. Even in this case we suggest to restrict full API access to users that can authenticate as admin, via Polkit’s auth_admin_keep setting. Read-only operations can still be allowed without authentication.

Making the API more Robust

The individual methods offered by the scx.Loader D-Bus service should not allow to perform actions beyond the intended scope, even if a caller would have authenticated in some form as outlined in the previous sections.

To this end, dangerous parameters for schedulers should either be rejected (e.g. by enforcing a whitelist of allowed parameters) or verified (e.g. by determining whether a provided path is only under control of root and similar checks).

Regarding input files, the client ideally should not pass path names at all, but send file descriptors instead, to avoid unexpected surprises and the burden of verifying input paths in the privileged D-Bus service.

Use systemd Sandboxing

The systemd service for scx_loader could make use of various hardening options that systemd offers (like ProtectSystem=full), as long as these do not interfere with the functionality of the service. This would prevent more dangerous attack vectors from succeeding if the first line of defense fails.

7) Missing Upstream Bugfix

Upstream showed a reluctant reaction to the report we provided in a GitHub issue, rejecting parts of our assessment. An attempt to introduce a Polkit authentication layer based on AI-generated code was abandoned quickly, and upstream instead split off the scx_loader service into a new repository to separate it from the scx core project. Our original GitHub issue has been closed, and we cloned it in the new repository to keep track of the issue.

Downstream integrators of scx_loader can can limit access to the D-Bus service to members of an scx group by applying the patch we offer in the Suggested Fixes section. This way access to the problematic API becomes opt-in, and is restricted to more privileged users that actually intend to use this service.

8) CVE Assignment

We suggested to upstream to assign at least one cumulative CVE to generally cover the unauthenticated D-Bus interface aspect leading to local DoS, potential information disclosure and integrity violation. We offered to assign a CVE from the SUSE pool to simplify the process.

Upstream did not respond to this and did not clearly confirm the issues we raised, but rather rejected certain elements of our report. For this reason there is currently no CVE assignment available.

9) Timeline

10) Links

• scx GitHub repository
• scx GitHub issue for this report
• newly created scx_loader GitHub repository
• cloned GitHub issue in the new scx_loader repository
• openSUSE Bugzilla review bug
• suggested patch to restrict access to the D-Bus service

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.