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

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

    m68k: Only force 030 bus error if PC not in exception table

    __get_kernel_nofault() does copy data in supervisor mode when     forcing a task backtrace log through /proc/sysrq_trigger.
    This is expected cause a bus error exception on e.g. NULL     pointer dereferencing when logging a kernel task has no     workqueue associated. This bus error ought to be ignored.

    Our 030 bus error handler is ill equipped to deal with this:

    Whenever ssw indicates a kernel mode access on a data fault,     we don't even attempt to handle the fault and instead always     send a SEGV signal (or panic). As a result, the check     for exception handling at the fault PC (buried in     send_sig_fault() which gets called from do_page_fault()     eventually) is never used.

    In contrast, both 040 and 060 access error handlers do not     care whether a fault happened on supervisor mode access,     and will call do_page_fault() on those, ultimately honoring     the exception table.

    Add a check in bus_error030 to call do_page_fault() in case     we do have an entry for the fault PC in our exception table.

    I had attempted a fix for this earlier in 2019 that did rely     on testing pagefault_disabled() (see link below) to achieve     the same thing, but this patch should be more generic.

    Tested on 030 Atari Falcon.

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.

  - m68k: Only force 030 bus error if PC not in exception table __get_kernel_nofault() does copy data in     supervisor mode when forcing a task backtrace log through /proc/sysrq_trigger. This is expected cause a     bus error exception on e.g. NULL pointer dereferencing when logging a kernel task has no workqueue     associated. This bus error ought to be ignored. Our 030 bus error handler is ill equipped to deal with     this: Whenever ssw indicates a kernel mode access on a data fault, we don't even attempt to handle the     fault and instead always send a SEGV signal (or panic). As a result, the check for exception handling at     the fault PC (buried in send_sig_fault() which gets called from do_page_fault() eventually) is never used.
    In contrast, both 040 and 060 access error handlers do not care whether a fault happened on supervisor     mode access, and will call do_page_fault() on those, ultimately honoring the exception table. Add a check     in bus_error030 to call do_page_fault() in case we do have an entry for the fault PC in our exception     table. I had attempted a fix for this earlier in 2019 that did rely on testing pagefault_disabled() (see     link below) to achieve the same thing, but this patch should be more generic. Tested on 030 Atari Falcon.
    (CVE-2023-54232)

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

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

    m68k: Only force 030 bus error if PC not in exception table

    __get_kernel_nofault() does copy data in supervisor mode when     forcing a task backtrace log through /proc/sysrq_trigger.
    This is expected cause a bus error exception on e.g. NULL     pointer dereferencing when logging a kernel task has no     workqueue associated. This bus error ought to be ignored.

    Our 030 bus error handler is ill equipped to deal with this:

    Whenever ssw indicates a kernel mode access on a data fault,     we don't even attempt to handle the fault and instead always     send a SEGV signal (or panic). As a result, the check     for exception handling at the fault PC (buried in     send_sig_fault() which gets called from do_page_fault()     eventually) is never used.

    In contrast, both 040 and 060 access error handlers do not     care whether a fault happened on supervisor mode access,     and will call do_page_fault() on those, ultimately honoring     the exception table.

    Add a check in bus_error030 to call do_page_fault() in case     we do have an entry for the fault PC in our exception table.

    I had attempted a fix for this earlier in 2019 that did rely     on testing pagefault_disabled() (see link below) to achieve     the same thing, but this patch should be more generic.

    Tested on 030 Atari Falcon.

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

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

    m68k: Only force 030 bus error if PC not in exception table

    __get_kernel_nofault() does copy data in supervisor mode when     forcing a task backtrace log through /proc/sysrq_trigger.
    This is expected cause a bus error exception on e.g. NULL     pointer dereferencing when logging a kernel task has no     workqueue associated. This bus error ought to be ignored.

    Our 030 bus error handler is ill equipped to deal with this:

    Whenever ssw indicates a kernel mode access on a data fault,     we don't even attempt to handle the fault and instead always     send a SEGV signal (or panic). As a result, the check     for exception handling at the fault PC (buried in     send_sig_fault() which gets called from do_page_fault()     eventually) is never used.

    In contrast, both 040 and 060 access error handlers do not     care whether a fault happened on supervisor mode access,     and will call do_page_fault() on those, ultimately honoring     the exception table.

    Add a check in bus_error030 to call do_page_fault() in case     we do have an entry for the fault PC in our exception table.

    I had attempted a fix for this earlier in 2019 that did rely     on testing pagefault_disabled() (see link below) to achieve     the same thing, but this patch should be more generic.

    Tested on 030 Atari Falcon.

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
309245	Unity Linux 20.1060a / 20.1070a Security Update: kernel (UTSA-2026-013636)	Nessus	Unity Linux Local Security Checks	4/22/2026	4/26/2026	medium
281716	Linux Distros Unpatched Vulnerability : CVE-2023-54232	Nessus	Misc.	1/5/2026	2/3/2026	medium
307969	Unity Linux 20.1070e Security Update: kernel (UTSA-2026-013290)	Nessus	Unity Linux Local Security Checks	4/21/2026	4/21/2026	medium
308560	Unity Linux 20.1060e / 20.1070e Security Update: kernel (UTSA-2026-010915)	Nessus	Unity Linux Local Security Checks	4/21/2026	4/21/2026	medium
151965	Photon OS 4.0: Linux PHSA-2021-4.0-0065	Nessus	PhotonOS Local Security Checks	7/22/2021	3/23/2026	high

Detections

Analytics

Plugins Search

medium

medium

medium

medium

high