A security-relevant race between mremap() and THP code has been discovered. Reaching the buggy code typically requires the ability to create unprivileged namespaces. The bug leads to installing physical address 0 as a page table, which is likely exploitable in several ways: For example, triggering the bug in multiple processes can probably lead to unintended page table sharing, which probably can lead to stale TLB entries pointing to freed pages.

    SummaryI found a security-relevant race between mremap() and THP code. Reaching the buggy code typically requires the ability to create unprivileged namespaces. The bug leads to installing physical address 0 as a page table, which is likely exploitable in several ways: For example, triggering the bug in multiple processes can probably lead to unintended page table sharing, which probably can lead to stale TLB entries pointing to freed pages.I also found two other (untested) theoretical races, but those arguably might not even count as bugs, and I'm pretty sure they're not security bugs. I am including my analysis of the closely related non-issues 2 and 3 as context in case you're curious, but I think they're stuff we can deal with on the public list later (or maybe even just leave as-is). Feel free to ignore that part of this report.I will send a suggested patch for the security bug, but I think it's unclear if my patch is actually the right way to fix it.This bug is subject to a 90-day disclosure deadline. If a fix for this issue is made available to users before the end of the 90-day deadline, this bug report will become public 30 days after the fix was made available. Otherwise, this bug report will become public at the deadline. The scheduled deadline is 2024-12-31.For more details, see the Project Zero vulnerability disclosure policy: https://googleprojectzero.blogspot.com/p/vulnerability-disclosure-policy.htmlSecurity bug: move_normal_pmd vs MADVISE_COLLAPSEDescriptionIn mremap(), move_page_tables() looks at the type of the PMD entry and the specified address range to figure out by which method the next chunk of page table entries should be moved. At that point, the mmap_lock is held in write mode, but no rmap locks are held. For PMD entries that point to page tables and are fully covered by the source address range, move_pgt_entry(NORMAL_PMD, ...) is called, which first takes rmap locks, then does move_normal_pmd().move_normal_pmd() takes the necessary page table locks at source and destination, then moves an entire page table from the source to the destination:        /* Clear the pmd */        pmd = *old_pmd;        pmd_clear(old_pmd);        VM_BUG_ON(!pmd_none(*new_pmd));        pmd_populate(mm, new_pmd, pmd_pgtable(pmd));        flush_tlb_range(vma, old_addr, old_addr + PMD_SIZE);The problem is: The rmap locks, which protect against concurrent page table removal by retract_page_tables() in the THP code, are only taken after we have inspected the PMD entry to decide how to move it. So we can race as follows (with two processes that have mappings of the same tmpfs file that is stored on a tmpfs mount with huge=advise):process A                      process B=========                      =========mremap  mremap_to    move_vma      move_page_tables        get_old_pmd        alloc_new_pmd                      *** PREEMPT ***                               madvise(MADV_COLLAPSE)                                 do_madvise                                   madvise_walk_vmas                                     madvise_vma_behavior                                       madvise_collapse                                         hpage_collapse_scan_file                                           collapse_file                                             retract_page_tables                                               i_mmap_lock_read(mapping)                                               pmdp_collapse_flush                                               i_mmap_unlock_read(mapping)        move_pgt_entry(NORMAL_PMD, ...)          take_rmap_locks          move_normal_pmd          drop_rmap_locksIn this case, while move_normal_pmd() expects to see a PMD entry pointing to a page table, the PMD entry has actually been cleared. So this line:pmd_populate(mm, new_pmd, pmd_pgtable(pmd));runs pmd_pgtable() on a cleared PMD entry. On typical implementations (including the X86 one), this simply masks off some bits of pmd and assumes that the remainder is a physical address - so pmd_pgtable(0) returns a pointer to the page for physical address 0. Then, pmd_populate() constructs a PMD entry that points to this physical address as a page table.So this ends up installing physical address 0 as a page table.Fixing itI guess there are two ways we could fix this:    Hold the rmap locks much more broadly in move_page_tables(). In particular, take them before inspecting the source pmd, and if we do a PMD-level move, keep them held throughout the entire move.    Add a bunch of extra recheck/retry logic.I think the first option is nicer in terms of code complexity. Moving the lock up requires a small bit of refactoring though, and the broader locking could conceivably degrade the performance of concurrent rmap access.I will send a suggested patch for the first option in a minute (and I have tested that with that patch, my reproducer no longer triggers); but we might want to do some more bikeshedding of whether this is the right way to patch it, and if yes, whether the patch is doing too little lock-dropping for performance or adds too much complexity with the lock-dropping...ReproducerI made a testcase that triggers this issue after a while and causes a splat when the kernel later tries to unmap this page table at physical address 0:#define _GNU_SOURCE#include <err.h>#include <sched.h>#include <stdio.h>#include <string.h>#include <fcntl.h>#include <signal.h>#include <stdlib.h>#include <unistd.h>#include <sys/syscall.h>#include <sys/stat.h>#include <sys/prctl.h>#include <sys/mount.h>#include <sys/mman.h>#include <sys/wait.h>#include <sys/ioctl.h>static void pin_to(int cpu) {  cpu_set_t cset;  CPU_ZERO(&cset);  CPU_SET(cpu, &cset);  if (sched_setaffinity(0, sizeof(cpu_set_t), &cset))    err(1, "set affinity");}#ifndef MADV_COLLAPSE#define MADV_COLLAPSE 25#endif#define SYSCHK(x) ({          \  typeof(x) __res = (x);      \  if (__res == (typeof(x))-1) \    err(1, "SYSCHK(" #x ")"); \  __res;                      \})static void write_file(char *name, char *buf) {  int fd = SYSCHK(open(name, O_WRONLY));  if (write(fd, buf, strlen(buf)) != strlen(buf))    err(1, "write %s", name);  close(fd);}static void write_map(char *name, int outer_id) {  char buf[100];  sprintf(buf, "0 %d 1", outer_id);  write_file(name, buf);}int main(void) {  // set up new mount ns for tmpfs with THP  int outer_uid = getuid();  int outer_gid = getgid();  SYSCHK(unshare(CLONE_NEWNS|CLONE_NEWUSER));  SYSCHK(mount(NULL, "/", NULL, MS_PRIVATE|MS_REC, NULL));  write_file("/proc/self/setgroups", "deny");  write_map("/proc/self/uid_map", outer_uid);  write_map("/proc/self/gid_map", outer_gid);  // make tmpfs with THP  SYSCHK(mount("none", "/tmp", "tmpfs", MS_NOSUID|MS_NODEV, "huge=advise"));  pin_to(0);  while (1) {    int fd = SYSCHK(open("/tmp/a", O_RDWR|O_CREAT, 0600));    void *ptr = SYSCHK(mmap((void*)0x200000UL, 0x200000, PROT_READ|PROT_WRITE, MAP_SHARED|MAP_FIXED_NOREPLACE, fd, 0));    SYSCHK(ftruncate(fd, 0x1000));    *((volatile char *)ptr) = 'a';    SYSCHK(ftruncate(fd, 0x200000));    SYSCHK(madvise(ptr, 0x200000, MADV_HUGEPAGE));    close(fd);    SYSCHK(unlink("/tmp/a"));    int child = SYSCHK(fork());    if (child == 0) {      for (int i=0; i<512; i++)        ((volatile char *)ptr)[0x1000*i] = 'a';      struct sched_param param = { .sched_priority = 0 };      SYSCHK(sched_setscheduler(0, SCHED_IDLE, &param));      /* race (outer side, will be preempted) */      SYSCHK(mremap((void*)0x200000, 0x200000, 0x200000, MREMAP_MAYMOVE|MREMAP_FIXED, (void*)0x40000000));      return 0;    }    for (int i=0; i<512; i++)      ((volatile char *)ptr)[0x1000*i] = 'a';    usleep(10);    /* race (inner side, will preempt after timer and voluntary resched) */    int madv_res = madvise(ptr, 0x200000, MADV_COLLAPSE);    if (madv_res == -1)      fprintf(stderr, "_");    int wstatus;    SYSCHK(waitpid(child, &wstatus, 0));    SYSCHK(munmap(ptr, 0x200000));    fprintf(stderr, ".");  }}Usage:user@vm:~/collapse-vs-mremap$ gcc -o collapse-vs-mremap-2-noassist collapse-vs-mremap-2-noassist.cuser@vm:~/collapse-vs-mremap$ ./collapse-vs-mremap-2-noassist.................................................................................................................................Result on Linux 6.11 in a QEMU VM, where a bunch of non-zero data is left over in the first 0x1000 bytes of physical memory (note the pmd:00000067):[  120.427189] BUG: Bad page map in process collapse-vs-mre  pte:f000ff53f000ff53 pmd:00000067[  120.428763] addr:0000000040000000 vm_flags:200000fb anon_vma:0000000000000000 mapping:ffff888007dd70f8 index:0[  120.430526] file:a fault:shmem_fault mmap:shmem_mmap read_folio:0x0[  120.431706] CPU: 0 UID: 1000 PID: 1219 Comm: collapse-vs-mre Tainted: G        W          6.11.0 #493[  120.433591] Tainted: [W]=WARN[  120.434201] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014[  120.435849] Call Trace:[  120.436375]  <TASK>[  120.436843]  dump_stack_lvl+0x53/0x70[  120.437570]  print_bad_pte+0x4e6/0x8e0[...][  120.447625]  vm_normal_page+0x1c8/0x260[...][  120.450162]  unmap_page_range+0x914/0x3d10[...][  120.456954]  unmap_vmas+0x1cc/0x390[...][  120.461123]  exit_mmap+0x160/0x6c0[...][  120.465181]  mmput+0xa0/0x3a0[  120.465793]  do_exit+0x7cd/0x27f0[...][  120.472198]  do_group_exit+0xac/0x230[  120.472916]  __x64_sys_exit_group+0x3e/0x50[  120.473722]  x64_sys_call+0x17f3/0x1800[  120.474469]  do_syscall_64+0x4b/0x110[  120.475189]  entry_SYSCALL_64_after_hwframe+0x76/0x7e[...][  120.489560]  </TASK>On other machines where physical page 0 contains only zeroes, the error is different and the kernel complains about the mm's pagetable bytes counter being -4096 on process exit.ImpactReaching this bug requires that you can create shmem/file THP mappings - anonymous THP uses different code that doesn't zap stuff under rmap locks. File THP is gated on an experimental config flag (CONFIG_READ_ONLY_THP_FOR_FS), so on normal distro kernels you need shmem THP to hit this bug. (Some Android kernels set CONFIG_READ_ONLY_THP_FOR_FS=y, but those kernels are older than 6.6, so they're not affected.)As far as I know, getting shmem THP normally requires that you can mount your own tmpfs with the right mount flags, so on normal Linux systems you usually need the ability to create your own user+mount namespace (like my reproducer does).If you trigger this bug in two different processes, or in two different locations in the same process, you should get physical page 0 mapped in two different places. Assuming you know that a certain part of the page contains zeroes, you should be able to get page table entries installed through one of the mappings, and then access those page table entries through the other mapping of the same page table.At that point, I think several bad things can happen that could lead to privilege escalation, though I haven't tested that:    When a PTE is zapped through the page table's first mapping, TLB flushes will only be done for the first mapping, but there can be TLB entries created through the second mapping. So you could probably end up with stale TLB entries pointing to freed pages.    If VMA 1 and VMA 2 share a page table, and you install an anonymous page through VMA 1, and then use mremap() on VMA 2 to move that PTE to another location, and then munmap() VMA 1, you'll end up with an anonymous page that's only mapped into a VMA that is not associated with the page's anon_vma, which leads to kernel UAF. (See https://project-zero.issues.chromium.org/issues/42451486 and https://git.kernel.org/linus/2555283eb40d .)I think the exploitability of this bug depends on whether a struct page has been allocated for physical address 0 - but that seems to be the case at least on the two X86 systems I tested this on.Non-issue 2 (no impact): move_ptes vs MADVISE_COLLAPSEmove_ptes() locks the source and destination page tables as follows:        old_pte = pte_offset_map_lock(mm, old_pmd, old_addr, &old_ptl);        if (!old_pte)                return -EAGAIN;        new_pte = pte_offset_map_nolock(mm, new_pmd, new_addr, &new_ptl);        if (!new_pte) {                pte_unmap_unlock(old_pte, old_ptl);                return -EAGAIN;        }        if (new_ptl != old_ptl)                spin_lock_nested(new_ptl, SINGLE_DEPTH_NESTING);pte_offset_map_nolock() followed by manually taking the page table lock does not (unlike pte_offset_map_lock()) protect against concurrent removal of the page table via retract_page_tables(); and that can happen when need_rmap_locks is false. So I think that after this block, we can end up with new_pte pointing to a page table that has already been scheduled for RCU-delayed freeing. The good news is that (as far as I understand) this can only happen when all the PTEs in the source page table are pte_none(), so no PTEs will actually be written to the detached destination page table, so nothing bad happens.Non-issue 3 (probably no impact, untested): move_huge_pmd vs split_huge_page_to_list_to_orderThe classic way mremap() used to work is:    We make a new VMA.    We move page table entries into the new VMA with move_page_tables(), creating page tables if necessary. Only page table entries are moved; the old page tables stay where they are.    If a page table allocation fails due to OOM, or if the ->mremap handler returns an error, we use move_page_tables() to move the page table entries back to the old VMA; this is expected to always succeed, since the old page tables still exist, so page table allocation should not happen.As a comment in move_page_tables() explains:/* * On error, move entries back from new area to old, * which will succeed since page tables still there, * and then proceed to unmap new area instead of old. */However, that does not hold in the following scenario, assuming that the architecture does not define HAVE_MOVE_PMD (which permits mremap() to move entire page tables):    move_vma() calls move_page_tables()    move_page_tables() moves an anonymous huge PMD entry.    move_page_tables() tries to move more page table entries, but page table allocation fails, and the function returns early.    Another racing process causes the huge PMD entry to be split via split_huge_page_to_list_to_order() (turning the huge PMD entry into a PMD entry pointing to a page table whose PTEs point to all the subpages).    move_vma() calls move_page_tables() in the reverse direction to move PTEs back.    move_page_tables() unexpectedly needs to allocate a new page table to move the PTEs generated by the huge PMD split, which again fails. PTEs are left behind in the destination area.    do_vmi_munmap() removes the temporary destination VMA and removes the left-behind PTEs in the destination area.So in the end, an anonymous page has erroneously disappeared from the VMA, but I think that doesn't lead to any major consequences.FWIW, the architectures that define HAVE_ARCH_TRANSPARENT_HUGEPAGE without also defining HAVE_MOVE_PMD are: mips, loongarch, s390, sparc64, arc, arm.I think similar things can probably also happen on x86/arm64 if, when moving PTEs back with move_pgt_entry(HPAGE_PMD, ...), we race with a concurrent split_huge_page_to_list_to_order() such that move_huge_pmd() fails at the __pmd_trans_huge_lock() and we fall back to the move_ptes() path.CommentsAll commentsja...@google.com <ja...@google.com> #2Oct 15, 2024 11:05AMThe fix for the security bug is currently in the MM tree at https://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm.git/commit/?id=9118e3ff1212add463770537519dce4aed51cf94 , on the mm-hotfixes-unstable branch.ja...@google.com <ja...@google.com> #3Oct 22, 2024 09:28AMMarked as fixed, reassigned to ja...@google.com.Fix landed as https://git.kernel.org/linus/6fa1066fc5d00cb9f1b0e83b7ff6ef98d26ba2aa ("mm/mremap: fix move_normal_pmd/retract_page_tables race").In stable releases:    6.6.58 (2024-10-22)    6.11.5 (2024-10-22)Related CVE Number: CVE-2024-50066.Credit: Jann Horn

Linux 6.6 Race Condition

Ubuntu Security Notice 7120-3 - Several security issues were discovered in the Linux kernel. An attacker could possibly use these to compromise the system.

==========================================================================  
Ubuntu Security Notice USN-7120-3  
November 21, 2024

linux-lowlatency, linux-lowlatency-hwe-6.8 vulnerabilities  
==========================================================================

A security issue affects these releases of Ubuntu and its derivatives:

- Ubuntu 24.04 LTS  
- Ubuntu 22.04 LTS

Summary:

Several security issues were fixed in the Linux kernel.

Software Description:  
- linux-lowlatency: Linux low latency kernel  
- linux-lowlatency-hwe-6.8: Linux low latency kernel

Details:

Several security issues were discovered in the Linux kernel.  
An attacker could possibly use these to compromise the system.  
This update corrects flaws in the following subsystems:  
  - File systems infrastructure;  
  - Network traffic control;  
(CVE-2024-46800, CVE-2024-43882)

Update instructions:

The problem can be corrected by updating your system to the following  
package versions:

Ubuntu 24.04 LTS  
  linux-image-6.8.0-49-lowlatency  6.8.0-49.49.1  
  linux-image-6.8.0-49-lowlatency-64k  6.8.0-49.49.1  
  linux-image-lowlatency          6.8.0-49.49.1  
  linux-image-lowlatency-64k      6.8.0-49.49.1  
  linux-image-lowlatency-64k-hwe-24.04  6.8.0-49.49.1  
  linux-image-lowlatency-hwe-24.04  6.8.0-49.49.1

Ubuntu 22.04 LTS  
  linux-image-6.8.0-49-lowlatency  6.8.0-49.49.1~22.04.1  
  linux-image-6.8.0-49-lowlatency-64k  6.8.0-49.49.1~22.04.1  
  linux-image-lowlatency-64k-hwe-22.04  6.8.0-49.49.1~22.04.1  
  linux-image-lowlatency-hwe-22.04  6.8.0-49.49.1~22.04.1

After a standard system update you need to reboot your computer to make  
all the necessary changes.

ATTENTION: Due to an unavoidable ABI change the kernel updates have  
been given a new version number, which requires you to recompile and  
reinstall all third party kernel modules you might have installed.  
Unless you manually uninstalled the standard kernel metapackages  
(e.g. linux-generic, linux-generic-lts-RELEASE, linux-virtual,  
linux-powerpc), a standard system upgrade will automatically perform  
this as well.

References:  
  https://ubuntu.com/security/notices/USN-7120-3  
  https://ubuntu.com/security/notices/USN-7120-2  
  https://ubuntu.com/security/notices/USN-7120-1  
  CVE-2024-43882, CVE-2024-46800

Package Information:  
  https://launchpad.net/ubuntu/+source/linux-lowlatency/6.8.0-49.49.1

 https://launchpad.net/ubuntu/+source/linux-lowlatency-hwe-6.8/6.8.0-49.49.1~22.04.1

Ubuntu Security Notice USN-7120-3

Debian Linux Security Advisory 5812-2 - The postgresql minor release shipped in DSA 5812 introduced an ABI break, which has been reverted so that extensions do not need to be rebuilt.

    -----BEGIN PGP SIGNED MESSAGE-----Hash: SHA512- -------------------------------------------------------------------------Debian Security Advisory DSA-5812-2                   security@debian.orghttps://www.debian.org/security/                       Moritz MuehlenhoffNovember 21, 2024                     https://www.debian.org/security/faq- -------------------------------------------------------------------------Package        : postgresql-15The postgresql minor release shipped in DSA 5812 introduced an ABI break,which has been reverted so that extensions do not need to be rebuilt.For the stable distribution (bookworm), this  has been fixed inversion 15.10-0+deb12u1.We recommend that you upgrade your postgresql-15 packages.For the detailed security status of postgresql-15 please refer toits security tracker page at:https://security-tracker.debian.org/tracker/postgresql-15Further information about Debian Security Advisories, how to applythese updates to your system and frequently asked questions can befound at: https://www.debian.org/security/Mailing list: debian-security-announce@lists.debian.org-----BEGIN PGP SIGNATURE-----iQIzBAEBCgAdFiEEtuYvPRKsOElcDakFEMKTtsN8TjYFAmc/hswACgkQEMKTtsN8TjZePRAAgnIkPa8sI7Rv38Ye9PxPsElOYO5pMMe4Pn8xcqtVtDdYsu/D2n/H7lF5u7Yn3WAjSLYbTi2wc9sPZ2lqg/qgEgGuU0xh4+Bbd2N0eXSWRZMCe9ILIJqdyX0BeF3hjpqmJrkOi1xxIxsvS8nLxXdI4zEJdCd9R+Q2iH8D0Xl3IuRWPFYpOdu4aWSgtqlYrmRtZ6yM/LCM8qnTOf1WZ+L8x7jYHQ21PGYH+645UY3tCEoe4mr3H2e/f0rLVxAJMvFQbbUk/gLVozI4+5cIracmcQMaHR+TqHfkVY8qMq9iASehFF9qhxMJVSP2o0aprYMHyKoIudyzLUuM0fJD0xs2yQjj+wP71mTPe3t4NqBDE4z/oDNgXuehRMmOPeBq3nP7JQG/BhQN/F4bDI3aSu/EPfUwEODiIPapGeYTjnI0RPU6RxgfM1qTLPFAvzFYIyRCPlqmAF/RhFndSnXl2mMsZo/w69CUgKtt04c1nATXGI+VklIV400mHPLFCj+ETF0qESNwGqiUdyxYY2uuTa/KyJ+JzHBTJ9wYEgZErKVdpyVcaB7+0j+Sx15tObwIfhdTths2BOtCl9jp1hLtitwog7486FOVIL4TpXkqk4TfLwD9DiK/KurE/aUlEwDDk9j5F8KA7HqW+e1eAlsqI+P+kHHkSXlVj+DssQRvQywqIN0==pbdM-----END PGP SIGNATURE-----

Debian Security Advisory 5812-2

Red Hat Security Advisory 2024-9738-03 - An update for squid is now available for Red Hat Enterprise Linux 7 Extended Lifecycle Support. Issues addressed include a denial of service vulnerability.

    The following advisory data is extracted from:https://security.access.redhat.com/data/csaf/v2/advisories/2024/rhsa-2024_9738.jsonRed Hat officially shut down their mailing list notifications October 10, 2023.  Due to this, Packet Storm has recreated the below data as a reference point to raise awareness.  It must be noted that due to an inability to easily track revision updates without crawling Red Hat's archive, these advisories are single notifications and we strongly suggest that you visit the Red Hat provided links to ensure you have the latest information available if the subject matter listed pertains to your environment.- Packet Storm Staff====================================================================Red Hat Security AdvisorySynopsis:           Important: squid security updateAdvisory ID:        RHSA-2024:9738-03Product:            Red Hat Enterprise LinuxAdvisory URL:       https://access.redhat.com/errata/RHSA-2024:9738Issue date:         2024-11-21Revision:           03CVE Names:          CVE-2024-45802====================================================================Summary: An update for squid is now available for Red Hat Enterprise Linux 7 Extended Lifecycle Support.Red Hat Product Security has rated this update as having a security impact of Important. A Common Vulnerability Scoring System (CVSS) base score, which gives a detailed severity rating, is available for each vulnerability from the CVE link(s) in the References section.Description:Squid is a high-performance proxy caching server for web clients, supporting FTP, Gopher, and HTTP data objects.Security Fix(es):* squid: Denial of Service processing ESI response content (CVE-2024-45802)For more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and other related information, refer to the CVE page(s) listed in the References section.Solution:https://access.redhat.com/articles/11258CVEs:CVE-2024-45802References:https://access.redhat.com/security/updates/classification/#importanthttps://bugzilla.redhat.com/show_bug.cgi?id=2322154

Red Hat Security Advisory 2024-9738-03

Red Hat Security Advisory 2024-9729-03 - An update for squid is now available for Red Hat Enterprise Linux 9.0 Update Services for SAP Solutions. Issues addressed include a denial of service vulnerability.

    The following advisory data is extracted from:https://security.access.redhat.com/data/csaf/v2/advisories/2024/rhsa-2024_9729.jsonRed Hat officially shut down their mailing list notifications October 10, 2023.  Due to this, Packet Storm has recreated the below data as a reference point to raise awareness.  It must be noted that due to an inability to easily track revision updates without crawling Red Hat's archive, these advisories are single notifications and we strongly suggest that you visit the Red Hat provided links to ensure you have the latest information available if the subject matter listed pertains to your environment.- Packet Storm Staff====================================================================Red Hat Security AdvisorySynopsis:           Important: squid security updateAdvisory ID:        RHSA-2024:9729-03Product:            Red Hat Enterprise LinuxAdvisory URL:       https://access.redhat.com/errata/RHSA-2024:9729Issue date:         2024-11-21Revision:           03CVE Names:          CVE-2024-45802====================================================================Summary: An update for squid is now available for Red Hat Enterprise Linux 9.0 Update Services for SAP Solutions.Red Hat Product Security has rated this update as having a security impact of Important. A Common Vulnerability Scoring System (CVSS) base score, which gives a detailed severity rating, is available for each vulnerability from the CVE link(s) in the References section.Description:Squid is a high-performance proxy caching server for web clients, supporting FTP, Gopher, and HTTP data objects.Security Fix(es):* squid: Denial of Service processing ESI response content (CVE-2024-45802)For more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and other related information, refer to the CVE page(s) listed in the References section.Solution:https://access.redhat.com/articles/11258CVEs:CVE-2024-45802References:https://access.redhat.com/security/updates/classification/#importanthttps://bugzilla.redhat.com/show_bug.cgi?id=2322154

Red Hat Security Advisory 2024-9729-03

Red Hat Security Advisory 2024-9690-03 - An update for tigervnc is now available for Red Hat Enterprise Linux 8.8 Extended Update Support. Issues addressed include buffer overflow and privilege escalation vulnerabilities.

    The following advisory data is extracted from:https://security.access.redhat.com/data/csaf/v2/advisories/2024/rhsa-2024_9690.jsonRed Hat officially shut down their mailing list notifications October 10, 2023.  Due to this, Packet Storm has recreated the below data as a reference point to raise awareness.  It must be noted that due to an inability to easily track revision updates without crawling Red Hat's archive, these advisories are single notifications and we strongly suggest that you visit the Red Hat provided links to ensure you have the latest information available if the subject matter listed pertains to your environment.- Packet Storm Staff====================================================================Red Hat Security AdvisorySynopsis:           Important: tigervnc security updateAdvisory ID:        RHSA-2024:9690-03Product:            Red Hat Enterprise LinuxAdvisory URL:       https://access.redhat.com/errata/RHSA-2024:9690Issue date:         2024-11-21Revision:           03CVE Names:          CVE-2024-9632====================================================================Summary: An update for tigervnc is now available for Red Hat Enterprise Linux 8.8 Extended Update Support.Red Hat Product Security has rated this update as having a security impact of Important. A Common Vulnerability Scoring System (CVSS) base score, which gives a detailed severity rating, is available for each vulnerability from the CVE link(s) in the References section.Description:Virtual Network Computing (VNC) is a remote display system which allows users to view a computing desktop environment not only on the machine where it is running, but from anywhere on the Internet and from a wide variety of machine architectures. TigerVNC is a suite of VNC servers and clients.Security Fix(es):* xorg-x11-server: tigervnc: heap-based buffer overflow privilege escalation vulnerability (CVE-2024-9632)For more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and other related information, refer to the CVE page(s) listed in the References section.Solution:https://access.redhat.com/articles/11258CVEs:CVE-2024-9632References:https://access.redhat.com/security/updates/classification/#importanthttps://bugzilla.redhat.com/show_bug.cgi?id=2317233

Red Hat Security Advisory 2024-9690-03

Red Hat Security Advisory 2024-9689-03 - An update for binutils is now available for Red Hat Enterprise Linux 8. Issues addressed include a buffer overflow vulnerability.

    The following advisory data is extracted from:https://security.access.redhat.com/data/csaf/v2/advisories/2024/rhsa-2024_9689.jsonRed Hat officially shut down their mailing list notifications October 10, 2023.  Due to this, Packet Storm has recreated the below data as a reference point to raise awareness.  It must be noted that due to an inability to easily track revision updates without crawling Red Hat's archive, these advisories are single notifications and we strongly suggest that you visit the Red Hat provided links to ensure you have the latest information available if the subject matter listed pertains to your environment.- Packet Storm Staff====================================================================Red Hat Security AdvisorySynopsis:           Low: binutils security updateAdvisory ID:        RHSA-2024:9689-03Product:            Red Hat Enterprise LinuxAdvisory URL:       https://access.redhat.com/errata/RHSA-2024:9689Issue date:         2024-11-21Revision:           03CVE Names:          CVE-2018-12699====================================================================Summary: An update for binutils is now available for Red Hat Enterprise Linux 8.Red Hat Product Security has rated this update as having a security impact of Low. A Common Vulnerability Scoring System (CVSS) base score, which gives a detailed severity rating, is available for each vulnerability from the CVE link(s) in the References section.Description:The binutils packages provide a collection of binary utilities for the manipulation of object code in various object file formats. It includes the ar, as, gprof, ld, nm, objcopy, objdump, ranlib, readelf, size, strings, strip, and addr2line utilities.Security Fix(es):* binutils: heap-based buffer overflow in finish_stab in stabs.c (CVE-2018-12699)For more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and other related information, refer to the CVE page(s) listed in the References section.Solution:https://access.redhat.com/articles/11258CVEs:CVE-2018-12699References:https://access.redhat.com/security/updates/classification/#lowhttps://bugzilla.redhat.com/show_bug.cgi?id=1595427

Red Hat Security Advisory 2024-9689-03

Red Hat Security Advisory 2024-9679-03 - An update for webkit2gtk3 is now available for Red Hat Enterprise Linux 8.4 Advanced Mission Critical Update Support, Red Hat Enterprise Linux 8.4 Telecommunications Update Service, and Red Hat Enterprise Linux 8.4 Update Services for SAP Solutions. Issues addressed include code execution, out of bounds read, and use-after-free vulnerabilities.

The following advisory data is extracted from:

https://security.access.redhat.com/data/csaf/v2/advisories/2024/rhsa-2024_9679.json

Red Hat officially shut down their mailing list notifications October 10, 2023.  Due to this, Packet Storm has recreated the below data as a reference point to raise awareness.  It must be noted that due to an inability to easily track revision updates without crawling Red Hat's archive, these advisories are single notifications and we strongly suggest that you visit the Red Hat provided links to ensure you have the latest information available if the subject matter listed pertains to your environment.

- Packet Storm Staff

====================================================================  
Red Hat Security Advisory

Synopsis:           Important: webkit2gtk3 security update  
Advisory ID:        RHSA-2024:9679-03  
Product:            Red Hat Enterprise Linux  
Advisory URL:       https://access.redhat.com/errata/RHSA-2024:9679  
Issue date:         2024-11-21  
Revision:           03  
CVE Names:          CVE-2022-32885  
====================================================================

Summary: 

An update for webkit2gtk3 is now available for Red Hat Enterprise Linux 8.4 Advanced Mission Critical Update Support, Red Hat Enterprise Linux 8.4 Telecommunications Update Service, and Red Hat Enterprise Linux 8.4 Update Services for SAP Solutions.

Red Hat Product Security has rated this update as having a security impact of Important. A Common Vulnerability Scoring System (CVSS) base score, which gives a detailed severity rating, is available for each vulnerability from the CVE link(s) in the References section.

Description:

WebKitGTK is the port of the portable web rendering engine WebKit to the GTK platform.

Security Fix(es):

* webkitgtk: Memory corruption issue when processing web content (CVE-2022-32885)

* webkitgtk: arbitrary javascript code execution (CVE-2023-40397)

* webkitgtk: Arbitrary Remote Code Execution (CVE-2023-42917)

* webkitgtk: type confusion may lead to arbitrary code execution (CVE-2024-23222)

* webkitgtk: Processing web content may lead to arbitrary code execution (CVE-2023-42852)

* chromium-browser: Use after free in ANGLE (CVE-2024-4558)

* webkitgtk: webkit2gtk: Use after free may lead to Remote Code Execution (CVE-2024-40776)

* webkitgtk: webkit2gtk: Processing maliciously crafted web content may lead to an unexpected process crash (CVE-2024-40789)

* webkitgtk: webkit2gtk: Out-of-bounds read was addressed with improved bounds checking (CVE-2024-40780)

* webkitgtk: webkit2gtk: Out-of-bounds read was addressed with improved bounds checking (CVE-2024-40779)

* webkitgtk: webkit2gtk: Use-after-free was addressed with improved memory management (CVE-2024-40782)

* webkitgtk: Processing web content may lead to arbitrary code execution (CVE-2024-27808)

* webkitgtk: Processing web content may lead to arbitrary code execution (CVE-2024-27820)

* webkitgtk: Processing maliciously crafted web content may lead to arbitrary code execution (CVE-2024-27833)

* webkitgtk: Processing maliciously crafted web content may lead to arbitrary code execution (CVE-2024-27851)

* webkitgtk: webkit2gtk: Processing maliciously crafted web content may lead to an unexpected process crash (CVE-2024-44185)

* webkitgtk: webkit2gtk: Processing maliciously crafted web content may lead to an unexpected process crash (CVE-2024-44244)

For more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and other related information, refer to the CVE page(s) listed in the References section.

Solution:

https://access.redhat.com/articles/11258

CVEs:

CVE-2022-32885

References:

https://access.redhat.com/security/updates/classification/#important  
https://bugzilla.redhat.com/show_bug.cgi?id=2236842  
https://bugzilla.redhat.com/show_bug.cgi?id=2238945  
https://bugzilla.redhat.com/show_bug.cgi?id=2253058  
https://bugzilla.redhat.com/show_bug.cgi?id=2259893  
https://bugzilla.redhat.com/show_bug.cgi?id=2271456  
https://bugzilla.redhat.com/show_bug.cgi?id=2279689  
https://bugzilla.redhat.com/show_bug.cgi?id=2301841  
https://bugzilla.redhat.com/show_bug.cgi?id=2302067  
https://bugzilla.redhat.com/show_bug.cgi?id=2302069  
https://bugzilla.redhat.com/show_bug.cgi?id=2302070  
https://bugzilla.redhat.com/show_bug.cgi?id=2302071  
https://bugzilla.redhat.com/show_bug.cgi?id=2314697  
https://bugzilla.redhat.com/show_bug.cgi?id=2314698  
https://bugzilla.redhat.com/show_bug.cgi?id=2314700  
https://bugzilla.redhat.com/show_bug.cgi?id=2314704  
https://bugzilla.redhat.com/show_bug.cgi?id=2323263  
https://bugzilla.redhat.com/show_bug.cgi?id=2323278

Red Hat Security Advisory 2024-9679-03

Red Hat Security Advisory 2024-9678-03 - An update for squid is now available for Red Hat Enterprise Linux 9.4 Extended Update Support. Issues addressed include a denial of service vulnerability.

    The following advisory data is extracted from:https://security.access.redhat.com/data/csaf/v2/advisories/2024/rhsa-2024_9678.jsonRed Hat officially shut down their mailing list notifications October 10, 2023.  Due to this, Packet Storm has recreated the below data as a reference point to raise awareness.  It must be noted that due to an inability to easily track revision updates without crawling Red Hat's archive, these advisories are single notifications and we strongly suggest that you visit the Red Hat provided links to ensure you have the latest information available if the subject matter listed pertains to your environment.- Packet Storm Staff====================================================================Red Hat Security AdvisorySynopsis:           Important: squid security updateAdvisory ID:        RHSA-2024:9678-03Product:            Red Hat Enterprise LinuxAdvisory URL:       https://access.redhat.com/errata/RHSA-2024:9678Issue date:         2024-11-21Revision:           03CVE Names:          CVE-2024-45802====================================================================Summary: An update for squid is now available for Red Hat Enterprise Linux 9.4 Extended Update Support.Red Hat Product Security has rated this update as having a security impact of Important. A Common Vulnerability Scoring System (CVSS) base score, which gives a detailed severity rating, is available for each vulnerability from the CVE link(s) in the References section.Description:Squid is a high-performance proxy caching server for web clients, supporting FTP, Gopher, and HTTP data objects.Security Fix(es):* squid: Denial of Service processing ESI response content (CVE-2024-45802)For more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and other related information, refer to the CVE page(s) listed in the References section.Solution:https://access.redhat.com/articles/11258CVEs:CVE-2024-45802References:https://access.redhat.com/security/updates/classification/#importanthttps://bugzilla.redhat.com/show_bug.cgi?id=2322154

Red Hat Security Advisory 2024-9678-03

In a sign of the times, a backdoor malware whose ancestors date back to 2005 has morphed to target Linux systems.

Source: Imagebroker via Alamy Stock Photo

Two well-documented Chinese backdoors have recently been modified to operate on Linux systems.

The advanced persistent threat (APT) "Gelsemium" is a decade old now, and the new malware tied to the group, Wolfsbane and Firewood, can trace their lineage back to 2005. Throughout its history, Gelsemium has focused on information gathering from Windows systems. Now, it has adjusted its tooling to operate just as effectively in Linux environments.

This, experts say, is merely the latest manifestation of a long-brewing trend.

"The Linux malware landscape is certainly accelerating," says Jason Soroko, senior fellow at Sectigo. "The increase does make sense, as organizations have heavily adopted Linux for their back office server needs, both on premises and in the cloud. Adversaries are developing cross-platform malware to maximize their reach."

**The Wolfsbane & Firewood Backdoors**

The first public sample of the first new backdoor, dubbed Wolsbane, was uploaded to VirusTotal on March 6, 2023, from Taiwan, with later uploads coming from the Philippines and Singapore (historically, Gelsemium has targeted entities in the Middle East and East Asia).

Contextual evidence suggests that the malware's authors have been exploiting vulnerabilities in Java Web applications to access public-facing Apache Tomcat servers. And a deeper look inside reveals unmistakable overlaps with Gelsevirine, a Windows backdoor known to be used by Gelsemium. In essence, the Wolfsbane malware was a Linux port of Gelsevirine, featuring a modified Beurk Experimental Unix RootKit to hide its various malicious activities.

Alongside Wolfsbane, though not definitively attributable to Gelsemium, was a second Linux-ported backdoor, Firewood. An addition to its varied and typical backdoor capabilities, it possesses a kernel-level rootkit. 

Most interestingly, Firewood appears to be the latest evolution of "Project Wood," a phylum of a backdoor that traces back generations to a program first compiled in January 2005. The latest manifestation of Project Wood before Firewood, NSPX30, was reported earlier this year.

**What Explains the Surge in Linux Cyber Threats?**

Cyber threats rise across the board every year, but the particular rise in Linux-based threats stands out. 

Since at least 2020, vendors have tracked double- and triple-digit year-over-year increases in Linux attacks. In its annual "Global Threat Report," Elastic Security has regularly found that the Linux threat landscape vastly outpaces that of macOS, more closely resembling Windows in terms of sheer volume of attacks. In 2023, for example, it found that 54% of endpoint attacks affected Linux-based devices, compared with just 39% for Windows.

Over the past 12 months, around 32% of malware infections have targeted Linux, according to Jake King, Elastic's head of threat and security intelligence. "While steadily increasing, we are seeing greater volumes of attacks and, in some cases, with greater levels of sophistication. The XZ/Liblzma backdoor discovered by researchers earlier this year shows the desire of adversaries to compromise Linux hosts, likely for a variety of reasons, growing in sophistication to supply chain compromise," he says.

The rising threats to Linux may be attributable to an increasing adoption of Linux in enterprise environments, as Soroko alluded to, or the generally improving state of Windows security — the explanation ESET went with in its blog post — or an explanation even simpler.

"One of the reasons for growing observations can always be targeted to adversarial focus changing, but it is also likely that security tooling and telemetry for Linux hosts are improving at a pace whereby attacks are identified earlier, with a greater level of context," King suggests. For example, "A growing trend for threat observations this year was Impaired Defenses for Linux, showing that adversaries are specifically looking to bypass security tools native to Linux or disable third-party security tools. This is important, as it shows we're exposing many attacks that would have previously gone undetected years ago."

**About the Author**

Nate Nelson is a freelance writer based in New York City. Formerly a reporter at Threatpost, he contributes to a number of cybersecurity blogs and podcasts. He writes "Malicious Life" -- an award-winning Top 20 tech podcast on Apple and Spotify -- and hosts every other episode, featuring interviews with leading voices in security. He also co-hosts "The Industrial Security Podcast," the most popular show in its field.

Tag

#linux