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

    在 Linux 核心中發現一個缺陷。如果透過驅動程式的裝置檔案連續要求 NVME_IOCTL_RESET 和 NVME_IOCTL_SUBSYS_RESET，可能會發生拒絕服務，進而導致 PCIe 連結中斷。(CVE-2022-3169)

    在 Linux 核心的 GPU i915 核心驅動程式中發現不正確的 TLB 排清問題，此問題可能會導致隨機記憶體損毀或資料洩漏。本機使用者可利用此缺陷造成系統當機，或提升自己的系統權限。(CVE-2022-4139)

    在 5.10.155 之前的 Linux 核心 5.10.x 版中發現一個問題。在 fs/io_uring.c 的 io_sqpoll_wait_sq 中，攻擊者可利用釋放後使用來造成核心損毀，進而導致拒絕服務。可略過 finish_wait。在某些情況下，若將處理程序分支再快速終止，可能會發生攻擊。
    注意：較新的核心版本 (例如 5.15 longterm 系列) 已大幅變更 io_sqpoll_wait_sq 的實作。(CVE-2022-47946)

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

    mm/damon/sysfs：修正 damon_sysfs_set_schemes() 中線上微調底下的錯誤空白配置假設 (CVE-2022-48996)

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

    gfs2：讀取超級區塊後檢查 sb_bsize_shift (CVE-2022-49769)

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

    Ceph：當解碼快照失敗時，避免將領域放置兩次 （CVE-2022-49770）

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

    dm ioctl：修正 list_versions 與模組載入爭用時的錯誤行為 (CVE-2022-49771)

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

    macvlan：強制執行一致的最小 mtu (CVE-2022-49776)

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

    輸入：i8042 - 修正模組移除時平台裝置洩漏 （CVE-2022-49777）

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

    kprobes：跳過 kprobe-on-ftrace 案例中清除 aggrprobe 的post_handler （CVE-2022-49779）

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

    scsi： target： tcm_loop：修正 tcm_loop_setup_hba_bus（） 中可能的名稱洩漏 （CVE-2022-49780）

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

    mmc：sdhci-pci：修正因缺少 pci_dev_put() 而可能造成的記憶體洩漏 (CVE-2022-49787)

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

    misc/vmw_vmci：修正 vmci_host_do_receive_datagram() 中的資訊洩漏 (CVE-2022-49788)

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

    ftrace：修正 ftrace_add_mod() 中的 null 指標解除參照 (CVE-2022-49802)

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

    drbd：drbd_create_device() 中有釋放後使用錯誤 (CVE-2022-49811)

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

    bridge： switchdev：修正變更 VLAN 通訊協定時的記憶體洩漏 （CVE-2022-49812）

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

    kcm：關閉 sk_receive_queue 上的爭用情形 (CVE-2022-49814)

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

    ata： libata-transport：修正 ata_tdev_add（） 中的錯誤處理 （CVE-2022-49823）

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

    ata： libata-transport：修正 ata_tlink_add（）CVE-2022-49824 （） 中的錯誤處理

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

    ata： libata-transport：修正 ata_tport_add（）CVE-2022-49825 （） 中的錯誤處理

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

    ata： libata-transport：修正 ata_tport_add（）CVE-2022-49826 中的雙 ata_host_put（） （）

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

    drm：修正 drm_vblank_destroy_worker（） 中潛在的 null-ptr-deref （CVE-2022-49827）

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

    drm/drv：修正 drm_dev_init（）CVE-2022-49830 （） 中潛在的記憶體洩漏

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

    pinctrl：devicetree：修正 pinctrl_dt_to_map 中的 null 指標解除參照 (CVE-2022-49832)

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

    sctp：如果修剪了目前 msg 的所有片段區塊，則清除out_curr （CVE-2022-49838）

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

    scsi： scsi_transport_sas：修正 sas_phy_add（） 中的錯誤處理 （CVE-2022-49839）

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

    bpf、test_run：修正 bpf_prog_test_run_skb() 中的對齊問題 (CVE-2022-49840)

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

    ASoC: core: 修復 snd_soc_exit() 中的釋放後使用問題 (CVE-2022-49842)

    在 Linux 核心中發現一個資料爭用缺陷，介於配置 con 的位置和設定 con->sock 的位置之間。在 Linux 核心的 tipc 通訊協定中，存取 net/tipc/topsrv.c 中的 con->sock->sk 時，此問題會導致 NULL 指標解除參照。(CVE-2023-1382)

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

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

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

  - 已解決 Linux 核心中的下列弱點：net: amd-xgbe: Fix skb data length underflow There will be BUG_ON() triggered in include/linux/skbuff.h leading to intermittent kernel panic, when the skb length underflow is detected. Fix this by dropping the packet if such length underflows are seen because of inconsistencies in the hardware descriptors. (CVE-2022-48743)

  - 已解決 Linux 核心中的下列弱點：net: bcmgenet: Use stronger register read/writes to assure ordering GCC12 appears to be much smarter about its dependency tracking and is aware that the relaxed variants are just normal loads and stores and this is causing problems like: [210.074549] ------------[ cut here ]------------ [ 210.079223] NETDEV WATCHDOG: enabcm6e4ei0 (bcmgenet):
    transmit queue 1 timed out [ 210.086717] WARNING: CPU: 1 PID: 0 at net/sched/sch_generic.c:529 dev_watchdog+0x234/0x240 [ 210.095044] Modules linked in: genet(E) nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat] [ 210.146561] ACPI CPPC: PCC check channel failed for ss: 0. ret=-110 [ 210.146927] CPU: 1 PID: 0 Comm: swapper/1 Tainted: G E 5.17.0-rc7G12+ #58 [ 210.153226] CPPC Cpufreq:cppc_scale_freq_workfn: failed to read perf counters [210.161349] Hardware name: Raspberry Pi Foundation Raspberry Pi 4 Model B/Raspberry Pi 4 Model B, BIOS EDK2-DEV 02/08/2022 [ 210.161353] pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [210.161358] pc : dev_watchdog+0x234/0x240 [ 210.161364] lr : dev_watchdog+0x234/0x240 [ 210.161368] sp :
    ffff8000080a3a40 [ 210.161370] x29: ffff8000080a3a40 x28: ffffcd425af87000 x27: ffff8000080a3b20 [210.205150] x26: ffffcd425aa00000 x25: 0000000000000001 x24: ffffcd425af8ec08 [ 210.212321] x23:
    0000000000000100 x22: ffffcd425af87000 x21: ffff55b142688000 [ 210.219491] x20: 0000000000000001 x19:
    ffff55b1426884c8 x18: ffffffffffffffff [ 210.226661] x17: 64656d6974203120 x16: 0000000000000001 x15:
    6d736e617274203a [ 210.233831] x14: 2974656e65676d63 x13: ffffcd4259c300d8 x12: ffffcd425b07d5f0 [210.241001] x11: 00000000ffffffff x10: ffffcd425b07d5f0 x9 : ffffcd4258bdad9c [ 210.248171] x8 :
    00000000ffffdfff x7 : 000000000000003f x6 : 0000000000000000 [ 210.255341] x5 : 0000000000000000 x4 :
    0000000000000000 x3 : 0000000000001000 [ 210.262511] x2 : 0000000000001000 x1 : 0000000000000005 x0 :
    0000000000000044 [ 210.269682] Call trace: [ 210.272133] dev_watchdog+0x234/0x240 [ 210.275811] call_timer_fn+0x3c/0x15c [ 210.279489] __run_timers.part.0+0x288/0x310 [ 210.283777] run_timer_softirq+0x48/0x80 [ 210.287716] __do_softirq+0x128/0x360 [ 210.291392]
    __irq_exit_rcu+0x138/0x140 [ 210.295243] irq_exit_rcu+0x1c/0x30 [ 210.298745] el1_interrupt+0x38/0x54 [210.302334] el1h_64_irq_handler+0x18/0x24 [ 210.306445] el1h_64_irq+0x7c/0x80 [ 210.309857] arch_cpu_idle+0x18/0x2c [ 210.313445] default_idle_call+0x4c/0x140 [ 210.317470] cpuidle_idle_call+0x14c/0x1a0 [ 210.321584] do_idle+0xb0/0x100 [ 210.324737] cpu_startup_entry+0x30/0x8c [210.328675] secondary_start_kernel+0xe4/0x110 [ 210.333138] __secondary_switched+0x94/0x98 The assumption when these were relaxed seems to be that device memory would be mapped non reordering, and that other constructs (spinlocks/etc) would provide the barriers to assure that packet data and in memory rings/queues were ordered with respect to device register reads/writes. This itself seems a bit sketchy, but the real problem with GCC12 is that it is moving the actual reads/writes around at will as though they were independent operations when in truth they are not, but the compiler can't know that. When looking at the assembly dumps for many of these routines its possible to see very clean, but not strictly in program order operations occurring as the compiler would be free to do if these weren't actually register reads/write operations. Its possible to suppress the timeout with a liberal bit of dma_mb()'s sprinkled around but the device still seems unable to reliably send/receive data. A better plan is to use the safer readl/writel everywhere. Since this partially reverts an older commit, which notes the use of the relaxed variants for performance reasons. I would suggest that any performance problems ---truncated--- (CVE-2022-49194)

  - 已解決 Linux 核心中的下列弱點：ima: Fix a potential integer overflow in ima_appraise_measurement When the ima-modsig is enabled, the rc passed to evm_verifyxattr() may be negative, which may cause the integer overflow problem. (CVE-2022-49643)

  - 已解決 Linux 核心中的下列弱點：ovl: Use buf flexible array for memcpy() destination The buf flexible array needs to be the memcpy() destination to avoid false positive run-time warning from the recent FORTIFY_SOURCE hardening: memcpy: detected field-spanning write (size 93) of single field &fh->fb at fs/overlayfs/export.c:799 (size 21) (CVE-2022-49743)

  - 已解決 Linux 核心中的下列弱點：kprobes: Skip clearing aggrprobe's post_handler in kprobe-on-ftrace case In __unregister_kprobe_top(), if the currently unregistered probe has post_handler but other child probes of the aggrprobe do not have post_handler, the post_handler of the aggrprobe is cleared. If this is a ftrace-based probe, there is a problem. In later calls to disarm_kprobe(), we will use kprobe_ftrace_ops because post_handler is NULL. But we're armed with kprobe_ipmodify_ops. This triggers a WARN in __disarm_kprobe_ftrace() and may even cause use-after-free:
    Failed to disarm kprobe-ftrace at kernel_clone+0x0/0x3c0 (error -2) WARNING: CPU: 5 PID: 137 at kernel/kprobes.c:1135 __disarm_kprobe_ftrace.isra.21+0xcf/0xe0 Modules linked in: testKprobe_007(-) CPU: 5 PID: 137 Comm: rmmod Not tainted 6.1.0-rc4-dirty #18 [...] Call Trace: <TASK> __disable_kprobe+0xcd/0xe0
    __unregister_kprobe_top+0x12/0x150 ? mutex_lock+0xe/0x30 unregister_kprobes.part.23+0x31/0xa0 unregister_kprobe+0x32/0x40 __x64_sys_delete_module+0x15e/0x260 ? do_user_addr_fault+0x2cd/0x6b0 do_syscall_64+0x3a/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd [...] For the kprobe-on-ftrace case, we keep the post_handler setting to identify this aggrprobe armed with kprobe_ipmodify_ops. This way we can disarm it correctly. (CVE-2022-49779)

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

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

    在 Linux 核心中發現一個缺陷。如果透過驅動程式的裝置檔案連續要求 NVME_IOCTL_RESET 和 NVME_IOCTL_SUBSYS_RESET，可能會發生拒絕服務，進而導致 PCIe 連結中斷。(CVE-2022-3169)

    在 Linux 核心中發現一個歸類為「有問題」的弱點。這會影響 IPv4 處置程式元件中 net/ipv4/fib_semantics.c 檔案的 fib_nh_match 函式。操控此弱點可導致超出邊界讀取。攻擊者可從遠端發動攻擊。建議套用修補程式以修正此問題。已爲此弱點指派識別碼 VDB-210357。(CVE-2022-3435)

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

    char：tpm：使用鎖定保護 tpm_pm_suspend (CVE-2022-48997)

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

    ipv4：當 fib_info 包含 nh 參照時，處理刪除多重路徑路由的嘗試 (CVE-2022-48999)

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

    iommu/vt-d：修正 dmar_dev_scope_init() 中的 PCI 裝置 refcount 洩漏 (CVE-2022-49002)

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

    追踪：移除使用的動態事件時釋放緩衝區 (CVE-2022-49006)

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

    nilfs2：修正 nilfs_palloc_commit_free_entry() 中的 NULL 指標解除參照 (CVE-2022-49007)

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

    sctp：修正 sctp_stream_outq_migrate() 中的記憶體洩漏 (CVE-2022-49013)

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

    net：tun：修正 tun_detach() 中的釋放後使用 (CVE-2022-49014)

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

    net：hsr：修復潛在的釋放後使用問題 (CVE-2022-49015)

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

    net：phy：在 probe() 失敗時修正 null-ptr-deref (CVE-2022-49021)

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

    net/mlx5e：修正還原終止表格時的釋放後使用 (CVE-2022-49025)

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

    btrfs：qgroup：修復 btrfs_qgroup_inherit() 中無效內容錯誤的 Sleep (CVE-2022-49033)

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

    ntfs：迭代 ATTR_RECORD 時檢查溢位情況 (CVE-2022-49762)

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

    ntfs：修正 ntfs_attr_find() 中的釋放後使用 (CVE-2022-49763)

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

    gfs2：讀取超級區塊後檢查 sb_bsize_shift (CVE-2022-49769)

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

    Ceph：當解碼快照失敗時，避免將領域放置兩次 （CVE-2022-49770）

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

    dm ioctl：修正 list_versions 與模組載入爭用時的錯誤行為 (CVE-2022-49771)

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

    macvlan：強制執行一致的最小 mtu (CVE-2022-49776)

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

    輸入：i8042 - 修正模組移除時平台裝置洩漏 （CVE-2022-49777）

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

    kprobes：跳過 kprobe-on-ftrace 案例中清除 aggrprobe 的post_handler （CVE-2022-49779）

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

    scsi： target： tcm_loop：修正 tcm_loop_setup_hba_bus（） 中可能的名稱洩漏 （CVE-2022-49780）

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

    mmc：sdhci-pci：修正因缺少 pci_dev_put() 而可能造成的記憶體洩漏 (CVE-2022-49787)

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

    misc/vmw_vmci：修正 vmci_host_do_receive_datagram() 中的資訊洩漏 (CVE-2022-49788)

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

    ftrace：修正 ftrace_add_mod() 中的 null 指標解除參照 (CVE-2022-49802)

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

    drbd：drbd_create_device() 中有釋放後使用錯誤 (CVE-2022-49811)

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

    kcm：關閉 sk_receive_queue 上的爭用情形 (CVE-2022-49814)

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

    ata： libata-transport：修正 ata_tport_add（）CVE-2022-49826 中的雙 ata_host_put（） （）

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

    pinctrl：devicetree：修正 pinctrl_dt_to_map 中的 null 指標解除參照 (CVE-2022-49832)

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

    nilfs2：修正重新掛載時 ns_writer 的釋放後使用錯誤 (CVE-2022-49834)

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

    bpf、test_run：修正 bpf_prog_test_run_skb() 中的對齊問題 (CVE-2022-49840)

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

    ASoC: core: 修復 snd_soc_exit() 中的釋放後使用問題 (CVE-2022-49842)

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

    can： j1939： j1939_send_one（）：修正缺少的 CAN 標頭初始化 （CVE-2022-49845）

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

    udf：修正 udf_find_entry() 中的 slab-out-of-bounds 寫入錯誤 (CVE-2022-49846)

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

    nilfs2：修正 nilfs_count_free_blocks() 中的鎖死 (CVE-2022-49850)

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

    net：macvlan：修正 macvlan_common_newlink 的記憶體洩漏 (CVE-2022-49853)

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

    tipc：修正 tipc_nl_compat_name_table_dump_header 中的 msg->req tlv len 檢查 (CVE-2022-49862)

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

    can： af_can：修正 can_rx_register（） 中的 NULL 指標解除參照 （CVE-2022-49863）

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

    ipv6：addrlabel：修正將結構 ifaddrlblmsg 傳送至網路時的資訊洩漏 (CVE-2022-49865)

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

    bnxt_en：修正 bnxt_hwrm_set_coal（） 中可能的損毀 （CVE-2022-49869）

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

    capabilities：修正對 CAP_TO_MASK 進行位移運算時的未定義行為 (CVE-2022-49870)

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

    net： tun：修正 napi_get_frags （CVE-2022-49871） 的記憶體洩漏

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

    net：gso：修正具有混合 head alloc 類型的 frag_list 上的錯誤 (CVE-2022-49872)

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

    HID：hyperv：修正 mousevsc_probe() 中的潛在記憶體洩漏 (CVE-2022-49874)

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

    bpf， sockmap：修正 sk_stream_kill_queues （CVE-2022-49877） 的 sk->sk_forward_alloc 警告

    在 Linux 核心中發現一個資料爭用缺陷，介於配置 con 的位置和設定 con->sock 的位置之間。在 Linux 核心的 tipc 通訊協定中，存取 net/tipc/topsrv.c 中的 con->sock->sk 時，此問題會導致 NULL 指標解除參照。(CVE-2023-1382)

    在 Linux 核心 6.0.8 版本中，fs/ntfs/attrib.c 的 ntfs_attr_find 中有超出邊界讀取情形。
    (CVE-2023-26607)

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

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

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

  - 已解決 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 核心中的下列弱點：xen/privcmd: fix error exit of privcmd_ioctl_dm_op() The error exit of privcmd_ioctl_dm_op() is calling unlock_pages() potentially with pages being NULL, leading to a NULL dereference. Additionally lock_pages() doesn't check for pin_user_pages_fast() having been completely successful, resulting in potentially not locking all pages into memory. This could result in sporadic failures when using the related memory in user mode. Fix all of that by calling unlock_pages() always with the real number of pinned pages, which will be zero in case pages being NULL, and by checking the number of pages pinned by pin_user_pages_fast() matching the expected number of pages. (CVE-2022-49989)

  - 已解決 Linux 核心中的下列弱點：platform/x86: mxm-wmi: fix memleak in mxm_wmi_call_mx[ds|mx]() The ACPI buffer memory (out.pointer) returned by wmi_evaluate_method() is not freed after the call, so it leads to memory leak. The method results in ACPI buffer is not used, so just pass NULL to wmi_evaluate_method() which fixes the memory leak. (CVE-2022-50521)

  - 已解決 Linux 核心中的下列弱點：net: USB: Fix wrong-direction WARNING in plusb.c The syzbot fuzzer detected a bug in the plusb network driver: A zero-length control-OUT transfer was treated as a read instead of a write. In modern kernels this error provokes a WARNING: usb 1-1: BOGUS control dir, pipe 80000280 doesn't match bRequestType c0 WARNING: CPU: 0 PID: 4645 at drivers/usb/core/urb.c:411 usb_submit_urb+0x14a7/0x1880 drivers/usb/core/urb.c:411 Modules linked in: CPU:
    1 PID: 4645 Comm: dhcpcd Not tainted 6.2.0-rc6-syzkaller-00050-g9f266ccaa2f5 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/12/2023 RIP: 0010:usb_submit_urb+0x14a7/0x1880 drivers/usb/core/urb.c:411 ... Call Trace: <TASK> usb_start_wait_urb+0x101/0x4b0 drivers/usb/core/message.c:58 usb_internal_control_msg drivers/usb/core/message.c:102 [inline] usb_control_msg+0x320/0x4a0 drivers/usb/core/message.c:153 __usbnet_read_cmd+0xb9/0x390 drivers/net/usb/usbnet.c:2010 usbnet_read_cmd+0x96/0xf0 drivers/net/usb/usbnet.c:2068 pl_vendor_req drivers/net/usb/plusb.c:60 [inline] pl_set_QuickLink_features drivers/net/usb/plusb.c:75 [inline] pl_reset+0x2f/0xf0 drivers/net/usb/plusb.c:85 usbnet_open+0xcc/0x5d0 drivers/net/usb/usbnet.c:889
    __dev_open+0x297/0x4d0 net/core/dev.c:1417 __dev_change_flags+0x587/0x750 net/core/dev.c:8530 dev_change_flags+0x97/0x170 net/core/dev.c:8602 devinet_ioctl+0x15a2/0x1d70 net/ipv4/devinet.c:1147 inet_ioctl+0x33f/0x380 net/ipv4/af_inet.c:979 sock_do_ioctl+0xcc/0x230 net/socket.c:1169 sock_ioctl+0x1f8/0x680 net/socket.c:1286 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:870 [inline] __se_sys_ioctl fs/ioctl.c:856 [inline] __x64_sys_ioctl+0x197/0x210 fs/ioctl.c:856 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x39/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd The fix is to call usbnet_write_cmd() instead of usbnet_read_cmd() and remove the USB_DIR_IN flag. (CVE-2023-52742)

  - 已解決 Linux 核心中的下列弱點：tracing: Make sure trace_printk() can output as soon as it can be used Currently trace_printk() can be used as soon as early_trace_init() is called from start_kernel(). But if a crash happens, and ftrace_dump_on_oops is set on the kernel command line, all you get will be: [ 0.456075] <idle>-0 0dN.2. 347519us : Unknown type 6 [ 0.456075] <idle>-0 0dN.2. 353141us : Unknown type 6 [ 0.456075] <idle>-0 0dN.2. 358684us : Unknown type 6 This is because the trace_printk() event (type 6) hasn't been registered yet. That gets done via an early_initcall(), which may be early, but not early enough. Instead of registering the trace_printk() event (and other ftrace events, which are not trace events) via an early_initcall(), have them registered at the same time that trace_printk() can be used. This way, if there is a crash before early_initcall(), then the trace_printk()s will actually be useful. (CVE-2023-53007)

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

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

  - 已解決 Linux 核心中的下列弱點：kprobes: Skip clearing aggrprobe's post_handler in kprobe-on-ftrace case In __unregister_kprobe_top(), if the currently unregistered probe has post_handler but other child probes of the aggrprobe do not have post_handler, the post_handler of the aggrprobe is cleared. If this is a ftrace-based probe, there is a problem. In later calls to disarm_kprobe(), we will use kprobe_ftrace_ops because post_handler is NULL. But we're armed with kprobe_ipmodify_ops. This triggers a WARN in __disarm_kprobe_ftrace() and may even cause use-after-free:
    Failed to disarm kprobe-ftrace at kernel_clone+0x0/0x3c0 (error -2) WARNING: CPU: 5 PID: 137 at kernel/kprobes.c:1135 __disarm_kprobe_ftrace.isra.21+0xcf/0xe0 Modules linked in: testKprobe_007(-) CPU: 5 PID: 137 Comm: rmmod Not tainted 6.1.0-rc4-dirty #18 [...] Call Trace: <TASK> __disable_kprobe+0xcd/0xe0
    __unregister_kprobe_top+0x12/0x150 ? mutex_lock+0xe/0x30 unregister_kprobes.part.23+0x31/0xa0 unregister_kprobe+0x32/0x40 __x64_sys_delete_module+0x15e/0x260 ? do_user_addr_fault+0x2cd/0x6b0 do_syscall_64+0x3a/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd [...] For the kprobe-on-ftrace case, we keep the post_handler setting to identify this aggrprobe armed with kprobe_ipmodify_ops. This way we can disarm it correctly. (CVE-2022-49779)

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

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

  - 已解決 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 核心中的下列弱點：xen/privcmd: fix error exit of privcmd_ioctl_dm_op() The error exit of privcmd_ioctl_dm_op() is calling unlock_pages() potentially with pages being NULL, leading to a NULL dereference. Additionally lock_pages() doesn't check for pin_user_pages_fast() having been completely successful, resulting in potentially not locking all pages into memory. This could result in sporadic failures when using the related memory in user mode. Fix all of that by calling unlock_pages() always with the real number of pinned pages, which will be zero in case pages being NULL, and by checking the number of pages pinned by pin_user_pages_fast() matching the expected number of pages. (CVE-2022-49989)

  - 已解決 Linux 核心中的下列弱點：platform/x86: mxm-wmi: fix memleak in mxm_wmi_call_mx[ds|mx]() The ACPI buffer memory (out.pointer) returned by wmi_evaluate_method() is not freed after the call, so it leads to memory leak. The method results in ACPI buffer is not used, so just pass NULL to wmi_evaluate_method() which fixes the memory leak. (CVE-2022-50521)

  - 已解決 Linux 核心中的下列弱點：net: USB: Fix wrong-direction WARNING in plusb.c The syzbot fuzzer detected a bug in the plusb network driver: A zero-length control-OUT transfer was treated as a read instead of a write. In modern kernels this error provokes a WARNING: usb 1-1: BOGUS control dir, pipe 80000280 doesn't match bRequestType c0 WARNING: CPU: 0 PID: 4645 at drivers/usb/core/urb.c:411 usb_submit_urb+0x14a7/0x1880 drivers/usb/core/urb.c:411 Modules linked in: CPU:
    1 PID: 4645 Comm: dhcpcd Not tainted 6.2.0-rc6-syzkaller-00050-g9f266ccaa2f5 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/12/2023 RIP: 0010:usb_submit_urb+0x14a7/0x1880 drivers/usb/core/urb.c:411 ... Call Trace: <TASK> usb_start_wait_urb+0x101/0x4b0 drivers/usb/core/message.c:58 usb_internal_control_msg drivers/usb/core/message.c:102 [inline] usb_control_msg+0x320/0x4a0 drivers/usb/core/message.c:153 __usbnet_read_cmd+0xb9/0x390 drivers/net/usb/usbnet.c:2010 usbnet_read_cmd+0x96/0xf0 drivers/net/usb/usbnet.c:2068 pl_vendor_req drivers/net/usb/plusb.c:60 [inline] pl_set_QuickLink_features drivers/net/usb/plusb.c:75 [inline] pl_reset+0x2f/0xf0 drivers/net/usb/plusb.c:85 usbnet_open+0xcc/0x5d0 drivers/net/usb/usbnet.c:889
    __dev_open+0x297/0x4d0 net/core/dev.c:1417 __dev_change_flags+0x587/0x750 net/core/dev.c:8530 dev_change_flags+0x97/0x170 net/core/dev.c:8602 devinet_ioctl+0x15a2/0x1d70 net/ipv4/devinet.c:1147 inet_ioctl+0x33f/0x380 net/ipv4/af_inet.c:979 sock_do_ioctl+0xcc/0x230 net/socket.c:1169 sock_ioctl+0x1f8/0x680 net/socket.c:1286 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:870 [inline] __se_sys_ioctl fs/ioctl.c:856 [inline] __x64_sys_ioctl+0x197/0x210 fs/ioctl.c:856 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x39/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd The fix is to call usbnet_write_cmd() instead of usbnet_read_cmd() and remove the USB_DIR_IN flag. (CVE-2023-52742)

  - 已解決 Linux 核心中的下列弱點：tracing: Make sure trace_printk() can output as soon as it can be used Currently trace_printk() can be used as soon as early_trace_init() is called from start_kernel(). But if a crash happens, and ftrace_dump_on_oops is set on the kernel command line, all you get will be: [ 0.456075] <idle>-0 0dN.2. 347519us : Unknown type 6 [ 0.456075] <idle>-0 0dN.2. 353141us : Unknown type 6 [ 0.456075] <idle>-0 0dN.2. 358684us : Unknown type 6 This is because the trace_printk() event (type 6) hasn't been registered yet. That gets done via an early_initcall(), which may be early, but not early enough. Instead of registering the trace_printk() event (and other ftrace events, which are not trace events) via an early_initcall(), have them registered at the same time that trace_printk() can be used. This way, if there is a crash before early_initcall(), then the trace_printk()s will actually be useful. (CVE-2023-53007)

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

ID	名稱	產品	系列	已發布	已更新	嚴重性
170458	Amazon Linux 2：核心， --advisory ALAS2KERNEL-5。15-2023-012（ALASKERNEL-5。15-2023-012	Nessus	Amazon Linux Local Security Checks	2023/1/24	2026/6/4	high
168728	Amazon Linux 2：核心， --advisory ALAS2KERNEL-5。10-2022-024（ALASKERNEL-5。10-2022-024	Nessus	Amazon Linux Local Security Checks	2022/12/14	2026/6/4	high
353122	AlmaLinux 9.2 [TuxCare] 安全性更新：bpftool / kernel / kernel-abi-stablelists / kernel-core / etc 多個弱點（ALMALINUX9.2：CLSA-2026：1779375889）	Nessus	Alma Linux Local Security Checks	2026/9/30	2026/10/1	high
200364	Amazon Linux 2：核心， --advisory ALAS2KERNEL-5。4-2024-071（ALASKERNEL-5。4-2024-071	Nessus	Amazon Linux Local Security Checks	2024/6/11	2026/6/4	high
359640	AlmaLinux 9.6 [TuxCare] 安全性更新：kernel / kernel-abi-stablelists / kernel-core / etc 多個弱點（ALMALINUX9.6：CLSA-2026：1782155469）	Nessus	Alma Linux Local Security Checks	2026/10/1	2026/10/1	high
247177	Linux Distros 未修補弱點：CVE-2022-49779	Nessus	Misc.	2025/8/10	2026/9/30	high
359694	Rocky Linux 9.6 [TuxCare] 安全性更新：kernel / kernel-abi-stablelists / kernel-core / etc 多個弱點（ALMALINUX9.6：CLSA-2026：1782155469）	Nessus	Rocky Linux Local Security Checks	2026/10/1	2026/10/1	high

偵測

搜尋 Plugin

high

high

high

high

high

high

high