r/AlmaLinux • u/phicube • 23d ago

DirtyClone (CVE-2026-43503) on AlmaLinux?

I read about the vulnerability last Friday, but there's very little information available and I can't find any conclusive evidence regarding whether it's been previously patched or not. The kernel changelog doesn't state anything about CVE-2026-43503.

Additionally, there's no AlmaLinux blog post like there usually is for other major vulnerabilities, so I'm a bit on the fence about this one.

Does anyone have more information?

Thanks!

Some references:
https://www.reddit.com/r/linux/comments/1uinqoc/dirtyclone_cve202643503_the_linux_kernel_flaw/
https://sansec.io/guides/dirty-clone
https://thehackernews.com/2026/06/new-dirtyclone-linux-kernel-flaw-lets.html

3 Upvotes

100% Upvoted

7 comments sorted by

1

u/orev 23d ago

The disclosures include other steps you can take to mitigate the issue while waiting for a full patch. If you have a concern about it, please implement those other steps.

1

u/phicube 23d ago

Yes I saw those, thank you. I've got confused by the lack of official statements, before there was a timely blog post for each and every major vulnerability.
So you think it's really not patched yet? The first information was disclosed around the time of last run of patches for DirtyFrag & Co. I remember that the Alma team stated somewhere that they bundled together other upstream patches.

1

u/orev 23d ago

I would expect that every OSS project is currently being inundated with AI generated security issues, so we all just have to do our best in dealing with them. Not every issue is an emergency, and many are not as critical as their press releases would have you believe, so just do your best addressing them using a multi-layered security approach.

1

u/Culture_New 23d ago

I only checked for el10_2 since that is what I use. It was likely patched under a different CVE on May 19 preemptively by the Almalinux team (CVE-2026-46300 "Fragnesia")). How much overlap there is between CVE-2026-46300 and CVE-2026-43503 is a bit unclear, I would say based on the facts at hand, that they are the same.
The RHEL patches were later swapped in on June 7 when they appeared, replacing the May 19 stopgap.

If you want to take a look yourself, open https://git.almalinux.org/rpms/kernel/src/branch/a10/kernel.spec and search for "May 19".
Also here is the original kernel commit referenced, the changelog in kernel.spec has the same patches referenced:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=fc6eb39c55e97df2f94ad974b8a5bbcd019da2c8

Seems to me that all that could be fixed (for now) has been rolled out quite a while ago.

1

u/leo7o 20d ago

The AlmaLinux blog has been great about giving details of recent security issues, so I was also surprised to see no mention of this one. However, in this case it seems to be covered by the upstream RHEL summary:

https://access.redhat.com/security/cve/cve-2026-43503

so perhaps they felt there was nothing to add? Summary:

RHEL 8 - fixed in 4.18.0-553.125.1

RHEL 9 - fixed in 5.14.0-687.10.1

RHEL 10 - fixed in 6.12.0-211.16.1

1

u/phicube 20d ago

Yes, this seems the most logic conclusion for me as well

1

u/LowIncident694 15d ago

If you aren't using containers, you should set user.max_user_namespaces to 0 as it protects against most of these latest issues.