Community Update - Week 19 2026 – Fedora Community Blog

This is a report created by CLE Team, which is a team containing community members working in various Fedora groups for example Infrastructure, Release Engineering, Quality etc. This team is also moving forward some initiatives inside Fedora project.

Week: 4 – 8 May 2026

Fedora Infrastructure

This team is taking care of day to day business regarding Fedora Infrastructure.
It’s responsible for services running in Fedora infrastructure.
Ticket tracker

OpenShift Allowing Project Creating Despite Missing Relevant Permissions
mirrormanager app no longer builds
Monitoring of Varnish in Zabbix
Decomission Ipsilon OpenID instance
Copyfail: updated and rebooted key Fedora hosts, applied kernel team recommended mitigation on key EL 9 hosts

CentOS Infra including CentOS CI

This team is taking care of day to day business regarding CentOS Infrastructure and CentOS Stream Infrastructure.
It’s responsible for services running in CentOS Infrastructure and CentOS Stream.
CentOS ticket tracker
CentOS Stream ticket tracker

Release Engineering

This team is taking care of day to day business regarding Fedora releases.
It’s responsible for releases, retirement process of packages and package builds.
Ticket tracker

Post-release cleanup.

RISC-V

This is the summary of the work done regarding the RISC-V architecture in Fedora.

OpenJDK CVE updates Wrote up initial analysis. Created an F44 branch with three small RISC-V patches on the secondary dist-git. Kicked off a boot JDK build.
Flock prep: Started writing up notes about the updates for our talk on RISC-V. If logistics work out, we may bring a board or two for a demo.
Explore shipping some upcoming RVA23 hardware (“SpacemiT K3”) for JasonM and DavidA for Koji builders. Figure out approximate costs for it.
Continued with LLVM’s ‘libomp’ test failures investigation; it’s a slow grind.
Caught up with Adam Williamson’s nice talk on lessons from root cause analysis.

AI

This is the summary of the work done regarding AI in Fedora.

The prototype AI Developer Desktop has been rebased to Fedora 44, and the associated Remix kernel with NVIDIA OpenRM has been rebased to 6.18.

QE

This team is taking care of quality of Fedora. Maintaining CI, organizing test days
and keeping an eye on overall quality of Fedora releases.

Fedora QE Pagure -> Forge migration is now fully complete. The new version of Blockerbugs (that uses Forge instead of Pagure for blocker discussion tickets) is now deployed to production.
Caught an issue with kernel module signing in ELN
Ongoing openQA test development work
Kernel test week testing
Starting work on reviving the contribution statistics scripts and communications
Some communications around copyfail, reassuring folks that it was addressed day 0 in Fedora

Forgejo

This team is working on introduction of https://forge.fedoraproject.org to Fedora
and migration of repositories from pagure.io.

Runnerhost zabbix agent updated with encryption
Forge v15 running on staging instance
Privileged and unprivileged aarch64 runners tested on staging, requested larger VM
Runnerhost VM’s kernel version updated to 6.19.14 to counter the CVE
Handful of new orgs added

EPEL

This team is working on keeping Epel running and helping package things.

prep work for EPEL presentations and booth work at Summit
routine packaging and documentation work

UX

This team is working on improving User experience. Providing artwork, user experience,
usability, and general design services to the Fedora project

Finished Bootc Sealed Images logo [ticket]
Flock t-shirt design finalised and handed over
Had our first Backlog Refinement call ahead of our next sprint 🙂

If you have any questions or feedback, please respond to this report or contact us on #admin:fedoraproject.org channel on matrix.

Do not use this if you don’t know what you are doing! Never copy paste code from the internet or AI without checking what it does!

AI spat out this procedure:

create a file at /etc/modprobe.d/ telling modprobe to not load the affected kernel modules on startup:

sudo tee /etc/modprobe.d/dirty_frag_mitigation.conf > /dev/null <<'EOF' blacklist esp4 blacklist esp6 blacklist rxrpc EOF

regenerate initramfs:

sudo dracut --force --kver "$(uname -r)"

reboot for changes to take effect:

sudo reboot now

To reenable the modules after an eventual patch, just delete the file blacklisting them and repeat steps 2 & 3:

sudo rm /etc/modprobe.d/dirty_frag_mitigation.conf

Comments

theprogram says:

I just noticed we don’t have a Fedora Council section in the weekly update here.

Could we include that in future?
chaordic says:
@tyleodev just adding info for anyone searching for this:
The affected kernel modules are esp4, esp6 and rxrpc. There is an Alma Linux Kernel available FOR TESTING. ~~I suppose disabling the modules works via grubby, similar to copyfail. If somebody with more experience in using grubby could paste the command here that would be great. Thanks!~~

EDIT:
Disabling these modules probably breaks IPsec processing in the kernel, preventing you from using IPsec VPN tunnels! RxRCP and AFS will also break (IDK what those protocols are, seems to be obscure remote FS stuff).

EDIT:
im leaving this procedure for people who know they are not relying on the affected modules (you can check if they are loaded on your machine using lsmod | egrep 'esp4|esp6|rxrpc'):

EDIT:
If the modules are not loaded / used on your system, an attacker would need root to enable them before using the exploit. If you want to disable the modules, use the procedure below (at your own risk!).

First of all:

Do not use this if you don’t know what you are doing! Never copy paste code from the internet or AI without checking what it does!

AI spat out this procedure:
1. create a file at /etc/modprobe.d/ telling modprobe to not load the affected kernel modules on startup:
```
sudo tee /etc/modprobe.d/dirty_frag_mitigation.conf > /dev/null <<'EOF'
blacklist esp4
blacklist esp6
blacklist rxrpc
EOF
```
1. regenerate initramfs:
```
sudo dracut --force --kver "$(uname -r)"
```
1. reboot for changes to take effect:
```
sudo reboot now
```
To reenable the modules after an eventual patch, just delete the file blacklisting them and repeat steps 2 & 3:
```
sudo rm /etc/modprobe.d/dirty_frag_mitigation.conf
```
pg-tips says:

MatH:

I just noticed we don’t have a Fedora Council section in the weekly update here.

I believe these weekly update posts are specific to the Community Linux Engineering team.

It might be better to retitle them “Community Linux Engineering Update” to avoid people reading them under the impression that they’ll see news relating to the Fedora Community as a whole. Certainly I had that misconception when I first saw them.
barryascott says:

Tyleo Dev:

Hi, any information about Dirty Frag vulnerability ?

I guess you missed this post from the kernel maintainers.
FYI Searching for “Dirtfrag” works but “dirty frag” does not.

All fixed: Update to fix DirtyFrag available
zlopez says:

As most of the people don’t know what Community Linux Engineering team is, we decided to name it Community update, but this is made clear in the first paragraph. I can recommend looking at this report made by @abompard Making sure you're not a bot!
pg-tips says:

Michal KoneÄný:

I can recommend looking at this report made by @abompard Making sure you’re not a bot!

Thanks, that’s a great resource! It would be great for it to be cross-posted to Discourse! (or at least post a quick summary and a link).
theprogram says:

Michal KoneÄný:

As most of the people don’t know what Community Linux Engineering team is

You could put in a short sentence info about what CLE is?
And a link to a page if you have it?
zlopez says:

This is already in the first sentence of the update.

Continue the discussion at discussion.fedoraproject.org

1 more reply