CentOS Linux 7 主機已安裝的套件會受到 TuxCare CENTOS7：CLSA-2026：1782148320 公告中提及的多個弱點影響。

  - 已解決 Linux 核心中的下列弱點：media: ngene: Fix out-of-bounds bug in ngene_command_config_free_buf() Fix an 11-year old bug in ngene_command_config_free_buf() while addressing the following warnings caught with -Warray-bounds: arch/alpha/include/asm/string.h:22:16: warning:
    '__builtin_memcpy' offset [12, 16] from the object at 'com' is out of the bounds of referenced subobject 'config' with type 'unsigned char' at offset 10 [-Warray-bounds] arch/x86/include/asm/string_32.h:182:25:
    warning: '__builtin_memcpy' offset [12, 16] from the object at 'com' is out of the bounds of referenced subobject 'config' with type 'unsigned char' at offset 10 [-Warray-bounds] The problem is that the original code is trying to copy 6 bytes of data into a one-byte size member _config_ of the wrong structue FW_CONFIGURE_BUFFERS, in a single call to memcpy(). This causes a legitimate compiler warning because memcpy() overruns the length of &com.cmd.ConfigureBuffers.config. It seems that the right structure is FW_CONFIGURE_FREE_BUFFERS, instead, because it contains 6 more members apart from the header _hdr_. Also, the name of the function ngene_command_config_free_buf() suggests that the actual intention is to ConfigureFreeBuffers, instead of ConfigureBuffers (which takes place in the function ngene_command_config_buf(), above). Fix this by enclosing those 6 members of struct FW_CONFIGURE_FREE_BUFFERS into new struct config, and use &com.cmd.ConfigureFreeBuffers.config as the destination address, instead of &com.cmd.ConfigureBuffers.config, when calling memcpy(). This also helps with the ongoing efforts to globally enable -Warray-bounds and get us closer to being able to tighten the FORTIFY_SOURCE routines on memcpy(). (CVE-2021-47288)

  - 已解決 Linux 核心中的下列弱點：nvme: fix a possible use-after-free in controller reset during load Unlike .queue_rq, in .submit_async_event drivers may not check the ctrl readiness for AER submission. This may lead to a use-after-free condition that was observed with nvme-tcp.
    The race condition may happen in the following scenario: 1. driver executes its reset_ctrl_work 2. -> nvme_stop_ctrl - flushes ctrl async_event_work 3. ctrl sends AEN which is received by the host, which in turn schedules AEN handling 4. teardown admin queue (which releases the queue socket) 5. AEN processed, submits another AER, calling the driver to submit 6. driver attempts to send the cmd ==> use-after-free In order to fix that, add ctrl state check to validate the ctrl is actually able to accept the AER submission. This addresses the above race in controller resets because the driver during teardown should:
    1. change ctrl state to RESETTING 2. flush async_event_work (as well as other async work elements) So after 1,2, any other AER command will find the ctrl state to be RESETTING and bail out without submitting the AER. (CVE-2022-48790)

  - 已解決 Linux 核心中的下列弱點：scsi: pm8001: Fix use-after-free for aborted TMF sas_task Currently a use-after-free may occur if a TMF sas_task is aborted before we handle the IO completion in mpi_ssp_completion(). The abort occurs due to timeout. When the timeout occurs, the SAS_TASK_STATE_ABORTED flag is set and the sas_task is freed in pm8001_exec_internal_tmf_task(). However, if the I/O completion occurs later, the I/O completion still thinks that the sas_task is available. Fix this by clearing the ccb->task if the TMF times out - the I/O completion handler does nothing if this pointer is cleared. (CVE-2022-48791)

  - 已解決 Linux 核心中的下列弱點：tracing: Free buffers when a used dynamic event is removed After 65536 dynamic events have been added and removed, the type field of the event then uses the first type number that is available (not currently used by other events). A type number is the identifier of the binary blobs in the tracing ring buffer (known as events) to map them to logic that can parse the binary blob. The issue is that if a dynamic event (like a kprobe event) is traced and is in the ring buffer, and then that event is removed (because it is dynamic, which means it can be created and destroyed), if another dynamic event is created that has the same number that new event's logic on parsing the binary blob will be used. To show how this can be an issue, the following can crash the kernel: # cd /sys/kernel/tracing # for i in `seq 65536`; do echo 'p:kprobes/foo do_sys_openat2 $arg1:u32' > kprobe_events # done For every iteration of the above, the writing to the kprobe_events will remove the old event and create a new one (with the same format) and increase the type number to the next available on until the type number reaches over 65535 which is the max number for the 16 bit type. After it reaches that number, the logic to allocate a new number simply looks for the next available number.
    When an dynamic event is removed, that number is then available to be reused by the next dynamic event created. That is, once the above reaches the max number, the number assigned to the event in that loop will remain the same. Now that means deleting one dynamic event and created another will reuse the previous events type number. This is where bad things can happen. After the above loop finishes, the kprobes/foo event which reads the do_sys_openat2 function call's first parameter as an integer. # echo 1 > kprobes/foo/enable # cat /etc/passwd > /dev/null # cat trace cat-2211 [005] .... 2007.849603: foo:
    (do_sys_openat2+0x0/0x130) arg1=4294967196 cat-2211 [005] .... 2007.849620: foo:
    (do_sys_openat2+0x0/0x130) arg1=4294967196 cat-2211 [005] .... 2007.849838: foo:
    (do_sys_openat2+0x0/0x130) arg1=4294967196 cat-2211 [005] .... 2007.849880: foo:
    (do_sys_openat2+0x0/0x130) arg1=4294967196 # echo 0 > kprobes/foo/enable Now if we delete the kprobe and create a new one that reads a string: # echo 'p:kprobes/foo do_sys_openat2 +0($arg2):string' > kprobe_events And now we can the trace: # cat trace sendmail-1942 [002] ..... 530.136320: foo:
    (do_sys_openat2+0x0/0x240) arg1= cat-2046 [004] ..... 530.930817: foo: (do_sys_openat2+0x0/0x240) arg1= cat-2046 [004] ..... 530.930961: foo: (do_sys_openat2+0x0/0x240) arg1= cat-2046 [004] ..... 530.934278: foo: (do_sys_openat2+0x0/0x240) arg1= cat-2046 [004] ..... 530.934563: foo: (do_sys_openat2+0x0/0x240) arg1= ---truncated--- (CVE-2022-49006)

  - 已解決 Linux 核心中的下列弱點：dm raid: fix accesses beyond end of raid member array On dm-raid table load (using raid_ctr), dm-raid allocates an array rs->devs[rs->raid_disks] for the raid device members. rs->raid_disks is defined by the number of raid metadata and image tupples passed into the target's constructor. In the case of RAID layout changes being requested, that number can be different from the current number of members for existing raid sets as defined in their superblocks. Example RAID layout changes include: - raid1 legs being added/removed - raid4/5/6/10 number of stripes changed (stripe reshaping) - takeover to higher raid level (e.g. raid5 -> raid6) When accessing array members, rs->raid_disks must be used in control loops instead of the potentially larger value in rs->md.raid_disks. Otherwise it will cause memory access beyond the end of the rs->devs array. Fix this by changing code that is prone to out-of-bounds access. Also fix validate_raid_redundancy() to validate all devices that are added. Also, use braces to help clean up raid_iterate_devices(). The out-of-bounds memory accesses was discovered using KASAN. This commit was verified to pass all LVM2 RAID tests (with KASAN enabled). (CVE-2022-49674)

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

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

    在 Linux 核心中發現一個弱點。目前已將其歸類為「有問題」。受到此弱點影響的是 IPv6 Handler 元件的 ipv6_renew_options 函式。攻擊者可利用此弱點造成記憶體洩漏。攻擊者可在遠端執行此攻擊。建議套用修補程式以修正此問題。
    已爲此弱點指派識別碼 VDB-211021。(CVE-2022-3524)

    在 Linux 核心的邏輯連結控制和適配通訊協定 (L2CAP) 實作中發現釋放後使用缺陷，這是 l2cap_parse_conf_rsp 和 l2cap_parse_conf_req 函式中藍牙堆疊一部分。攻擊者如果在標準藍牙傳輸範圍內具有實體存取權，則在受害者附近時，可以透過藍牙執行程式碼，造成核心記憶體流失。(CVE-2022-42896)

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

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

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

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

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

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

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

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

    在 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 核心中，下列弱點已解決：

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

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

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

    在 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 核心中，下列弱點已解決：

    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 核心中，下列弱點已解決：

    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 核心中，下列弱點已解決：

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

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

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

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

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

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

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

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

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

請注意，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 並未測試這些問題，而是僅依據應用程式自我報告的版本號碼作出判斷。

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

  - ASoC： core： 修正 snd_soc_exit（） 中的釋放後使用： KASAN 報告釋放後使用： 錯誤： KASAN：在 device_del+0xb5b/0xc60 中的釋放後使用 透過任務 rmmod/387 在 addr ffff888008655050 讀取大小 8 CPU：2 PID：387 通訊：rmmod 硬體名稱：QEMU 標準電腦 （i440FX + PIIX，1996） 呼叫追蹤： <TASK> dump_stack_lvl+0x79/0x9a print_report+0x17f/0x47b kasan_report+0xbb/0xf0 device_del+0xb5b/0xc60 platform_device_del.part.0+0x24/0x200 platform_device_unregister+0x2e/0x40 snd_soc_exit+0xa/0x22 [snd_soc_core] __do_sys_delete_module.constprop.0+0x34f/0x5b0 do_syscall_64+0x3a/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd ...</TASK> 這是因為在 snd_soc_init（） 中，snd_soc_util_init（） 可能會失敗，但它的 ret 被忽略了，這使得soc_dummy_dev兩次未註冊。snd_soc_init（） snd_soc_util_init（） platform_device_register_simple（soc_dummy_dev） platform_driver_register（） # 失敗 platform_device_unregister（soc_dummy_dev） platform_driver_register（） # 成功 ...snd_soc_exit（） snd_soc_util_exit（） # soc_dummy_dev將第二次取消註冊 要修復它，請處理錯誤並在 util_init（） 失敗時停止 snd_soc_init（）。當 util_init（） 或 driver_register（） 失敗時，也要清理 debugfs。
    (CVE-2022-49842)

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

CentOS Linux 8.4 主機已安裝的套件會受到 TuxCare CENTOS8.4：CLSA-2025：1749568993 公告中提及的多個弱點影響。

  - 已解決 Linux 核心中的下列弱點：cifs: potential buffer overflow in handling symlinks Smatch printed a warning: arch/x86/crypto/poly1305_glue.c:198 poly1305_update_arch() error: __memcpy() 'dctx->buf' too small (16 vs u32max) It's caused because Smatch marks 'link_len' as untrusted since it comes from sscanf(). Add a check to ensure that 'link_len' is not larger than the size of the 'link_str' buffer. (CVE-2022-49058)

  - 已解決 Linux 核心中的下列弱點：mac80211: fix potential double free on mesh join While commit 6a01afcf8468 (mac80211: mesh: Free ie data when leaving mesh) fixed a memory leak on mesh leave / teardown it introduced a potential memory corruption caused by a double free when rejoining the mesh: ieee80211_leave_mesh() -> kfree(sdata->u.mesh.ie); ... ieee80211_join_mesh() -> copy_mesh_setup() -> old_ie = ifmsh->ie; -> kfree(old_ie); This double free / kernel panics can be reproduced by using wpa_supplicant with an encrypted mesh (if set up without encryption via iw then ifmsh->ie is always NULL, which avoids this issue). And then calling: $ iw dev mesh0 mesh leave $ iw dev mesh0 mesh join my-mesh Note that typically these commands are not used / working when using wpa_supplicant. And it seems that wpa_supplicant or wpa_cli are going through a NETDEV_DOWN/NETDEV_UP cycle between a mesh leave and mesh join where the NETDEV_UP resets the mesh.ie to NULL via a memcpy of default_mesh_setup in cfg80211_netdev_notifier_call, which then avoids the memory corruption, too. The issue was first observed in an application which was not using wpa_supplicant but Senf instead, which implements its own calls to nl80211. Fixing the issue by removing the kfree()'ing of the mesh IE in the mesh join function and leaving it solely up to the mesh leave to free the mesh IE. (CVE-2022-49290)

  - 已解決 Linux 核心中的下列弱點：tracing: Fix potential double free in create_var_ref() In create_var_ref(), init_var_ref() is called to initialize the fields of variable ref_field, which is allocated in the previous function call to create_hist_field(). Function init_var_ref() allocates the corresponding fields such as ref_field->system, but frees these fields when the function encounters an error. The caller later calls destroy_hist_field() to conduct error handling, which frees the fields and the variable itself. This results in double free of the fields which are already freed in the previous function. Fix this by storing NULL to the corresponding fields when they are freed in init_var_ref(). (CVE-2022-49410)

  - 已解決 Linux 核心中的下列弱點：wifi: mac80211: fix use-after-free in chanctx code In ieee80211_vif_use_reserved_context(), when we have an old context and the new context's replace_state is set to IEEE80211_CHANCTX_REPLACE_NONE, we free the old context in ieee80211_vif_use_reserved_reassign(). Therefore, we cannot check the old_ctx anymore, so we should set it to NULL after this point. However, since the new_ctx replace state is clearly not IEEE80211_CHANCTX_REPLACES_OTHER, we're not going to do anything else in this function and can just return to avoid accessing the freed old_ctx. (CVE-2022-49416)

  - 已解決 Linux 核心中的下列弱點：media: pvrusb2: fix array-index-out-of-bounds in pvr2_i2c_core_init Syzbot reported that -1 is used as array index. The problem was in missing validation check. hdw->unit_number is initialized with -1 and then if init table walk fails this value remains unchanged. Since code blindly uses this member for array indexing adding sanity check is the easiest fix for that. hdw->workpoll initialization moved upper to prevent warning in __flush_work.
    (CVE-2022-49478)

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

遠端主機上安裝的核心版本早於 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 並未測試這些問題，而是僅依據應用程式自我報告的版本號碼作出判斷。

ID	名稱	產品	系列	已發布	已更新	嚴重性
353232	CentOS Linux 7 [TuxCare] 安全性更新：bpftool / kernel / kernel-debug / kernel-debug-devel / kernel-devel / etc 多個漏洞（CENTOS7：CLSA-2026：1782148320）	Nessus	CentOS Local Security Checks	2026/9/30	2026/9/30	high
168676	Amazon Linux 2：核心 (ALAS-2022-1903)	Nessus	Amazon Linux Local Security Checks	2022/12/13	2026/2/24	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
244135	Linux Distros 未修補弱點：CVE-2022-49842	Nessus	Misc.	2025/8/6	2026/9/30	high
362017	CentOS Linux 8.4 [TuxCare] 安全性更新：bpftool / kernel-core / kernel-debug / kernel-debug-core / etc 多個弱點（CENTOS8.4：CLSA-2025：1749568993）	Nessus	CentOS Local Security Checks	2026/10/1	2026/10/1	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

偵測

搜尋 Plugin

high

high

high

high

high

high