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

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

    riscv: fix reserved memory setup

    Currently, RISC-V sets up reserved memory using the early copy of the     device tree. As a result, when trying to get a reserved memory region     using of_reserved_mem_lookup(), the pointer to reserved memory regions     is using the early, pre-virtual-memory address which causes a kernel     panic when trying to use the buffer's name:

     Unable to handle kernel paging request at virtual address 00000000401c31ac      Oops [#1]      Modules linked in:
     CPU: 0 PID: 0 Comm: swapper Not tainted 6.0.0-rc1-00001-g0d9d6953d834 #1      Hardware name: Microchip PolarFire-SoC Icicle Kit (DT)      epc : string+0x4a/0xea       ra : vsnprintf+0x1e4/0x336      epc : ffffffff80335ea0 ra : ffffffff80338936 sp : ffffffff81203be0       gp : ffffffff812e0a98 tp : ffffffff8120de40 t0 : 0000000000000000       t1 : ffffffff81203e28 t2 : 7265736572203a46 s0 : ffffffff81203c20       s1 : ffffffff81203e28 a0 : ffffffff81203d22 a1 : 0000000000000000       a2 : ffffffff81203d08 a3 : 0000000081203d21 a4 : ffffffffffffffff       a5 : 00000000401c31ac a6 : ffff0a00ffffff04 a7 : ffffffffffffffff       s2 : ffffffff81203d08 s3 : ffffffff81203d00 s4 : 0000000000000008       s5 : ffffffff000000ff s6 : 0000000000ffffff s7 : 00000000ffffff00       s8 : ffffffff80d9821a s9 : ffffffff81203d22 s10: 0000000000000002       s11: ffffffff80d9821c t3 : ffffffff812f3617 t4 : ffffffff812f3617       t5 : ffffffff812f3618 t6 : ffffffff81203d08      status: 0000000200000100 badaddr: 00000000401c31ac cause: 000000000000000d      [<ffffffff80338936>] vsnprintf+0x1e4/0x336      [<ffffffff80055ae2>] vprintk_store+0xf6/0x344      [<ffffffff80055d86>] vprintk_emit+0x56/0x192      [<ffffffff80055ed8>] vprintk_default+0x16/0x1e      [<ffffffff800563d2>] vprintk+0x72/0x80      [<ffffffff806813b2>] _printk+0x36/0x50      [<ffffffff8068af48>] print_reserved_mem+0x1c/0x24      [<ffffffff808057ec>] paging_init+0x528/0x5bc      [<ffffffff808031ae>] setup_arch+0xd0/0x592      [<ffffffff8080070e>] start_kernel+0x82/0x73c

    early_init_fdt_scan_reserved_mem() takes no arguments as it operates on     initial_boot_params, which is populated by early_init_dt_verify(). On     RISC-V, early_init_dt_verify() is called twice. Once, directly, in     setup_arch() if CONFIG_BUILTIN_DTB is not enabled and once indirectly,     very early in the boot process, by parse_dtb() when it calls     early_init_dt_scan_nodes().

    This first call uses dtb_early_va to set initial_boot_params, which is     not usable later in the boot process when     early_init_fdt_scan_reserved_mem() is called. On arm64 for example, the     corresponding call to early_init_dt_scan_nodes() uses fixmap addresses     and doesn't suffer the same fate.

    Move early_init_fdt_scan_reserved_mem() further along the boot sequence,     after the direct call to early_init_dt_verify() in setup_arch() so that     the names use the correct virtual memory addresses. The above supposed     that CONFIG_BUILTIN_DTB was not set, but should work equally in the case     where it is - unflatted_and_copy_device_tree() also updates     initial_boot_params.

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.

  - riscv: fix reserved memory setup Currently, RISC-V sets up reserved memory using the early copy of the     device tree. As a result, when trying to get a reserved memory region using of_reserved_mem_lookup(), the     pointer to reserved memory regions is using the early, pre-virtual-memory address which causes a kernel     panic when trying to use the buffer's name: Unable to handle kernel paging request at virtual address     00000000401c31ac Oops [#1] Modules linked in: CPU: 0 PID: 0 Comm: swapper Not tainted     6.0.0-rc1-00001-g0d9d6953d834 #1 Hardware name: Microchip PolarFire-SoC Icicle Kit (DT) epc :
    string+0x4a/0xea ra : vsnprintf+0x1e4/0x336 epc : ffffffff80335ea0 ra : ffffffff80338936 sp :
    ffffffff81203be0 gp : ffffffff812e0a98 tp : ffffffff8120de40 t0 : 0000000000000000 t1 : ffffffff81203e28     t2 : 7265736572203a46 s0 : ffffffff81203c20 s1 : ffffffff81203e28 a0 : ffffffff81203d22 a1 :
    0000000000000000 a2 : ffffffff81203d08 a3 : 0000000081203d21 a4 : ffffffffffffffff a5 : 00000000401c31ac     a6 : ffff0a00ffffff04 a7 : ffffffffffffffff s2 : ffffffff81203d08 s3 : ffffffff81203d00 s4 :
    0000000000000008 s5 : ffffffff000000ff s6 : 0000000000ffffff s7 : 00000000ffffff00 s8 : ffffffff80d9821a     s9 : ffffffff81203d22 s10: 0000000000000002 s11: ffffffff80d9821c t3 : ffffffff812f3617 t4 :
    ffffffff812f3617 t5 : ffffffff812f3618 t6 : ffffffff81203d08 status: 0000000200000100 badaddr:
    00000000401c31ac cause: 000000000000000d [<ffffffff80338936>] vsnprintf+0x1e4/0x336 [<ffffffff80055ae2>]     vprintk_store+0xf6/0x344 [<ffffffff80055d86>] vprintk_emit+0x56/0x192 [<ffffffff80055ed8>]     vprintk_default+0x16/0x1e [<ffffffff800563d2>] vprintk+0x72/0x80 [<ffffffff806813b2>] _printk+0x36/0x50     [<ffffffff8068af48>] print_reserved_mem+0x1c/0x24 [<ffffffff808057ec>] paging_init+0x528/0x5bc     [<ffffffff808031ae>] setup_arch+0xd0/0x592 [<ffffffff8080070e>] start_kernel+0x82/0x73c     early_init_fdt_scan_reserved_mem() takes no arguments as it operates on initial_boot_params, which is     populated by early_init_dt_verify(). On RISC-V, early_init_dt_verify() is called twice. Once, directly, in     setup_arch() if CONFIG_BUILTIN_DTB is not enabled and once indirectly, very early in the boot process, by     parse_dtb() when it calls early_init_dt_scan_nodes(). This first call uses dtb_early_va to set     initial_boot_params, which is not usable later in the boot process when early_init_fdt_scan_reserved_mem()     is called. On arm64 for example, the corresponding call to early_init_dt_scan_nodes() uses fixmap     addresses and doesn't suffer the same fate. Move early_init_fdt_scan_reserved_mem() further along the boot     sequence, after the direct call to early_init_dt_verify() in setup_arch() so that the names use the     correct virtual memory addresses. The above supposed that CONFIG_BUILTIN_DTB was not set, but should work     equally in the case where it is - unflatted_and_copy_device_tree() also updates initial_boot_params.
    (CVE-2022-49851)

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

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

    riscv: fix reserved memory setup

    Currently, RISC-V sets up reserved memory using the early copy of the     device tree. As a result, when trying to get a reserved memory region     using of_reserved_mem_lookup(), the pointer to reserved memory regions     is using the early, pre-virtual-memory address which causes a kernel     panic when trying to use the buffer's name:

     Unable to handle kernel paging request at virtual address 00000000401c31ac      Oops [#1]      Modules linked in:
     CPU: 0 PID: 0 Comm: swapper Not tainted 6.0.0-rc1-00001-g0d9d6953d834 #1      Hardware name: Microchip PolarFire-SoC Icicle Kit (DT)      epc : string+0x4a/0xea       ra : vsnprintf+0x1e4/0x336      epc : ffffffff80335ea0 ra : ffffffff80338936 sp : ffffffff81203be0       gp : ffffffff812e0a98 tp : ffffffff8120de40 t0 : 0000000000000000       t1 : ffffffff81203e28 t2 : 7265736572203a46 s0 : ffffffff81203c20       s1 : ffffffff81203e28 a0 : ffffffff81203d22 a1 : 0000000000000000       a2 : ffffffff81203d08 a3 : 0000000081203d21 a4 : ffffffffffffffff       a5 : 00000000401c31ac a6 : ffff0a00ffffff04 a7 : ffffffffffffffff       s2 : ffffffff81203d08 s3 : ffffffff81203d00 s4 : 0000000000000008       s5 : ffffffff000000ff s6 : 0000000000ffffff s7 : 00000000ffffff00       s8 : ffffffff80d9821a s9 : ffffffff81203d22 s10: 0000000000000002       s11: ffffffff80d9821c t3 : ffffffff812f3617 t4 : ffffffff812f3617       t5 : ffffffff812f3618 t6 : ffffffff81203d08      status: 0000000200000100 badaddr: 00000000401c31ac cause: 000000000000000d      [<ffffffff80338936>] vsnprintf+0x1e4/0x336      [<ffffffff80055ae2>] vprintk_store+0xf6/0x344      [<ffffffff80055d86>] vprintk_emit+0x56/0x192      [<ffffffff80055ed8>] vprintk_default+0x16/0x1e      [<ffffffff800563d2>] vprintk+0x72/0x80      [<ffffffff806813b2>] _printk+0x36/0x50      [<ffffffff8068af48>] print_reserved_mem+0x1c/0x24      [<ffffffff808057ec>] paging_init+0x528/0x5bc      [<ffffffff808031ae>] setup_arch+0xd0/0x592      [<ffffffff8080070e>] start_kernel+0x82/0x73c

    early_init_fdt_scan_reserved_mem() takes no arguments as it operates on     initial_boot_params, which is populated by early_init_dt_verify(). On     RISC-V, early_init_dt_verify() is called twice. Once, directly, in     setup_arch() if CONFIG_BUILTIN_DTB is not enabled and once indirectly,     very early in the boot process, by parse_dtb() when it calls     early_init_dt_scan_nodes().

    This first call uses dtb_early_va to set initial_boot_params, which is     not usable later in the boot process when     early_init_fdt_scan_reserved_mem() is called. On arm64 for example, the     corresponding call to early_init_dt_scan_nodes() uses fixmap addresses     and doesn't suffer the same fate.

    Move early_init_fdt_scan_reserved_mem() further along the boot sequence,     after the direct call to early_init_dt_verify() in setup_arch() so that     the names use the correct virtual memory addresses. The above supposed     that CONFIG_BUILTIN_DTB was not set, but should work equally in the case     where it is - unflatted_and_copy_device_tree() also updates     initial_boot_params.

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.

An update of the linux package has been released.

ID	Name	Product	Family	Published	Updated	Severity
275102	Unity Linux 20.1070e Security Update: kernel (UTSA-2025-990750)	Nessus	Unity Linux Local Security Checks	11/12/2025	11/12/2025	high
297592	EulerOS 2.0 SP13 : kernel (EulerOS-SA-2026-1224)	Nessus	Huawei Local Security Checks	2/2/2026	2/4/2026	high
302971	EulerOS Virtualization 2.13.0 : kernel (EulerOS-SA-2026-1629)	Nessus	Huawei Local Security Checks	3/18/2026	3/18/2026	high
250040	Linux Distros Unpatched Vulnerability : CVE-2022-49851	Nessus	Misc.	8/15/2025	1/14/2026	high
281266	Unity Linux 20.1060a / 20.1070a Security Update: kernel (UTSA-2025-992781)	Nessus	Unity Linux Local Security Checks	12/31/2025	12/31/2025	high
151965	Photon OS 4.0: Linux PHSA-2021-4.0-0065	Nessus	PhotonOS Local Security Checks	7/22/2021	3/23/2026	high
302981	EulerOS Virtualization 2.13.1 : kernel (EulerOS-SA-2026-1637)	Nessus	Huawei Local Security Checks	3/18/2026	3/18/2026	high
297598	EulerOS 2.0 SP13 : kernel (EulerOS-SA-2026-1212)	Nessus	Huawei Local Security Checks	2/2/2026	2/4/2026	high

Detections

Analytics

Plugins Search

high

high

high

high

high

high

high

high