CentOS Linux 8.5 主機已安裝的套件會受到 TuxCare CENTOS8.5：CLSA-2026：1773047921 公告中提及的多個弱點影響。

  - 已解決 Linux 核心中的下列弱點：asix: fix uninit-value in asix_mdio_read() asix_read_cmd() may read less than sizeof(smsr) bytes and in this case smsr will be uninitialized. Fail log: BUG: KMSAN: uninit-value in asix_check_host_enable drivers/net/usb/asix_common.c:82 [inline] BUG: KMSAN: uninit-value in asix_check_host_enable drivers/net/usb/asix_common.c:82 [inline] drivers/net/usb/asix_common.c:497 BUG: KMSAN: uninit-value in asix_mdio_read+0x3c1/0xb00 drivers/net/usb/asix_common.c:497 drivers/net/usb/asix_common.c:497 asix_check_host_enable drivers/net/usb/asix_common.c:82 [inline] asix_check_host_enable drivers/net/usb/asix_common.c:82 [inline] drivers/net/usb/asix_common.c:497 asix_mdio_read+0x3c1/0xb00 drivers/net/usb/asix_common.c:497 drivers/net/usb/asix_common.c:497 (CVE-2021-47101)

  - 已解決 Linux 核心中的下列弱點：net/mlx5e: Avoid field-overflowing memcpy() In preparation for FORTIFY_SOURCE performing compile-time and run-time field bounds checking for memcpy(), memmove(), and memset(), avoid intentionally writing across neighboring fields. Use flexible arrays instead of zero-element arrays (which look like they are always overflowing) and split the cross-field memcpy() into two halves that can be appropriately bounds-checked by the compiler. We were doing:
    #define ETH_HLEN 14 #define VLAN_HLEN 4 ... #define MLX5E_XDP_MIN_INLINE (ETH_HLEN + VLAN_HLEN) ... struct mlx5e_tx_wqe *wqe = mlx5_wq_cyc_get_wqe(wq, pi); ... struct mlx5_wqe_eth_seg *eseg = &wqe->eth; struct mlx5_wqe_data_seg *dseg = wqe->data; ... memcpy(eseg->inline_hdr.start, xdptxd->data, MLX5E_XDP_MIN_INLINE); target is wqe->eth.inline_hdr.start (which the compiler sees as being 2 bytes in size), but copying 18, intending to write across start (really vlan_tci, 2 bytes). The remaining 16 bytes get written into wqe->data[0], covering byte_count (4 bytes), lkey (4 bytes), and addr (8 bytes). struct mlx5e_tx_wqe { struct mlx5_wqe_ctrl_seg ctrl; /* 0 16 */ struct mlx5_wqe_eth_seg eth; /* 16 16 */ struct mlx5_wqe_data_seg data[]; /* 32 0 */ /* size: 32, cachelines: 1, members: 3 */ /* last cacheline: 32 bytes
    */ }; struct mlx5_wqe_eth_seg { u8 swp_outer_l4_offset; /* 0 1 */ u8 swp_outer_l3_offset; /* 1 1 */ u8 swp_inner_l4_offset; /* 2 1 */ u8 swp_inner_l3_offset; /* 3 1 */ u8 cs_flags; /* 4 1 */ u8 swp_flags; /* 5 1 */ __be16 mss; /* 6 2 */ __be32 flow_table_metadata; /* 8 4 */ union { struct { __be16 sz; /* 12 2 */ u8 start[2]; /* 14 2 */ } inline_hdr; /* 12 4 */ struct { __be16 type; /* 12 2 */ __be16 vlan_tci; /* 14 2 */} insert; /* 12 4 */ __be32 trailer; /* 12 4 */ }; /* 12 4 */ /* size: 16, cachelines: 1, members: 9 */ /* last cacheline: 16 bytes */ }; struct mlx5_wqe_data_seg { __be32 byte_count; /* 0 4 */ __be32 lkey; /* 4 4
    */ __be64 addr; /* 8 8 */ /* size: 16, cachelines: 1, members: 3 */ /* last cacheline: 16 bytes */ }; So, split the memcpy() so the compiler can reason about the buffer sizes. pahole shows no size nor member offset changes to struct mlx5e_tx_wqe nor struct mlx5e_umr_wqe. objdump -d shows no meaningful object code changes (i.e. only source line number induced differences and optimizations). (CVE-2022-48744)

  - 已解決 Linux 核心中的下列弱點：NFSD: Fix the behavior of READ near OFFSET_MAX Dan Aloni reports: > Due to commit 8cfb9015280d (NFS: Always provide aligned buffers to > the RPC read layers) on the client, a read of 0xfff is aligned up > to server rsize of 0x1000. > > As a result, in a test where the server has a file of size > 0x7fffffffffffffff, and the client tries to read from the offset > 0x7ffffffffffff000, the read causes loff_t overflow in the server > and it returns an NFS code of EINVAL to the client. The client as > a result indefinitely retries the request. The Linux NFS client does not handle NFS?ERR_INVAL, even though all NFS specifications permit servers to return that status code for a READ. Instead of NFS?ERR_INVAL, have out-of-range READ requests succeed and return a short result. Set the EOF flag in the result to prevent the client from retrying the READ request. This behavior appears to be consistent with Solaris NFS servers. Note that NFSv3 and NFSv4 use u64 offset values on the wire. These must be converted to loff_t internally before use -- an implicit type cast is not adequate for this purpose. Otherwise VFS checks against sb->s_maxbytes do not work properly.
    (CVE-2022-48827)

  - 已解決 Linux 核心中的下列弱點：virtio_net: fix xdp_rxq_info bug after suspend/resume The following sequence currently causes a driver bug warning when using virtio_net: # ip link set eth0 up # echo mem > /sys/power/state (or e.g. # rtcwake -s 10 -m mem) <resume> # ip link set eth0 down Missing register, driver bug WARNING: CPU: 0 PID: 375 at net/core/xdp.c:138 xdp_rxq_info_unreg+0x58/0x60 Call trace: xdp_rxq_info_unreg+0x58/0x60 virtnet_close+0x58/0xac
    __dev_close_many+0xac/0x140 __dev_change_flags+0xd8/0x210 dev_change_flags+0x24/0x64 do_setlink+0x230/0xdd0 ... This happens because virtnet_freeze() frees the receive_queue completely (including struct xdp_rxq_info) but does not call xdp_rxq_info_unreg(). Similarly, virtnet_restore() sets up the receive_queue again but does not call xdp_rxq_info_reg(). Actually, parts of virtnet_freeze_down() and virtnet_restore_up() are almost identical to virtnet_close() and virtnet_open(): only the calls to xdp_rxq_info_(un)reg() are missing. This means that we can fix this easily and avoid such problems in the future by just calling virtnet_close()/open() from the freeze/restore handlers. Aside from adding the missing xdp_rxq_info calls the only difference is that the refill work is only cancelled if netif_running(). However, this should not make any functional difference since the refill work should only be active if the network interface is actually up. (CVE-2022-49687)

  - 已解決 Linux 核心中的下列弱點：ceph: avoid putting the realm twice when decoding snaps fails When decoding the snaps fails it maybe leaving the 'first_realm' and 'realm' pointing to the same snaprealm memory. And then it'll put it twice and could cause random use-after-free, BUG_ON, etc issues. (CVE-2022-49770)

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

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

  在 4.7.7 版之前的 Linux 核心中，fs/aio.c 的 aio_mount 函式不會正確限制執行存取權，這會讓本機使用者更容易透過 io_setup 系統呼叫，繞過預定的 SELinux W ^ X 原則限制，進而取得權限。(CVE-2016-10044)

  - 已解決 Linux 核心中的下列弱點：x86/kvm: Disable kvmclock on all CPUs on shutdown Currenly, we disable kvmclock from machine_shutdown() hook and this only happens for boot CPU.
    We need to disable it for all CPUs to guard against memory corruption e.g. on restore from hibernate.
    Note, writing '0' to kvmclock MSR doesn't clear memory location, it just prevents hypervisor from updating the location so for the short while after write and while CPU is still alive, the clock remains usable and correct so we don't need to switch to some other clocksource. (CVE-2021-47110)

  - 已解決 Linux 核心中的下列弱點：cifs: fix double free race when mount fails in cifs_get_root() When cifs_get_root() fails during cifs_smb3_do_mount() we call deactivate_locked_super() which eventually will call delayed_free() which will free the context. In this situation we should not proceed to enter the out: section in cifs_smb3_do_mount() and free the same resources a second time. [Thu Feb 10 12:59:06 2022] BUG: KASAN: use-after-free in rcu_cblist_dequeue+0x32/0x60 [Thu Feb 10 12:59:06 2022] Read of size 8 at addr ffff888364f4d110 by task swapper/1/0 [Thu Feb 10 12:59:06 2022] CPU: 1 PID: 0 Comm: swapper/1 Tainted: G OE 5.17.0-rc3+ #4 [Thu Feb 10 12:59:06 2022] Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.0 12/17/2019 [Thu Feb 10 12:59:06 2022] Call Trace: [Thu Feb 10 12:59:06 2022] <IRQ> [Thu Feb 10 12:59:06 2022] dump_stack_lvl+0x5d/0x78 [Thu Feb 10 12:59:06 2022] print_address_description.constprop.0+0x24/0x150 [Thu Feb 10 12:59:06 2022] ? rcu_cblist_dequeue+0x32/0x60 [Thu Feb 10 12:59:06 2022] kasan_report.cold+0x7d/0x117 [Thu Feb 10 12:59:06 2022] ? rcu_cblist_dequeue+0x32/0x60 [Thu Feb 10 12:59:06 2022] __asan_load8+0x86/0xa0 [Thu Feb 10 12:59:06 2022] rcu_cblist_dequeue+0x32/0x60 [Thu Feb 10 12:59:06 2022] rcu_core+0x547/0xca0 [Thu Feb 10 12:59:06 2022] ? call_rcu+0x3c0/0x3c0 [Thu Feb 10 12:59:06 2022] ? __this_cpu_preempt_check+0x13/0x20 [Thu Feb 10 12:59:06 2022] ? lock_is_held_type+0xea/0x140 [Thu Feb 10 12:59:06 2022] rcu_core_si+0xe/0x10 [Thu Feb 10 12:59:06 2022] __do_softirq+0x1d4/0x67b [Thu Feb 10 12:59:06 2022] __irq_exit_rcu+0x100/0x150 [Thu Feb 10 12:59:06 2022] irq_exit_rcu+0xe/0x30 [Thu Feb 10 12:59:06 2022] sysvec_hyperv_stimer0+0x9d/0xc0 ... [Thu Feb 10 12:59:07 2022] Freed by task 58179: [Thu Feb 10 12:59:07 2022] kasan_save_stack+0x26/0x50 [Thu Feb 10 12:59:07 2022] kasan_set_track+0x25/0x30 [Thu Feb 10 12:59:07 2022] kasan_set_free_info+0x24/0x40 [Thu Feb 10 12:59:07 2022] ____kasan_slab_free+0x137/0x170 [Thu Feb 10 12:59:07 2022] __kasan_slab_free+0x12/0x20 [Thu Feb 10 12:59:07 2022] slab_free_freelist_hook+0xb3/0x1d0 [Thu Feb 10 12:59:07 2022] kfree+0xcd/0x520 [Thu Feb 10 12:59:07 2022] cifs_smb3_do_mount+0x149/0xbe0 [cifs] [Thu Feb 10 12:59:07 2022] smb3_get_tree+0x1a0/0x2e0 [cifs] [Thu Feb 10 12:59:07 2022] vfs_get_tree+0x52/0x140 [Thu Feb 10 12:59:07 2022] path_mount+0x635/0x10c0 [Thu Feb 10 12:59:07 2022] __x64_sys_mount+0x1bf/0x210 [Thu Feb 10 12:59:07 2022] do_syscall_64+0x5c/0xc0 [Thu Feb 10 12:59:07 2022] entry_SYSCALL_64_after_hwframe+0x44/0xae [Thu Feb 10 12:59:07 2022] Last potentially related work creation: [Thu Feb 10 12:59:07 2022] kasan_save_stack+0x26/0x50 [Thu Feb 10 12:59:07 2022] __kasan_record_aux_stack+0xb6/0xc0 [Thu Feb 10 12:59:07 2022] kasan_record_aux_stack_noalloc+0xb/0x10 [Thu Feb 10 12:59:07 2022] call_rcu+0x76/0x3c0 [Thu Feb 10 12:59:07 2022] cifs_umount+0xce/0xe0 [cifs] [Thu Feb 10 12:59:07 2022] cifs_kill_sb+0xc8/0xe0 [cifs] [Thu Feb 10 12:59:07 2022] deactivate_locked_super+0x5d/0xd0 [Thu Feb 10 12:59:07 2022] cifs_smb3_do_mount+0xab9/0xbe0 [cifs] [Thu Feb 10 12:59:07 2022] smb3_get_tree+0x1a0/0x2e0 [cifs] [Thu Feb 10 12:59:07 2022] vfs_get_tree+0x52/0x140 [Thu Feb 10 12:59:07 2022] path_mount+0x635/0x10c0 [Thu Feb 10 12:59:07 2022] __x64_sys_mount+0x1bf/0x210 [Thu Feb 10 12:59:07 2022] do_syscall_64+0x5c/0xc0 [Thu Feb 10 12:59:07 2022] entry_SYSCALL_64_after_hwframe+0x44/0xae (CVE-2022-48919)

  - 已解決 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 核心中的下列弱點：scsi: libfc: Fix use after free in fc_exch_abts_resp() fc_exch_release(ep) will decrease the ep's reference count. When the reference count reaches zero, it is freed. But ep is still used in the following code, which will lead to a use after free. Return after the fc_exch_release() call to avoid use after free. (CVE-2022-49114)

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

CentOS Linux 7.9 主機已安裝的套件受到 CIQ ciqsa-2026_0648 公告中提及的多個漏洞影響。

    此公告匯總了 CIQ CentOS 橋接器 7.9中核心 SRPM 的安全性修正。它解決了 3 個 CVE：
    CVE-2022-49770、CVE-2023-6040、CVE-2023-5717。

Tenable 已直接從 CIQ 安全性公告中擷取上述描述區塊。

請注意，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 主機上安裝了一個或多個受到弱點影響的套件，且供應商未提供可用的修補程式。

  - ceph：當解碼快照失敗時，避免將領域放置兩次 解碼快照失敗時，可能會留下指向相同 snaprealm 記憶體的「first_realm」和「realm」。然後它會放置兩次，並可能導致釋放後隨機使用、BUG_ON等問題。（CVE-2022-49770）

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

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

  - 已解決 Linux 核心中的下列弱點：pid: take a reference when initializing `cad_pid` During boot, kernel_init_freeable() initializes `cad_pid` to the init task's struct pid. Later on, we may change `cad_pid` via a sysctl, and when this happens proc_do_cad_pid() will increment the refcount on the new pid via get_pid(), and will decrement the refcount on the old pid via put_pid(). As we never called get_pid() when we initialized `cad_pid`, we decrement a reference we never incremented, can therefore free the init task's struct pid early. As there can be dangling references to the struct pid, we can later encounter a use-after-free (e.g. when delivering signals). This was spotted when fuzzing v5.13-rc3 with Syzkaller, but seems to have been around since the conversion of `cad_pid` to struct pid in commit 9ec52099e4b8 ([PATCH] replace cad_pid by a struct pid) from the pre-KASAN stone age of v2.6.19. Fix this by getting a reference to the init task's struct pid when we assign it to `cad_pid`.
    Full KASAN splat below. ================================================================== BUG: KASAN:
    use-after-free in ns_of_pid include/linux/pid.h:153 [inline] BUG: KASAN: use-after-free in task_active_pid_ns+0xc0/0xc8 kernel/pid.c:509 Read of size 4 at addr ffff23794dda0004 by task syz-executor.0/273 CPU: 1 PID: 273 Comm: syz-executor.0 Not tainted 5.12.0-00001-g9aef892b2d15 #1 Hardware name: linux,dummy-virt (DT) Call trace: ns_of_pid include/linux/pid.h:153 [inline] task_active_pid_ns+0xc0/0xc8 kernel/pid.c:509 do_notify_parent+0x308/0xe60 kernel/signal.c:1950 exit_notify kernel/exit.c:682 [inline] do_exit+0x2334/0x2bd0 kernel/exit.c:845 do_group_exit+0x108/0x2c8 kernel/exit.c:922 get_signal+0x4e4/0x2a88 kernel/signal.c:2781 do_signal arch/arm64/kernel/signal.c:882 [inline] do_notify_resume+0x300/0x970 arch/arm64/kernel/signal.c:936 work_pending+0xc/0x2dc Allocated by task 0: slab_post_alloc_hook+0x50/0x5c0 mm/slab.h:516 slab_alloc_node mm/slub.c:2907 [inline] slab_alloc mm/slub.c:2915 [inline] kmem_cache_alloc+0x1f4/0x4c0 mm/slub.c:2920 alloc_pid+0xdc/0xc00 kernel/pid.c:180 copy_process+0x2794/0x5e18 kernel/fork.c:2129 kernel_clone+0x194/0x13c8 kernel/fork.c:2500 kernel_thread+0xd4/0x110 kernel/fork.c:2552 rest_init+0x44/0x4a0 init/main.c:687 arch_call_rest_init+0x1c/0x28 start_kernel+0x520/0x554 init/main.c:1064 0x0 Freed by task 270:
    slab_free_hook mm/slub.c:1562 [inline] slab_free_freelist_hook+0x98/0x260 mm/slub.c:1600 slab_free mm/slub.c:3161 [inline] kmem_cache_free+0x224/0x8e0 mm/slub.c:3177 put_pid.part.4+0xe0/0x1a8 kernel/pid.c:114 put_pid+0x30/0x48 kernel/pid.c:109 proc_do_cad_pid+0x190/0x1b0 kernel/sysctl.c:1401 proc_sys_call_handler+0x338/0x4b0 fs/proc/proc_sysctl.c:591 proc_sys_write+0x34/0x48 fs/proc/proc_sysctl.c:617 call_write_iter include/linux/fs.h:1977 [inline] new_sync_write+0x3ac/0x510 fs/read_write.c:518 vfs_write fs/read_write.c:605 [inline] vfs_write+0x9c4/0x1018 fs/read_write.c:585 ksys_write+0x124/0x240 fs/read_write.c:658 __do_sys_write fs/read_write.c:670 [inline] __se_sys_write fs/read_write.c:667 [inline] __arm64_sys_write+0x78/0xb0 fs/read_write.c:667 __invoke_syscall arch/arm64/kernel/syscall.c:37 [inline] invoke_syscall arch/arm64/kernel/syscall.c:49 [inline] el0_svc_common.constprop.1+0x16c/0x388 arch/arm64/kernel/syscall.c:129 do_el0_svc+0xf8/0x150 arch/arm64/kernel/syscall.c:168 el0_svc+0x28/0x38 arch/arm64/kernel/entry-common.c:416 el0_sync_handler+0x134/0x180 arch/arm64/kernel/entry-common.c:432 el0_sync+0x154/0x180 arch/arm64/kernel/entry.S:701 The buggy address belongs to the object at ffff23794dda0000 which belongs to the cache pid of size 224 The buggy address is located 4 bytes inside of 224-byte region [ff
    ---truncated--- (CVE-2021-47118)

  - 已解決 Linux 核心中的下列弱點：i2c: i801: Don't generate an interrupt on bus reset Now that the i2c-i801 driver supports interrupts, setting the KILL bit in a attempt to recover from a timed out transaction triggers an interrupt. Unfortunately, the interrupt handler (i801_isr) is not prepared for this situation and will try to process the interrupt as if it was signaling the end of a successful transaction. In the case of a block transaction, this can result in an out-of-range memory access. This condition was reproduced several times by syzbot:
    https://syzkaller.appspot.com/bug?extid=ed71512d469895b5b34e https://syzkaller.appspot.com/bug?extid=8c8dedc0ba9e03f6c79e https://syzkaller.appspot.com/bug?extid=c8ff0b6d6c73d81b610e https://syzkaller.appspot.com/bug?extid=33f6c360821c399d69eb https://syzkaller.appspot.com/bug?extid=be15dc0b1933f04b043a https://syzkaller.appspot.com/bug?extid=b4d3fd1dfd53e90afd79 So disable interrupts while trying to reset the bus. Interrupts will be enabled again for the following transaction. (CVE-2021-47153)

  - 已解決 Linux 核心中的下列弱點：scsi: target: Fix WRITE_SAME No Data Buffer crash In newer version of the SBC specs, we have a NDOB bit that indicates there is no data buffer that gets written out. If this bit is set using commands like sg_write_same --ndob we will crash in target_core_iblock/file's execute_write_same handlers when we go to access the se_cmd->t_data_sg because its NULL. This patch adds a check for the NDOB bit in the common WRITE SAME code because we don't support it. And, it adds a check for zero SG elements in each handler in case the initiator tries to send a normal WRITE SAME with no data buffer. (CVE-2022-21546)

  - 已解決 Linux 核心中的下列弱點：net/mlx5e: IPoIB, Block PKEY interfaces with less rx queues than parent A user is able to configure an arbitrary number of rx queues when creating an interface via netlink. This doesn't work for child PKEY interfaces because the child interface uses the parent receive channels. Although the child shares the parent's receive channels, the number of rx queues is important for the channel_stats array: the parent's rx channel index is used to access the child's channel_stats. So the array has to be at least as large as the parent's rx queue size for the counting to work correctly and to prevent out of bound accesses. This patch checks for the mentioned scenario and returns an error when trying to create the interface. The error is propagated to the user. (CVE-2022-48883)

  - 已解決 Linux 核心中的下列弱點：ath9k_htc: fix potential out of bounds access with invalid rxstatus->rs_keyix The rxstatus->rs_keyix eventually gets passed to test_bit() so we need to ensure that it is within the bitmap. drivers/net/wireless/ath/ath9k/common.c:46 ath9k_cmn_rx_accept() error: passing untrusted data 'rx_stats->rs_keyix' to 'test_bit()' (CVE-2022-49503)

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

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

  - 已解決 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 核心中的下列弱點：net: mdio: fix undefined behavior in bit shift for __mdiobus_register Shifting signed 32-bit value by 31 bits is undefined, so changing significant bit to unsigned. The UBSAN warning calltrace like below: UBSAN: shift-out-of-bounds in drivers/net/phy/mdio_bus.c:586:27 left shift of 1 by 31 places cannot be represented in type 'int' Call Trace: <TASK> dump_stack_lvl+0x7d/0xa5 dump_stack+0x15/0x1b ubsan_epilogue+0xe/0x4e
    __ubsan_handle_shift_out_of_bounds+0x1e7/0x20c __mdiobus_register+0x49d/0x4e0 fixed_mdio_bus_init+0xd8/0x12d do_one_initcall+0x76/0x430 kernel_init_freeable+0x3b3/0x422 kernel_init+0x24/0x1e0 ret_from_fork+0x1f/0x30 </TASK> (CVE-2022-49907)

  - 已解決 Linux 核心中的下列弱點：vt: Clear selection before changing the font When changing the console font with ioctl(KDFONTOP) the new font size can be bigger than the previous font. A previous selection may thus now be outside of the new screen size and thus trigger out-of-bounds accesses to graphics memory if the selection is removed in vc_do_resize(). Prevent such out-of-memory accesses by dropping the selection before the various con_font_set() console handlers are called.
    (CVE-2022-49948)

  - 已解決 Linux 核心中的下列弱點：wifi: iwlwifi: mvm: fix double free on tx path. We see kernel crashes and lockups and KASAN errors related to ax210 firmware crashes. One of the KASAN dumps pointed at the tx path, and it appears there is indeed a way to double-free an skb. If iwl_mvm_tx_skb_sta returns non-zero, then the 'skb' sent into the method will be freed. But, in case where we build TSO skb buffer, the skb may also be freed in error case. So, return 0 in that particular error case and do cleanup manually. BUG: KASAN: use-after-free in __list_del_entry_valid+0x12/0x90 iwlwifi 0000:06:00.0: 0x00000000 | tsf hi Read of size 8 at addr ffff88813cfa4ba0 by task btserver/9650 CPU: 4 PID: 9650 Comm: btserver Tainted: G W 5.19.8+ #5 iwlwifi 0000:06:00.0: 0x00000000 | time gp1 Hardware name: Default string Default string/SKYBAY, BIOS 5.12 02/19/2019 Call Trace: <TASK> dump_stack_lvl+0x55/0x6d print_report.cold.12+0xf2/0x684 iwlwifi 0000:06:00.0: 0x1D0915A8 | time gp2 ?
    __list_del_entry_valid+0x12/0x90 kasan_report+0x8b/0x180 iwlwifi 0000:06:00.0: 0x00000001 | uCode revision type ? __list_del_entry_valid+0x12/0x90 __list_del_entry_valid+0x12/0x90 iwlwifi 0000:06:00.0: 0x00000048 | uCode version major tcp_update_skb_after_send+0x5d/0x170 __tcp_transmit_skb+0xb61/0x15c0 iwlwifi 0000:06:00.0: 0xDAA05125 | uCode version minor ? __tcp_select_window+0x490/0x490 iwlwifi 0000:06:00.0:
    0x00000420 | hw version ? trace_kmalloc_node+0x29/0xd0 ? __kmalloc_node_track_caller+0x12a/0x260 ? memset+0x1f/0x40 ? __build_skb_around+0x125/0x150 ? __alloc_skb+0x1d4/0x220 ? skb_zerocopy_clone+0x55/0x230 iwlwifi 0000:06:00.0: 0x00489002 | board version ? kmalloc_reserve+0x80/0x80 ? rcu_read_lock_bh_held+0x60/0xb0 tcp_write_xmit+0x3f1/0x24d0 iwlwifi 0000:06:00.0: 0x034E001C | hcmd ?
    __check_object_size+0x180/0x350 iwlwifi 0000:06:00.0: 0x24020000 | isr0 tcp_sendmsg_locked+0x8a9/0x1520 iwlwifi 0000:06:00.0: 0x01400000 | isr1 ? tcp_sendpage+0x50/0x50 iwlwifi 0000:06:00.0: 0x48F0000A | isr2 ? lock_release+0xb9/0x400 ? tcp_sendmsg+0x14/0x40 iwlwifi 0000:06:00.0: 0x00C3080C | isr3 ? lock_downgrade+0x390/0x390 ? do_raw_spin_lock+0x114/0x1d0 iwlwifi 0000:06:00.0: 0x00200000 | isr4 ? rwlock_bug.part.2+0x50/0x50 iwlwifi 0000:06:00.0: 0x034A001C | last cmd Id ? rwlock_bug.part.2+0x50/0x50 ? lockdep_hardirqs_on_prepare+0xe/0x200 iwlwifi 0000:06:00.0: 0x0000C2F0 | wait_event ?
    __local_bh_enable_ip+0x87/0xe0 ? inet_send_prepare+0x220/0x220 iwlwifi 0000:06:00.0: 0x000000C4 | l2p_control tcp_sendmsg+0x22/0x40 sock_sendmsg+0x5f/0x70 iwlwifi 0000:06:00.0: 0x00010034 | l2p_duration
    __sys_sendto+0x19d/0x250 iwlwifi 0000:06:00.0: 0x00000007 | l2p_mhvalid ? __ia32_sys_getpeername+0x40/0x40 iwlwifi 0000:06:00.0: 0x00000000 | l2p_addr_match ? rcu_read_lock_held_common+0x12/0x50 ? rcu_read_lock_sched_held+0x5a/0xd0 ? rcu_read_lock_bh_held+0xb0/0xb0 ? rcu_read_lock_sched_held+0x5a/0xd0 ? rcu_read_lock_sched_held+0x5a/0xd0 ? lock_release+0xb9/0x400 ? lock_downgrade+0x390/0x390 ? ktime_get+0x64/0x130 ? ktime_get+0x8d/0x130 ? rcu_read_lock_held_common+0x12/0x50 ? rcu_read_lock_sched_held+0x5a/0xd0 ? rcu_read_lock_held_common+0x12/0x50 ? rcu_read_lock_sched_held+0x5a/0xd0 ? rcu_read_lock_bh_held+0xb0/0xb0 ? rcu_read_lock_bh_held+0xb0/0xb0
    __x64_sys_sendto+0x6f/0x80 do_syscall_64+0x34/0xb0 entry_SYSCALL_64_after_hwframe+0x46/0xb0 RIP:
    0033:0x7f1d126e4531 Code: 00 00 00 00 0f 1f 44 00 00 f3 0f 1e fa 48 8d 05 35 80 0c 00 41 89 ca 8b 00 85 c0 75 1c 45 31 c9 45 31 c0 b8 2c 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 67 c3 66 0f 1f 44 00 00 55 48 83 ec 20 48 89 RSP: 002b:00007ffe21a679d8 EFLAGS: 00000246 ORIG_RAX: 000000000000002c RAX: ffffffffffffffda RBX:
    000000000000ffdc RCX: 00007f1d126e4531 RDX: 0000000000010000 RSI: 000000000374acf0 RDI: 0000000000000014 RBP: 00007ffe21a67ac0 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11:
    0000000000000246 R ---truncated--- (CVE-2022-50248)

  - 已解決 Linux 核心中的下列弱點：mmc: rtsx_usb_sdmmc: fix return value check of mmc_add_host() mmc_add_host() may return error, if we ignore its return value, the memory that allocated in mmc_alloc_host() will be leaked and it will lead a kernel crash because of deleting not added device in the remove path. So fix this by checking the return value and calling mmc_free_host() in the error path, besides, led_classdev_unregister() and pm_runtime_disable() also need be called.
    (CVE-2022-50347)

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

ID	名稱	產品	系列	已發布	已更新	嚴重性
352370	CentOS Linux 8.5 [TuxCare] 安全性更新：bpftool / kernel / kernel-core / kernel-cross-headers / etc 多個弱點（CENTOS8.5：CLSA-2026：1773047921）	Nessus	CentOS Local Security Checks	2026/9/30	2026/9/30	high
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
353092	CentOS Linux 7 [TuxCare] 安全性更新：bpftool / kernel / kernel-debug / kernel-debug-devel / kernel-devel / etc 多個弱點（CENTOS7：CLSA-2025：1757967705）	Nessus	CentOS Local Security Checks	2026/9/30	2026/10/1	high
354804	CentOS Linux 7.9 [CIQ] 安全性更新： bpftool / bpftool-debuginfo / kernel / kernel-abi-whitelists / etc多個漏洞（ciqsa-2026_0648）	Nessus	CentOS Local Security Checks	2026/10/1	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
283191	MiracleLinux 7kernel-3.10.0-1160.119.1.0.14.el7.AXS7 (AXSA:2025-10933:76)	Nessus	Miracle Linux Local Security Checks	2026/1/13	2026/2/13	high
250153	Linux Distros 未修補弱點：CVE-2022-49770	Nessus	Misc.	2025/8/15	2026/9/30	high
361173	CentOS Linux 8.4 [TuxCare] 安全性更新：bpftool / kernel / kernel-core / kernel-cross-headers / etc 多個弱點（CENTOS8.4：CLSA-2026：1771078945）	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
353159	AlmaLinux 9.2 [TuxCare] 安全性更新：bpftool / kernel / kernel-abi-stablelists / kernel-core / etc 多個弱點（ALMALINUX9.2：CLSA-2026：1777616064）	Nessus	Alma Linux Local Security Checks	2026/9/30	2026/10/1	high

偵測

搜尋 Plugin

high

high

high

high

high

high

high

high

high

high