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

  - 郵箱：imx：新增頻道關閉欄位 sashiko 抱怨可能存在的拆卸問題。案例 CPU 0 CPU 1 imx_mu_isr（） imx_mu_shutdown（） imx_mu_xcr_rmw（priv， IMX_MU_RCR， 0， IMX_MU_xCR_RIEn（priv->dcfg->type， cp->idx））;imx_mu_specific_rx（） imx_mu_xcr_rmw（priv， IMX_MU_RCR， IMX_MU_xCR_RIEn（priv->dcfg->type， 0）， 0）;free_irq（） RX 事件保持啟用狀態，因為在這個短窗口中，當中斷處於活動狀態時，RX 事件在 ->shutdown（） 中被禁用，然後在 free_irq（） 中等待 ->shutdown 時由 ISR 再次啟用。此爭用需要計時，如果發生，如果已移除的通道觸發中斷，則共用處理常式可能會發生問題。在這種情況下，irq-core 將關閉帶有無人關心訊息的中斷。引入 imx_mu_con_priv：：shutdown 以表示通道正在關閉。此標誌是在鎖定保持的情況下設定的（由 imx_mu_xcr_clr_shut（））。取消遮罩端使用 imx_mu_xcr_set_act（），它僅在通道尚未關閉並在同一鎖定上序列化時啟用該事件。（CVE-2026-98903）

請注意，Nessus 的判定取決於廠商所報告的套件是否存在。

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

  - mailbox：imx：添加通道关闭字段，sashiko 抱怨可能存在的拆卸问题。场景 CPU 0 CPU 1 imx_mu_isr（） imx_mu_shutdown（） imx_mu_xcr_rmw（priv， IMX_MU_RCR， 0， IMX_MU_xCR_RIEn（priv->dcfg->type， cp->idx））;imx_mu_specific_rx（） imx_mu_xcr_rmw（priv， IMX_MU_RCR， IMX_MU_xCR_RIEn（priv->dcfg->type， 0）， 0）;free_irq（） RX 事件保持启用状态，这是因为在此短窗口中，当中断处于活动状态时，RX 事件会在 ->shutdown（） 中禁用，然后在 free_irq（） 中等待 ->shutdown 时由 ISR 再次启用。此争用要求计时，如果发生的情况，如果删除的通道触发了中断，则会在共享处理程序上产生问题。在这种情况下，irq-core 将关闭中断并显示 nobody careed 消息。引入 imx_mu_con_priv：：shutdown 以表示通道正在关闭。此标记是在（通过 imx_mu_xcr_clr_shut（））保持的锁定的情况下设置的。取消掩码端使用 imx_mu_xcr_set_act（），它仅在通道未关闭时启用事件，并且在同一锁定上序列化。（CVE-2026-98903）

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

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

  - mailbox:imx:チャネルシャットダウンフィールドを追加 sashiko 氏は、ティアダウンの問題の可能性について苦情を申し立てました。シナリオ CPU 0 CPU 1 imx_mu_isr() imx_mu_shutdown() imx_mu_xcr_rmw(priv, IMX_MU_RCR, 0, IMX_MU_xCR_RIEn(priv->dcfg->type, cp->idx));imx_mu_specific_rx() imx_mu_xcr_rmw(priv, IMX_MU_RCR, IMX_MU_xCR_RIEn(priv->dcfg->type, 0), 0);free_irq() この短いウィンドウで、割り込みがアクティブな間に RX イベントが ->shutdown() で無効化され、->shutdown が free_irq() で待機している間に ISR によって再度有効化されるため、RX イベントは有効なままになります。この競合にはタイミングが必要です。発生した場合、削除されたチャネルが割り込みをトリガーすると、共有ハンドラーで問題になる可能性があります。この場合、irq-core は「nobody careed」メッセージで割り込みをシャットダウンします。チャネルがシャットダウンしていることを知らせるために imx_mu_con_priv::shutdown を導入します。このフラグは、ロックが保持された状態で(imx_mu_xcr_clr_shut() により設定されます)。マスク解除側では imx_mu_xcr_set_act() が使用され、チャネルがシャットダウンされておらず、同じロックでシリアル化されている場合にのみイベントを有効にします。(CVE-2026-98903)

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

An update of the linux package has been released.

The Linux/Unix host has one or more packages installed that are impacted by a vulnerability without a vendor supplied patch available.

  - mailbox: imx: Add a channel shutdown field sashiko complained about possible teardown problem. The     scenario CPU 0 CPU 1 imx_mu_isr() imx_mu_shutdown() imx_mu_xcr_rmw(priv, IMX_MU_RCR, 0,     IMX_MU_xCR_RIEn(priv->dcfg->type, cp->idx)); imx_mu_specific_rx() imx_mu_xcr_rmw(priv, IMX_MU_RCR,     IMX_MU_xCR_RIEn(priv->dcfg->type, 0), 0); free_irq() The RX event remains enabled because in this short     window the RX event was disabled in ->shutdown() while the interrupt was active and then enabled again by     the ISR while ->shutdown waited in free_irq(). This race requires timing and if happens can be problematic     on shared handlers if the removed channel triggers an interrupt. In this case the irq-core will shutdown     the interrupt with the nobody cared message. Introduce imx_mu_con_priv::shutdown to signal that the     channel is shutting down. This flag is set with the lock held (by imx_mu_xcr_clr_shut()). The unmask side     uses imx_mu_xcr_set_act() which only enables the event if the channel has not been shutdown and serialises     on the same lock. (CVE-2026-98903)

Note that Nessus relies on the presence of the package as reported by the vendor.

The AlmaLinux 9.2 host has packages installed that are affected by multiple vulnerabilities as referenced in the TuxCare ALMALINUX9.2:CLSA-2026:1794643812 advisory.

  - In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: add HE 6 GHz     capability in the scan elems len The HE 6 GHz Band Capability element is in the probe request for every     band if 6 GHz is supported, so add the size to scan_ies_len. Otherwise, building probe request elements     can fail, triggering the WARN_ON in __ieee80211_start_scan(). (CVE-2026-98328)

  - In the Linux kernel, the following vulnerability has been resolved: bpf: Fix issue in verifying     allow_ptr_leaks After we converted the capabilities of our networking-bpf program from cap_sys_admin to     cap_net_admin+cap_bpf, our networking-bpf program failed to start. Because it failed the bpf verifier, and     the error log is R3 pointer comparison prohibited. A simple reproducer as follows, SEC(cls-ingress)     int ingress(struct __sk_buff *skb) { struct iphdr *iph = (void *)(long)skb->data + sizeof(struct ethhdr);
    if ((long)(iph + 1) > (long)skb->data_end) return TC_ACT_STOLEN; return TC_ACT_OK; } Per discussion with     Yonghong and Alexei [1], comparison of two packet pointers is not a pointer leak. This patch fixes it. Our     local kernel is 6.1.y and we expect this fix to be backported to 6.1.y, so stable is CCed. [1].
    https://lore.kernel.org/bpf/CAADnVQ+Nmspr7Si+pxWn8zkE7hX-7s93ugwC+94aXSy4uQ9vBg@mail.gmail.com/     (CVE-2023-54181)

  - In the Linux kernel, the following vulnerability has been resolved: driver core: Avoid warning when     removing a device while its supplier is unbinding During driver removal, the following warning can appear:
    WARNING: CPU: 1 PID: 139 at drivers/base/core.c:1497 __device_links_no_driver+0xcc/0xfc ... Call trace:
    __device_links_no_driver+0xcc/0xfc (P) device_links_driver_cleanup+0xa8/0xf0     device_release_driver_internal+0x208/0x23c device_links_unbind_consumers+0xe0/0x108     device_release_driver_internal+0xec/0x23c device_links_unbind_consumers+0xe0/0x108     device_release_driver_internal+0xec/0x23c device_links_unbind_consumers+0xe0/0x108     device_release_driver_internal+0xec/0x23c driver_detach+0xa0/0x12c bus_remove_driver+0x6c/0xbc     driver_unregister+0x30/0x60 pci_unregister_driver+0x20/0x9c lan966x_pci_driver_exit+0x18/0xa90     [lan966x_pci] This warning is triggered when a consumer is removed because the links status of its     supplier is not DL_DEV_DRIVER_BOUND and the link flag DL_FLAG_SYNC_STATE_ONLY is not set. The topology in     terms of consumers/suppliers used was the following (consumer ---> supplier): i2c -----------> OIC ---->     PCI device | ^ | | +---> pinctrl ---+ When the PCI device is removed, the OIC (interrupt controller) has     to be removed. In order to remove the OIC, pinctrl and i2c need to be removed and to remove pinctrl, i2c     need to be removed. The removal order is: 1) i2c 2) pinctrl 3) OIC 4) PCI device In details, the removal     sequence is the following (with 0000:01:00.0 the PCI device): driver_detach: call     device_release_driver_internal(0000:01:00.0)... device_links_busy(0000:01:00.0): links->status =     DL_DEV_UNBINDING device_links_unbind_consumers(0000:01:00.0): 0000:01:00.0--oic link->status =     DL_STATE_SUPPLIER_UNBIND call device_release_driver_internal(oic)... device_links_busy(oic): links->status     = DL_DEV_UNBINDING device_links_unbind_consumers(oic): oic--pinctrl link->status =     DL_STATE_SUPPLIER_UNBIND call device_release_driver_internal(pinctrl)... device_links_busy(pinctrl):
    links->status = DL_DEV_UNBINDING device_links_unbind_consumers(pinctrl): pinctrl--i2c link->status =     DL_STATE_SUPPLIER_UNBIND call device_release_driver_internal(i2c)... device_links_busy(i2c): links->status     = DL_DEV_UNBINDING __device_links_no_driver(i2c)... pinctrl--i2c link->status is DL_STATE_SUPPLIER_UNBIND     oic--i2c link->status is DL_STATE_ACTIVE oic--i2c link->supplier->links.status is DL_DEV_UNBINDING The     warning is triggered by the i2c removal because the OIC (supplier) links status is not     DL_DEV_DRIVER_BOUND. Its links status is indeed set to DL_DEV_UNBINDING. It is perfectly legit to have the     links status set to DL_DEV_UNBINDING in that case. Indeed we had started to unbind the OIC which triggered     the consumer unbinding and didn't finish yet when the i2c is unbound. Avoid the warning when the supplier     links status is set to DL_DEV_UNBINDING and thus support this removal sequence without any warnings.
    (CVE-2026-97479)

  - In the Linux kernel, the following vulnerability has been resolved: usb: typec: ucsi: displayport: Fix OOB     altmode array index The UCSI displayport driver indexes the connector's port altmode array with the     GET_CURRENT_CAM response after checking it is not 0xff. The port altmode array is UCSI_MAX_ALTMODES     elements long. If the PPM returns an invalid GET_CURRENT_CAM response above UCSI_MAX_ALTMODES and not     equal to 0xff, the kernel may crash with an array index OOB error. Update the UCSI displayport driver to     verify the current cam is less than UCSI_MAX_ALTMODES before accessing the port altmode array.
    (CVE-2026-90025)

  - In the Linux kernel, the following vulnerability has been resolved: NFSv4.1: fix layout segment leak on     the pnfs_layout_process() forget path When the server returns a new layout stateid while a valid one is     still held, pnfs_layout_process() calls pnfs_mark_matching_lsegs_return() on the on-stack free_me list and     jumps to out_forget. Segments whose reference count drops to zero are unlinked from lo->plh_segs and moved     to free_me by mark_lseg_invalid(); for an idle cached segment the layout header holds the only reference,     so this happens on the first decrement. out_forget never drains free_me -- only the success path calls     pnfs_free_lseg_list(). Commit 814b84971388 (pNFS/NFSv4: Fix a layout segment leak in     pnfs_layout_process()) added the drain; commit 08bd8dbe8882 (pNFS/NFSv4: Try to return invalid layout in     pnfs_layout_process()) removed it while switching the destination to lo->plh_return_segs, which is     drained elsewhere. Commit fb700ef02676 (NFSv4.1: Simplify layout return in pnfs_layout_process())     switched the destination back to free_me without restoring the drain. Restore the pnfs_free_lseg_list()     call. (CVE-2026-89710)

Note that Nessus has not tested for these issues but has instead relied only on the application's self-reported version number.

ID	名稱	產品	系列	已發布	已更新	嚴重性
371510	Linux Distros 未修補弱點：CVE-2026-98903	Nessus	Misc.	2026/10/23	2026/11/14	medium
371510	Linux Distros 未修补的漏洞：CVE-2026-98903	Nessus	Misc.	2026/10/23	2026/11/14	medium
371510	Linux Distros のパッチ未適用の脆弱性: CVE-2026-98903	Nessus	Misc.	2026/10/23	2026/11/14	medium
375014	Photon OS 5.0: Linux PHSA-2026-5.0-92-1014	Nessus	PhotonOS Local Security Checks	2026/11/2	2026/11/2	high
371510	Linux Distros Unpatched Vulnerability : CVE-2026-98903	Nessus	Misc.	2026/10/23	2026/11/14	medium
376443	Ubuntu 24.04 LTS / 26.04 LTS : Linux kernel vulnerabilities (USN-8959-1)	Nessus	Ubuntu Local Security Checks	2026/11/5	2026/11/5	high
381298	AlmaLinux 9.2 [TuxCare] Security Update: bpftool / kernel / kernel-64k / kernel-64k-core / kernel-64k-debug / etc Multiple Vulnerabilities (ALMALINUX9.2:CLSA-2026:1794643812)	Nessus	Alma Linux Local Security Checks	2026/11/14	2026/11/14	high
375113	Photon OS 5.0: Linux PHSA-2026-5.0-91-1014	Nessus	PhotonOS Local Security Checks	2026/11/2	2026/11/2	high

偵測

搜尋 Plugin

medium

medium

medium

high

medium

high

high

high