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

  - configfs修正 configfs_{,un}register_subsystem() 中的爭用。當 configfs_register_subsystem() 或 configfs_unregister_subsystem() 執行 link_group() 或 unlink_group() 時兩個處理程序可能會同時新增或刪除清單。這些弱點的某些交錯可能會造成核心錯誤。
    其中一種情況為A --> B --> C --> DA <-- B <-- C <-- D 刪除 list_head *B |刪除 list_head *C
    ---------------------------------|-------------------- ------------------ configfs_unregister_subsystem | configfs_unregister_subsystem unlink_group | unlink_group unlink_obj | unlink_obj list_del_init | list_del_init __list_del_entry | __list_del_entry __list_del | __list_del // next == C | next->prev = prev | | next->prev = prev prev->next = next | | // prev == B | prev->next = next 呼叫 link_group() 或 unlink_group() 時藉由新增 mutex 來修正此問題但當 config_item 為 root 時父項 configfs_subsystem 為 NULL。因此我建立了一個 mutex configfs_subsystem_mutex。 (CVE-2022-48931)

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

遠端主機上安裝的核心版本早於 4.14.273-207.502。因此，會受到 ALAS2-2022-1768 公告中所提及的多個弱點影響。

    - 在 Linux 核心的 netfilter 子系統的 linux/net/netfilter/nf_tables_api.c 中發現一個缺陷。
    本機使用者可利用此缺陷造成超出邊界寫入問題。(CVE-2022-1015)

    在 Linux 核心的 net/netfilter/nf_tables_core.c:nft_do_chain 中發現可造成釋放後使用的缺陷。此問題需要以適當的前置條件處理傳回，本機非特權攻擊者可藉此造成核心資訊洩漏問題。(CVE-2022-1016)

    產品：Android 版本：Android 核心 Android ID：A-224546354 參照：上游核心 (CVE-2022-20368)

    在 Linux 核心中，下列弱點已解決：

    net/packet：修正 packet_recvmsg() 中的 slab 超出邊界存取弱點 (CVE-2022-48839)

    在 Linux 核心中，下列弱點已解決：

    net-sysfs: 在 speed_show 中新增網路裝置存在性檢查 (CVE-2022-48850)

    在 Linux 核心中，下列弱點已解決：

    sctp：修復 SCTP 通訊端的核心資訊洩漏問題 (CVE-2022-48855)

    在 Linux 核心中，下列弱點已解決：

    netfilternf_queue修正可能的釋放後使用問題 (CVE-2022-48911)

    在 Linux 核心中，下列弱點已解決：

    netfilter：修正 __nf_register_net_hook() 中的釋放後使用 (CVE-2022-48912)

    在 Linux 核心中，下列弱點已解決：

    cifs：修正因 cifs_get_root() 中掛載失敗而引起的重複釋放爭用 (CVE-2022-48919)

    在 Linux 核心中，下列弱點已解決：

    RDMA/ib_srp修正鎖死 (CVE-2022-48930)

    在 Linux 核心中，下列弱點已解決：

    configfs修正 configfs_{,un}register_subsystem() 中的爭用 (CVE-2022-48931)

    在 Linux 核心中，下列弱點已解決：

    netfilter: nf_tables: 初始化 nft_do_chain() 中的暫存器 (CVE-2022-49293)

Tenable 已直接從所測試產品的安全公告擷取前置描述區塊。

請注意，Nessus 並未測試這些問題，而是僅依據應用程式自我報告的版本號碼作出判斷。

遠端主機上安裝的核心版本早於 5.4.186-102.354。因此，會受到 ALAS2KERNEL-5.4-2022-024 公告中所提及的多個弱點影響。

    在 Linux 核心中，下列弱點已解決：

    mm/damon/dbgfs：修復 'dbgfs_target_ids_write()' 中的 'struct pid' 洩漏問題 (CVE-2021-46937)

    在 Linux 核心中，下列弱點已解決：

    mm/damon/dbgfs：使用 kdamond_lock 保護目標損毀 (CVE-2021-47088)

    - 在 Linux 核心的 netfilter 子系統的 linux/net/netfilter/nf_tables_api.c 中發現一個缺陷。
    本機使用者可利用此缺陷造成超出邊界寫入問題。(CVE-2022-1015)

    在 Linux 核心的 net/netfilter/nf_tables_core.c:nft_do_chain 中發現可造成釋放後使用的缺陷。此問題需要以適當的前置條件處理傳回，本機非特權攻擊者可藉此造成核心資訊洩漏問題。(CVE-2022-1016)

    在 Linux 核心中，發現 net/sched/cls_api.c 的 tc_new_tfilter 函式中包含釋放後使用弱點。本機非特權使用者命名空間的可用性允許特權提升。
    (CVE-2022-1055)

    在 Linux 核心的 netfilter 子元件中，發現 net/netfilter/nf_dup_netdev.c 的 nft_fwd_dup_netdev_offload 中存在超出邊界 (OOB) 記憶體存取缺陷，這是堆積超出邊界寫入問題所導致。此缺陷可讓在系統中擁有使用者帳戶的本機攻擊者取得超出邊界存取記憶體的權限，進而導致系統當機或特權提升威脅。(CVE-2022-25636)

    在 Linux 核心中，下列弱點已解決：

    drm/vrr：僅在連接至連接器時設定支援 VRR 的屬性 (CVE-2022-48843)

    在 Linux 核心中，下列弱點已解決：

    net-sysfs: 在 speed_show 中新增網路裝置存在性檢查 (CVE-2022-48850)

    在 Linux 核心中，下列弱點已解決：

    sctp：修復 SCTP 通訊端的核心資訊洩漏問題 (CVE-2022-48855)

    在 Linux 核心中，下列弱點已解決：

    net/mlx5：修正命令排清流程中的爭用問題 (CVE-2022-48858)

    在 Linux 核心中，下列弱點已解決：

    netfilternf_queue修正可能的釋放後使用問題 (CVE-2022-48911)

    在 Linux 核心中，下列弱點已解決：

    netfilter：修正 __nf_register_net_hook() 中的釋放後使用 (CVE-2022-48912)

    在 Linux 核心中，下列弱點已解決：

    xen/netfront在清空 real_num_tx_queues 之前破壞佇列 (CVE-2022-48914)

    在 Linux 核心中，下列弱點已解決：

    cifs：修正因 cifs_get_root() 中掛載失敗而引起的重複釋放爭用 (CVE-2022-48919)

    在 Linux 核心中，下列弱點已解決：

    RDMA/ib_srp修正鎖死 (CVE-2022-48930)

    在 Linux 核心中，下列弱點已解決：

    configfs修正 configfs_{,un}register_subsystem() 中的爭用 (CVE-2022-48931)

    在 Linux 核心中，下列弱點已解決：

    netfilternf_tables修正有狀態 obj 更新期間的記憶體洩漏 (CVE-2022-48933)

    在 Linux 核心中，下列弱點已解決：

    netfilter: nf_tables: 初始化 nft_do_chain() 中的暫存器 (CVE-2022-49293)

Tenable 已直接從所測試產品的安全公告擷取前置描述區塊。

請注意，Nessus 並未測試這些問題，而是僅依據應用程式自我報告的版本號碼作出判斷。

AlmaLinux 9.2 主機已安裝的套件會受到 TuxCare ALMALINUX9.2：CLSA-2026：1780516677 公告中提及的多個弱點影響。

  - 已解決 Linux 核心中的下列弱點：can: isotp: fix potential CAN frame reception race in isotp_rcv() When receiving a CAN frame the current code logic does not consider concurrently receiving processes which do not show up in real world usage. Ziyang Xuan writes: The following syz problem is one of the scenarios. so->rx.len is changed by isotp_rcv_ff() during isotp_rcv_cf(), so->rx.len equals 0 before alloc_skb() and equals 4096 after alloc_skb(). That will trigger skb_over_panic() in skb_put(). ======================================================= CPU: 1 PID:
    19 Comm: ksoftirqd/1 Not tainted 5.16.0-rc8-syzkaller #0 RIP: 0010:skb_panic+0x16c/0x16e net/core/skbuff.c:113 Call Trace: <TASK> skb_over_panic net/core/skbuff.c:118 [inline] skb_put.cold+0x24/0x24 net/core/skbuff.c:1990 isotp_rcv_cf net/can/isotp.c:570 [inline] isotp_rcv+0xa38/0x1e30 net/can/isotp.c:668 deliver net/can/af_can.c:574 [inline] can_rcv_filter+0x445/0x8d0 net/can/af_can.c:635 can_receive+0x31d/0x580 net/can/af_can.c:665 can_rcv+0x120/0x1c0 net/can/af_can.c:696 __netif_receive_skb_one_core+0x114/0x180 net/core/dev.c:5465
    __netif_receive_skb+0x24/0x1b0 net/core/dev.c:5579 Therefore we make sure the state changes and data structures stay consistent at CAN frame reception time by adding a spin_lock in isotp_rcv(). This fixes the issue reported by syzkaller but does not affect real world operation. (CVE-2022-48830)

  - 已解決 Linux 核心中的下列弱點：wifi: mac80211: sdata can be NULL during AMPDU start ieee80211_tx_ba_session_handle_start() may get NULL for sdata when a deauthentication is ongoing. Here a trace triggering the race with the hostapd test multi_ap_fronthaul_on_ap: (gdb) list
    *drv_ampdu_action+0x46 0x8b16 is in drv_ampdu_action (net/mac80211/driver-ops.c:396). 391 int ret =
    -EOPNOTSUPP; 392 393 might_sleep(); 394 395 sdata = get_bss_sdata(sdata); 396 if (!check_sdata_in_driver(sdata)) 397 return -EIO; 398 399 trace_drv_ampdu_action(local, sdata, params); 400 wlan0: moving STA 02:00:00:00:03:00 to state 3 wlan0: associated wlan0: deauthenticating from 02:00:00:00:03:00 by local choice (Reason: 3=DEAUTH_LEAVING) wlan3.sta1: Open BA session requested for 02:00:00:00:00:00 tid 0 wlan3.sta1: dropped frame to 02:00:00:00:00:00 (unauthorized port) wlan0: moving STA 02:00:00:00:03:00 to state 2 wlan0: moving STA 02:00:00:00:03:00 to state 1 wlan0: Removed STA 02:00:00:00:03:00 wlan0: Destroyed STA 02:00:00:00:03:00 BUG: unable to handle page fault for address:
    fffffffffffffb48 PGD 11814067 P4D 11814067 PUD 11816067 PMD 0 Oops: 0000 [#1] PREEMPT SMP PTI CPU: 2 PID:
    133397 Comm: kworker/u16:1 Tainted: G W 6.1.0-rc8-wt+ #59 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.0-20220807_005459-localhost 04/01/2014 Workqueue: phy3 ieee80211_ba_session_work [mac80211] RIP: 0010:drv_ampdu_action+0x46/0x280 [mac80211] Code: 53 48 89 f3 be 89 01 00 00 e8 d6 43 bf ef e8 21 46 81 f0 83 bb a0 1b 00 00 04 75 0e 48 8b 9b 28 0d 00 00 48 81 eb 10 0e 00 00 <8b> 93 58 09 00 00 f6 c2 20 0f 84 3b 01 00 00 8b 05 dd 1c 0f 00 85 RSP: 0018:ffffc900025ebd20 EFLAGS: 00010287 RAX:
    0000000000000000 RBX: fffffffffffff1f0 RCX: ffff888102228240 RDX: 0000000080000000 RSI: ffffffff918c5de0 RDI: ffff888102228b40 RBP: ffffc900025ebd40 R08: 0000000000000001 R09: 0000000000000001 R10:
    0000000000000001 R11: 0000000000000000 R12: ffff888118c18ec0 R13: 0000000000000000 R14: ffffc900025ebd60 R15: ffff888018b7efb8 FS: 0000000000000000(0000) GS:ffff88817a600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: fffffffffffffb48 CR3: 0000000105228006 CR4: 0000000000170ee0 Call Trace: <TASK> ieee80211_tx_ba_session_handle_start+0xd0/0x190 [mac80211] ieee80211_ba_session_work+0xff/0x2e0 [mac80211] process_one_work+0x29f/0x620 worker_thread+0x4d/0x3d0 ? process_one_work+0x620/0x620 kthread+0xfb/0x120 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork+0x22/0x30 </TASK> (CVE-2022-48875)

  - 已解決 Linux 核心中的下列弱點：udf: Fix preallocation discarding at indirect extent boundary When preallocation extent is the first one in the extent block, the code would corrupt extent tree header instead. Fix the problem and use udf_delete_aext() for deleting extent to avoid some code duplication. (CVE-2022-48946)

  - 已解決 Linux 核心中的下列弱點：Bluetooth: Fix crash when replugging CSR fake controllers It seems fake CSR 5.0 clones can cause the suspend notifier to be registered twice causing the following kernel panic: [ 71.986122] Call Trace: [ 71.986124] <TASK> [ 71.986125] blocking_notifier_chain_register+0x33/0x60 [ 71.986130] hci_register_dev+0x316/0x3d0 [bluetooth 99b5497ea3d09708fa1366c1dc03288bf3cca8da] [ 71.986154] btusb_probe+0x979/0xd85 [btusb e1e0605a4f4c01984a4b9c8ac58c3666ae287477] [ 71.986159] ? __pm_runtime_set_status+0x1a9/0x300 [ 71.986162] ? ktime_get_mono_fast_ns+0x3e/0x90 [ 71.986167] usb_probe_interface+0xe3/0x2b0 [ 71.986171] really_probe+0xdb/0x380 [ 71.986174] ? pm_runtime_barrier+0x54/0x90 [ 71.986177]
    __driver_probe_device+0x78/0x170 [ 71.986180] driver_probe_device+0x1f/0x90 [ 71.986183]
    __device_attach_driver+0x89/0x110 [ 71.986186] ? driver_allows_async_probing+0x70/0x70 [ 71.986189] bus_for_each_drv+0x8c/0xe0 [ 71.986192] __device_attach+0xb2/0x1e0 [ 71.986195] bus_probe_device+0x92/0xb0 [ 71.986198] device_add+0x422/0x9a0 [ 71.986201] ? sysfs_merge_group+0xd4/0x110 [ 71.986205] usb_set_configuration+0x57a/0x820 [ 71.986208] usb_generic_driver_probe+0x4f/0x70 [ 71.986211] usb_probe_device+0x3a/0x110 [ 71.986213] really_probe+0xdb/0x380 [ 71.986216] ? pm_runtime_barrier+0x54/0x90 [ 71.986219] __driver_probe_device+0x78/0x170 [ 71.986221] driver_probe_device+0x1f/0x90 [ 71.986224] __device_attach_driver+0x89/0x110 [ 71.986227] ? driver_allows_async_probing+0x70/0x70 [ 71.986230] bus_for_each_drv+0x8c/0xe0 [ 71.986232]
    __device_attach+0xb2/0x1e0 [ 71.986235] bus_probe_device+0x92/0xb0 [ 71.986237] device_add+0x422/0x9a0 [71.986239] ? _dev_info+0x7d/0x98 [ 71.986242] ? blake2s_update+0x4c/0xc0 [ 71.986246] usb_new_device.cold+0x148/0x36d [ 71.986250] hub_event+0xa8a/0x1910 [ 71.986255] process_one_work+0x1c4/0x380 [ 71.986259] worker_thread+0x51/0x390 [ 71.986262] ? rescuer_thread+0x3b0/0x3b0 [ 71.986264] kthread+0xdb/0x110 [ 71.986266] ? kthread_complete_and_exit+0x20/0x20 [ 71.986268] ret_from_fork+0x1f/0x30 [ 71.986273] </TASK> [ 71.986274]
    ---[ end trace 0000000000000000 ]--- [ 71.986284] btusb: probe of 2-1.6:1.0 failed with error -17 (CVE-2022-48982)

  - 已解決 Linux 核心中的下列弱點：can: m_can: pci: add missing m_can_class_free_dev() in probe/remove methods In m_can_pci_remove() and error handling path of m_can_pci_probe(), m_can_class_free_dev() should be called to free resource allocated by m_can_class_allocate_dev(), otherwise there will be memleak. (CVE-2022-49024)

請注意，Nessus 並未測試這些問題，而是僅依據應用程式自我報告的版本號碼作出判斷。

遠端主機上安裝的核心版本早於 5.10.106-102.504。因此，會受到 ALAS2KERNEL-5.10-2022-012 公告中所提及的多個弱點影響。

    在 Linux 核心中，下列弱點已解決：

    mm/damon/dbgfs：修復 'dbgfs_target_ids_write()' 中的 'struct pid' 洩漏問題 (CVE-2021-46937)

    在 Linux 核心中，下列弱點已解決：

    mm/damon/dbgfs：使用 kdamond_lock 保護目標損毀 (CVE-2021-47088)

    在 BPF_BTF_LOAD 不受限制地使用 eBPF 的方式中發現一個缺陷，由於使用者載入 BTF 的方式，可能導致 Linux 核心的 BPF 子系統中發生超出邊界記憶體寫入問題。本機使用者可利用此缺陷造成系統當機，或提升自己的系統權限。(CVE-2022-0500)

    在 Linux 核心的 FUSE 檔案系統中發現釋放後使用缺陷，此缺陷與使用者觸發 write() 的方式有關。
    此缺陷允許本機使用者從 FUSE 檔案系統取得資料的未經授權存取權，進而導致特權提升。(CVE-2022-1011)

    - 在 Linux 核心的 netfilter 子系統的 linux/net/netfilter/nf_tables_api.c 中發現一個缺陷。
    本機使用者可利用此缺陷造成超出邊界寫入問題。(CVE-2022-1015)

    在 Linux 核心的 net/netfilter/nf_tables_core.c:nft_do_chain 中發現可造成釋放後使用的缺陷。此問題需要以適當的前置條件處理傳回，本機非特權攻擊者可藉此造成核心資訊洩漏問題。(CVE-2022-1016)

    Linux PV 裝置前端容易受到後端攻擊 [其 CNA 資訊記錄與多個 CVE 有關；文字說明了哪些方面/弱點對應哪個 CVE。] 數個 Linux PV 裝置前端正在以易受爭用情形影響的方式，使用授權表介面移除後端的存取權，進而可能導致資料洩漏、惡意後端損毀資料以及惡意後端觸發拒絕服務：blkfront、netfront、scsifront 和 gntalloc 驅動程式正在測試授權參照是否仍在使用中。如果情況並非如此，則它們會假設後續每次都能移除授予的存取權；但如果後端已在執行這兩項作業之間對應授權頁面，則此假設不成立。因此，無論前端 I/O 完成後如何使用頁面，後端都可以繼續存取客體的記憶體頁面。
    xenbus 驅動程式有一個類似的問題，因為它不會檢查是否成功移除向共用環形緩衝區授予的存取權。blkfront：CVE-2022-23036 netfront：CVE-2022-23037 scsifront：CVE-2022-23038 gntalloc：CVE-2022-23039 xenbus：CVE-2022-23040 blkfront、netfront、scsifront、usbfront、dmabuf、xenbus、9p、kbdfront 和 pvcalls 使用功能延遲釋放授權參照 (直到不再使用這個參照)，但相關資料頁面的釋放與刪除授予的存取權並不同步。因此，即使在記憶體頁面被釋放並重新用於其他目的之後，後端仍可繼續存取該頁面。CVE-2022-23041 如果 netfront 無法撤銷 rx 路徑中的存取權，則 BUG_ON() 宣告將失敗。這會導致客體發生拒絕服務 (DoS) 情形，而此情形可能由後端觸發。CVE-2022-23042 (CVE-2022-23036)

    Linux PV 裝置前端容易受到後端攻擊 [其 CNA 資訊記錄與多個 CVE 有關；文字說明了哪些方面/弱點對應哪個 CVE。] 數個 Linux PV 裝置前端正在以易受爭用情形影響的方式，使用授權表介面移除後端的存取權，進而可能導致資料洩漏、惡意後端損毀資料以及惡意後端觸發拒絕服務：blkfront、netfront、scsifront 和 gntalloc 驅動程式正在測試授權參照是否仍在使用中。如果情況並非如此，則它們會假設後續每次都能移除授予的存取權；但如果後端已在執行這兩項作業之間對應授權頁面，則此假設不成立。因此，無論前端 I/O 完成後如何使用頁面，後端都可以繼續存取客體的記憶體頁面。
    xenbus 驅動程式有一個類似的問題，因為它不會檢查是否成功移除向共用環形緩衝區授予的存取權。blkfront：CVE-2022-23036 netfront：CVE-2022-23037 scsifront：CVE-2022-23038 gntalloc：CVE-2022-23039 xenbus：CVE-2022-23040 blkfront、netfront、scsifront、usbfront、dmabuf、xenbus、9p、kbdfront 和 pvcalls 使用功能延遲釋放授權參照 (直到不再使用這個參照)，但相關資料頁面的釋放與刪除授予的存取權並不同步。因此，即使在記憶體頁面被釋放並重新用於其他目的之後，後端仍可繼續存取該頁面。CVE-2022-23041 如果 netfront 無法撤銷 rx 路徑中的存取權，則 BUG_ON() 宣告將失敗。這會導致客體發生拒絕服務 (DoS) 情形，而此情形可能由後端觸發。CVE-2022-23042 (CVE-2022-23037)

    Linux PV 裝置前端容易受到後端攻擊 [其 CNA 資訊記錄與多個 CVE 有關；文字說明了哪些方面/弱點對應哪個 CVE。] 數個 Linux PV 裝置前端正在以易受爭用情形影響的方式，使用授權表介面移除後端的存取權，進而可能導致資料洩漏、惡意後端損毀資料以及惡意後端觸發拒絕服務：blkfront、netfront、scsifront 和 gntalloc 驅動程式正在測試授權參照是否仍在使用中。如果情況並非如此，則它們會假設後續每次都能移除授予的存取權；但如果後端已在執行這兩項作業之間對應授權頁面，則此假設不成立。因此，無論前端 I/O 完成後如何使用頁面，後端都可以繼續存取客體的記憶體頁面。
    xenbus 驅動程式有一個類似的問題，因為它不會檢查是否成功移除向共用環形緩衝區授予的存取權。blkfront：CVE-2022-23036 netfront：CVE-2022-23037 scsifront：CVE-2022-23038 gntalloc：CVE-2022-23039 xenbus：CVE-2022-23040 blkfront、netfront、scsifront、usbfront、dmabuf、xenbus、9p、kbdfront 和 pvcalls 使用功能延遲釋放授權參照 (直到不再使用這個參照)，但相關資料頁面的釋放與刪除授予的存取權並不同步。因此，即使在記憶體頁面被釋放並重新用於其他目的之後，後端仍可繼續存取該頁面。CVE-2022-23041 如果 netfront 無法撤銷 rx 路徑中的存取權，則 BUG_ON() 宣告將失敗。這會導致客體發生拒絕服務 (DoS) 情形，而此情形可能由後端觸發。CVE-2022-23042 (CVE-2022-23038)

    Linux PV 裝置前端容易受到後端攻擊 [其 CNA 資訊記錄與多個 CVE 有關；文字說明了哪些方面/弱點對應哪個 CVE。] 數個 Linux PV 裝置前端正在以易受爭用情形影響的方式，使用授權表介面移除後端的存取權，進而可能導致資料洩漏、惡意後端損毀資料以及惡意後端觸發拒絕服務：blkfront、netfront、scsifront 和 gntalloc 驅動程式正在測試授權參照是否仍在使用中。如果情況並非如此，則它們會假設後續每次都能移除授予的存取權；但如果後端已在執行這兩項作業之間對應授權頁面，則此假設不成立。因此，無論前端 I/O 完成後如何使用頁面，後端都可以繼續存取客體的記憶體頁面。
    xenbus 驅動程式有一個類似的問題，因為它不會檢查是否成功移除向共用環形緩衝區授予的存取權。blkfront：CVE-2022-23036 netfront：CVE-2022-23037 scsifront：CVE-2022-23038 gntalloc：CVE-2022-23039 xenbus：CVE-2022-23040 blkfront、netfront、scsifront、usbfront、dmabuf、xenbus、9p、kbdfront 和 pvcalls 使用功能延遲釋放授權參照 (直到不再使用這個參照)，但相關資料頁面的釋放與刪除授予的存取權並不同步。因此，即使在記憶體頁面被釋放並重新用於其他目的之後，後端仍可繼續存取該頁面。CVE-2022-23041 如果 netfront 無法撤銷 rx 路徑中的存取權，則 BUG_ON() 宣告將失敗。這會導致客體發生拒絕服務 (DoS) 情形，而此情形可能由後端觸發。CVE-2022-23042 (CVE-2022-23039)

    Linux PV 裝置前端容易受到後端攻擊 [其 CNA 資訊記錄與多個 CVE 有關；文字說明了哪些方面/弱點對應哪個 CVE。] 數個 Linux PV 裝置前端正在以易受爭用情形影響的方式，使用授權表介面移除後端的存取權，進而可能導致資料洩漏、惡意後端損毀資料以及惡意後端觸發拒絕服務：blkfront、netfront、scsifront 和 gntalloc 驅動程式正在測試授權參照是否仍在使用中。如果情況並非如此，則它們會假設後續每次都能移除授予的存取權；但如果後端已在執行這兩項作業之間對應授權頁面，則此假設不成立。因此，無論前端 I/O 完成後如何使用頁面，後端都可以繼續存取客體的記憶體頁面。
    xenbus 驅動程式有一個類似的問題，因為它不會檢查是否成功移除向共用環形緩衝區授予的存取權。blkfront：CVE-2022-23036 netfront：CVE-2022-23037 scsifront：CVE-2022-23038 gntalloc：CVE-2022-23039 xenbus：CVE-2022-23040 blkfront、netfront、scsifront、usbfront、dmabuf、xenbus、9p、kbdfront 和 pvcalls 使用功能延遲釋放授權參照 (直到不再使用這個參照)，但相關資料頁面的釋放與刪除授予的存取權並不同步。因此，即使在記憶體頁面被釋放並重新用於其他目的之後，後端仍可繼續存取該頁面。CVE-2022-23041 如果 netfront 無法撤銷 rx 路徑中的存取權，則 BUG_ON() 宣告將失敗。這會導致客體發生拒絕服務 (DoS) 情形，而此情形可能由後端觸發。CVE-2022-23042 (CVE-2022-23040)

    Linux PV 裝置前端容易受到後端攻擊 [其 CNA 資訊記錄與多個 CVE 有關；文字說明了哪些方面/弱點對應哪個 CVE。] 數個 Linux PV 裝置前端正在以易受爭用情形影響的方式，使用授權表介面移除後端的存取權，進而可能導致資料洩漏、惡意後端損毀資料以及惡意後端觸發拒絕服務：blkfront、netfront、scsifront 和 gntalloc 驅動程式正在測試授權參照是否仍在使用中。如果情況並非如此，則它們會假設後續每次都能移除授予的存取權；但如果後端已在執行這兩項作業之間對應授權頁面，則此假設不成立。因此，無論前端 I/O 完成後如何使用頁面，後端都可以繼續存取客體的記憶體頁面。
    xenbus 驅動程式有一個類似的問題，因為它不會檢查是否成功移除向共用環形緩衝區授予的存取權。blkfront：CVE-2022-23036 netfront：CVE-2022-23037 scsifront：CVE-2022-23038 gntalloc：CVE-2022-23039 xenbus：CVE-2022-23040 blkfront、netfront、scsifront、usbfront、dmabuf、xenbus、9p、kbdfront 和 pvcalls 使用功能延遲釋放授權參照 (直到不再使用這個參照)，但相關資料頁面的釋放與刪除授予的存取權並不同步。因此，即使在記憶體頁面被釋放並重新用於其他目的之後，後端仍可繼續存取該頁面。CVE-2022-23041 如果 netfront 無法撤銷 rx 路徑中的存取權，則 BUG_ON() 宣告將失敗。這會導致客體發生拒絕服務 (DoS) 情形，而此情形可能由後端觸發。CVE-2022-23042 (CVE-2022-23042)

    現在，Amazon Linux 核心依預設會針對所有 ARM 型 EC2 執行個體類型啟用此問題的軟體緩解措施。(CVE-2022-23960)

    在 Linux 核心的 netfilter 子元件中，發現 net/netfilter/nf_dup_netdev.c 的 nft_fwd_dup_netdev_offload 中存在超出邊界 (OOB) 記憶體存取缺陷，這是堆積超出邊界寫入問題所導致。此缺陷可讓在系統中擁有使用者帳戶的本機攻擊者取得超出邊界存取記憶體的權限，進而導致系統當機或特權提升威脅。(CVE-2022-25636)

    在 net/ipv4/esp4.c 和 net/ipv6/esp6.c 的 IPsec ESP 轉換程式碼中發現堆積緩衝區溢位缺陷。此缺陷允許具有一般使用者權限的本機攻擊者覆寫核心堆積物件，並可能造成本機特權提升威脅。(CVE-2022-27666)

    在 Linux 核心中，下列弱點已解決：

    watch_queue：修正篩選條件限制檢查 (CVE-2022-48847)

    在 Linux 核心中，下列弱點已解決：

    net-sysfs: 在 speed_show 中新增網路裝置存在性檢查 (CVE-2022-48850)

    在 Linux 核心中，下列弱點已解決：

    sctp：修復 SCTP 通訊端的核心資訊洩漏問題 (CVE-2022-48855)

    在 Linux 核心中，下列弱點已解決：

    net/mlx5：修正命令排清流程中的爭用問題 (CVE-2022-48858)

    在 Linux 核心中，下列弱點已解決：

    tipc：修正啟用承載程式時發生的核心錯誤 (CVE-2022-48865)

    在 Linux 核心中，下列弱點已解決：

    netipv6確保我們至多呼叫 ipv6_mc_down() 一次 (CVE-2022-48910)

    在 Linux 核心中，下列弱點已解決：

    netfilternf_queue修正可能的釋放後使用問題 (CVE-2022-48911)

    在 Linux 核心中，下列弱點已解決：

    netfilter：修正 __nf_register_net_hook() 中的釋放後使用 (CVE-2022-48912)

    在 Linux 核心中，下列弱點已解決：

    xen/netfront在清空 real_num_tx_queues 之前破壞佇列 (CVE-2022-48914)

    在 Linux 核心中，下列弱點已解決：

    thermal核心修正 TZ_GET_TRIP NULL 指標解除參照 (CVE-2022-48915)

    在 Linux 核心中，下列弱點已解決：

    cifs：修正因 cifs_get_root() 中掛載失敗而引起的重複釋放爭用 (CVE-2022-48919)

    在 Linux 核心中，下列弱點已解決：

    thermalint340x修正 int3400_notify() 中的記憶體洩漏 (CVE-2022-48924)

    在 Linux 核心中，下列弱點已解決：

    RDMA/cma：不在狀態檢查之外變更 route.addr.src_addr (CVE-2022-48925)

    在 Linux 核心中，下列弱點已解決：

    RDMA/ib_srp修正鎖死 (CVE-2022-48930)

    在 Linux 核心中，下列弱點已解決：

    configfs修正 configfs_{,un}register_subsystem() 中的爭用 (CVE-2022-48931)

    在 Linux 核心中，下列弱點已解決：

    netfilternf_tables修正有狀態 obj 更新期間的記憶體洩漏 (CVE-2022-48933)

    在 Linux 核心中，下列弱點已解決：

    io_uring在 io_add_buffers() 中新增排程點 (CVE-2022-48937)

    在 Linux 核心中，下列弱點已解決：

    bpf在批次 ops 中新增排程點 (CVE-2022-48939)

    在 Linux 核心中，下列弱點已解決：

    hwmon處理使用熱區域正確註冊感應器的失敗 (CVE-2022-48942)

    在 Linux 核心中，下列弱點已解決：

    KVM：x86/mmu：使 apf 權杖變成非零，以修正錯誤 (CVE-2022-48943)

    在 Linux 核心中，下列弱點已解決：

    netfilter: nf_tables: 初始化 nft_do_chain() 中的暫存器 (CVE-2022-49293)

Tenable 已直接從所測試產品的安全公告擷取前置描述區塊。

請注意，Nessus 並未測試這些問題，而是僅依據應用程式自我報告的版本號碼作出判斷。

AlmaLinux 9.6 主機已安裝的套件會受到 TuxCare ALMALINUX9.6：CLSA-2026：1779434490 公告中提及的多個弱點影響。

  - 已解決 Linux 核心中的下列弱點：configfs: fix a race in configfs_{,un}register_subsystem() When configfs_register_subsystem() or configfs_unregister_subsystem() is executing link_group() or unlink_group(), it is possible that two processes add or delete list concurrently. Some unfortunate interleavings of them can cause kernel panic. One of cases is: A --> B --> C --> D A <-- B <-- C <-- D delete list_head *B | delete list_head *C
    --------------------------------|----------------------------------- configfs_unregister_subsystem | configfs_unregister_subsystem unlink_group | unlink_group unlink_obj | unlink_obj list_del_init | list_del_init __list_del_entry | __list_del_entry __list_del | __list_del // next == C | next->prev = prev | | next->prev = prev prev->next = next | | // prev == B | prev->next = next Fix this by adding mutex when calling link_group() or unlink_group(), but parent configfs_subsystem is NULL when config_item is root. So I create a mutex configfs_subsystem_mutex. (CVE-2022-48931)

  - 已解決 Linux 核心中的下列弱點：list: fix a data-race around ep->rdllist ep_poll() first calls ep_events_available() with no lock held and checks if ep->rdllist is empty by list_empty_careful(), which reads rdllist->prev. Thus all accesses to it need some protection to avoid store/load-tearing. Note INIT_LIST_HEAD_RCU() already has the annotation for both prev and next.
    Commit bf3b9f6372c4 (epoll: Add busy poll support to epoll with socket fds.) added the first lockless ep_events_available(), and commit c5a282e9635e (fs/epoll: reduce the scope of wq lock in epoll_wait()) made some ep_events_available() calls lockless and added single call under a lock, finally commit e59d3c64cba6 (epoll: eliminate unnecessary lock for zero timeout) made the last ep_events_available() lockless. BUG: KCSAN: data-race in do_epoll_wait / do_epoll_wait write to 0xffff88810480c7d8 of 8 bytes by task 1802 on cpu 0: INIT_LIST_HEAD include/linux/list.h:38 [inline] list_splice_init include/linux/list.h:492 [inline] ep_start_scan fs/eventpoll.c:622 [inline] ep_send_events fs/eventpoll.c:1656 [inline] ep_poll fs/eventpoll.c:1806 [inline] do_epoll_wait+0x4eb/0xf40 fs/eventpoll.c:2234 do_epoll_pwait fs/eventpoll.c:2268 [inline] __do_sys_epoll_pwait fs/eventpoll.c:2281 [inline] __se_sys_epoll_pwait+0x12b/0x240 fs/eventpoll.c:2275 __x64_sys_epoll_pwait+0x74/0x80 fs/eventpoll.c:2275 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x44/0xd0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae read to 0xffff88810480c7d8 of 8 bytes by task 1799 on cpu 1: list_empty_careful include/linux/list.h:329 [inline] ep_events_available fs/eventpoll.c:381 [inline] ep_poll fs/eventpoll.c:1797 [inline] do_epoll_wait+0x279/0xf40 fs/eventpoll.c:2234 do_epoll_pwait fs/eventpoll.c:2268 [inline] __do_sys_epoll_pwait fs/eventpoll.c:2281 [inline] __se_sys_epoll_pwait+0x12b/0x240 fs/eventpoll.c:2275 __x64_sys_epoll_pwait+0x74/0x80 fs/eventpoll.c:2275 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x44/0xd0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae value changed: 0xffff88810480c7d0 -> 0xffff888103c15098 Reported by Kernel Concurrency Sanitizer on: CPU: 1 PID: 1799 Comm: syz-fuzzer Tainted:
    G W 5.17.0-rc7-syzkaller-dirty #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 (CVE-2022-49443)

  - 已解決 Linux 核心中的下列弱點：ima: Fix potential memory leak in ima_init_crypto() On failure to allocate the SHA1 tfm, IMA fails to initialize and exits without freeing the ima_algo_array. Add the missing kfree() for ima_algo_array to avoid the potential memory leak.
    (CVE-2022-49627)

  - 已解決 Linux 核心中的下列弱點：tracing/histograms: Fix memory leak problem This reverts commit 46bbe5c671e06f070428b9be142cc4ee5cedebac. As commit 46bbe5c671e0 (tracing:
    fix double free) said, the double free problem reported by clang static analyzer is: > In parse_var_defs() if there is a problem allocating > var_defs.expr, the earlier var_defs.name is freed. > This free is duplicated by free_var_defs() which frees > the rest of the list. However, if there is a problem allocating N-th var_defs.expr: + in parse_var_defs(), the freed 'earlier var_defs.name' is actually the N-th var_defs.name; + then in free_var_defs(), the names from 0th to (N-1)-th are freed; IF ALLOCATING PROBLEM HAPPENED HERE!!! -+ \ | 0th 1th (N-1)-th N-th V +-------------+-------------+-----+-------------+----------- var_defs: | name | expr | name | expr | ... | name | expr | name | /// +-------------+-------------+-----+-------------+----------- These two frees don't act on same name, so there was no double free problem before. Conversely, after that commit, we get a memory leak problem because the above N-th var_defs.name is not freed. If enable CONFIG_DEBUG_KMEMLEAK and inject a fault at where the N-th var_defs.expr allocated, then execute on shell like: $ echo 'hist:key=call_site:val=$v1,$v2:v1=bytes_req,v2=bytes_alloc' > \ /sys/kernel/debug/tracing/events/kmem/kmalloc/trigger Then kmemleak reports: unreferenced object 0xffff8fb100ef3518 (size 8): comm bash, pid 196, jiffies 4295681690 (age 28.538s) hex dump (first 8 bytes): 76 31 00 00 b1 8f ff ff v1...... backtrace: [<0000000038fe4895>] kstrdup+0x2d/0x60 [<00000000c99c049a>] event_hist_trigger_parse+0x206f/0x20e0 [<00000000ae70d2cc>] trigger_process_regex+0xc0/0x110 [<0000000066737a4c>] event_trigger_write+0x75/0xd0 [<000000007341e40c>] vfs_write+0xbb/0x2a0 [<0000000087fde4c2>] ksys_write+0x59/0xd0 [<00000000581e9cdf>] do_syscall_64+0x3a/0x80 [<00000000cf3b065c>] entry_SYSCALL_64_after_hwframe+0x46/0xb0 (CVE-2022-49648)

  - 已解決 Linux 核心中的下列弱點：linux/dim: Fix divide by 0 in RDMA DIM Fix a divide 0 error in rdma_dim_stats_compare() when prev->cpe_ratio == 0. CallTrace: Hardware name: H3C R4900 G3/RS33M2C9S, BIOS 2.00.37P21 03/12/2020 task: ffff880194b78000 task.stack: ffffc90006714000 RIP:
    0010:backport_rdma_dim+0x10e/0x240 [mlx_compat] RSP: 0018:ffff880c10e83ec0 EFLAGS: 00010202 RAX:
    0000000000002710 RBX: ffff88096cd7f780 RCX: 0000000000000064 RDX: 0000000000000000 RSI: 0000000000000002 RDI: 0000000000000001 RBP: 0000000000000001 R08: 0000000000000000 R09: 0000000000000000 R10:
    0000000000000000 R11: 0000000000000000 R12: 000000001d7c6c09 R13: ffff88096cd7f780 R14: ffff880b174fe800 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffff880c10e80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000a0965b00 CR3: 000000000200a003 CR4: 00000000007606e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6:
    00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: <IRQ> ib_poll_handler+0x43/0x80 [ib_core] irq_poll_softirq+0xae/0x110 __do_softirq+0xd1/0x28c irq_exit+0xde/0xf0 do_IRQ+0x54/0xe0 common_interrupt+0x8f/0x8f </IRQ> ? cpuidle_enter_state+0xd9/0x2a0 ? cpuidle_enter_state+0xc7/0x2a0 ? do_idle+0x170/0x1d0 ? cpu_startup_entry+0x6f/0x80 ? start_secondary+0x1b9/0x210 ? secondary_startup_64+0xa5/0xb0 Code: 0f 87 e1 00 00 00 8b 4c 24 14 44 8b 43 14 89 c8 4d 63 c8 44 29 c0 99 31 d0 29 d0 31 d2 48 98 48 8d 04 80 48 8d 04 80 48 c1 e0 02 <49> f7 f1 48 83 f8 0a 0f 86 c1 00 00 00 44 39 c1 7f 10 48 89 df RIP: backport_rdma_dim+0x10e/0x240 [mlx_compat] RSP: ffff880c10e83ec0 (CVE-2022-49670)

請注意，Nessus 並未測試這些問題，而是僅依據應用程式自我報告的版本號碼作出判斷。

Rocky Linux 9.6 主機已安裝的套件會受到 TuxCare ALMALINUX9.6：CLSA-2026：1779434490 公告中提及的多個弱點影響。

  - 已解決 Linux 核心中的下列弱點：configfs: fix a race in configfs_{,un}register_subsystem() When configfs_register_subsystem() or configfs_unregister_subsystem() is executing link_group() or unlink_group(), it is possible that two processes add or delete list concurrently. Some unfortunate interleavings of them can cause kernel panic. One of cases is: A --> B --> C --> D A <-- B <-- C <-- D delete list_head *B | delete list_head *C
    --------------------------------|----------------------------------- configfs_unregister_subsystem | configfs_unregister_subsystem unlink_group | unlink_group unlink_obj | unlink_obj list_del_init | list_del_init __list_del_entry | __list_del_entry __list_del | __list_del // next == C | next->prev = prev | | next->prev = prev prev->next = next | | // prev == B | prev->next = next Fix this by adding mutex when calling link_group() or unlink_group(), but parent configfs_subsystem is NULL when config_item is root. So I create a mutex configfs_subsystem_mutex. (CVE-2022-48931)

  - 已解決 Linux 核心中的下列弱點：list: fix a data-race around ep->rdllist ep_poll() first calls ep_events_available() with no lock held and checks if ep->rdllist is empty by list_empty_careful(), which reads rdllist->prev. Thus all accesses to it need some protection to avoid store/load-tearing. Note INIT_LIST_HEAD_RCU() already has the annotation for both prev and next.
    Commit bf3b9f6372c4 (epoll: Add busy poll support to epoll with socket fds.) added the first lockless ep_events_available(), and commit c5a282e9635e (fs/epoll: reduce the scope of wq lock in epoll_wait()) made some ep_events_available() calls lockless and added single call under a lock, finally commit e59d3c64cba6 (epoll: eliminate unnecessary lock for zero timeout) made the last ep_events_available() lockless. BUG: KCSAN: data-race in do_epoll_wait / do_epoll_wait write to 0xffff88810480c7d8 of 8 bytes by task 1802 on cpu 0: INIT_LIST_HEAD include/linux/list.h:38 [inline] list_splice_init include/linux/list.h:492 [inline] ep_start_scan fs/eventpoll.c:622 [inline] ep_send_events fs/eventpoll.c:1656 [inline] ep_poll fs/eventpoll.c:1806 [inline] do_epoll_wait+0x4eb/0xf40 fs/eventpoll.c:2234 do_epoll_pwait fs/eventpoll.c:2268 [inline] __do_sys_epoll_pwait fs/eventpoll.c:2281 [inline] __se_sys_epoll_pwait+0x12b/0x240 fs/eventpoll.c:2275 __x64_sys_epoll_pwait+0x74/0x80 fs/eventpoll.c:2275 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x44/0xd0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae read to 0xffff88810480c7d8 of 8 bytes by task 1799 on cpu 1: list_empty_careful include/linux/list.h:329 [inline] ep_events_available fs/eventpoll.c:381 [inline] ep_poll fs/eventpoll.c:1797 [inline] do_epoll_wait+0x279/0xf40 fs/eventpoll.c:2234 do_epoll_pwait fs/eventpoll.c:2268 [inline] __do_sys_epoll_pwait fs/eventpoll.c:2281 [inline] __se_sys_epoll_pwait+0x12b/0x240 fs/eventpoll.c:2275 __x64_sys_epoll_pwait+0x74/0x80 fs/eventpoll.c:2275 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x44/0xd0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae value changed: 0xffff88810480c7d0 -> 0xffff888103c15098 Reported by Kernel Concurrency Sanitizer on: CPU: 1 PID: 1799 Comm: syz-fuzzer Tainted:
    G W 5.17.0-rc7-syzkaller-dirty #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 (CVE-2022-49443)

  - 已解決 Linux 核心中的下列弱點：ima: Fix potential memory leak in ima_init_crypto() On failure to allocate the SHA1 tfm, IMA fails to initialize and exits without freeing the ima_algo_array. Add the missing kfree() for ima_algo_array to avoid the potential memory leak.
    (CVE-2022-49627)

  - 已解決 Linux 核心中的下列弱點：tracing/histograms: Fix memory leak problem This reverts commit 46bbe5c671e06f070428b9be142cc4ee5cedebac. As commit 46bbe5c671e0 (tracing:
    fix double free) said, the double free problem reported by clang static analyzer is: > In parse_var_defs() if there is a problem allocating > var_defs.expr, the earlier var_defs.name is freed. > This free is duplicated by free_var_defs() which frees > the rest of the list. However, if there is a problem allocating N-th var_defs.expr: + in parse_var_defs(), the freed 'earlier var_defs.name' is actually the N-th var_defs.name; + then in free_var_defs(), the names from 0th to (N-1)-th are freed; IF ALLOCATING PROBLEM HAPPENED HERE!!! -+ \ | 0th 1th (N-1)-th N-th V +-------------+-------------+-----+-------------+----------- var_defs: | name | expr | name | expr | ... | name | expr | name | /// +-------------+-------------+-----+-------------+----------- These two frees don't act on same name, so there was no double free problem before. Conversely, after that commit, we get a memory leak problem because the above N-th var_defs.name is not freed. If enable CONFIG_DEBUG_KMEMLEAK and inject a fault at where the N-th var_defs.expr allocated, then execute on shell like: $ echo 'hist:key=call_site:val=$v1,$v2:v1=bytes_req,v2=bytes_alloc' > \ /sys/kernel/debug/tracing/events/kmem/kmalloc/trigger Then kmemleak reports: unreferenced object 0xffff8fb100ef3518 (size 8): comm bash, pid 196, jiffies 4295681690 (age 28.538s) hex dump (first 8 bytes): 76 31 00 00 b1 8f ff ff v1...... backtrace: [<0000000038fe4895>] kstrdup+0x2d/0x60 [<00000000c99c049a>] event_hist_trigger_parse+0x206f/0x20e0 [<00000000ae70d2cc>] trigger_process_regex+0xc0/0x110 [<0000000066737a4c>] event_trigger_write+0x75/0xd0 [<000000007341e40c>] vfs_write+0xbb/0x2a0 [<0000000087fde4c2>] ksys_write+0x59/0xd0 [<00000000581e9cdf>] do_syscall_64+0x3a/0x80 [<00000000cf3b065c>] entry_SYSCALL_64_after_hwframe+0x46/0xb0 (CVE-2022-49648)

  - 已解決 Linux 核心中的下列弱點：linux/dim: Fix divide by 0 in RDMA DIM Fix a divide 0 error in rdma_dim_stats_compare() when prev->cpe_ratio == 0. CallTrace: Hardware name: H3C R4900 G3/RS33M2C9S, BIOS 2.00.37P21 03/12/2020 task: ffff880194b78000 task.stack: ffffc90006714000 RIP:
    0010:backport_rdma_dim+0x10e/0x240 [mlx_compat] RSP: 0018:ffff880c10e83ec0 EFLAGS: 00010202 RAX:
    0000000000002710 RBX: ffff88096cd7f780 RCX: 0000000000000064 RDX: 0000000000000000 RSI: 0000000000000002 RDI: 0000000000000001 RBP: 0000000000000001 R08: 0000000000000000 R09: 0000000000000000 R10:
    0000000000000000 R11: 0000000000000000 R12: 000000001d7c6c09 R13: ffff88096cd7f780 R14: ffff880b174fe800 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffff880c10e80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000a0965b00 CR3: 000000000200a003 CR4: 00000000007606e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6:
    00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: <IRQ> ib_poll_handler+0x43/0x80 [ib_core] irq_poll_softirq+0xae/0x110 __do_softirq+0xd1/0x28c irq_exit+0xde/0xf0 do_IRQ+0x54/0xe0 common_interrupt+0x8f/0x8f </IRQ> ? cpuidle_enter_state+0xd9/0x2a0 ? cpuidle_enter_state+0xc7/0x2a0 ? do_idle+0x170/0x1d0 ? cpu_startup_entry+0x6f/0x80 ? start_secondary+0x1b9/0x210 ? secondary_startup_64+0xa5/0xb0 Code: 0f 87 e1 00 00 00 8b 4c 24 14 44 8b 43 14 89 c8 4d 63 c8 44 29 c0 99 31 d0 29 d0 31 d2 48 98 48 8d 04 80 48 8d 04 80 48 c1 e0 02 <49> f7 f1 48 83 f8 0a 0f 86 c1 00 00 00 44 39 c1 7f 10 48 89 df RIP: backport_rdma_dim+0x10e/0x240 [mlx_compat] RSP: ffff880c10e83ec0 (CVE-2022-49670)

請注意，Nessus 並未測試這些問題，而是僅依據應用程式自我報告的版本號碼作出判斷。

ID	名稱	產品	系列	已發布	已更新	嚴重性
225614	Linux Distros 未修補的弱點：CVE-2022-48931	Nessus	Misc.	2025/3/5	2026/7/17	medium
159558	Amazon Linux 2核心 --advisory ALAS2-2022-1768 (ALAS-2022-1768)	Nessus	Amazon Linux Local Security Checks	2022/4/6	2026/2/24	high
160422	Amazon Linux 2核心 --advisory ALAS2KERNEL-5。4-2022-024 (ALASKERNEL-5.4-2022-024)	Nessus	Amazon Linux Local Security Checks	2022/5/2	2026/1/26	high
351689	AlmaLinux 9.2 [TuxCare] 安全性更新：bpftool / kernel / kernel-abi-stablelists / kernel-core / etc 多個弱點（ALMALINUX9.2：CLSA-2026：1780516677）	Nessus	Alma Linux Local Security Checks	2026/9/30	2026/9/30	high
160433	Amazon Linux 2核心 --advisory ALAS2KERNEL-5。10-2022-012 (ALASKERNEL-5.10-2022-012)	Nessus	Amazon Linux Local Security Checks	2022/5/2	2026/2/26	high
360724	AlmaLinux 9.6 [TuxCare] 安全性更新：kernel / kernel-abi-stablelists / kernel-core / etc 多個弱點（ALMALINUX9.6：CLSA-2026：1779434490）	Nessus	Alma Linux Local Security Checks	2026/10/1	2026/10/2	high
360889	Rocky Linux 9.6 [TuxCare] 安全性更新：kernel / kernel-abi-stablelists / kernel-core / etc 多個弱點（ALMALINUX9.6：CLSA-2026：1779434490）	Nessus	Rocky Linux Local Security Checks	2026/10/1	2026/10/2	high

偵測

搜尋 Plugin

medium

high

high

high

high

high

high