In the Linux kernel, the following vulnerability has been resolved: mm: memcontrol: slab: fix obtain a reference to a freeing memcg Patch series "Use obj_cgroup APIs to charge kmem pages", v5. Since Roman's series "The new cgroup slab memory controller" applied. All slab objects are charged with the new APIs of obj_cgroup. The new APIs introduce a struct obj_cgroup to charge slab objects. It prevents long-living objects from pinning the original memory cgroup in the memory. But there are still some corner objects (e.g. allocations larger than order-1 page on SLUB) which are not charged with the new APIs. Those objects (include the pages which are allocated from buddy allocator directly) are charged as kmem pages which still hold a reference to the memory cgroup. E.g. We know that the kernel stack is charged as kmem pages because the size of the kernel stack can be greater than 2 pages (e.g. 16KB on x86_64 or arm64). If we create a thread (suppose the thread stack is charged to memory cgroup A) and then move it from memory cgroup A to memory cgroup B. Because the kernel stack of the thread hold a reference to the memory cgroup A. The thread can pin the memory cgroup A in the memory even if we remove the cgroup A. If we want to see this scenario by using the following script. We can see that the system has added 500 dying cgroups (This is not a real world issue, just a script to show that the large kmallocs are charged as kmem pages which can pin the memory cgroup in the memory). #!/bin/bash cat /proc/cgroups | grep memory cd /sys/fs/cgroup/memory echo 1 > memory.move_charge_at_immigrate for i in range{1..500} do mkdir kmem_test echo $$ > kmem_test/cgroup.procs sleep 3600 & echo $$ > cgroup.procs echo `cat kmem_test/cgroup.procs` > cgroup.procs rmdir kmem_test done cat /proc/cgroups | grep memory This patchset aims to make those kmem pages to drop the reference to memory cgroup by using the APIs of obj_cgroup. Finally, we can see that the number of the dying cgroups will not increase if we run the above test script. This patch (of 7): The rcu_read_lock/unlock only can guarantee that the memcg will not be freed, but it cannot guarantee the success of css_get (which is in the refill_stock when cached memcg changed) to memcg. rcu_read_lock() memcg = obj_cgroup_memcg(old) __memcg_kmem_uncharge(memcg) refill_stock(memcg) if (stock->cached != memcg) // css_get can change the ref counter from 0 back to 1. css_get(&memcg->css) rcu_read_unlock() This fix is very like the commit: eefbfa7fd678 ("mm: memcg/slab: fix use after free in obj_cgroup_charge") Fix this by holding a reference to the memcg which is passed to the __memcg_kmem_uncharge() before calling __memcg_kmem_uncharge().

The Unity Linux 20 host has a package installed that is affected by a vulnerability as referenced in the UTSA-2025-989580 advisory.

    In the Linux kernel, the following vulnerability has been resolved:

    mm: memcontrol: slab: fix obtain a reference to a freeing memcg

    Patch series Use obj_cgroup APIs to charge kmem pages, v5.

    Since Roman's series The new cgroup slab memory controller applied.
    All slab objects are charged with the new APIs of obj_cgroup.  The new     APIs introduce a struct obj_cgroup to charge slab objects.  It prevents     long-living objects from pinning the original memory cgroup in the     memory.  But there are still some corner objects (e.g.  allocations     larger than order-1 page on SLUB) which are not charged with the new     APIs.  Those objects (include the pages which are allocated from buddy     allocator directly) are charged as kmem pages which still hold a     reference to the memory cgroup.

    E.g.  We know that the kernel stack is charged as kmem pages because the     size of the kernel stack can be greater than 2 pages (e.g.  16KB on     x86_64 or arm64).  If we create a thread (suppose the thread stack is     charged to memory cgroup A) and then move it from memory cgroup A to     memory cgroup B.  Because the kernel stack of the thread hold a     reference to the memory cgroup A.  The thread can pin the memory cgroup     A in the memory even if we remove the cgroup A.  If we want to see this     scenario by using the following script.  We can see that the system has     added 500 dying cgroups (This is not a real world issue, just a script     to show that the large kmallocs are charged as kmem pages which can pin     the memory cgroup in the memory).

            #!/bin/bash

            cat /proc/cgroups | grep memory

            cd /sys/fs/cgroup/memory             echo 1 > memory.move_charge_at_immigrate

            for i in range{1..500}             do                     mkdir kmem_test                     echo $$ > kmem_test/cgroup.procs                     sleep 3600 &                     echo $$ > cgroup.procs                     echo `cat kmem_test/cgroup.procs` > cgroup.procs                     rmdir kmem_test             done

            cat /proc/cgroups | grep memory

    This patchset aims to make those kmem pages to drop the reference to     memory cgroup by using the APIs of obj_cgroup.  Finally, we can see that     the number of the dying cgroups will not increase if we run the above test     script.

    This patch (of 7):

    The rcu_read_lock/unlock only can guarantee that the memcg will not be     freed, but it cannot guarantee the success of css_get (which is in the     refill_stock when cached memcg changed) to memcg.

      rcu_read_lock()       memcg = obj_cgroup_memcg(old)
      __memcg_kmem_uncharge(memcg)           refill_stock(memcg)               if (stock->cached != memcg)                   // css_get can change the ref counter from 0 back to 1.
                  css_get(&memcg->css)       rcu_read_unlock()

    This fix is very like the commit:

      eefbfa7fd678 (mm: memcg/slab: fix use after free in obj_cgroup_charge)

    Fix this by holding a reference to the memcg which is passed to the
    __memcg_kmem_uncharge() before calling __memcg_kmem_uncharge().

Tenable has extracted the preceding description block directly from the Unity Linux security advisory.

Note that Nessus has not tested for this issue but has instead relied only on the application's self-reported version number.

The Unity Linux 20 host has a package installed that is affected by a vulnerability as referenced in the UTSA-2025-987124 advisory.

    In the Linux kernel, the following vulnerability has been resolved:

    mm: memcontrol: slab: fix obtain a reference to a freeing memcg

    Patch series Use obj_cgroup APIs to charge kmem pages, v5.

    Since Roman's series The new cgroup slab memory controller applied.
    All slab objects are charged with the new APIs of obj_cgroup.  The new     APIs introduce a struct obj_cgroup to charge slab objects.  It prevents     long-living objects from pinning the original memory cgroup in the     memory.  But there are still some corner objects (e.g.  allocations     larger than order-1 page on SLUB) which are not charged with the new     APIs.  Those objects (include the pages which are allocated from buddy     allocator directly) are charged as kmem pages which still hold a     reference to the memory cgroup.

    E.g.  We know that the kernel stack is charged as kmem pages because the     size of the kernel stack can be greater than 2 pages (e.g.  16KB on     x86_64 or arm64).  If we create a thread (suppose the thread stack is     charged to memory cgroup A) and then move it from memory cgroup A to     memory cgroup B.  Because the kernel stack of the thread hold a     reference to the memory cgroup A.  The thread can pin the memory cgroup     A in the memory even if we remove the cgroup A.  If we want to see this     scenario by using the following script.  We can see that the system has     added 500 dying cgroups (This is not a real world issue, just a script     to show that the large kmallocs are charged as kmem pages which can pin     the memory cgroup in the memory).

            #!/bin/bash

            cat /proc/cgroups | grep memory

            cd /sys/fs/cgroup/memory             echo 1 > memory.move_charge_at_immigrate

            for i in range{1..500}             do                     mkdir kmem_test                     echo $$ > kmem_test/cgroup.procs                     sleep 3600 &                     echo $$ > cgroup.procs                     echo `cat kmem_test/cgroup.procs` > cgroup.procs                     rmdir kmem_test             done

            cat /proc/cgroups | grep memory

    This patchset aims to make those kmem pages to drop the reference to     memory cgroup by using the APIs of obj_cgroup.  Finally, we can see that     the number of the dying cgroups will not increase if we run the above test     script.

    This patch (of 7):

    The rcu_read_lock/unlock only can guarantee that the memcg will not be     freed, but it cannot guarantee the success of css_get (which is in the     refill_stock when cached memcg changed) to memcg.

      rcu_read_lock()       memcg = obj_cgroup_memcg(old)
      __memcg_kmem_uncharge(memcg)           refill_stock(memcg)               if (stock->cached != memcg)                   // css_get can change the ref counter from 0 back to 1.
                  css_get(&memcg->css)       rcu_read_unlock()

    This fix is very like the commit:

      eefbfa7fd678 (mm: memcg/slab: fix use after free in obj_cgroup_charge)

    Fix this by holding a reference to the memcg which is passed to the
    __memcg_kmem_uncharge() before calling __memcg_kmem_uncharge().

Tenable has extracted the preceding description block directly from the Unity Linux security advisory.

Note that Nessus has not tested for this issue but has instead relied only on the application's self-reported version number.

The Linux/Unix host has one or more packages installed that are impacted by a vulnerability without a vendor supplied patch available.

  - In the Linux kernel, the following vulnerability has been resolved: mm: memcontrol: slab: fix obtain a     reference to a freeing memcg Patch series Use obj_cgroup APIs to charge kmem pages, v5. Since Roman's     series The new cgroup slab memory controller applied. All slab objects are charged with the new APIs of     obj_cgroup. The new APIs introduce a struct obj_cgroup to charge slab objects. It prevents long-living     objects from pinning the original memory cgroup in the memory. But there are still some corner objects     (e.g. allocations larger than order-1 page on SLUB) which are not charged with the new APIs. Those objects     (include the pages which are allocated from buddy allocator directly) are charged as kmem pages which     still hold a reference to the memory cgroup. E.g. We know that the kernel stack is charged as kmem pages     because the size of the kernel stack can be greater than 2 pages (e.g. 16KB on x86_64 or arm64). If we     create a thread (suppose the thread stack is charged to memory cgroup A) and then move it from memory     cgroup A to memory cgroup B. Because the kernel stack of the thread hold a reference to the memory cgroup     A. The thread can pin the memory cgroup A in the memory even if we remove the cgroup A. If we want to see     this scenario by using the following script. We can see that the system has added 500 dying cgroups (This     is not a real world issue, just a script to show that the large kmallocs are charged as kmem pages which     can pin the memory cgroup in the memory). #!/bin/bash cat /proc/cgroups | grep memory cd     /sys/fs/cgroup/memory echo 1 > memory.move_charge_at_immigrate for i in range{1..500} do mkdir kmem_test     echo $$ > kmem_test/cgroup.procs sleep 3600 & echo $$ > cgroup.procs echo `cat kmem_test/cgroup.procs` >     cgroup.procs rmdir kmem_test done cat /proc/cgroups | grep memory This patchset aims to make those kmem     pages to drop the reference to memory cgroup by using the APIs of obj_cgroup. Finally, we can see that the     number of the dying cgroups will not increase if we run the above test script. This patch (of 7): The     rcu_read_lock/unlock only can guarantee that the memcg will not be freed, but it cannot guarantee the     success of css_get (which is in the refill_stock when cached memcg changed) to memcg. rcu_read_lock()     memcg = obj_cgroup_memcg(old) __memcg_kmem_uncharge(memcg) refill_stock(memcg) if (stock->cached != memcg)     // css_get can change the ref counter from 0 back to 1. css_get(&memcg->css) rcu_read_unlock() This fix is     very like the commit: eefbfa7fd678 (mm: memcg/slab: fix use after free in obj_cgroup_charge) Fix this by     holding a reference to the memcg which is passed to the __memcg_kmem_uncharge() before calling
    __memcg_kmem_uncharge(). (CVE-2021-47011)

Note that Nessus relies on the presence of the package as reported by the vendor.

The remote Redhat Enterprise Linux 8 host has packages installed that are affected by multiple vulnerabilities as referenced in the RHSA-2021:4356 advisory.

    The kernel packages contain the Linux kernel, the core of any Linux operating system.

    Security Fix(es):
    * kernel: out-of-bounds reads in pinctrl subsystem (CVE-2020-0427)
    * kernel: Improper input validation in some Intel(R) Ethernet E810 Adapter drivers (CVE-2020-24502)
    * kernel: Insufficient access control in some Intel(R) Ethernet E810 Adapter drivers (CVE-2020-24503)
    * kernel: Uncontrolled resource consumption in some Intel(R) Ethernet E810 Adapter drivers     (CVE-2020-24504)
    * kernel: Fragmentation cache not cleared on reconnection (CVE-2020-24586)
    * kernel: Reassembling fragments encrypted under different keys (CVE-2020-24587)
    * kernel: wifi frame payload being parsed incorrectly as an L2 frame (CVE-2020-24588)
    * kernel: Forwarding EAPOL from unauthenticated wifi client (CVE-2020-26139)
    * kernel: accepting plaintext data frames in protected networks (CVE-2020-26140)
    * kernel: not verifying TKIP MIC of fragmented frames (CVE-2020-26141)
    * kernel: accepting fragmented plaintext frames in protected networks (CVE-2020-26143)
    * kernel: accepting unencrypted A-MSDU frames that start with RFC1042 header (CVE-2020-26144)
    * kernel: accepting plaintext broadcast fragments as full frames (CVE-2020-26145)
    * kernel: powerpc: RTAS calls can be used to compromise kernel integrity (CVE-2020-27777)
    * kernel: locking inconsistency in tty_io.c and tty_jobctrl.c can lead to a read-after-free     (CVE-2020-29660)
    * kernel: buffer overflow in mwifiex_cmd_802_11_ad_hoc_start function via a long SSID value     (CVE-2020-36158)
    * kernel: slab out-of-bounds read in hci_extended_inquiry_result_evt()  (CVE-2020-36386)
    * kernel: Improper access control in BlueZ may allow information disclosure vulnerability. (CVE-2021-0129)
    * kernel: Use-after-free in ndb_queue_rq() in drivers/block/nbd.c (CVE-2021-3348)
    * kernel: Linux kernel eBPF RINGBUF map oversized allocation (CVE-2021-3489)
    * kernel: double free in bluetooth subsystem when the HCI device initialization fails (CVE-2021-3564)
    * kernel: use-after-free in function hci_sock_bound_ioctl() (CVE-2021-3573)
    * kernel: eBPF 32-bit source register truncation on div/mod (CVE-2021-3600)
    * kernel: DoS in rb_per_cpu_empty() (CVE-2021-3679)
    * kernel: Mounting overlayfs inside an unprivileged user namespace can reveal files (CVE-2021-3732)
    * kernel: heap overflow in __cgroup_bpf_run_filter_getsockopt() (CVE-2021-20194)
    * kernel: Race condition in sctp_destroy_sock list_del (CVE-2021-23133)
    * kernel: fuse: stall on CPU can occur because a retry loop continually finds the same bad inode     (CVE-2021-28950)
    * kernel: System crash in intel_pmu_drain_pebs_nhm in arch/x86/events/intel/ds.c (CVE-2021-28971)
    * kernel: protection can be bypassed to leak content of kernel memory (CVE-2021-29155)
    * kernel: improper input validation in tipc_nl_retrieve_key function in net/tipc/node.c (CVE-2021-29646)
    * kernel: lack a full memory barrier may lead to DoS (CVE-2021-29650)
    * kernel: local escalation of privileges in handling of eBPF programs (CVE-2021-31440)
    * kernel: protection of stack pointer against speculative pointer arithmetic can be bypassed to leak     content of kernel memory (CVE-2021-31829)
    * kernel: out-of-bounds reads and writes due to enforcing incorrect limits for pointer arithmetic     operations by BPF verifier (CVE-2021-33200)
    * kernel: reassembling encrypted fragments with non-consecutive packet numbers (CVE-2020-26146)
    * kernel: reassembling mixed encrypted/plaintext fragments (CVE-2020-26147)
    * kernel: the copy-on-write implementation can grant unintended write access because of a race condition     in a THP mapcount check (CVE-2020-29368)
    * kernel: flowtable list del corruption with kernel BUG at lib/list_debug.c:50 (CVE-2021-3635)
    * kernel: NULL pointer dereference in llsec_key_alloc() in net/mac802154/llsec.c (CVE-2021-3659)
    * kernel: setsockopt System Call Untrusted Pointer Dereference Information Disclosure (CVE-2021-20239)
    * kernel: out of bounds array access in drivers/md/dm-ioctl.c (CVE-2021-31916)

Tenable has extracted the preceding description block directly from the Red Hat Enterprise Linux security advisory.

Note that Nessus has not tested for these issues but has instead relied only on the application's self-reported version number.

ID	Name	Product	Family	Severity
272962	Unity Linux 20.1070a Security Update: kernel (UTSA-2025-989580)	Nessus	Unity Linux Local Security Checks	medium
269078	Unity Linux 20.1070e Security Update: kernel (UTSA-2025-987124)	Nessus	Unity Linux Local Security Checks	medium
230211	Linux Distros Unpatched Vulnerability : CVE-2021-47011	Nessus	Misc.	medium
160459	Amazon Linux 2 : kernel, --advisory ALAS2KERNEL-5.10-2022-002 (ALASKERNEL-5.10-2022-002)	Nessus	Amazon Linux Local Security Checks	high
155219	RHEL 8 : kernel (RHSA-2021:4356)	Nessus	Red Hat Local Security Checks	high

Detections

Analytics

CVE-2021-47011

medium

Tenable Plugins

medium

medium

medium

high

high