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

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.

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.

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.

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

ID	Name	Product	Family	Severity
273419	Unity Linux 20.1070a Security Update: kernel (UTSA-2025-989837)	Nessus	Unity Linux Local Security Checks	medium
270920	Unity Linux 20.1070e Security Update: kernel (UTSA-2025-987656)	Nessus	Unity Linux Local Security Checks	medium
234407	SUSE SLES15 Security Update : kernel (SUSE-SU-2025:1241-1)	Nessus	SuSE Local Security Checks	high
233410	SUSE SLES15 Security Update : kernel (SUSE-SU-2025:1027-1)	Nessus	SuSE Local Security Checks	high
230116	Linux Distros Unpatched Vulnerability : CVE-2021-47635	Nessus	Misc.	medium

Detections

Analytics

CVE-2021-47635

medium

Tenable Plugins

medium

medium

high

high

medium