Just a quick question about xz and xz-libs


Right after Fedora 40 beta was released, I upgraded my F39 using the method in this doc.

Having fedora-testing repo enabled, I got the compromised version of xz and xz-libs.

I have already read Urgent security alert for Fedora Linux 40 and Fedora Rawhide users and reverted these packages to their safe version by executing:

sudo dnf upgrade --refresh --advisory=FEDORA-2024-d02c7bb266

So now I have:

Installed Packages
Name         : xz
Epoch        : 1
Version      : 5.4.6
Release      : 3.fc40

Name         : xz-libs
Epoch        : 1
Version      : 5.4.6
Release      : 3.fc40

I just wanted to make sure that it is all I needed to do and to know if my system is secure now?

Do you think I have to reinstall the system to be sure that everything is fine?

Removed f39

As I understand it.

That is the version of xz that does not have the exploit code in it.

If your system was exposed to the internet directly you may have been compromised.
If you system was not then you should be okay.

You might try a sudo dnf remove xz openssh and see what it wants to takedown along with it. Better have no ssh than a compromised one.

And a

systemctl disable --now sshd
systemctl mask sshd

Should also be helpful, as it looks like it focuses on remote shell access via ssh.

Thanks for the reply @barryascott!

I have never used ssh to remote into this system. As a matter of fact sshd was never enabled on this system so hopefully things should be ok.

Thanks for the suggestions @boredsquirrel!

I did already tried to remove openssh but it is a dependency of gnome-shell.

$ sudo dnf remove openssh 
 Problem: The operation would result in removing the following protected packages: gnome-shell
(try to add '--skip-broken' to skip uninstallable packages)

Also xz seems to be used by things like dracut so I don’t think removing it is an option.

$ sudo dnf remove xz
Dependencies resolved.
 Package                             Architecture          Version                        Repository              Size
 xz                                  x86_64                1:5.4.6-3.fc40                 @fedora                2.0 M
Removing dependent packages:
 dracut                              x86_64                059-22.fc40                    @fedora                1.3 M
 dracut-config-rescue                x86_64                059-22.fc40                    @fedora                3.7 k
 dracut-live                         x86_64                059-22.fc40                    @fedora                 38 k
 dracut-network                      x86_64                059-22.fc40                    @fedora                155 k
 dracut-squash                       x86_64                059-22.fc40                    @fedora                3.0 k
 kexec-tools                         x86_64                2.0.28-4.fc40                  @fedora                1.2 M
Removing unused dependencies:
 kpartx                              x86_64                0.9.7-7.fc40                   @fedora                 81 k
 libkcapi                            x86_64                1.4.0-10.fc40                  @fedora                 99 k
 libkcapi-hmaccalc                   x86_64                1.4.0-10.fc40                  @fedora                 37 k
 memstrack                           x86_64                0.2.5-4.fc40                   @fedora                120 k
 pigz                                x86_64                2.8-4.fc40                     @fedora                159 k
 squashfs-tools                      x86_64                4.6.1-4.fc40                   @fedora                650 k
 tpm2-tools                          x86_64                5.6-2.fc40                     @fedora                1.5 M
 tpm2-tss-fapi                       x86_64                4.0.1-7.fc40                   @fedora                826 k

Transaction Summary
Remove  15 Packages

Freed space: 8.1 M
Is this ok [Y/n]: n
Operation aborted.

As I said above, sshd was never enabled on this system and now I have also masked both sshd.service and sshd.socket. I hope that things are fine now.

1 Like

How… can a f***ing DE depend on an ssh server. How?

package-maintainers it would be great to make this a soft dependency :smiley:

Yeah you dont really know. I dont know if this was only meant for targeted attacks, or if threat actors would have gotten pinged from your machine. If the former is the case, then I think there is no problem.

On an atomic variant you should reset your distro and create a new user account, hoping it doesnt get infected. Also cleaning up /var and /etc is needed, or verifying with a hashsum.

silverblue-team kinoite-team it would be good to have an automatically created hash of the mutable system directories, and a way to reset them

By default sshd is not enabled. In which case its was enabled deliberately by the user and we should assume Required.

I have not tried, but I assume that xz is a dependency of systemd so removing it will not be allowed.

1 Like

Since the investigation into the capabilities of the malicious payload is still ongoing, it is best not to draw any conclusions.

The worst case is that the malware has means for arbitrary code execution with escalated privileges, so a complete system re-installation is the only effective option to ensure the threat is eliminated.

Preliminary reverse engineering results confirm remote code execution:


Not only that, but all kernel modules are XZ compressed.

Also, the latest sources of systemd has removed the hard dependency on xz-libs.

commit 3fc72d54132151c131301fc7954e0b44cdd3c860
Author: Matteo Croce <teknoraver@meta.com>
Date:   Tue Feb 27 21:28:14 2024 +0100

    dynamically load compression libraries

    Dynamically load liblz4, libzstd and liblzma with dlopen().
    This helps to reduce the size of the initrd image when these libraries
    are not really needed.

Excuse my Ignorance (I’m pretty new to Fedora) but has this always been the case and for all .iso s both pre-release and stable?

I have an installation of F40 dated March 24.
I believe it was an Everything iso install , but I never explicitly enabled sshd as I had no reason to.

I was lucky to not have been affected by the problematic versions, but I was surprised by your comment as I had to manually act by disabling sshd myself while awaiting the recommended actions of the community.

root@fedora:~# systemctl status sshd.service
○ sshd.service - OpenSSH server daemon
     Loaded: loaded (/usr/lib/systemd/system/sshd.service; disabled; preset: enabled)

Notice preset: enabled

root@fedora:~# journalctl --unit=sshd.service | grep "Started" | cut -d ' ' -f1-2 | uniq
Mar 24
Mar 25
Mar 26
Mar 27
Mar 28
Mar 29

The service has only not been started for the last couple of days, since I disabled it myself.

1 Like

How odd I always need to enable it on new installs.
I use fedora server and fedora plasma spin.

I believe the everything iso (AKA netinst) (and maybe the server version) may enable sshd by default where the main desktop versions (workstation, kde, etc.) do not.


That would explain my observation.
Thank you for the insight!

I’m slowly reading through the kickstart reference docs so I hopefully won’t have surprising defaults in my future installs.

service presents get picked here:


I think this should be disabled for “everything”. Are there any dealbreakers for that?

Probably like most that provide remote desktop capabilities, which is what all of them?

Even if your system isn’t directly connected to the internet, if your system may have been exposed to other directly connected systems (e.g., university campus network) it could be compromised.

There is a detect.sh script in the original post on openwall.com.

It depends on which spin you install, and when you use the network install, it depends on which group you select to install. It is all up to whoever puts the group configurations together. In the end it is up to the end user to determine which service should be enable and which shouldn’t. The default is just a suggestion.

1 Like