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

  - m68k透過 /proc/sysrq_trigger 強制工作反向追踪記錄時若 PC 不在例外表格 __get_kernel_nofault() 中在監督模式下複製資料只強制執行 030 匯流排錯誤。預計當記錄沒有相關工作佇列的核心工作時這會造成在 NULL 指標解除參照等上發生匯流排錯誤例外狀況。應忽略此匯流排錯誤。我們的 030 匯流排錯誤處置程式無法處理此問題每當 ssw 指出核心模式存取有資料錯誤時我們甚至都不嘗試處理該錯誤而是一律傳送 SEGV 訊號 (或不穩定)。因此在錯誤的 PC 中處理例外狀況的檢查 (隱藏在 send_sig_fault() 中最終會從 do_page_fault() 呼叫) 從未使用過。
    相反地040 和 060 存取錯誤處置程式並不關心監督模式存取上是否發生錯誤而且會呼叫這些存取上的 do_page_fault()最終接受例外表格。若例外表格中有錯誤 PC 的項目則在 bus_error030 中新增檢查以呼叫 do_page_fault()。我曾在 2019 年稍早嘗試過此問題的修正但此修補程式應該更通用。在 030 Atari Falcon 上測試。
    (CVE-2023-54232)

請注意，Nessus 依賴供應商報告的套件存在。

Linux/Unix 主机中安装的一个或多个程序包受到一个漏洞影响，而供应商没有提供补丁程序。

  - m68k仅当 PC 不在异常表中时 __get_kernel_nofault() 在通过 /proc/sysrq_trigger 强制任务回溯日志时在监控程序模式下复制数据时才强制 030 总线错误。预计这会导致总线错误异常例如当记录的内核任务没有相关联的空指针取消引用时。应忽略此总线错误。我们的 030 总线错误处理程序无法处理此问题每当 ssw 指示对数据进行内核模式访问错误时我们甚至不会尝试处理该错误而是始终发送 SEGV 信号或错误。因此绝不会使用对错误 PC在 send_sig_fault() 中掩码最终从 do_page_fault() 调用的异常处理的检查。
    相比之下040 和 060 访问错误处理程序不在乎管理员模式访问是否发生错误都会对这些错误处理调用 do_page_fault()从而最终遵守异常表。在 bus_error030 中新增一个检查以便在异常表中无错误 PC 的条目时调用 do_page_fault()。我曾在 2019 年早些时候尝试修复此问题确实依赖于测试 pagefault_disabled()请参阅下面的链接来实现相同的目的但此修补程序应该更通用。已在 030 Atari Falcon 上测试。
    (CVE-2023-54232)

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

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

  - m68kPC が /proc/sysrq_trigger を通じてタスクバックトレースログを強制する際に、例外テーブル __get_kernel_nofault() がスーパーバイザーモードでデータをコピーする場合、030 バスエラーのみを強制します。これは、カーネルタスクのロギングにワークキューが関連付けられていない場合、NULL ポインターデリファレンスなどでバスエラーの例外を引き起こすことが想定されます。このバスエラーは無視する必要があります。: 030 バスエラーハンドラーはこれに対処する能力が欠けています: ssw がデータ障害でカーネルモードアクセスを示すときは常に、障害の処理を試行せず、その代わりに常に SEGV 信号またはパニックを送信します。結果として、障害 PC (最終的に do_page_fault() から呼び出される send_sig_fault() に埋め込まれる) の例外処理のチェックが使用されません。
    対照的に、040 と 060 の両方のアクセスエラーハンドラーは、スーパーバイザーモードのアクセスで障害が発生したかどうかを考慮せず、これらのモードで do_page_fault() を呼び出し、最終的に例外テーブルを遵守します。例外テーブルに障害 PC のエントリがある場合に、do_page_fault() を呼び出すために bus_error030 にチェックを追加します。2019年にこの問題の修正を試みました。これは、pagefault_disabled()のテスト以下のリンクを参照して同じことを達成しましたが、このパッチはより一般的になる必要があります。030 Atari Falcon でテスト済みです。
    (CVE-2023-54232)

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

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	名称	产品	系列	发布时间	最近更新时间	严重程度
281716	Linux Distros 未修補的弱點：CVE-2023-54232	Nessus	Misc.	2026/1/5	2026/2/3	medium
281716	Linux Distros 未修补的漏洞：CVE-2023-54232	Nessus	Misc.	2026/1/5	2026/2/3	medium
281716	Linux Distros のパッチ未適用の脆弱性: CVE-2023-54232	Nessus	Misc.	2026/1/5	2026/2/3	medium
309245	Unity Linux 20.1060a / 20.1070a Security Update: kernel (UTSA-2026-013636)	Nessus	Unity Linux Local Security Checks	2026/4/22	2026/4/26	medium
281716	Linux Distros Unpatched Vulnerability : CVE-2023-54232	Nessus	Misc.	2026/1/5	2026/2/3	medium
307969	Unity Linux 20.1070e Security Update: kernel (UTSA-2026-013290)	Nessus	Unity Linux Local Security Checks	2026/4/21	2026/4/21	medium
308560	Unity Linux 20.1060e / 20.1070e Security Update: kernel (UTSA-2026-010915)	Nessus	Unity Linux Local Security Checks	2026/4/21	2026/4/21	medium
151965	Photon OS 4.0: Linux PHSA-2021-4.0-0065	Nessus	PhotonOS Local Security Checks	2021/7/22	2026/3/23	high

检测

插件搜索

medium

medium

medium

medium

medium

medium

medium

high