Bug in Kernel 6.13 crashing Flatpak and FUSE apps

Ask Fedora Common Issues Proposed Common Issues
, , , ,
1

Kernel 6.13 introduced a very bad bug that causes “bad page states” when opening some flatpak apps.

Symptoms can be

uname -r shows if you use kernel 6.13

Upstream bug

Upstream bug fix

Solved?

The bug was supposedly fixed upstream and the kernel package upgraded.

We need to wait for the upgrades to arrive everywhere, and atomic images to be built.

Just upgrade your system normally and you will get a fixed kernel.

If you need faster fixes:

Atomic Desktops

run0

#backup
ostree admin pin 0
exit

#replace kernel with fixed one
rpm-ostree override replace https://bodhi.fedoraproject.org/updates/FEDORA-2025-232314eb1d

When the update has arrived in the repo and images, reset the override again:

rpm-ostree override reset kernel-tools-libs kernel kernel-modules-extra python3-perf kernel-modules-core kernel-core kernel-modules kernel-tools

DNF Fedora

TODO

Prevent updates

If the update does not fix your issue, you may want to use an older kernel until it is.

Note that poorly there are many vulnerabilities in every kernel version, so this is not a good longterm solution.

dnf Fedora

Use this command to prevent updates of the kernel

sudo dnf versionlock add kernel-6.12.15-200.fc41.x86_64

(On ARM or other architectures, replace the last part.)

Only do this temporary! Remember to remove that lock again

sudo dnf versionlock delete kernel-6.12.15-200.fc41.x86_64

Atomic Desktops

If version 41.20250224.0 is still shown, use `rpm-ostree rollback

# check if that version is still there
rpm-ostree status | grep 41.20250224.0

# check how many pinned deployments exist
rpm-ostee status

# save that known good version
# use 0 for current, 1 for previous, 2 for the 3rd shown entry, etc.
sudo ostree admin pin 1

# rollback to that version
rpm-ostree rollback

reboot

If that version is not shown anymore, you need to download it again

# download that version
rpm-ostree deploy 41.20250224.0

# this removes all layered packages, so you might want to add them now
rpm-ostree install a b c

# save that version
sudo ostree admin pin 0

reboot
7 Likes
3

@boredsquirrel, perhaps move to Common Issues > Proposed Common Issues (instead of Ask Fedora)?

1 Like
5

Yeah, that’d be nice.

It’s odd, I’ve been running Silverblue on 6.13/6.14 for weeks (so all my apps are flatpaks) and have never seen this. I wonder if there’s some specific environmental trigger needed? I would’ve expected to have seen this at least once…

6

It’s the same here, I’ve been using 6.13 since 6.13.0, going though each version, but it only hit me on Tuesday this week

7

I ran GNOME Papers as I thought this was an Okular error, it worked without issues. Uses poppler in the background I think.

Then had a crash in Gwenview (thought it was a KDE issue), then in Celluloid, then knew it was a kernel thing.

This bug will happen in some specific cases. Papers for example doesn’t isolate processes afaik, that is why they dont support tabs.

8

Versionlock seems like a rather bad idea overall. There are CVE fixes in almost every kernel.

In the meantime, please try https://bodhi.fedoraproject.org/updates/FEDORA-2025-232314eb1d and the corresponding F40 updates. I pulled back a fix.

7 Likes
9

Thanks a lot, flatpak/fuse issue is fixed in F41 kernel.

10

Thanks, when will this be in the repos approximately?

Or if it already is I guess the atomic desktop users just need to wait another day.

1 Like
11

For Fedora Atomic Desktops 41, you can try the fixed kernel-6.13.5-200.fc41 with sudo rpm-ostree override replace https://bodhi.fedoraproject.org/updates/FEDORA-2025-232314eb1d.

Don’t forget to sudo rpm-ostree override reset kernel-tools-libs kernel kernel-modules-extra python3-perf kernel-modules-core kernel-core kernel-modules kernel-tools when the update is pushed to stable and available in the repos.

1 Like
12

I am using 6.13.5-200.fc41.x86_64 and Okular is still filling up with RAM…

Opening the same 11MB PDF, it filled up until 5GB then I killed it

Gwenview does not use more than 300MB, which is not good but I guess fine.

13

@boredsquirrel, you’re using dl.flathub.org/repo/appstream/org.kde.okular.flatpakref, right? Not okular-24.12.2-1.fc41.x86_64.rpm?

14

yes, all flatpaks from flathub

Libreoffice, GNOME papers, GIMP, Cosmic player work… so I guess I just dont use these apps

15

@boredsquirrel, can you not choose another kernel, via GRUB2? I’m running 6.12.15:

  1. #!/usr/bin/env sh
uname -r

  2. 6.12.15-200.fc41.x86_64

…despite having the undermentioned installed:

  1. #!/usr/bin/env sh
rpm -qa kernel

  2. kernel-6.12.13-200.fc41.x86_64
kernel-6.12.15-200.fc41.x86_64
kernel-6.13.4-200.fc41.x86_64
1 Like
16

I can, have a backup, I just live with it currently XD

btw atomic desktops don’t guarantee to have a backup kernel version, which is pretty bad

17

@boredsquirrel, yeah, that’s dreadful, especially since nobody’s using rpm-ostree to install all their software (unless they want a corrupt image).

I don’t know what kinds of modifications having the “immutable” layer prevents, but superuser.com/revisions/1423560/1 might work:

Edit the file /etc/dnf/dnf.conf, changing the numeric value in installonly_limit=3 to a number of your choosing.

Be aware that if you increase the number too high then you run the risk of filling up the /boot partition.

18

Why is that bad? It’s always possible to downgrade to a previous kernel by running a rpm-ostree replace override $BODHI_URL, adding custom logic for the kernel only seems to complicate the system and process.

And the kernel in the previous deployment should be able to stage updates, because it already did it successfully once.

2 Likes
19

@job79, there should always be at least 2 kernels:

Examples

  2. unix.stackexchange.com/revisions/178881/4

20

For non-atomic Fedora, sure, we agree. You always want to be sure there is at least 1 kernel that boots (and can do updates and rollbacks).

But for atomic Fedora there is always a kernel that does that in the previous deployment. If the kernel can’t boot, it can’t stage a next deployment.

1 Like
21

Atomic desktops use an entire different package and OS manager. The dnf config will not do anything here

1 Like