Community Update - Week 19 2026

News & Announcements Community Blog
1

Originally published at: 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

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.

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.

Forgejo

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

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.

1 Like
2

Hi, any information about Dirty Frag vulnerability ? :slightly_smiling_face:

3

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

Could we include that in future?

4

@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
6

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.

7

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

8

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!

1 Like
9

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).

10

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

11

This is already in the first sentence of the update.

1 Like