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

Linux/Unix ホストには、ベンダーが提供するパッチが利用できない脆弱性の影響を受ける複数のパッケージがインストールされています。

  - Linux カーネルにおいて、以下の脆弱性は解決されました： 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)

Nessus は、ベンダーによって報告されたパッケージの存在に依存していることに注意してください。

Linux/Unix 主机中安装的一个或多个程序包受到一个漏洞影响，而供应商没有提供补丁程序。

  - 在 Linux 内核中，已解决以下漏洞： 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)

请注意，Nessus 依赖供应商报告的程序包是否存在进行判断。

Linux/Unix 主機上安裝了一個或多個受到弱點影響的套件，且供應商未提供可用的修補程式。

  - 在 Linux 核心中，已解決下列弱點： 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)

請注意，Nessus 依賴供應商報告的套件存在。

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

リモートRedhat Enterprise Linux 8ホストに、RHSA-2021:4356アドバイザリに記載されている複数の脆弱性の影響を受けるパッケージがインストールされています。

  - kernel: Intel グラフィックスカードの情報漏洩。(CVE-2019-14615)

  - kernel: pinctrl サブシステム内の領域外読み取り。(CVE-2020-0427)

  - kernel: 一部の Intel(R) Ethernet E810 Adapter ドライバーにおける不適切な入力検証 (CVE-2020-24502)

  - kernel: 一部の Intel(R) Ethernet E810 Adapter ドライバーにおける不十分なアクセス制御 (CVE-2020-24503)

  - kernel: 一部の Intel(R) Ethernet E810 Adapter ドライバーにおける制御されていないリソース消費 (CVE-2020-24504)

  - kernel: フラグメントキャッシュが再接続時にクリアされない (CVE-2020-24586)

  - kernel: 異なる鍵で暗号化されたフラグメントの再アセンブリ (CVE-2020-24587)

  - kernel: L2 フレームとして不適切に解析されている wifi フレームペイロード (CVE-2020-24588)

  - kernel: 認証されていない wifi クライアントからの EAPOL の転送 (CVE-2020-26139)

  - kernel: 保護されたネットワークにおける平文データフレームの受け入れ (CVE-2020-26140)

  - kernel: フラグメント化されたフレームの TKIP MIC を検証しない (CVE-2020-26141)

  - kernel: 保護されたネットワークにおけるフラグメント化された平文フレームの受け入れ (CVE-2020-26143)

  - kernel: RFC1042 ヘッダーで始まる暗号化されていない A-MSDU フレームの受け入れ (CVE-2020-26144)

  - kernel: 平文ブロードキャストフラグメントをフルフレームとして受け入れ (CVE-2020-26145)

  - kernel: 非連続パケット番号の暗号化されたフラグメントの再アセンブリ (CVE-2020-26146)

  - kernel: 暗号化された/平文フラグメントの混合再アセンブリ (CVE-2020-26147)

  - kernel: RTAS 呼び出しがカーネルの整合性を侵害するのに使用される可能性があります (CVE-2020-27777)

  - kernel: コピーオンライト実装は、THP mapcount チェックの競合状態が原因で、意図しない書き込みアクセスを許可する可能性があります。(CVE-2020-29368)

  - kernel: drivers/tty/tty_io.c および drivers/tty/tty_jobctrl.c の不一致のロックにより、メモリ解放後読み取りが発生します (CVE-2020-29660)

  - kernel: 長い SSID 値を介した drivers/net/wireless/marvell/mwifiex/join.c の mwifiex_cmd_802_11_ad_hoc_start 関数におけるバッファオーバーフロー (CVE-2020-36158)

  - kernel: virt/kvm/kvm_main.c の kvm_io_bus_unregister_dev 関数における kmalloc 失敗時のメモリリーク (CVE-2020-36312)

  - kernel: net/bluetooth/hci_event.c の hci_extended_inquiry_result_evt() のスラブ領域外読み取り (CVE-2020-36386)

  - kernel: BlueZ における不適切なアクセス制御により、情報漏洩の脆弱性が発生する可能性があります。(CVE-2021-0129)

  - kernel: drivers/block/nbd.c の ndb_queue_rq() におけるメモリ解放後使用 (Use After Free) (CVE-2021-3348)

  - kernel: Linux カーネル eBPF RINGBUF マップの過大な割り当て (CVE-2021-3489)

  - kernel: HCI デバイスの初期化が失敗する場合の bluetooth サブシステムにおける二重解放 (CVE-2021-3564)

  - kernel: 関数 hci_sock_bound_ioctl() におけるメモリ解放後使用 (Use After Free) (CVE-2021-3573)

  - kernel: div/mod の eBPF 32 ビットソースレジスターの切り捨て (CVE-2021-3600)

  - kernel: lib/list_debug.c:50 のカーネルバグのあるフローテーブルリスト del 破損 (CVE-2021-3635)

  - kernel: net/mac802154/llsec.c の llsec_key_alloc() における NULL ポインターデリファレンス (CVE-2021-3659)

  - kernel: rb_per_cpu_empty() の Dos (CVE-2021-3679)

  - kernel: overlayfs: 権限のないユーザー名前空間内に overlayfs をマウントすると、ファイルが漏洩する可能性があります (CVE-2021-3732)

  - kernel: __cgroup_bpf_run_filter_getsockopt() におけるヒープオーバーフロー (CVE-2021-20194)

  - kernel: setsockopt システムコールの信頼されていないポインターデリファレンスの情報漏洩 (CVE-2021-20239)

  - kernel: sctp_destroy_sock list_del における競合状態 (CVE-2021-23133)

  - kernel: fuse: 再試行ループが同じ不適切な inode を継続的に検出するために、CPU でストールが発生する可能性があります (CVE-2021-28950)

  - kernel: arch/x86/events/intel/ds.c の intel_pmu_drain_pebs_nhm におけるシステムクラッシュ (CVE-2021-28971)

  - kernel: 投機的な領域外ロードに対するポインター演算操作シーケンスの保護が、バイパスされて、カーネルメモリの内容が漏洩する可能性があります (CVE-2021-29155)

  - kernel: net/tipc/node.c の tipc_nl_retrieve_key 関数の不適切な入力検証 (CVE-2021-29646)

  - kernel: net/netfilter/x_tables.c および include/linux/netfilter/x_tables.h の新しいテーブル値の割り当て時に完全なメモリバリアが欠如しているために DoS が引き起こされる可能性があります (CVE-2021-29650)

  - kernel: eBPF プログラムの処理におけるローカル権限昇格 (CVE-2021-31440)

  - kernel: 投機的なポインター演算に対するスタックポインターの保護が、バイパスされてカーネルメモリの内容が漏洩する可能性があります (CVE-2021-31829)

  - kernel: drivers/md/dm-ioctl.c における領域外配列アクセス (CVE-2021-31916)

  - kernel: net/ipv4/cipso_ipv4.c の cipso_v4_genopt のメモリ解放後使用 (Use After Free) (CVE-2021-33033)

  - kernel: Intel(R) Ethernet ixgbe ドライバーの入力検証が不適切なため、認証されたユーザーがローカルアクセスを介してサービス拒否を引き起こす可能性があります (CVE-2021-33098)

  - kernel: BPF 検証機能によるポインター演算操作の不適切な制限強化が原因である領域外読み取りおよび書き込み (CVE-2021-33200)

  - kernel: sysfs 読み取りにおけるバッファオーバーフローの可能性 (CVE-2022-20166)

Nessus はこれらの問題をテストしておらず、代わりにアプリケーションが自己報告するバージョン番号にのみ依存していることに注意してください。

远程 Redhat Enterprise Linux 8 主机上安装的程序包受到 RHSA-2021:4356 公告中提及的多个漏洞的影响。

  - kernel：Intel 显卡信息泄露。(CVE-2019-14615)

  - kernel：pinctrl 子系统中存在越界读取。(CVE-2020-0427)

  - kernel：某些 Intel (R) Ethernet E810 Adapter 驱动程序中存在输入验证不当问题 (CVE-2020-24502)

  - kernel：某些 Intel (R) Ethernet E810 Adapter 驱动程序中存在访问控制不充分问题 (CVE-2020-24503)

  - kernel：某些 Intel (R) Ethernet E810 Adapter 驱动程序中存在资源占用不受控制问题 (CVE-2020-24504)

  - kernel：重新连接时未清除碎片缓存 (CVE-2020-24586)

  - kernel：重组以不同密钥加密的片段 (CVE-2020-24587)

  - kernel：wifi 帧负载被错误解析为 L2 帧 (CVE-2020-24588)

  - kernel：从未认证的 wifi 客户端转发 EAPOL (CVE-2020-26139)

  - kernel：接受受保护网络中的明文数据帧 (CVE-2020-26140)

  - kernel：未验证碎片化帧的 TKIP MIC (CVE-2020-26141)

  - kernel：接受受保护网络中的碎片化明文帧 (CVE-2020-26143)

  - kernel：接受以 RFC1042 标头开头未加密的 A-MSDU 帧 (CVE-2020-26144)

  - kernel：接受纯文本广播片段作为完整帧 (CVE-2020-26145)

  - kernel：重组具有不连续数据包编号的加密片段 (CVE-2020-26146)

  - kernel：重组混合加密/明文片段 (CVE-2020-26147)

  - kernel：powerpc：RTAS 调用可用来破坏内核完整性 (CVE-2020-27777)

  - 内核：由于 THP 映射计数检查中的争用条件，写入时复制实现可授予非预期的写入访问权限 (CVE-2020-29368)

  - kernel：drivers/tty/tty_io.c 和 drivers/tty/tty_jobctrl.c 中的锁定不一致可导致释放后读取 (CVE-2020-29660)

  - kernel：通过长 SSID 值在 drivers/net/wireless/marvell/mwifiex/join.c 中的 mwifiex_cmd_802_11_ad_oc_start 函数中造成缓冲区溢出 (CVE-2020-36158)

  - kernel：virt/kvm/kvm_main.c 中的 kvm_io_bus_unregister_dev 函数会在 kmalloc 分配失败时造成内存泄漏 (CVE-2020-36312)

  - kernel：net/bluetooth/hci_event.c 中的 hci_extended_inquiry_result_evt() 存在 slab 越界读取问题 (CVE-2020-36386)

  - kernel：BlueZ 中的访问控制不当问题可能导致信息泄露漏洞。(CVE-2021-0129)

  - kernel：drivers/block/nbd.c 中的 ndb_queue_rq() 存在释放后使用问题 (CVE-2021-3348)

  - kernel：Linux 内核 eBPF RINGBUF 会映射超大分配 (CVE-2021-3489)

  - kernel：HCI 设备初始化失败时，蓝牙子系统中会发生双重释放 (CVE-2021-3564)

  - kernel：函数 hci_sock_bound_ioctl() 中存在释放后使用问题 (CVE-2021-3573)

  - kernel：div/mod 中存在 eBPF 32 位源寄存器截断 (CVE-2021-3600)

  - kernel：删除位于 lib/list_debug.c:50 的流表列表时出现内核错误，会导致列表损坏 (CVE-2021-3635)

  - kernel：net/mac802154/llsec.c 的 llsec_key_alloc() 中存在空指针取消引用 (CVE-2021-3659)

  - kernel：rb_per_cpu_empty() 中存在 DoS 问题 (CVE-2021-3679)

  - kernel：overlayfs：在非特权用户命名空间中挂载 overlayfs 可泄露文件 (CVE-2021-3732)

  - kernel：__cgroup_bpf_run_filter_getsockopt() 中存在堆溢出问题 (CVE-2021-20194)

  - kernel：setsockopt 系统调用不受信任的指针取消引用信息泄露 (CVE-2021-20239)

  - kernel：sctp_destroy_sock list_del 中存在争用条件 (CVE-2021-23133)

  - kernel：fuse：由于重试循环不断发现相同的不良 inode，导致 CPU 出现停止 (CVE-2021-28950)

  - kernel：arch/x86/events/intel/ds.c 中的 intel_pmu_drain_pebs_nhm 会导致系统崩溃 (CVE-2021-28971)

  - kernel：可绕过针对推测性越界加载的指针算术运算序列保护机制，以泄露内核内存内容 (CVE-2021-29155)

  - kernel：net/tipc/node.c 中的 tipc_nl_retrieve_key 函数存在输入验证不当问题 (CVE-2021-29646)

  - kernel：在 net/netfilter/x_tables.c 和 include/linux/netfilter/x_tables.h 中分配新的表值时缺少完整的内存屏障，可能导致 DoS (CVE-2021-29650)

  - kernel：处理 eBPF 程序时会发生本地权限升级问题 (CVE-2021-31440)

  - kernel：可绕过针对推测性指针算术的栈指针保护机制，以泄漏内核内存的内容 (CVE-2021-31829)

  - kernel：drivers/md/dm-ioctl.c 中存在越界数组访问问题 (CVE-2021-31916)

  - kernel：net/ipv4/cipso_ipv4.c 的 cipso_v4_genopt 中存在释放后使用问题 (CVE-2021-33033)

  - kernel：Intel(R) Ethernet ixgbe 驱动程序中存在输入验证不当漏洞，从而允许经过身份验证的用户通过本地访问 DoS (CVE-2021-33098)

  - kernel：由于 BPF 验证程序对指针算术运算执行错误限制，可导致越界读取和写入 (CVE-2021-33200)

  - kernel：sysfs 读取中可能存在缓冲区溢出 (CVE-2022-20166)

请注意，Nessus 尚未测试这些问题，而是只依据应用程序自我报告的版本号进行判断。

遠端 Redhat Enterprise Linux 8 主機上安裝的套件受到 RHSA-2021:4356 公告中提及的多個弱點影響。

  - 核心：Intel 圖形卡的資訊洩漏問題。(CVE-2019-14615)

  - 核心：pinctrl 子系統中存在超出邊界讀取弱點。(CVE-2020-0427)

  - 核心：某些 Intel(R) Ethernet E810 Adapter 驅動程式中存在輸入驗證不當問題 (CVE-2020-24502)

  - 核心：某些 Intel(R) Ethernet E810 Adapter 驅動程式中存在存取控制不足問題 (CVE-2020-24503)

  - 核心：某些 Intel(R) Ethernet E810 Adapter 驅動程式中存在資源消耗不受控制的問題 (CVE-2020-24504)

  - 核心：重新連線時未清除片段快取 (CVE-2020-24586)

  - 核心：重組在不同金鑰下加密的片段 (CVE-2020-24587)

  - 核心：wifi 幀承載被錯誤剖析為 L2 幀 (CVE-2020-24588)

  - 核心：從未經驗證的 wifi 用戶端轉送 EAPOL (CVE-2020-26139)

  - 核心：在受保護的網路中接受純文字資料幀 (CVE-2020-26140)

  - 核心：不驗證分段幀的 TKIP MIC (CVE-2020-26141)

  - 核心：在受保護的網路中接受分段式純文字幀 (CVE-2020-26143)

  - 核心：接受以 RFC1042 標頭開頭的未加密 A-MSDU 幀 (CVE-2020-26144)

  - 核心：接受純文字廣播片段作為完整幀 (CVE-2020-26145)

  - 核心：重組具有非連續封包編號的加密片段 (CVE-2020-26146)

  - 核心：重組混合的加密/純文字片段 (CVE-2020-26147)

  - 核心：powerpc：RTAS 呼叫可用來危害核心完整性 (CVE-2020-27777)

  - kernel：由於 THP mapcount 檢查中存在爭用情形，寫入時複製實作可授予非預定的寫入存取權 (CVE-2020-29368)

  - 核心：drivers/tty/tty_io.c 和 drivers/tty/tty_jobctrl.c 中的鎖定不一致會導致釋放後讀取 (CVE-2020-29660)

  - 核心：在 drivers/net/wireless/marvell/mwifiex/join.c 的 mwifiex_cmd_802_11_ad_hoc_start 函式中，透過長 SSID 值可觸發緩衝區溢位問題 (CVE-2020-36158)

  - 核心：在 virt/kvm/kvm_main.c 的 kvm_io_bus_unregister_dev 函式中，執行 kmalloc 失敗時會發生記憶體流失問題 (CVE-2020-36312)

  - 核心：net/bluetooth/hci_event.c 的 hci_extended_inquiry_result_evt() 中存在 slab 超出邊界讀取問題 (CVE-2020-36386)

  - 核心：BlueZ 中的不當存取控制可導致資訊洩漏弱點。(CVE-2021-0129)

  - 核心：drivers/block/nbd.c 的 ndb_queue_rq() 中存在釋放後使用弱點 (CVE-2021-3348)

  - 核心：Linux 核心的 eBPF RINGBUF 對應配置過大 (CVE-2021-3489)

  - 核心：HCI 裝置初始化失敗時，藍牙子系統中會發生雙重釋放 (CVE-2021-3564)

  - 核心：hci_sock_bound_ioctl() 函式中的釋放後使用弱點 (CVE-2021-3573)

  - 核心：div/mod 上的 eBPF 32 位元來源暫存器截斷 (CVE-2021-3600)

  - 核心：lib/list_debug.c:50 存在流程表清單 del 損毀和核心錯誤 (CVE-2021-3635)

  - 核心：net/mac802154/llsec.c 的 llsec_key_alloc() 中存在 NULL 指標解除參照弱點 (CVE-2021-3659)

  - 核心：rb_per_cpu_empty() 中的 DoS 弱點 (CVE-2021-3679)

  - 核心：overlayfs：在非特權使用者命名空間內掛載 overlayfs 可能會造成檔案洩漏 (CVE-2021-3732)

   核心：__cgroup_bpf_run_filter_getsockopt() 中的堆積溢位弱點 (CVE-2021-20194)

  - 核心：setsockopt 系統呼叫未受信任的指標解除參照和資訊洩漏弱點 (CVE-2021-20239)

  - 核心：sctp_destroy_sock list_del 中的爭用條件 (CVE-2021-23133)

  - 核心：fuse：由於重試迴圈不斷發現相同的錯誤 inode，可能會發生 CPU 停頓問題 (CVE-2021-28950)

  - 核心：在 arch/x86/events/intel/ds.c 中的 intel_pmu_drain_pebs_nhm 發生系統當機 (CVE-2021-28971)

  - 核心：可以迴避防範推測性超出邊界載入的指標算術作業序列保護機制，造成核心記憶體的內容遭洩漏 (CVE-2021-29155)

  - 核心：net/tipc/node.c 中 tipc_nl_retrieve_key 函式的不當輸入驗證弱點 (CVE-2021-29646)

  - 核心：在 net/netfilter/x_tables.c 和 include/linux/netfilter/x_tables.h 中指派新表格值時缺少完整的記憶體屏障，可導致 DoS (CVE-2021-29650)

  - 核心：處理 eBPF 程式時可造成本機權限提升 (CVE-2021-31440)

  - 核心：可以迴避防範推測性指標算術的堆疊指標保護機制，造成核心記憶體的內容遭洩漏 (CVE-2021-31829)

  - 核心：drivers/md/dm-ioctl.c 中的超出邊界陣列存取弱點 (CVE-2021-31916)

  - 核心：net/ipv4/cipso_ipv4.c 中 cipso_v4_genopt 的釋放後使用弱點 (CVE-2021-33033)

  - 核心：Intel(R) Ethernet ixgbe 驅動程式中存在不當輸入驗證問題，因此經驗證的使用者可以透過本機存取權限造成拒絕服務 (CVE-2021-33098)

  - 核心：BPF 驗證程式對指標算術作業強制執行不正確的限制，因而導致超出邊界讀取和寫入 (CVE-2021-33200)

  - 核心：sysfs 讀取中可能發生緩衝區溢位 (CVE-2022-20166)

請注意，Nessus 並未測試這些問題，而是僅依據應用程式自我報告的版本號碼作出判斷。

ID	名稱	產品	系列	已發布	已更新	嚴重性
230211	Linux Distros Unpatched Vulnerability : CVE-2021-47011	Nessus	Misc.	2025/3/5	2025/8/9	medium
272962	Unity Linux 20.1070a Security Update: kernel (UTSA-2025-989580)	Nessus	Unity Linux Local Security Checks	2025/11/5	2025/11/5	medium
230211	Linux Distros のパッチ未適用の脆弱性: CVE-2021-47011	Nessus	Misc.	2025/3/5	2025/8/9	medium
230211	Linux Distros 未修补的漏洞: CVE-2021-47011	Nessus	Misc.	2025/3/5	2025/8/9	medium
230211	Linux Distros 未修補弱點：CVE-2021-47011	Nessus	Misc.	2025/3/5	2025/8/9	medium
269078	Unity Linux 20.1070e Security Update: kernel (UTSA-2025-987124)	Nessus	Unity Linux Local Security Checks	2025/10/7	2025/10/15	medium
155219	RHEL 8 : kernel (RHSA-2021:4356)	Nessus	Red Hat Local Security Checks	2021/11/11	2025/8/15	high
160459	Amazon Linux 2 : kernel, --advisory ALAS2KERNEL-5.10-2022-002 (ALASKERNEL-5.10-2022-002)	Nessus	Amazon Linux Local Security Checks	2022/5/2	2025/11/7	high
155219	RHEL 8：kernel（RHSA-2021:4356）	Nessus	Red Hat Local Security Checks	2021/11/11	2025/8/15	high
160459	Amazon Linux 2kernel、 --advisory ALAS2KERNEL-5。10-2022-002 ALASKERNEL-5.10-2022-002	Nessus	Amazon Linux Local Security Checks	2022/5/2	2025/11/7	high
155219	RHEL 8：内核 (RHSA-2021:4356)	Nessus	Red Hat Local Security Checks	2021/11/11	2025/8/15	high
160459	Amazon Linux 2 内核 --advisory ALAS2KERNEL-5。10-2022-002 (ALASKERNEL-5.10-2022-002)	Nessus	Amazon Linux Local Security Checks	2022/5/2	2025/11/7	high
155219	RHEL 8：核心 (RHSA-2021:4356)	Nessus	Red Hat Local Security Checks	2021/11/11	2025/8/15	high
160459	Amazon Linux 2核心 --advisory ALAS2KERNEL-5。10-2022-002 (ALASKERNEL-5.10-2022-002)	Nessus	Amazon Linux Local Security Checks	2022/5/2	2025/11/7	high

偵測

搜尋 Plugin

medium

medium

medium

medium

medium

medium

high

high

high

high

high

high

high

high