- AlmaLinux Users - AlmaLinux List Archives

GhostLock (CVE-2026-43499) kernel LPE - patched kernels in testing repo now
by Jonathan Wright 09 Jul '26

09 Jul '26

Hello AlmaLinux Community! It's me again! Patched kernels for GhostLock (CVE-2026-43499), a newly disclosed Linux kernel local privilege escalation, are available in the almalinux-testing repository right now, and we need your help verifying them before we promote them to production. WHY THIS MATTERS GhostLock is a use-after-free in the kernel's rtmutex priority inheritance code. An unprivileged local user can exploit it to gain root, and it works from inside a container to escape to the host. No special capabilities are required, and all supported AlmaLinux releases (8, 9, and 10) are affected. The bug has been present in the kernel since 2011. Our core team has backported the upstream fix to every affected branch, and ALESCo approved shipping ahead of the CentOS Stream / RHEL update. Community testing is what gets these kernels safely into production, so please help if you can. HOW TO TEST 1. Install the testing repo: sudo dnf install -y almalinux-release-testing 2. Update the kernel: sudo dnf update 'kernel*' --enablerepo=almalinux-testing 3. Reboot: sudo reboot 4. Confirm the patched kernel is running: uname -r rpm -q kernel Patched versions (or higher): AlmaLinux 8: kernel-4.18.0-553.141.2.el8_10 AlmaLinux 9: kernel-5.14.0-687.23.2.el9_8 AlmaLinux 10: kernel-6.12.0-211.31.2.el10_2 Unless this is a non-production environment, we recommend disabling the testing repo once you've updated: sudo dnf config-manager --disable almalinux-testing REPORT RESULTS Whether things work or break, we want to hear from you as soon as possible: - AlmaLinux Chat: https://chat.almalinux.org - Bug tracker: https://bugs.almalinux.org Full technical details, including how the vulnerability works, are in the blog post: https://almalinux.org/blog/2026-07-09-ghostlock/ Thank you for helping us keep AlmaLinux secure!

1 0

Re: Almalinux-9.8 speed problem
by Jonathan Wright 06 Jul '26

06 Jul '26

John, Testing with speedtest isn't going to be too reliable. I'd suggest an internal network test like iperf3 between local machines to rule out outside factors (the internet). On Fri, Jul 3, 2026 at 6:32 AM John Thompson via AlmaLinux Users < users(a)lists.almalinux.org> wrote: > My almalinux-9.8 desktop machine has suddenly suffered a severe network > (wired connection) slowdown. My ubuntu-24 laptop on the same network > (wifi connection) is much faster. This only happened recently: > > Almalinux-9.8 (wired) > speedtest-cli > Retrieving speedtest.net configuration... > Testing from Spectrum (74.135.192.205)... > Retrieving speedtest.net server list... > Selecting best server based on ping... > Hosted by 5NINES LLC (Madison, WI) [155.45 km]: 120.835 ms > Testing download > > speed................................................................................ > Download: 5.47 Mbit/s > Testing upload > > speed...................................................................................................... > Upload: 18.46 Mbit/s > > > Ubuntu-24 (wifi) > spedtest-cli > Retrieving speedtest.net configuration... > Testing from Spectrum (74.135.192.205)... > Retrieving speedtest.net server list... > Selecting best server based on ping... > Hosted by 5NINES LLC (Madison, WI) [155.45 km]: 44.175 ms > Testing download > > speed................................................................................ > Download: 193.94 Mbit/s > Testing upload > > speed...................................................................................................... > Upload: 21.31 Mbit/s > > Any ideas? > > > > -- > > -John (JohnDThompson(a)gmail.com) > Appleton, WI USA > > _______________________________________________ > AlmaLinux Users mailing list -- users(a)lists.almalinux.org > To unsubscribe send an email to users-leave(a)lists.almalinux.org > -- Jonathan Wright AlmaLinux OS Foundation Mattermost: chat <https://chat.almalinux.org/almalinux/messages/@jonathan>

1 0

Almalinux-9.8 speed problem
by John Thompson 03 Jul '26

03 Jul '26

My almalinux-9.8 desktop machine has suddenly suffered a severe network (wired connection) slowdown. My ubuntu-24 laptop on the same network (wifi connection) is much faster. This only happened recently: Almalinux-9.8 (wired) speedtest-cli Retrieving speedtest.net configuration... Testing from Spectrum (74.135.192.205)... Retrieving speedtest.net server list... Selecting best server based on ping... Hosted by 5NINES LLC (Madison, WI) [155.45 km]: 120.835 ms Testing download speed................................................................................ Download: 5.47 Mbit/s Testing upload speed...................................................................................................... Upload: 18.46 Mbit/s Ubuntu-24 (wifi) spedtest-cli Retrieving speedtest.net configuration... Testing from Spectrum (74.135.192.205)... Retrieving speedtest.net server list... Selecting best server based on ping... Hosted by 5NINES LLC (Madison, WI) [155.45 km]: 44.175 ms Testing download speed................................................................................ Download: 193.94 Mbit/s Testing upload speed...................................................................................................... Upload: 21.31 Mbit/s Any ideas? -- -John (JohnDThompson(a)gmail.com) Appleton, WI USA

1 0

cuda12 and cuda13.3 coexistence
by Oscar Conchillo-Solé 18 Jun '26

18 Jun '26

Dear All I' am a sysadmin with around 10 computers working with Almalinux 8 and 10 (I am in a small biology research institution) Several of them have cuda installed. We are Amber25 / pmemd24 heavy users so we need cuda-toolkit-12-8 which is the only one compatible. I try to keep my systems updated. I keep updating cuda every time a new one comes around. Recently I found that if I have cuda-toolkit-12-? I cannot install cuda-toolkit-13-3 or what is the same, I cannot update cuda-toolkit. If I have cuda-toolkit-13-3 installed I cannot install cuda-toolkit-12-?. I had no similar problems up until now. cuda-toolkit has been updated without a problem up until 13-2 and all previous 13 versions where coexisting with all 12. Here Is the error: # dnf -y --disablerepo=oneAPI update --exclude=kernel-ml* No repository match: oneAPI Last metadata expiration check: 0:59:10 ago on Thu 18 Jun 2026 11:06:46 AM CEST. Error: Problem 1: package cuda-cudart-devel-12-0-12.0.146-1.x86_64 from @System requires cuda-cccl-12-0, but none of the providers can be installed - package cccl-13-3-13.3.3.3.1-1.x86_64 from cuda-rhel8-x86_64 obsoletes cuda-cccl-12-0 provided by cuda-cccl-12-0-12.0.140-1.x86_64 from @System - package cccl-13-3-13.3.3.3.1-1.x86_64 from cuda-rhel8-x86_64 obsoletes cuda-cccl-12-0 provided by cuda-cccl-12-0-12.0.140-1.x86_64 from cuda-rhel8-x86_64 - package cccl-13-3-13.3.3.3.1-1.x86_64 from cuda-rhel8-x86_64 obsoletes cuda-cccl-12-0 provided by cuda-cccl-12-0-12.0.90-1.x86_64 from cuda-rhel8-x86_64 - cannot install the best update candidate for package cuda-cudart-devel-12-0-12.0.146-1.x86_64 - cannot install the best update candidate for package cuda-cccl-12-0-12.0.140-1.x86_64 Problem 2: package cuda-cudart-devel-12-2-12.2.140-1.x86_64 from @System requires cuda-cccl-12-2, but none of the providers can be installed - package cccl-13-3-13.3.3.3.1-1.x86_64 from cuda-rhel8-x86_64 obsoletes cuda-cccl-12-2 provided by cuda-cccl-12-2-12.2.140-1.x86_64 from @System - package cccl-13-3-13.3.3.3.1-1.x86_64 from cuda-rhel8-x86_64 obsoletes cuda-cccl-12-2 provided by cuda-cccl-12-2-12.2.128-1.x86_64 from cuda-rhel8-x86_64 - package cccl-13-3-13.3.3.3.1-1.x86_64 from cuda-rhel8-x86_64 obsoletes cuda-cccl-12-2 provided by cuda-cccl-12-2-12.2.140-1.x86_64 from cuda-rhel8-x86_64 - package cccl-13-3-13.3.3.3.1-1.x86_64 from cuda-rhel8-x86_64 obsoletes cuda-cccl-12-2 provided by cuda-cccl-12-2-12.2.53-1.x86_64 from cuda-rhel8-x86_64 - cannot install the best update candidate for package cuda-cudart-devel-12-2-12.2.140-1.x86_64 - cannot install the best update candidate for package cuda-cccl-12-2-12.2.140-1.x86_64 Problem 3: package cuda-cudart-devel-12-6-12.6.77-1.x86_64 from @System requires cuda-cccl-12-6, but none of the providers can be installed - package cccl-13-3-13.3.3.3.1-1.x86_64 from cuda-rhel8-x86_64 obsoletes cuda-cccl-12-6 provided by cuda-cccl-12-6-12.6.77-1.x86_64 from @System - package cccl-13-3-13.3.3.3.1-1.x86_64 from cuda-rhel8-x86_64 obsoletes cuda-cccl-12-6 provided by cuda-cccl-12-6-12.6.37-1.x86_64 from cuda-rhel8-x86_64 - package cccl-13-3-13.3.3.3.1-1.x86_64 from cuda-rhel8-x86_64 obsoletes cuda-cccl-12-6 provided by cuda-cccl-12-6-12.6.77-1.x86_64 from cuda-rhel8-x86_64 - cannot install the best update candidate for package cuda-cudart-devel-12-6-12.6.77-1.x86_64 - cannot install the best update candidate for package cuda-cccl-12-6-12.6.77-1.x86_64 Problem 4: package cuda-cudart-devel-12-8-12.8.90-1.x86_64 from @System requires cuda-cccl-12-8, but none of the providers can be installed - package cccl-13-3-13.3.3.3.1-1.x86_64 from cuda-rhel8-x86_64 obsoletes cuda-cccl-12-8 provided by cuda-cccl-12-8-12.8.90-1.x86_64 from @System - package cccl-13-3-13.3.3.3.1-1.x86_64 from cuda-rhel8-x86_64 obsoletes cuda-cccl-12-8 provided by cuda-cccl-12-8-12.8.55-1.x86_64 from cuda-rhel8-x86_64 - package cccl-13-3-13.3.3.3.1-1.x86_64 from cuda-rhel8-x86_64 obsoletes cuda-cccl-12-8 provided by cuda-cccl-12-8-12.8.90-1.x86_64 from cuda-rhel8-x86_64 - cannot install the best update candidate for package cuda-cudart-devel-12-8-12.8.90-1.x86_64 - cannot install the best update candidate for package cuda-cccl-12-8-12.8.90-1.x86_64 Problem 5: package cuda-cudart-devel-12-9-12.9.79-1.x86_64 from @System requires cuda-cccl-12-9, but none of the providers can be installed - package cccl-13-3-13.3.3.3.1-1.x86_64 from cuda-rhel8-x86_64 obsoletes cuda-cccl-12-9 provided by cuda-cccl-12-9-12.9.27-1.x86_64 from @System - package cccl-13-3-13.3.3.3.1-1.x86_64 from cuda-rhel8-x86_64 obsoletes cuda-cccl-12-9 provided by cuda-cccl-12-9-12.9.27-1.x86_64 from cuda-rhel8-x86_64 - cannot install the best update candidate for package cuda-cudart-devel-12-9-12.9.79-1.x86_64 - cannot install the best update candidate for package cuda-cccl-12-9-12.9.27-1.x86_64 Problem 6: package cuda-libraries-devel-12-9-12.9.2-1.x86_64 from @System requires cuda-cccl-12-9 >= 12.9.27, but none of the providers can be installed - package cccl-13-3-13.3.3.3.1-1.x86_64 from cuda-rhel8-x86_64 obsoletes cuda-cccl-12-9 provided by cuda-cccl-12-9-12.9.27-1.x86_64 from @System - package cccl-13-3-13.3.3.3.1-1.x86_64 from cuda-rhel8-x86_64 obsoletes cuda-cccl-12-9 provided by cuda-cccl-12-9-12.9.27-1.x86_64 from cuda-rhel8-x86_64 - package cuda-libraries-devel-13-3-13.3.0-1.x86_64 from cuda-rhel8-x86_64 requires cccl-13-3 >= 13.3.3.3.1, but none of the providers can be installed - package cuda-toolkit-13-3-13.3.0-1.x86_64 from cuda-rhel8-x86_64 requires cuda-libraries-devel-13-3 >= 13.3.0, but none of the providers can be installed - package cuda-toolkit-13.3.0-1.x86_64 from cuda-rhel8-x86_64 requires cuda-toolkit-13-3 >= 13.3.0, but none of the providers can be installed - cannot install the best update candidate for package cuda-toolkit-13.2.1-1.x86_64 - cannot install the best update candidate for package cuda-libraries-devel-12-9-12.9.2-1.x86_64 I'm using nvidia cuda repo here is my repolist: ]# dnf repolist repo id repo name appstream AlmaLinux 8 - AppStream baseos AlmaLinux 8 - BaseOS code Visual Studio Code cuda-rhel8-x86_64 cuda-rhel8-x86_64 docker-ce-stable Docker CE Stable - x86_64 elrepo ELRepo.org Community Enterprise Linux Repository - el8 epel Extra Packages for Enterprise Linux 8 - x86_64 extras AlmaLinux 8 - Extras libnvidia-container libnvidia-container powertools AlmaLinux 8 - PowerTools rpmfusion-free-updates RPM Fusion for EL 8 - Free - Updates By any chance anybody here knows if this is an unintended behavior or something planned? Do you believe that we could expect a different behavior in 13-4? Any suggestions to bypass this problem? thank you very much OCS -- Oscar Conchillo Solé Computational Biology Group Data Center Manager, Sysadmin and Bioinformatics Institut de Biotecnologia i Biomedicina (UAB) Department of Genetics and Microbiology (UAB) mail:Oscar.Conchillo@uab.cat telf: 0034 93581 4431

1 0

No audio after upgrading to 9.8
by Adrian P. van Bloois 31 May '26

31 May '26

Hi Folks, This Wednesday I upgraded to 9.8, everything went smoothly as usual. Only after the upgrade the audio was muted one way or another. On my old laptop it still functions but that is no aalternative. The card is different so I guess it has something to do with that, but I can't find it. THe card causing the prroblem is a Rapter Lake high definition. Any suggestion to how to solve this? Adrian -- Adri P. van Bloois It's never too late for early music!!!

1 0

Security roundup: Copy Fail, Dirty Frag, NGINX Rift, Fragnesia, and ssh-keysign-pwn
by Jonathan Wright 15 May '26

15 May '26

Howdy folks, The last two weeks have been unusual, to put it mildly. Five separate high-severity disclosures that affect AlmaLinux have been announced since 2026-05-01: four local-root kernel flaws and one unauthenticated nginx RCE/DoS. If you have lost track of the running tally, you're not alone. Our build servers want a break. Here is where each one stands as of today, where we still need help, and a brief word on what to expect going forward. At a glance: Copy Fail (CVE-2026-31431) <https://almalinux.org/blog/2026-05-01-cve-2026-31431-copy-fail/>: in production Dirty Frag (CVE-2026-43284, CVE-2026-43500) <https://almalinux.org/blog/2026-05-07-dirty-frag/>: in production NGINX Rift (CVE-2026-42945) <https://almalinux.org/blog/2026-05-13-nginx-rift-cve-2026-42945/>: in production Fragnesia (CVE-2026-46300) <https://almalinux.org/blog/2026-05-13-fragnesia-cve-2026-46300/>: testing, please verify ssh-keysign-pwn (CVE-2026-46333) <https://almalinux.org/blog/2026-05-15-ssh-keysign-pwn-cve-2026-46333/>: testing, please verify To the community: thank you. The volume of testing reports we received on these rounds is the reason they moved from testing to production as quickly as they did. The Copy Fail rollout in particular was the highest-engagement community call for testing we have ever run. We do not take that lightly. Two patches are still sitting in the testing repository and need community verification before we can move them to production: Fragnesia (CVE-2026-46300) <https://almalinux.org/blog/2026-05-13-fragnesia-cve-2026-46300/> test builds in almalinux-testing were refreshed on 2026-05-14 with additional upstream patches. ssh-keysign-pwn (CVE-2026-46333) <https://almalinux.org/blog/2026-05-15-ssh-keysign-pwn-cve-2026-46333/> is a __ptrace_may_access() logic bug that lets an unprivileged user lift open file descriptors out of a dying privileged process and read root-owned files like /etc/shadow and SSH host keys. Public exploits are already out. The ssh-keysign-pwn build also carries the Fragnesia patches, so installing it gets you both fixes in a single reboot. See the blog post <https://almalinux.org/blog/2026-05-15-ssh-keysign-pwn-cve-2026-46333/> for testing instructions. A quick note on the pace. We are aware that "another week, another root" is becoming an actual schedule rather than a joke. Four local-root kernel disclosures in fifteen days is, statistically speaking, a lot. Here is what is not changing: 1. We will keep shipping ahead of upstream when the severity warrants it. ALESCo has approved every one of these fast-track rollouts so far, and that bar has not moved. If a critical fix is sitting upstream and our users are exposed, we will build it. 2. We will keep our patches strictly compatible. Every kernel and every nginx package we have shipped during this run uses the upstream fix backported and adapted to the AlmaLinux branch, with the same NVR scheme, the same module ABI, and the same repository layout you would expect from a normal Red Hat security update. Drop-in compatibility is the contract, and we are not breaking it to ship faster. 3. We will keep asking you to test. Community verification is what lets us move from testing to production with confidence. The reason these patches have rolled out cleanly so far is that you have been there to catch the things we cannot reproduce in our lab. Stay informed: Blog: https://almalinux.org/blog/ Mattermost: https://chat.almalinux.org/ Announce: https://lists.almalinux.org/mailman3/lists/announce.lists.almalinux.org/ Security: https://lists.almalinux.org/mailman3/lists/security.lists.almalinux.org/ -- Jonathan Wright AlmaLinux OS Foundation Mattermost: chat <https://chat.almalinux.org/almalinux/messages/@jonathan>

1 0

Re: Security updates vs dnf release timing
by Jonathan Wright 29 Apr '26

29 Apr '26

Hi Scott, Usually by the time the CVE notices roll out the updates have already shipped. A technical glitch that's since been resolved caused this one to be a little behind on the actual rollout. On Mon, Apr 27, 2026 at 11:09 PM Scott Techlist via AlmaLinux Users < users(a)lists.almalinux.org> wrote: > I'm trying to get a handle on monitoring Almalinux 10 for security > updates. I am getting emails but there is usually a lag between the > announcement and an actual package. Or so it seems to me. > > For example I got this one on Friday the 24th, but as of today, the 27th, > I have not seen a package for it. > > What is the normal timeline from Redhat security announcement to Almalinux > to package deployment? Not complaining, just wanting to understand. > > Thanks Scott > > > -----Original Message----- > From: AlmaLinux Errata Notifications via Announce [mailto: > announce(a)lists.almalinux.org] > Sent: Friday, April 24, 2026 10:07 AM > To: announce(a)lists.almalinux.org > Subject: [Announce] [Security Advisory] ALSA-2026:9264: kernel security > update (Important) > > Hi, > > You are receiving an AlmaLinux Security update email because you > subscribed to receive errata notifications from AlmaLinux. > > AlmaLinux: 10 > Type: Security > Severity: Important > Release date: 2026-04-24 > > > > _______________________________________________ > AlmaLinux Users mailing list -- users(a)lists.almalinux.org > To unsubscribe send an email to users-leave(a)lists.almalinux.org > -- Jonathan Wright AlmaLinux OS Foundation Mattermost: chat <https://chat.almalinux.org/almalinux/messages/@jonathan>

1 0

Security updates vs dnf release timing
by Scott Techlist 27 Apr '26

27 Apr '26

I'm trying to get a handle on monitoring Almalinux 10 for security updates. I am getting emails but there is usually a lag between the announcement and an actual package. Or so it seems to me. For example I got this one on Friday the 24th, but as of today, the 27th, I have not seen a package for it. What is the normal timeline from Redhat security announcement to Almalinux to package deployment? Not complaining, just wanting to understand. Thanks Scott -----Original Message----- From: AlmaLinux Errata Notifications via Announce [mailto:announce@lists.almalinux.org] Sent: Friday, April 24, 2026 10:07 AM To: announce(a)lists.almalinux.org Subject: [Announce] [Security Advisory] ALSA-2026:9264: kernel security update (Important) Hi, You are receiving an AlmaLinux Security update email because you subscribed to receive errata notifications from AlmaLinux. AlmaLinux: 10 Type: Security Severity: Important Release date: 2026-04-24

1 0

OpenStack RPMs - Call for packaging volunteers
by Francesco Di Nucci 16 Mar '26

16 Mar '26

Hi all, the RDO Project[0], that provided OpenStack RPM packages through the CentOS Cloud SIG, is switching to a container-based approach due to lack of maintainers.[1] This means *there will be no more RPM packages for OpenStack versions after 2025.1/Epoxy unless new maintainers come up*. *This is a call across the EL and OpenStack communities for volunteer maintainers of RPM build pipelines*. If you're interested you can: * Add your name to the dedicated Etherpad (https://etherpad.opendev.org/p/rdo-volunteers) * Register to the RDO devs mailing list (dev(a)lists.rdoproject.org) and ask for more information No previous experience with packaging/pipelines is required, just willingness to learn /Note: this email is being separately to different mailing lists. If you have subscribed to more than one and recieve it multiple times, sorry for the duplication./ Links [0] https://www.rdoproject.org/ [1] https://lists.rdoproject.org/archives/list/users@lists.rdoproject.org/threa… Francesco, another OpenStack on EL operator -- Francesco Di Nucci System Administrator Compute & Networking Service, INFN Naples Email:francesco.dinucci@na.infn.it

1 0

Access db slow
by Nikos Gatsis 03 Mar '26

03 Mar '26

Hello. I have a 8.10 version as a file server and 4.19 samba on a gigabit local network. Although coping on network is fast, accessing Access db files, is slow. The same files on a common win 11 pc is very fast. I try socket options in smb.conf but the performance is worse. Is there a suggestion? Thank you in advance. Nikos.

1 0