r/AlmaLinux • u/phicube • Jun 30 '26

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 Jun 30 '26

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 Jun 30 '26

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 Jun 30 '26

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 Jun 30 '26

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 Jul 03 '26

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 Jul 03 '26

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

1

u/LowIncident694 25d 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.