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

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

    ubifs: Fix to add refcount once page is set private

    MM defined the rule [1] very clearly that once page was set with PG_private     flag, we should increment the refcount in that page, also main flows like     pageout(), migrate_page() will assume there is one additional page     reference count if page_has_private() returns true. Otherwise, we may     get a BUG in page migration:

      page:0000000080d05b9d refcount:-1 mapcount:0 mapping:000000005f4d82a8       index:0xe2 pfn:0x14c12       aops:ubifs_file_address_operations [ubifs] ino:8f1 dentry name:f30e       flags: 0x1fffff80002405(locked|uptodate|owner_priv_1|private|node=0|       zone=1|lastcpupid=0x1fffff)       page dumped because: VM_BUG_ON_PAGE(page_count(page) != 0)
      ------------[ cut here ]------------       kernel BUG at include/linux/page_ref.h:184!       invalid opcode: 0000 [#1] SMP       CPU: 3 PID: 38 Comm: kcompactd0 Not tainted 5.15.0-rc5       RIP: 0010:migrate_page_move_mapping+0xac3/0xe70       Call Trace:
        ubifs_migrate_page+0x22/0xc0 [ubifs]         move_to_new_page+0xb4/0x600         migrate_pages+0x1523/0x1cc0         compact_zone+0x8c5/0x14b0         kcompactd+0x2bc/0x560         kthread+0x18c/0x1e0         ret_from_fork+0x1f/0x30

    Before the time, we should make clean a concept, what does refcount means     in page gotten from grab_cache_page_write_begin(). There are 2 situations:
    Situation 1: refcount is 3, page is created by __page_cache_alloc.
      TYPE_A - the write process is using this page       TYPE_B - page is assigned to one certain mapping by calling
               __add_to_page_cache_locked()       TYPE_C - page is added into pagevec list corresponding current cpu by                calling lru_cache_add()     Situation 2: refcount is 2, page is gotten from the mapping's tree       TYPE_B - page has been assigned to one certain mapping       TYPE_A - the write process is using this page (by calling                page_cache_get_speculative())     Filesystem releases one refcount by calling put_page() in xxx_write_end(),     the released refcount corresponds to TYPE_A (write task is using it). If     there are any processes using a page, page migration process will skip the     page by judging whether expected_page_refs() equals to page refcount.

    The BUG is caused by following process:
        PA(cpu 0)                           kcompactd(cpu 1)                                     compact_zone     ubifs_write_begin       page_a = grab_cache_page_write_begin         add_to_page_cache_lru           lru_cache_add             pagevec_add // put page into cpu 0's pagevec       (refcnf = 3, for page creation process)     ubifs_write_end       SetPagePrivate(page_a) // doesn't increase page count !       unlock_page(page_a)       put_page(page_a)  // refcnt = 2                                     [...]

        PB(cpu 0)     filemap_read       filemap_get_pages         add_to_page_cache_lru           lru_cache_add
            __pagevec_lru_add // traverse all pages in cpu 0's pagevec
              __pagevec_lru_add_fn                 SetPageLRU(page_a)                                     isolate_migratepages                                       isolate_migratepages_block                                         get_page_unless_zero(page_a)                                         // refcnt = 3                                           list_add(page_a, from_list)                                     migrate_pages(from_list)
                                      __unmap_and_move                                         move_to_new_page                                           ubifs_migrate_page(page_a)                                             migrate_page_move_mapping                                               expected_page_refs get 3                                       (migration[1] + mapping[1] + private[1])              release_pages                put_page_testzero(page_a) // refcnt = 3                                               page_ref_freeze  // refcnt = 0                  page_ref_dec_and_test(0 - 1 = -1)                                               page_ref_unfreeze                                                 VM_BUG_ON_PAGE(-1 != 0, page)

    UBIFS doesn't increase the page refcount after setting private flag, which     leads to page migration task believes the page is not used by any other     processes, so the page is migrated. This causes concurrent accessing on     page refcount between put_page() called by other process(eg. read process     calls lru_cache_add) and page_ref_unfreeze() called by mi
    ---truncated---

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

  - ubifsページがプライベートに設定されたら refcount を追加するのを修正します MM は、ルール [1] を非常に明確に定義しました。ページが PG_private フラグで設定されたら、そのページで refcount をインクリメントする必要があります。また、pageout()、migrate_page() などのメインフローも修正しますは、page_has_private() が true を返す場合、追加のページ参照カウントを 1 つと想定します。あるいは、ページ移行でバグが発生する可能性があります page:000000080d05b9d refcount:-1 mapcount:0 mapping:000000005f4d82a8 index:0xe2 pfn:0x14c12 aops:ubifs_file_address_operations [bifs] ino:8f1 dentry name:f30e flags: 0x1fffff80240080 |owner_priv_1|private|node=0| zone=1|lastcpupid=0x1fffffページがダンプされました VM_BUG_ON_PAGE(page_count(page) != 0) ------------[cuther]---- -------- include/linux/page_ref.h:184! でカーネルのバグが発生します無効な opcode: 0000 [#1] SMP CPU:3 PID:
    38 通信kcompactd0 汚染されていない 5.15.0-rc5 RIP0010:migrate_page_move_mapping+0xac3/0xe70 Call Trace
    [ubifs_migrate_page+0x22/0xc0 [ubifs] move_to_new_page+0xb4/0x600 migrate_pages+0x1523/0x1cc0 compact_zone+0x8c5/0x14b0 kcompactd+0x2bc/0x560 kthread+0x18c/0x1e0 ret_from_fork+0x1f/0x600 時間前に、概念をクリーンアップする必要があります。 refcount は、grab_cache_page_write_begin() から取得されるページ内で意味をなします。2 つの状況があります。状況 1: refcount が 3 であり、ページが によって作成されています。
    __page_cache_alloc。TYPE_A - 書き込みプロセスはこのページを使用しています TYPE_B - ページは __add_to_page_cache_locked() を呼び出すことで 1 つの特定のマッピングに割り当てられます TYPE_C - lru_cache_add() を呼び出すことで、現在の cpu に対応する pagevec リストにページが追加されます 状況 2refcount が 2、ページは から取得されますマッピングのツリー TYPE_B - ページが 1 つの特定のマッピング TYPE_A に割り当てられています - 書き込みプロセスがこのページを使用していますpage_cache_get_speculative() を呼び出すことでファイルシステムが xxx_write_end() で put_page() を呼び出すことで 1 つの refcount をリリースします、リリースされた refcount は TYPE_A に対応します書き込みタスクがこれを使用しています。ページを使用しているプロセスがあれば、予期_page_refs() がページ refcount と等しいかどうかを判断することで、ページ移行プロセスはページをスキップします。このバグは、次のプロセスによって発生します。PA(cpu 0) kcompactd(cpu 1) compact_zone ubifs_write_begin page_a = grab_cache_page_write_begin add_to_page_cache_lru lru_cache_add pagevec_add // put page in cpu 0's pagevec 、ページ作成プロセス用の refcnf = 3、ubifs_write_end SetPagePrivate(page_a) / / によってページカウントが増加しない ! unlock_page(page_a) put_page(page_a) // refcnt = 2 [...] PB(cpu 0) filemap_read filemap_get_pages add_to_page_cache_lru lru_cache_add __pagevec_lru_add // cpu 0 の pagevec の全ページをトラバースします __pagevec_lru_add_fn SetPageLRU(page_a) isolate_migrate_unlock_pagesisolate_migrate_unlock get_pages refcnt = 3 list_add(page_a, from_list) migrate_pages(from_list) __unmap_and_move move_to_new_page ubifs_migrate_page(page_a) migrate_page_move_mapping expected_page_refs get 3migration[1] + mapping[1] + private[1]) release_pages put_page_testzero(page_a) // refcnt = 3 page_ref_freeze // refcnt = 0 page_ref_dec_and_test(0 - 1 = -1) page_ref_unfreeze VM_BUG_ON_PAGE(-1 != 0, page) UBIFS は、プライベートフラグの設定後にページ refcount を増加させません。これにより、ページ移行タスクでは、ページが使用されていないと考えられます他のプロセスによって実行されないため、ページは移行されます。これは、他のプロセスによって呼び出されるput_page()例えば、プロセス呼び出し lru_cache_addと、mi によって呼び出される page_ref_unfreeze() の間のページ refcount での同時アクセスを引き起こします ---truncated---CVE-2021-47635]

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

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

  - ubifs: Fix to add refcount once page is set private MM defined the rule [1] very clearly that once page     was set with PG_private flag, we should increment the refcount in that page, also main flows like     pageout(), migrate_page() will assume there is one additional page reference count if page_has_private()     returns true. Otherwise, we may get a BUG in page migration: page:0000000080d05b9d refcount:-1 mapcount:0     mapping:000000005f4d82a8 index:0xe2 pfn:0x14c12 aops:ubifs_file_address_operations [ubifs] ino:8f1 dentry     name:f30e flags: 0x1fffff80002405(locked|uptodate|owner_priv_1|private|node=0|     zone=1|lastcpupid=0x1fffff) page dumped because: VM_BUG_ON_PAGE(page_count(page) != 0) ------------[ cut     here ]------------ kernel BUG at include/linux/page_ref.h:184! invalid opcode: 0000 [#1] SMP CPU: 3 PID:
    38 Comm: kcompactd0 Not tainted 5.15.0-rc5 RIP: 0010:migrate_page_move_mapping+0xac3/0xe70 Call Trace:
    ubifs_migrate_page+0x22/0xc0 [ubifs] move_to_new_page+0xb4/0x600 migrate_pages+0x1523/0x1cc0     compact_zone+0x8c5/0x14b0 kcompactd+0x2bc/0x560 kthread+0x18c/0x1e0 ret_from_fork+0x1f/0x30 Before the     time, we should make clean a concept, what does refcount means in page gotten from     grab_cache_page_write_begin(). There are 2 situations: Situation 1: refcount is 3, page is created by
    __page_cache_alloc. TYPE_A - the write process is using this page TYPE_B - page is assigned to one certain     mapping by calling __add_to_page_cache_locked() TYPE_C - page is added into pagevec list corresponding     current cpu by calling lru_cache_add() Situation 2: refcount is 2, page is gotten from the mapping's tree     TYPE_B - page has been assigned to one certain mapping TYPE_A - the write process is using this page (by     calling page_cache_get_speculative()) Filesystem releases one refcount by calling put_page() in     xxx_write_end(), the released refcount corresponds to TYPE_A (write task is using it). If there are any     processes using a page, page migration process will skip the page by judging whether expected_page_refs()     equals to page refcount. The BUG is caused by following process: PA(cpu 0) kcompactd(cpu 1) compact_zone     ubifs_write_begin page_a = grab_cache_page_write_begin add_to_page_cache_lru lru_cache_add pagevec_add //     put page into cpu 0's pagevec (refcnf = 3, for page creation process) ubifs_write_end     SetPagePrivate(page_a) // doesn't increase page count ! unlock_page(page_a) put_page(page_a) // refcnt = 2     [...] PB(cpu 0) filemap_read filemap_get_pages add_to_page_cache_lru lru_cache_add __pagevec_lru_add //     traverse all pages in cpu 0's pagevec __pagevec_lru_add_fn SetPageLRU(page_a) isolate_migratepages     isolate_migratepages_block get_page_unless_zero(page_a) // refcnt = 3 list_add(page_a, from_list)     migrate_pages(from_list) __unmap_and_move move_to_new_page ubifs_migrate_page(page_a)     migrate_page_move_mapping expected_page_refs get 3 (migration[1] + mapping[1] + private[1]) release_pages     put_page_testzero(page_a) // refcnt = 3 page_ref_freeze // refcnt = 0 page_ref_dec_and_test(0 - 1 = -1)     page_ref_unfreeze VM_BUG_ON_PAGE(-1 != 0, page) UBIFS doesn't increase the page refcount after setting     private flag, which leads to page migration task believes the page is not used by any other processes, so     the page is migrated. This causes concurrent accessing on page refcount between put_page() called by other     process(eg. read process calls lru_cache_add) and page_ref_unfreeze() called by mi ---truncated---     (CVE-2021-47635)

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

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

  - ubifs修正一旦頁面設定為私密 MM 會新增 refcount 的問題如果 page_has_private() 傳回 true 將假設還有一個額外的頁面參照計數。否則我們可能會在頁面移轉中遇到一個錯誤 page:0000000080d05b9d refcount:-1 mapcount:0 mapping:000000005f4d82a8 index:0xe2 pfn:0x14c12 aops:ubifs_file_address_operations [ubifs] ino:8f1 dentry name:f30e flags: 0x1fffff80002405(locked|file_address_operations [ubifs] ino:8f1 dentry name:f30e flags: 0x1fffff80002405(locked|fffff80002405(locked|file_address_operations [ubifs] ino:8f1 dentry name:f30e flags) |owner_priv_1|private|node=0| zone=1|lastcpupid=0x1fffff) 頁面已轉儲存因為 VM_BUG_ON_PAGE(page_count(page) != 0) ------------[截到此處 ]---- -------- include/linux/page_ref.h:184! 的核心錯誤無效 opcode0000 [#1] SMP CPU3 PID
    38 Commkcompactd0 未受污染 5.15.0-rc5 RIP 0010:migrate_page_move_mapping+0xac3/0xe70 呼叫追踪
    ubifs_migrate_page+0x22/0xc0 [ubifs] move_to_new_page+0xb4/0x600 migrate_pages+0x1523/0x1cc0 compact_zone+0x8c5/0x14b0 kcompactd+0x2bc/0x560 kthread+0x18c/0x1e0 ret_from_fork+0x1f/0x30 時間之前我們應該先清理一下概念refcount 是指在從 grab_cache_page_write_begin() 取得的頁面中嗎。有 2 種情況： 情況 1：refcount 是 3，頁面是由 建立
    __page_cache_alloc。TYPE_A - 寫入處理程序正在使用此頁面 TYPE_B - 透過呼叫 __add_to_page_cache_locked() 將頁面指派給特定對應 TYPE_C - 透過呼叫 lru_cache_add() 將頁面新增至與目前 cpu 對應的 pagevec 清單 情況 2refcount 為 2頁面是從 取得對應的樹狀結構TYPE_B - 頁面已指派給一個特定對應 TYPE_A - 寫入處理程序正在使用此頁面 (透過呼叫 page_cache_get_speculative()) 檔案系統藉由呼叫 xxx_write_end() 中的 put_page() 來釋出一個 refcount釋出的 refcount 對應於 TYPE_A (寫入任務正在使用它)。若有任何處理程序使用頁面頁面移轉處理程序將判斷 expected_page_refs() 是否等於頁面參照計數藉此略過該頁面。這個錯誤是由下列處理程序所造成 PA(cpu 0) kcompactd(cpu 1) compact_zone ubifs_write_begin page_a = grab_cache_page_write_begin add_to_page_cache_lru lru_cache_add pagevec_add // 將頁面放入 cpu 0 的 pagevec (refcnf = 3用於頁面建立處理程序) ubifs_write_end SetPagePrivate(page_a) / / 不會增加頁面計數unlock_page(page_a) put_page(page_a) // refcnt = 2 [...] PB(cpu 0) filemap_read filemap_get_pages add_to_page_cache_lru lru_cache_add __pagevec_lru_add // 遊走 cpu 0 的 pagevec 中的所有頁面 __pagevec_lru_add_fn SetPageLRU(page_a) isolate_migratepages isolate(migrate_zero_block) get //_page_migratepages isolate(migrate_zero_block) refcnt = 3 list_add(page_a, from_list) migrate_pages(from_list) __unmap_and_move move_to_new_page ubifs_migrate_page(page_a) migrate_page_move_mapping expected_page_refs get 3 (migration[1] + mapping[1] + private[1]) release_pages put_page_testzero(page_a) // refcnt = 3 page_ref_freeze // refcnt = 0 page_ref_dec_and_test(0 - 1 = -1) page_ref_unfreeze VM_BUG_ON_PAGE(-1 != 0, page) UBIFS 在設定私密旗標後並未增加頁面 refcount進而導致頁面移轉作業認為頁面未使用由任何其他處理程序執行，因此會移轉該頁面。這會造成在其他處理程序呼叫的 put_page() (例如讀取處理程序呼叫 lru_cache_add) 與 mi 呼叫的 page_ref_unfreeze() 之間對頁面 refcount 進行並行存取 ---truncated--- (CVE-2021-47635)

請注意，Nessus 的判定取決於廠商所報告的套件是否存在。

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

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

    ubifs: Fix to add refcount once page is set private

    MM defined the rule [1] very clearly that once page was set with PG_private     flag, we should increment the refcount in that page, also main flows like     pageout(), migrate_page() will assume there is one additional page     reference count if page_has_private() returns true. Otherwise, we may     get a BUG in page migration:

      page:0000000080d05b9d refcount:-1 mapcount:0 mapping:000000005f4d82a8       index:0xe2 pfn:0x14c12       aops:ubifs_file_address_operations [ubifs] ino:8f1 dentry name:f30e       flags: 0x1fffff80002405(locked|uptodate|owner_priv_1|private|node=0|       zone=1|lastcpupid=0x1fffff)       page dumped because: VM_BUG_ON_PAGE(page_count(page) != 0)
      ------------[ cut here ]------------       kernel BUG at include/linux/page_ref.h:184!       invalid opcode: 0000 [#1] SMP       CPU: 3 PID: 38 Comm: kcompactd0 Not tainted 5.15.0-rc5       RIP: 0010:migrate_page_move_mapping+0xac3/0xe70       Call Trace:
        ubifs_migrate_page+0x22/0xc0 [ubifs]         move_to_new_page+0xb4/0x600         migrate_pages+0x1523/0x1cc0         compact_zone+0x8c5/0x14b0         kcompactd+0x2bc/0x560         kthread+0x18c/0x1e0         ret_from_fork+0x1f/0x30

    Before the time, we should make clean a concept, what does refcount means     in page gotten from grab_cache_page_write_begin(). There are 2 situations:
    Situation 1: refcount is 3, page is created by __page_cache_alloc.
      TYPE_A - the write process is using this page       TYPE_B - page is assigned to one certain mapping by calling
               __add_to_page_cache_locked()       TYPE_C - page is added into pagevec list corresponding current cpu by                calling lru_cache_add()     Situation 2: refcount is 2, page is gotten from the mapping's tree       TYPE_B - page has been assigned to one certain mapping       TYPE_A - the write process is using this page (by calling                page_cache_get_speculative())     Filesystem releases one refcount by calling put_page() in xxx_write_end(),     the released refcount corresponds to TYPE_A (write task is using it). If     there are any processes using a page, page migration process will skip the     page by judging whether expected_page_refs() equals to page refcount.

    The BUG is caused by following process:
        PA(cpu 0)                           kcompactd(cpu 1)                                     compact_zone     ubifs_write_begin       page_a = grab_cache_page_write_begin         add_to_page_cache_lru           lru_cache_add             pagevec_add // put page into cpu 0's pagevec       (refcnf = 3, for page creation process)     ubifs_write_end       SetPagePrivate(page_a) // doesn't increase page count !       unlock_page(page_a)       put_page(page_a)  // refcnt = 2                                     [...]

        PB(cpu 0)     filemap_read       filemap_get_pages         add_to_page_cache_lru           lru_cache_add
            __pagevec_lru_add // traverse all pages in cpu 0's pagevec
              __pagevec_lru_add_fn                 SetPageLRU(page_a)                                     isolate_migratepages                                       isolate_migratepages_block                                         get_page_unless_zero(page_a)                                         // refcnt = 3                                           list_add(page_a, from_list)                                     migrate_pages(from_list)
                                      __unmap_and_move                                         move_to_new_page                                           ubifs_migrate_page(page_a)                                             migrate_page_move_mapping                                               expected_page_refs get 3                                       (migration[1] + mapping[1] + private[1])              release_pages                put_page_testzero(page_a) // refcnt = 3                                               page_ref_freeze  // refcnt = 0                  page_ref_dec_and_test(0 - 1 = -1)                                               page_ref_unfreeze                                                 VM_BUG_ON_PAGE(-1 != 0, page)

    UBIFS doesn't increase the page refcount after setting private flag, which     leads to page migration task believes the page is not used by any other     processes, so the page is migrated. This causes concurrent accessing on     page refcount between put_page() called by other process(eg. read process     calls lru_cache_add) and page_ref_unfreeze() called by mi
    ---truncated---

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 主机中安装的一个或多个程序包受到一个漏洞影响，而供应商没有提供补丁程序。

  - ubifs修复此缺陷在页面设置为私有 MM 时添加 refcount 定义了规则 [1] 非常清楚一旦使用 PG_private 标记设置页面后我们应该增加该页面中的 refcount还有 pageout()、migrate_page() 等主要流如果 page_has_private() 返回 true 将假设存在一个额外的页面引用计数。否则我们可能会在页面迁移中得到一个缺陷 page:0000000080d05b9d refcount:-1 mapcount:0 mapping:000000005f4d82a8 index:0xe2 pfn:0x14c12 aops:ubifs_file_address_operations [ubifs] ino:8f1 dentry name:f30e flags: 0x1ffff80002405(locked|uptodate) |owner_priv_1|private|node=0| zone=1|lastcpupid=0x1fffff) 页面转储因为 VM_BUG_ON_PAGE(page_count(page) != 0) ------------[ 在此处切换 ]---- -------- 位于 include/linux/page_ref.h:184! 的内核缺陷无效 opcode0000 [#1] SMP CPU3 PID
    38 Commkcompactd0 未受感染 5.15.0-rc5 RIP0010:migrate_page_move_mapping+0xac3/0xe70 调用跟踪
    ubifs_migrate_page+0x22/0xc0 [ubifs] move_to_new_page+0xb4/0x600 migrate_pages+0x1523/0x1cc0 compact_zone+0x8c5/0x14b0 kcompactd+0x2bc/0x560 kthread+0x18c/0x1e0 在清理时间概念之前我们应该执行从 grab_cache_page_write_begin() 获取的页面中的 refcount 表示。分 2 种情况第 1 种情况refcount 为 3页面创建者
    __page_cache_alloc。TYPE_A - 写入进程正在使用此页面 TYPE_B - 通过调用 __add_to_page_cache_locked() 将页面分配给某个映射 TYPE_C - 通过调用 lru_cache_add() 将页面添加到与当前 cpu 对应的 pagevec 列表中 情况 2refcount 为 2页面的获取方式映射的树 TYPE_B - 页面已分配给一个特定映射 TYPE_A - 写入进程正在使用此页面通过调用 page_cache_get_speculative() 文件系统通过调用 xxx_write_end() 中的 put_page() 释放一个 refcount释放的 refcount 对应于 TYPE_A (写任务正在使用它。如果有任何进程在使用某个页面页面迁移进程将通过判断 expected_page_refs() 是否等于页面引用计数来跳过该页面。此缺陷是由以下进程造成的 PA(cpu 0) kcompactd(cpu 1) compact_zone ubifs_write_begin page_a = grab_cache_page_write_begin add_to_page_cache_lru lru_cache_add pagevec_add // put page to cpu 0's pagevec (refcnf = 3用于页面创建进程) ubifs_write_end SetPagePrivate(page_a) / / 不会增加页数unlock_page(page_a) put_page(page_a) // refcnt = 2 [...] PB(cpu 0) filemap_read filemap_get_pages add_to_page_cache_lru lru_cache_add __pagevec_lru_add // 遍历 cpu 0 的 pagevec 中的所有页面 __pagevec_lru_add_fn SetPageLRU(page_a) isolate_migratepages isolate_zero_pages_pageless(getPage) // refcnt = 3 list_add(page_a, from_list) migrate_pages(from_list) __unmap_and_move move_to_new_page ubifs_migrate_page(page_a) migrate_page_move_mapping expected_page_refs get 3 (migration[1] + mapping[1] + private[1]) release_pages put_page_testzero(page_a) // refcnt = 3 page_ref_freeze // refcnt = 0 page_ref_dec_and_test(0 - 1 = -1) page_ref_unfreeze VM_BUG_ON_PAGE(-1 != 0, page) UBIFS 在设置私有标记后未增加页面引用计数从而导致页面迁移任务认为未使用该页面，因此页面会发生迁移。这会导致在其他进程调用的 put_page()例如读取进程调用 lru_cache_add和 mi 调用的 page_ref_unfreeze() 之间的页面引用计数上发生并发访问 ---truncated--- (CVE-2021-47635)

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

The remote SUSE Linux SLES15 / SLES_SAP15 host has packages installed that are affected by multiple vulnerabilities as referenced in the SUSE-SU-2025:1027-1 advisory.

    The SUSE Linux Enterprise 15 SP4 kernel was updated to receive various security bugfixes.


    The following security bugs were fixed:

    - CVE-2024-2201: Fixed information leak in x86/BHI (bsc#1217339).
    - CVE-2024-41092: drm/i915/gt: Fix potential UAF by revoke of fence registers (bsc#1228483).
    - CVE-2024-42098: crypto: ecdh - explicitly zeroize private_key (bsc#1228779).
    - CVE-2024-42229: crypto: aead,cipher - zeroize key buffer after use (bsc#1228708).
    - CVE-2024-57996: net_sched: sch_sfq: do not allow 1 packet limit (bsc#1239076).
    - CVE-2024-58014: wifi: brcmsmac: add gain range check to wlc_phy_iqcal_gainparams_nphy() (bsc#1239109).
    - CVE-2025-21718: net: rose: fix timer races against user threads (bsc#1239073).
    - CVE-2025-21780: drm/amdgpu: avoid buffer overflow attach in smu_sys_set_pp_table() (bsc#1239115).


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

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

The remote SUSE Linux SLES15 / SLES_SAP15 host has packages installed that are affected by multiple vulnerabilities as referenced in the SUSE-SU-2025:1241-1 advisory.

    The SUSE Linux Enterprise 15 SP5 kernel was updated to receive various security bugfixes.

    The following security bugs were fixed:

    - CVE-2022-49053: scsi: target: tcmu: Fix possible page UAF (bsc#1237918).
    - CVE-2022-49465: blk-throttle: Set BIO_THROTTLED when bio has been throttled (bsc#1238919).
    - CVE-2022-49739: gfs2: Always check inode size of inline inodes (bsc#1240207).
    - CVE-2023-52935: mm/khugepaged: fix ->anon_vma race (bsc#1240276).
    - CVE-2024-53124: net: fix data-races around sk->sk_forward_alloc (bsc#1234074).
    - CVE-2024-53176: smb: During unmount, ensure all cached dir instances drop their dentry (bsc#1234894).
    - CVE-2024-53178: smb: Do not leak cfid when reconnect races with open_cached_dir (bsc#1234895).
    - CVE-2024-56651: can: hi311x: hi3110_can_ist(): fix potential use-after-free (bsc#1235528).
    - CVE-2024-57996: net_sched: sch_sfq: do not allow 1 packet limit (bsc#1239076).
    - CVE-2024-58013: Bluetooth: MGMT: Fix slab-use-after-free Read in mgmt_remove_adv_monitor_sync     (bsc#1239095).
    - CVE-2024-58014: wifi: brcmsmac: add gain range check to wlc_phy_iqcal_gainparams_nphy() (bsc#1239109).
    - CVE-2025-21693: mm: zswap: properly synchronize freeing resources during CPU hotunplug (bsc#1237029).
    - CVE-2025-21718: net: rose: fix timer races against user threads (bsc#1239073).
    - CVE-2025-21772: partitions: mac: fix handling of bogus partition table (bsc#1238911).
    - CVE-2025-21780: drm/amdgpu: avoid buffer overflow attach in smu_sys_set_pp_table() (bsc#1239115).


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

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

リモートの SUSE Linux SLES15 / SLES_SAP15 ホストには、SUSE-SU-2025:1027-1 のアドバイザリに記載された複数の脆弱性の影響を受けるパッケージがインストールされています。

    SUSE Linux Enterprise 15 SP4 カーネルが更新され、さまざまなセキュリティバグ修正が行われています。


    次のセキュリティバグを修正しました。

    - CVE-2024-2201: x86/BHI での情報漏洩を修正しました (bsc#1217339)。
    - CVE-2024-41092: drm/i915/gt: フェンスレジスタの取り消しによる潜在的なメモリ解放後使用 (Use After Free) を修正しました (bsc#1228483)。
    - CVE-2024-42098: crypto: ecdh - private_key を明示的にゼロ化します (bsc#1228779)。
    - CVE-2024-42229: crypto: aead,cipher - 使用後にキーバッファをゼロ化します (bsc#1228708)。
    - CVE-2024-57996: net_sched: sch_sfq: 1 パケット制限を許可しません (bsc#1239076)。
    - CVE-2024-58014: wifi: brcmsmac: wlc_phy_iqcal_gainparams_nphy() にゲイン範囲チェックを追加しました (bsc#1239109)。
    - CVE-2025-21718: net: rose: ユーザースレッドに対するタイマーの競合状態を修正しました (bsc#1239073)。
    - CVE-2025-21780: drm/amdgpu: smu_sys_set_pp_table() のバッファオーバーフローのアタッチを回避します (bsc#1239115)。


Tenable は、前述の記述ブロックを SUSE セキュリティアドバイザリから直接抽出しています。

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

リモートの SUSE Linux SLES15 / SLES_SAP15 ホストには、SUSE-SU-2025:1241-1 のアドバイザリに記載された複数の脆弱性の影響を受けるパッケージがインストールされています。

    SUSE Linux Enterprise 15 SP5 カーネルが更新され、さまざまなセキュリティバグ修正が行われています。

    次のセキュリティバグを修正しました。

    - CVE-2022-49053：scsi：target：tcmu：潜在的なページ UAF を修正します（bsc#1237918）。
    - CVE-2022-49465：blk-throttle：bio が調整されているときに BIO_THROTTLED を設定します（bsc#1238919）。
    - CVE-2022-49739：gfs2：インライン inode の inode サイズを常にチェックします（bsc#1240207）。
    - CVE-2023-52935：mm/khugepaged：->anon_vma の競合を修正します（bsc#1240276）。
    - CVE-2024-53124：net：sk->sk_forward_alloc 周辺のデータ競合を修正します（bsc#1234074）。
    - CVE-2024-53176: smb: アンマウント中に、キャッシュされたすべての dir インスタンスが dentry を確実にドロップするようにします (bsc#1234894)。
    - CVE-2024-53178: smb: 再接続が open_cached_dir と競合する際に cfid を漏洩しません (bsc#1234895)。
    - CVE-2024-56651：can: hi311x：hi3110_can_ist()：潜在的な use-after-free を修正します（bsc#1235528）。
    - CVE-2024-57996: net_sched: sch_sfq: 1 パケット制限を許可しません (bsc#1239076)。
    - CVE-2024-58013：Bluetooth： MGMT：mgmt_remove_adv_monitor_sync の slab-use-after-free 読み取りを修正（bsc#1239095）。
    - CVE-2024-58014: wifi: brcmsmac: wlc_phy_iqcal_gainparams_nphy() にゲイン範囲チェックを追加しました (bsc#1239109)。
    - CVE-2025-21693：mm：zswap：CPU ホットアンプラグ中に適切に同期してリソースを解放します（bsc#1237029）。
    - CVE-2025-21718: net: rose: ユーザースレッドに対するタイマーの競合状態を修正しました (bsc#1239073)。
    - CVE-2025-21772：パーティション：mac：偽造パーティションテーブルの処理を修正します（bsc#1238911）。
    - CVE-2025-21780: drm/amdgpu: smu_sys_set_pp_table() のバッファオーバーフローのアタッチを回避します (bsc#1239115)。


Tenable は、前述の記述ブロックを SUSE セキュリティアドバイザリから直接抽出しています。

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

ID	名前	製品	ファミリー	公開日	更新日	深刻度
273419	Unity Linux 20.1070a Security Update: kernel (UTSA-2025-989837)	Nessus	Unity Linux Local Security Checks	2025/11/5	2025/11/5	medium
230116	Linux Distros のパッチ未適用の脆弱性: CVE-2021-47635	Nessus	Misc.	2025/3/5	2025/10/28	medium
230116	Linux Distros Unpatched Vulnerability : CVE-2021-47635	Nessus	Misc.	2025/3/5	2025/10/28	medium
230116	Linux Distros 未修補弱點：CVE-2021-47635	Nessus	Misc.	2025/3/5	2025/10/28	medium
270920	Unity Linux 20.1070e Security Update: kernel (UTSA-2025-987656)	Nessus	Unity Linux Local Security Checks	2025/10/21	2025/10/21	medium
230116	Linux Distros 未修补的漏洞：CVE-2021-47635	Nessus	Misc.	2025/3/5	2025/10/28	medium
233410	SUSE SLES15 Security Update : kernel (SUSE-SU-2025:1027-1)	Nessus	SuSE Local Security Checks	2025/3/27	2025/9/24	high
234407	SUSE SLES15 Security Update : kernel (SUSE-SU-2025:1241-1)	Nessus	SuSE Local Security Checks	2025/4/15	2025/10/28	high
233410	SUSE SLES15 セキュリティ更新 : kernel (SUSE-SU-2025:1027-1)	Nessus	SuSE Local Security Checks	2025/3/27	2025/9/24	high
234407	SUSE SLES15 セキュリティ更新 : kernel (SUSE-SU-2025:1241-1)	Nessus	SuSE Local Security Checks	2025/4/15	2025/10/28	high

検出

プラグインの検索

medium

medium

medium

medium

medium

medium

high

high

high

high