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

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

    x86/tdx: Panic on bad configs that #VE on private memory access

    All normal kernel memory is TDX private memory.  This includes     everything from kernel stacks to kernel text.  Handling     exceptions on arbitrary accesses to kernel memory is essentially     impossible because they can happen in horribly nasty places like     kernel entry/exit.  But, TDX hardware can theoretically _deliver_     a virtualization exception (#VE) on any access to private memory.

    But, it's not as bad as it sounds.  TDX can be configured to never     deliver these exceptions on private memory with a TD attribute     called ATTR_SEPT_VE_DISABLE.  The guest has no way to *set* this     attribute, but it can check it.

    Ensure ATTR_SEPT_VE_DISABLE is set in early boot.  panic() if it     is unset.  There is no sane way for Linux to run with this     attribute clear so a panic() is appropriate.

    There's small window during boot before the check where kernel     has an early #VE handler. But the handler is only for port I/O     and will also panic() as soon as it sees any other #VE, such as     a one generated by a private memory access.

    [ dhansen: Rewrite changelog and rebase on new tdx_parse_tdinfo().
               Add Kirill's tested-by because I made changes since                he wrote this. ]

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:02173-1 advisory.

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


    The following security bugs were fixed:

    - CVE-2022-49775: tcp: cdg: allow tcp_cdg_release() to be called multiple times (bsc#1242245).
    - CVE-2024-53168: net: make sock_inuse_add() available (bsc#1234887).
    - CVE-2024-56558: nfsd: make sure exp active before svc_export_show (bsc#1235100).
    - CVE-2025-21999: proc: fix UAF in proc_get_inode() (bsc#1240802).
    - CVE-2025-22056: netfilter: nft_tunnel: fix geneve_opt type confusion addition (bsc#1241525).
    - CVE-2025-23145: mptcp: fix NULL pointer in can_accept_new_subflow (bsc#1242596).
    - CVE-2025-37789: net: openvswitch: fix nested key length validation in the set() action (bsc#1242762).
    - CVE-2024-28956: x86/its: Add support for ITS-safe indirect thunk (bsc#1242006).
    - CVE-2025-37785: ext4: fix OOB read when checking dotdot dir (bsc#1241640).


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.

  - In the Linux kernel, the following vulnerability has been resolved: x86/tdx: Panic on bad configs that #VE     on private memory access All normal kernel memory is TDX private memory. This includes everything from     kernel stacks to kernel text. Handling exceptions on arbitrary accesses to kernel memory is essentially     impossible because they can happen in horribly nasty places like kernel entry/exit. But, TDX hardware can     theoretically _deliver_ a virtualization exception (#VE) on any access to private memory. But, it's not as     bad as it sounds. TDX can be configured to never deliver these exceptions on private memory with a TD     attribute called ATTR_SEPT_VE_DISABLE. The guest has no way to *set* this attribute, but it can check it.
    Ensure ATTR_SEPT_VE_DISABLE is set in early boot. panic() if it is unset. There is no sane way for Linux     to run with this attribute clear so a panic() is appropriate. There's small window during boot before the     check where kernel has an early #VE handler. But the handler is only for port I/O and will also panic() as     soon as it sees any other #VE, such as a one generated by a private memory access. [ dhansen: Rewrite     changelog and rebase on new tdx_parse_tdinfo(). Add Kirill's tested-by because I made changes since he     wrote this. ] (CVE-2022-49886)

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-2026-013478 advisory.

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

    x86/tdx: Panic on bad configs that #VE on private memory access

    All normal kernel memory is TDX private memory.  This includes     everything from kernel stacks to kernel text.  Handling     exceptions on arbitrary accesses to kernel memory is essentially     impossible because they can happen in horribly nasty places like     kernel entry/exit.  But, TDX hardware can theoretically _deliver_     a virtualization exception (#VE) on any access to private memory.

    But, it's not as bad as it sounds.  TDX can be configured to never     deliver these exceptions on private memory with a TD attribute     called ATTR_SEPT_VE_DISABLE.  The guest has no way to *set* this     attribute, but it can check it.

    Ensure ATTR_SEPT_VE_DISABLE is set in early boot.  panic() if it     is unset.  There is no sane way for Linux to run with this     attribute clear so a panic() is appropriate.

    There's small window during boot before the check where kernel     has an early #VE handler. But the handler is only for port I/O     and will also panic() as soon as it sees any other #VE, such as     a one generated by a private memory access.

    [ dhansen: Rewrite changelog and rebase on new tdx_parse_tdinfo().
               Add Kirill's tested-by because I made changes since                he wrote this. ]

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.

ID	Name	Product	Family	Published	Updated	Severity
308669	Unity Linux 20.1070e Security Update: kernel (UTSA-2026-010870)	Nessus	Unity Linux Local Security Checks	4/21/2026	4/21/2026	medium
241036	SUSE SLES15: cluster-md-kmp-default / dlm-kmp-default / gfs2-kmp-default / etc (SUSE-SU-2025:02173-1)	Nessus	SuSE Local Security Checks	7/1/2025	6/25/2026	medium
248661	Linux Distros Unpatched Vulnerability : CVE-2022-49886	Nessus	Misc.	8/12/2025	7/17/2026	medium
309247	Unity Linux 20.1070a Security Update: kernel (UTSA-2026-013478)	Nessus	Unity Linux Local Security Checks	4/22/2026	4/22/2026	medium

Detections

Analytics

Plugins Search

medium

medium

medium

medium