- Security - 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

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

Fragnesia (CVE-2026-46300) patched kernels available in AlmaLinux testing
by Jonathan Wright 13 May '26

13 May '26

Hi everyone, Here we go again. A third local-root flaw in the Linux kernel has been disclosed today in the same code area as Copy Fail and Dirty Frag. The bug, named "Fragnesia" by researcher William Bowling of the V12 security team, is tracked as CVE-2026-46300, and a working proof-of-concept is already public. Fragnesia is a logic flaw in the core socket-buffer code (skb_try_coalesce loses the SKBFL_SHARED_FRAG marker) that the XFRM ESP-in-TCP receive path then turns into in-place AES-GCM decryption over page-cache pages an unprivileged user controls. The end result is arbitrary byte writes into read-only files such as /usr/bin/su, i.e. immediate local root. All supported AlmaLinux releases (8, 9, 10) are affected through esp4 / esp6, which ship in the standard kernel package. AlmaLinux 9 and 10 are additionally affected through rxrpc, but only on systems that have installed the kernel-modules-partner package from the Devel repository. AlmaLinux 8 does not build rxrpc. The AlmaLinux core team has built patched kernels using the upstream skbuff fix, ahead of any Red Hat update, with ALESCo approval. They are available in the almalinux-testing repository today and will move to production once the community has helped verify them. AlmaLinux 8: kernel-4.18.0-553.124.2.el8_10 AlmaLinux 9: kernel-5.14.0-611.54.4.el9_7 AlmaLinux 10: kernel-6.12.0-124.56.2.el10_1 A dedicated Kitten 10 build will follow shortly. If you run AlmaLinux anywhere untrusted users can get a shell (multi-tenant hosts, container build farms, CI runners, shared developer boxes), please install the patched kernel from testing and help us verify it, or apply the one-line modprobe blacklist mitigation in the blog post. The same mitigation already used for Dirty Frag (esp4 / esp6 / rxrpc) also blocks Fragnesia, so if you applied that one you are already covered. Full write-up, install steps, NVRs, and the mitigation command: https://almalinux.org/blog/2026-05-13-fragnesia-cve-2026-46300/ References: NVD: https://nvd.nist.gov/vuln/detail/CVE-2026-46300 Red Hat: https://access.redhat.com/security/cve/CVE-2026-46300 PoC: https://github.com/v12-security/pocs/tree/main/fragnesia Please report any problems with the patched kernel in https://chat.almalinux.org or on https://bugs.almalinux.org so we can get this into the production repositories quickly. -- Jonathan Wright AlmaLinux OS Foundation Mattermost: chat <https://chat.almalinux.org/almalinux/messages/@jonathan>

1 0

CVE-2026-43284 "Dirty Frag" still present in raspberry pi kernel
by hambingen＠protonmail.com 09 May '26

09 May '26

Dear AlmaLinux community, the recently disclosed "Dirty Frag" exploit that was thankfully patched by the AlmaLinux team with impressive speed in the main kernels is still present in the `raspberrypi2-kernel4` package that is shipped with AlmaLinux for Raspberry Pi (https://repo.almalinux.org/almalinux/10/raspberrypi/images/) It can however easily be fixed as the upstream commit (https://github.com/raspberrypi/linux/commit/b54edf1e9a3fd3491bdcb82a21f8d21…) cleanly applies against the AlmaLinux raspberry pi kernel sources. I have quickly created a fedora copr repo (https://copr.fedorainfracloud.org/coprs/hambingen/raspberry-pi_kernel/) with the patched kernel for an example of how to secure your system. Please consider patching this CVE in the raspberry pi kernel (if this is not already in the works). Yours, Hambingen

1 0

Call for testing — patched kernels for Copy Fail (CVE-2026-31431)
by Jonathan Wright 01 May '26

01 May '26

Hello AlmaLinux Users, A few days ago Xint Code disclosed Copy Fail (CVE-2026-31431), a Linux kernel logic flaw in the crypto subsystem (algif_aead chained through AF_ALG and splice()). It lets any unprivileged local user escalate to root with a 732-byte exploit that the researchers report is 100% reliable across every mainstream Linux distribution built since 2017. Every supported AlmaLinux release is affected. Red Hat has not yet shipped a kernel update, so our core team has built patched kernels for AlmaLinux 8, 9, 10, and Kitten 10 using the upstream fix. ALESCo approved shipping ahead of upstream — the patched kernels are in the testing repository today, and they'll move to production once the community has helped us verify them. If you can spare a test box — especially anything multi-tenant, a container host, or a CI runner where untrusted users get a shell — we'd love your help testing. Full instructions, kernel versions, and feedback channels are on the blog: https://almalinux.org/blog/2026-05-01-cve-2026-31431-copy-fail/ -- Jonathan Wright AlmaLinux OS Foundation Mattermost: chat <https://chat.almalinux.org/almalinux/messages/@jonathan>

1 1

Unassigned CVE Leads to Kernel Crash on AlmaLinux 8 – Double-Free/UAF in nft_hash Garbage Collector
by patryk.sondej＠gmail.com 25 Jan '25

25 Jan '25

Hi, I am experiencing kernel crashes on AlmaLinux 8 caused by an unassigned CVE in the Linux kernel related to a double-free/Use-After-Free vulnerability. ] After analyzing the vmcore crash dump, I discovered that the AlmaLinux kernel contains changes introduced by commit f6c383b8c31a but is not patched with the fix provided in commit 7ffc7481153bbabf3332c6a19b289730c7e1edf5. According to this discussion, the issue was introduced by commit: f6c383b8c31a ("netfilter: nf_tables: adapt set backend to use GC transaction API") and subsequently resolved by commit: 7ffc7481153bbabf3332c6a19b289730c7e1edf5 ("netfilter: nft_set_hash: skip duplicated elements pending gc") See what they are saying in mailing list: https://lore.kernel.org/netdev/20241205002854.162490-3-pablo@netfilter.org/… The root cause is described as follows: > 6) Fix possible double-free in nft_hash garbage collector due to unstable > walk interator that can provide twice the same element. Use a sequence > number to skip expired/dead elements that have been already scheduled > for removal. Based on patch from Laurent Fasnach This unpatched vulnerability in the AlmaLinux 8 kernel results in potential Denial-of-Service (DoS) or crashes, especially when the server utilizes nftables+dynset firewall rules. It also provides a vector for privilege escalation (LPE) when user namespaces are enabled. The relevant crash dump from my system is shown below: ``` ------------[ cut here ]------------ kernel BUG at mm/slub.c:380! invalid opcode: 0000 [#1] SMP PTI CPU: 13 PID: 3660872 Comm: goiptrace Kdump: loaded Tainted: G W X -------- - - 4.18.0-553.27.1.el8_10.x86_64 #1 Hardware name: XXX RIP: 0010:__slab_free+0x19b/0x330 Code: 1f 44 00 00 eb 9c 41 f7 46 08 00 0d 21 00 0f 85 16 ff ff ff 4d 85 ed 0f 85 0d ff ff ff 80 4c 24 5b 80 45 31 ff e9 57 ff ff ff <0f> 0b 49 3b 54 24 28 75 c4 49 89 5c 24 20 49 89 4c 24 28 49 0f ba RSP: 0000:ffffaf87867bcd90 EFLAGS: 00010246 RAX: ffff99c6a85a13e0 RBX: ffff99c6a85a1380 RCX: ffff99c6a85a1380 RDX: 00000000002a001c RSI: ffffd55c47a16800 RDI: ffff99c5c0004e00 RBP: ffffaf87867bce30 R08: 0000000000000001 R09: ffffffffc0783137 R10: ffff99c6a85a1380 R11: 0000000000000029 R12: ffffd55c47a16800 R13: ffff99c6a85a1380 R14: ffff99c5c0004e00 R15: 0000000000000001 FS: 000000c000284c90(0000) GS:ffff99e4ffb40000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00001931ccf4e000 CR3: 0000000ae9b46006 CR4: 00000000003706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <IRQ> ? __die_body+0x1a/0x60 ? die+0x2a/0x50 ? do_trap+0xe7/0x110 ? __slab_free+0x19b/0x330 ? do_invalid_op+0x36/0x40 ? __slab_free+0x19b/0x330 ? invalid_op+0x14/0x20 ? nft_trans_gc_trans_free+0x97/0xd0 [nf_tables] ? __slab_free+0x19b/0x330 ? __unfreeze_partials+0x15b/0x1a0 ? __update_load_avg_cfs_rq+0x27a/0x300 ? nft_trans_gc_trans_free+0x97/0xd0 [nf_tables] kfree+0x22e/0x250 nft_trans_gc_trans_free+0x97/0xd0 [nf_tables] rcu_do_batch+0x1c5/0x4b0 rcu_core+0x14c/0x210 __do_softirq+0xdc/0x2cf irq_exit_rcu+0xc6/0xd0 irq_exit+0xa/0x10 smp_apic_timer_interrupt+0x74/0x130 apic_timer_interrupt+0xf/0x20 </IRQ> RIP: 0033:0x4231b2 Code: 23 4c 89 44 24 38 e8 cd 42 ff ff 48 85 f6 0f 84 a0 00 00 00 48 8b 94 24 88 00 00 00 49 89 f1 48 8b 74 24 48 4d 89 c8 4d 8b 09 <49> 29 d0 4d 85 c9 74 b0 4d 89 ca 49 29 d1 4c 39 ce 77 a5 4c 89 44 RSP: 002b:000000c000199e90 EFLAGS: 00000202 ORIG_RAX: ffffffffffffff13 RAX: 000000c002f19400 RBX: 0000000000000280 RCX: 294a529000000000 RDX: 000000c002f19200 RSI: 0000000000000480 RDI: 0000000000000040 RBP: 000000c000199f08 R08: 000000c002f19510 R09: 000000c000b1c690 R10: 00007fab2c7b1cfe R11: 00000000000002f8 R12: 0000000000000002 R13: 000000000000000b R14: 000000c0002a09c0 R15: 0000000000000001 Modules linked in: nbd rbd libceph binfmt_misc rpcsec_gss_krb5 nfsv4 dns_resolver nfs lockd grace fscache mptcp_diag tcp_diag udp_diag raw_diag inet_diag unix_diag xt_multiport xt_TPROXY nf_tproxy_ipv6 nf_tproxy_ipv4 cls_bpf sch_ingress vxlan ip6_udp_tunnel udp_tunnel veth xt_CT xt_socket nf_socket_ipv4 nf_socket_ipv6 ip6table_filter ip6table_raw ip6table_mangle ip6_tables iptable_filter iptable_raw iptable_mangle iptable_nat ip_tables xt_statistic xt_nat xt_addrtype ipt_REJECT nf_reject_ipv4 ip_set ip_vs_sh ip_vs_wrr ip_vs_rr ip_vs ip6t_MASQUERADE ipt_MASQUERADE xt_conntrack xt_comment xt_mark nft_compat nft_chain_nat nf_nat nf_conntrack_netlink 8021q garp mrp bonding tls(X) bridge stp llc nfnetlink_log nft_limit nft_log nft_counter nf_tables_set nft_ct nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 nf_tables nfnetlink overlay vfat fat intel_rapl_msr intel_rapl_common intel_uncore_frequency intel_uncore_frequency_common sb_edac x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel kvm irqbypass iTCO_wdt crct10dif_pclmul crc32_pclmul iTCO_vendor_support ghash_clmulni_intel rapl intel_cstate ipmi_si intel_uncore ipmi_devintf ipmi_msghandler pcspkr joydev mei_me i2c_i801 mei lpc_ich acpi_power_meter acpi_pad auth_rpcgss sunrpc xfs libcrc32c raid1 sd_mod t10_pi sg mpt3sas ahci ixgbe libahci crc32c_intel igb libata raid_class mdio i2c_algo_bit scsi_transport_sas dca dm_mirror dm_region_hash dm_log dm_mod fuse Red Hat flags: eBPF/rawtrace eBPF/event eBPF/cls eBPF/test ```

1 0

Httpd vulnerability
by Simon Dodd 09 Oct '24

09 Oct '24

Good morning, There was a new high vulnerability for apache released last week for version 2.4.57-11.el9_4 which is resolved in 2.4.57-11.el9_4.1 I have tried running an update but there is nothing available as of yet for this. Will this be added to the repository soon or should we update manually? Thanks -- Kindest regards, Simon Dodd Customer Systems Engineer Pervade Software Tel: +44 1327 304 843 Email: simon(a)pervade-software.com<mailto:simon@pervade-software.com> Web: www.pervade-software.com<http://www.pervade-software.com/> This email contains proprietary and confidential information which may be legally privileged, and is for the intended recipient only. The contents of any telephone or face-to-face conversations relating to the same subject matters referenced in this email should also be considered proprietary and confidential. Access, disclosure, copying, distribution, or reliance on any of it by anyone else is prohibited and may be a criminal offence. Please delete if obtained in error and email confirmation to the sender. Pervade Software Ltd, Registered in England & Wales No: 07060728 of Temple Court, 13a Cathedral Rd, Cardiff, UK, CF11 9HA. VAT No: 128 8405 03 Tel: 02920 647 632 Email: info(a)pervade-software.com<mailto:info@pervade-software.com>

3 2

Severe Unauthenticated RCE Flaw (CVSS 9.9) in GNU/Linux Systems - Awaiting Full Disclosure
by security＠ceo-vision.com 25 Sep '24

25 Sep '24

Hello everyone, As you may know, for reference : - https://cybersecuritynews.com/critical-unauthenticated-rce-flaw/ - https://threadreaderapp.com/thread/1838169889330135132.html It may be something big in the next few days

1 0

OpenSSH Vulnerability CVE-2024-6409
by Neil Coils 10 Jul '24

10 Jul '24

Good Morning, We’ve just been made aware of a possible new OpenSSH Vulnerability CVE-2024-6409 https://thehackernews.com/2024/07/new-openssh-vulnerability-discovered.html Can you please confirm if CVE-2024-6409 is covered by the update delivered for CVE-2024-6387 (aka RegreSSHion) or are we looking at a new vulnerability that will require a new update. If a new update is required are there any details or release dates available. We are currently running OpenSSH_8.7p1 on AlmaLinux release 9.4 (Seafoam Ocelot) Thanks for your help with this matter. Best Regards Neil Coils Pervade Software Mob: +44 7740451604<tel:+447740451604> Email: neil(a)pervade-software.com<mailto:neil@pervade-software.com> Web: www.pervade-software.com<http://www.pervade-software.com/> This email contains proprietary and confidential information which may be legally privileged, and is for the intended recipient only. The contents of any telephone or face-to-face conversations relating to the same subject matters referenced in this email should also be considered proprietary and confidential. Access, disclosure, copying, distribution, or reliance on any of it by anyone else is prohibited and may be a criminal offence. Please delete if obtained in error and email confirmation to the sender. Pervade Software Ltd, Registered in England & Wales No: 07060728 of Temple Court, 13a Cathedral Road, Cardiff, CF11 9HA. VAT No: 128 8405 03 Tel: 02920 647 632 Email: info(a)pervade-software.com<mailto:info@pervade-software.com>

2 2

AlmaLinux 9 OpenSSH "regreSSHion" CVE-2024-6387
by Jonathan Wright 10 Jul '24

10 Jul '24

Hello, We have published updates for OpenSSH's "regreSSHion" vulnerability, CVE-2024-6387. Please see the blog post at https://f89ae520.almalinux-org.pages.dev/blog/2024-07-01-almalinux-9-cve-20… for more information. -- Jonathan Wright AlmaLinux Foundation Mattermost: chat <https://chat.almalinux.org/almalinux/messages/@jonathan>

6 7

[Ticket ID: 190306] Re: OpenSSH Vulnerability- CVE identifier CVE-2024-6387
by Cybrancee Web Hosting Support 02 Jul '24

02 Jul '24

Can someone just remove us from this list, we didn't sign up to it. ---------------------------------------------- Ticket ID: #190306 Subject: [Security] Re: OpenSSH Vulnerability- CVE identifier CVE-2024-6387 Status: Answered Ticket URL: https://cybrancee.com/client/viewticket.php?tid=190306&c=Sf8JmXTV ----------------------------------------------

1 0

[Ticket ID: 190306] Re: OpenSSH Vulnerability- CVE identifier CVE-2024-6387
by Cybrancee Web Hosting Support 01 Jul '24

01 Jul '24

Jonathan Wright, Thank you for contacting our support team. A support ticket has now been opened for your request. You will be notified when a response is made by email. The details of your ticket are shown below. Subject: [Security] Re: OpenSSH Vulnerability- CVE identifier CVE-2024-6387 Priority: Medium Status: Open You can view the ticket at any time at https://cybrancee.com/client/viewticket.php?tid=190306&c=Sf8JmXTV --- Cybrancee https://cybrancee.com

1 0

OpenSSH Vulnerability- CVE identifier CVE-2024-6387
by Neil Coils 01 Jul '24

01 Jul '24

Hi, Is there a recommendation for AlmaLinux 9 users regarding this ‘OpenSSH Vulnerability- CVE identifier CVE-2024-6387’ Thanks & Regards Neil Coils Pervade Software Mob: +44 7740451604<tel:+447740451604> Email: neil(a)pervade-software.com<mailto:neil@pervade-software.com> Web: www.pervade-software.com<http://www.pervade-software.com/> This email contains proprietary and confidential information which may be legally privileged, and is for the intended recipient only. The contents of any telephone or face-to-face conversations relating to the same subject matters referenced in this email should also be considered proprietary and confidential. Access, disclosure, copying, distribution, or reliance on any of it by anyone else is prohibited and may be a criminal offence. Please delete if obtained in error and email confirmation to the sender. Pervade Software Ltd, Registered in England & Wales No: 07060728 of Temple Court, 13a Cathedral Road, Cardiff, CF11 9HA. VAT No: 128 8405 03 Tel: 02920 647 632 Email: info(a)pervade-software.com<mailto:info@pervade-software.com>

3 2

OpenSSH policies / system crypto policy equivalence
by Francesco Di Nucci 20 Jun '24

20 Jun '24

Hello, I am trying to write a crypto policy modifier to disable some kex algorithms in OpenSSH (not the one in the example, but the issue is the same). Reading //usr/share/crypto-policies/python/policygenerators/openssh.py/, I find mappings like /'ECDHE-SECP521R1-SHA2-512': 'ecdh-sha2-nistp521'/, so I tried to write in a pmod /key_exchange = -ECDHE-SECP521R1-SHA2-512/ When I try to load it with update-crypto-policies, it fails stating /Bad value of policy property `key_exchange`: `ECDHE-SECP521R1-SHA2-512`/, and in fact If I check //usr/share/crypto-policies/python/cryptopolicies/alg_lists.py, /ECDHE-SECP521R1-SHA2-512 is not defined there. So, how can I disable in OpenSSH kex/algorithms/etc that are defined in //usr/share/crypto-policies/python/policygenerators/openssh.py /but not in //usr/share/crypto-policies/python/cryptopolicies/alg_lists.py?/ Best regards Francesco Di Nucci

1 0

Hello
by ray 01 May '24

01 May '24

1 0

AlmaLinux 9 - OpenSSh vulnerability
by Sujith PK 29 Apr '24

29 Apr '24

Hi Team, We are reaching out to inquire about the reported vulnerabilities in the OpenSSH version (openssh.x86_64 8.7p1-34.el9_3.3) on AlmaLinux 9.We would like to know whether the fixes are included same like redaht in the version of openssh.x86_64 8.7p1-34.el9_3.3? CVE-2023-48795, CVE-2023-51385 and CVE-2023-51384. Thanks & Regards, Sujith P K CIO Global Server Management [Shape Description automatically generated with medium confidence] 3rd Floor, Wing B WTC2 Bagmane World Technology Center SEZ Marathahalli Outer Ring Road, Mahadevapura, Bangalore 560 048, India [cid:image002.gif@01DA970B.9E2E2670]<mailto:> +91- 8971692387 | sujith.pk(a)mphasis.com<mailto:sujith.pk@mphasis.com> www.mphasis.com<http://www.mphasis.com/> Information Transmitted by this Email is Proprietary to Mphasis, its Associated Companies and/or its Customers and is Intended for use only by the Individual or Entity to which it is Addressed, and may contain Information that is Privileged, Confidential or Exempt from Disclosure under Applicable Law. If you are not the Intended Recipient or it appears that this Email has been Forwarded to you without proper Authority, you are Notified that any use or Dissemination of this Information in any manner is Strictly Prohibited. In such cases, please Notify us Immediately at mailmaster(a)mphasis.com and delete this Email from your Records.

2 2

Air gapped updates
by Kevin Huntly 23 Feb '24

23 Feb '24

Hello, I have an air gapped system that requires updating. It is 9.3, and I'm just not sure where to get update packages for transfer into the secure area. Any ideas?

2 1

Re: Fwd: Question regarding ALSA-2023:5244
by Adam Stackhouse 30 Oct '23

30 Oct '23

Hi, Thanks that's great to know, good job it planned reboots then. Thanks for your time on this and have a good day On Mon, 30 Oct 2023, 16:14 Andrew Lukoshko, <alukoshko(a)almalinux.org> wrote: > Hello. > > Our kernel version 4.18.0-477.27.1.el8_8 was released without > CVE-2023-3390 and CVE-2023-20593 fixes, that's why additional kernel > release version 4.18.0-477.27.2.el8_8 was necessary. > So our kernel 4.18.0-477.27.2.el8_8 corresponds to RHEL's > 4.18.0-477.27.1.el8_8. > > -- > Best Regards, > > Andrew Lukoshko | AlmaLinux OS Architect > > On Sunday, Oct 22, 2023 at 6:52 PM, Jonathan Wright < > jonathan(a)almalinux.org> wrote: > Copying @Andrew Lukoshko <alukoshko(a)almalinux.org> to make sure he sees > this. > > On Sun, Oct 22, 2023 at 11:05 AM Adam Stackhouse <adstak(a)gmail.com> wrote: > >> Hi, >> >> Wondering if this is a better place to ask this question regarding a >> kernel release for ALSA-2023:5244 >> >> Original question should be below as a forwarded message to save writing >> it out again. >> >> Thanks in advance for any help regarding this and If you require anymore >> info feel free to reach out. >> >> >> ---------- Forwarded message --------- >> From: Adam Stackhouse <adstak(a)gmail.com> >> Date: Wed, 18 Oct 2023, 10:13 >> Subject: Question regarding ALSA-2023:5244 >> To: <packager(a)almalinux.org> >> >> >> Hi, >> >> I have noticed a slight difference with the kernel release for Alma >> compared to rocky and rhel for example. I was writing to ask if this is an >> expected diverge because of the recent centos repo issues or a mistake from >> the auto generated errata and updateinfo for the package. >> >> The question is on the errata page for --> >> https://errata.almalinux.org/8/ALSA-2023-5244.html >> >> The required kernel version is 4.18.0-477.27.2.el8_8 and this is >> reflected in the updateinfo in the repo however looking to "upstream" and >> alteratives like rocky you can see the same security advisory id generated >> from rhel is showing the required kernel version to be >> --> 4.18.0-477.27.1.el8_8 >> >> So as you can see I am just wondering if this is a mistake in the >> generated output for Alma or an expected diverge as the difference to me is >> rebooting thousands of servers or not to apply security updates :D >> >> Sources for security advisories from rocky and rhel: >> >> Rhel --> https://access.redhat.com/errata/RHSA-2023:5244 >> Rocky --> https://errata.rockylinux.org/RLSA-2023:5244 >> >> Any questions let me know >> _______________________________________________ >> Security mailing list -- security(a)lists.almalinux.org >> To unsubscribe send an email to security-leave(a)lists.almalinux.org >> > > > -- > Jonathan Wright > AlmaLinux Foundation > Mattermost: chat <https://chat.almalinux.org/almalinux/messages/@jonathan> > >

1 0

Fwd: Question regarding ALSA-2023:5244
by Adam Stackhouse 22 Oct '23

22 Oct '23

Hi, Wondering if this is a better place to ask this question regarding a kernel release for ALSA-2023:5244 Original question should be below as a forwarded message to save writing it out again. Thanks in advance for any help regarding this and If you require anymore info feel free to reach out. ---------- Forwarded message --------- From: Adam Stackhouse <adstak(a)gmail.com> Date: Wed, 18 Oct 2023, 10:13 Subject: Question regarding ALSA-2023:5244 To: <packager(a)almalinux.org> Hi, I have noticed a slight difference with the kernel release for Alma compared to rocky and rhel for example. I was writing to ask if this is an expected diverge because of the recent centos repo issues or a mistake from the auto generated errata and updateinfo for the package. The question is on the errata page for --> https://errata.almalinux.org/8/ALSA-2023-5244.html The required kernel version is 4.18.0-477.27.2.el8_8 and this is reflected in the updateinfo in the repo however looking to "upstream" and alteratives like rocky you can see the same security advisory id generated from rhel is showing the required kernel version to be --> 4.18.0-477.27.1.el8_8 So as you can see I am just wondering if this is a mistake in the generated output for Alma or an expected diverge as the difference to me is rebooting thousands of servers or not to apply security updates :D Sources for security advisories from rocky and rhel: Rhel --> https://access.redhat.com/errata/RHSA-2023:5244 Rocky --> https://errata.rockylinux.org/RLSA-2023:5244 Any questions let me know

2 1

RSS Feed for https://errata.almalinux.org/
by andre.pires_carvalho＠siemens.com 06 Sep '23

06 Sep '23

Dear AlmaLinux, I'm currently monitoring the security advisories for AlmaLinux packages by subscribing your email security list. Nonetheless, I'm an avid supporter of RSS-like delivering systems. Additionally, I think it is a perfect match for structured information such as your security advisories! Is an RSS Feed something that could be provided for the information on https://errata.almalinux.org/ ? Thank you so much for the great work! André C.

2 1

Request for Permission to Conduct Passive Reconnaissance for Academic Purposes
by Robert Crowe 14 Aug '23

14 Aug '23

Dear Almalinux Foundation, I hope this email finds you well. My name is Robert Crowe, and I am currently pursuing a degree in Cybersecurity at the University of Phoenix. As part of my Ethical Hacking course, I have been tasked with conducting a passive reconnaissance assignment focused on a chosen organization. I am reaching out to request your consent to select the Almalinux Foundation as the subject of my research. The objective of this assignment is threefold: 1. Summarize the Importance of Footprinting: This section will briefly discuss the significance of footprinting in ethical hacking, and how it serves as a foundational step in penetration testing. 2. Examine Organizational, Network, and System Information: I will analyze publicly available data about the Almalinux Foundation, including organizational structure, network components, and system configurations. This will allow me to describe the results of the examination. 3. Assess the Security Posture: Based on the collected information, I will provide an analysis of the current security stance of the Almalinux Foundation and identify any potential security vulnerabilities. Please be assured that this exercise will be entirely passive and will only utilize information that is publicly available. No active probing, scanning, or intrusive techniques will be employed. Additionally, I would be more than happy to share my report and findings with you once the assignment has been graded. The integrity and ethical considerations of this task are of paramount importance to me, and I am committed to ensuring full compliance with legal and professional standards. I would not proceed with this assignment without your explicit permission. Thank you for considering my request. I eagerly await your response and assure you of my utmost respect for your privacy and security. Best Regards, Robert Crowe robert.crowe(a)mykolab.com, Abilene, TX Cybersecurity Student University of Phoenix

2 1

Zenbleed Patch Release: 7/27/2023 @ 0700 EST
by Jonathan Wright 26 Jul '23

26 Jul '23

Hi all! There was a flaw announced and patches released that is trivially executable in a large number of AMD environments (CVE-2023-20593). We announced Monday that we had a patch for Zenbleed ready <https://almalinux.org/blog/zenbleed-patch-call-for-testing/> (please read the blog post for full details), but wanted testing. So far we have seen a significant number of users and companies apply the patches with our updated linux-firmware package with no reported problems, and therefore we plan to push the updated package live at 07:00 US eastern time July 27th. If you are at all concerned, we encourage you to test in your own environment and let us know if you find any problems. As a side note: we already have been, but are continuing to discuss the right way to handle this in a sustainable way going forward. If you have interest in being part of that solution, join our chat and keep an eye out for when we start to build those structures, and make sure to join us at the AlmaLinux OS Foundation <https://almalinux.org/members/>. -- Jonathan Wright AlmaLinux Foundation Mattermost: chat <https://chat.almalinux.org/almalinux/messages/@jonathan>

1 0

Zenbleed Patches Available for Testing
by Jonathan Wright 25 Jul '23

25 Jul '23

We are happy to announce that Zenbleed patches are available now for testing. You can apply the fix as follows: AlmaLinux 8: dnf update https://build.almalinux.org/pulp/content/builds/AlmaLinux-8-x86_64-7032-br/… AlmaLinux 9: dnf update https://build.almalinux.org/pulp/content/builds/AlmaLinux-9-x86_64-7033-br/… AlmaLinux 8/9: echo 1 > /sys/devices/system/cpu/microcode/reload For full details please see our blog post at https://almalinux.org/blog/zenbleed-patch-call-for-testing/ The updates are expected to hit the production repos in the coming days. -- Jonathan Wright AlmaLinux Foundation Mattermost: chat <https://chat.almalinux.org/almalinux/messages/@jonathan>

1 0

Package missing in Podman Module container-tools:rhel8 / container-selinux-2.189.0-1.module_el8.7.0+3344+5bcd850f.noarch.rpm
by Dominik Rutkowski 02 Feb '23

02 Feb '23

Hello, I just noticed this behavior because of an trivy scan I enabled podman module RHEL8 and installed podman: dnf module enable container-tools:rhel8 dnf install podman rpm -qa podman podman-4.2.0-6.module_el8.7.0+3385+a9526ac7.x86_64 rpm -qa container-selinux container-selinux-2.189.0-1.module_el8.6.0+3336+00d107d5.noarch if I switch to container-tools:4.0 then the correct container-selinux module get installed dnf module switch-to container-tools:4.0 rpm -qa podman podman-4.0.2-8.module_el8.7.0+3344+5bcd850f.x86_64 rpm -qa container-selinux container-selinux-2.189.0-1.module_el8.7.0+3344+5bcd850f.noarch The whole Module "container-tools:rhel8" seems messed up fuse-overlayfs 1.9-1.module_el8.6.0+3070+1510fbd1 get installed, but should be 1.9-1.module_el8.7.0+3344+5bcd850f I cannot replicate it on an RHEL machine, so I don't know if this is an upstream RHEL issue Thanks in advance If you need any more infos, just let me know Greetings Dominik

1 0

Re: Can I use the Elevate tool to migrate my CentOS 7.9 with Virtualmin/Webmin to AlmaLinux 9.0?
by Turritopsis Dohrnii Teo En Ming 24 Nov '22

24 Nov '22

On Fri, 18 Nov 2022 at 21:58, Scott Blaydes <scott(a)nettek.io> wrote: > > I believe that is beyond the scope of this list. > > Best bet would be to make a clone of the system and try running Elevate. If you can't make a clone, build a new server and try it. > > Also, if you do choose to build a new server and install an Alma/Virtualmin server, you can migrate backups from the CentOS/Virtualmin and restore them on the new Alma/Virtualmin server. > > Thank you, > Scott Blaydes Dear Scott Blaydes, Thank you for your reply. I think you may have saved my day. You mean I can make full and complete backups of my web hosting control panel using the Virtualmin GUI web interface in CentOS 7.9 and restore the backups on the fresh new installation of AlmaLinux 9.1/Virtualmin server? That means I do not need to make a clone of my CentOS 7.9 linux server and run Elevate tool already. I can simply make a fresh new installation of both AlmaLinux 9.1 and Virtualmin on a brand new server. No migration needed and no headaches and complications. Thank you. Mr. Turritopsis Dohrnii Teo En Ming > > On Wed, Nov 16, 2022 at 10:45:10PM +0800, Turritopsis Dohrnii Teo En Ming wrote: > > Subject: Can I use the Elevate tool to migrate my CentOS 7.9 with > > Virtualmin/Webmin to AlmaLinux 9.0? > > > > Good day from Singapore, > > > > I understand both CentOS Linux and AlmaLinux follow Red Hat Enterprise > > Linux (RHEL). > > > > I have 2 CentOS 7.9 Linux virtual private servers (VPS) in Europe. > > They are running Virtualmin/Webmin web hosting control panel in master > > and slave configuration. > > > > Unfortunately, the end of life (EOL) date for CentOS 7.9 is 30 June > > 2024, which is less than 2 years away. > > > > Can I use the Elevate tool to migrate my CentOS 7.9 with > > Virtualmin/Webmin to AlmaLinux 9.0? Is it technically impossible or > > will result in too many complications? > > > > Should I install AlmaLinux 9.0 from fresh and then install Virtualmin > > instead? If I choose this route, I will need to ask Virtualmin > > developers how I can migrate the web hosting control panel from CentOS > > 7.9 to AlmaLinux 9.0. > > > > Please advise. > > > > Thank you. > > > > Regards, > > > > Mr. Turritopsis Dohrnii Teo En Ming > > Targeted Individual in Singapore > > Blogs: > > https://tdtemcerts.blogspot.com > > https://tdtemcerts.wordpress.com > > _______________________________________________ > > Security mailing list -- security(a)lists.almalinux.org > > To unsubscribe send an email to security-leave(a)lists.almalinux.org

2 2