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

遠端 Debian 11 主機已安裝受到多個弱點影響的套件如 dla-4475 公告中所提及。

    -------------------------------------------------- ----------------------- Debian LTS 公告 DLA-4475-1 debian-lts@lists.debian.org https://www.debian.org/lts/security/Ben Hutchings 2026 年 2 月 10 日 https://wiki.debian.org/LTS-------------------------------------------------------------------------

    套件：linux 版本：5.10.249-1 CVE ID：CVE-2022-48744 CVE-2022-49168 CVE-2022-49465 CVE-2022-49711 CVE-2022-49743 CVE-2023-52975 CVE-2023-54207 CVE-2023-54321 CVE-2024-36903 CVE-2024-36927 CVE-2025-22022 CVE-2025-22121 CVE-2025-37830 CVE-2025-38022 CVE-2025-38119 CVE-2025-38556 CVE-2025-38591 CVE-2025-39702 CVE-2025-40110 CVE-2025-40215 CVE-2025-68211 CVE-2025-68255 CVE-2025-68257 CVE-2025-68258 CVE-2025-68261 CVE-2025-68264 CVE-2025-68266 CVE-2025-68282 CVE-2025-68325 CVE-2025-68332 CVE-2025-68336 CVE-2025-68337 CVE-2025-68344 CVE-2025-68346 CVE-2025-68349 CVE-2025-68354 CVE-2025-68362 CVE-2025-68364 CVE-2025-68366 CVE-2025-68367 CVE-2025-68372 CVE-2025-68724 CVE-2025-68725 CVE-2025-68733 CVE-2025-68740 CVE-2025-68757 CVE-2025-68758 CVE-2025-68759 CVE-2025-68764 CVE-2025-68767 CVE-2025-68769 CVE-2025-68771 CVE-2025-68773 CVE-2025-68774 CVE-2025-68776 CVE-2025-68777 CVE-2025-68782 CVE-2025-68783 CVE-2025-68785 CVE-2025-68787 CVE-2025-68788 CVE-2025-68795 CVE-2025-68796 CVE-2025-68797 CVE-2025-68799 CVE-2025-68800 CVE-2025-68801 CVE-2025-68803 CVE-2025-68804 CVE-2025-68808 CVE-2025-68813 CVE-2025-68815 CVE-2025-68816 CVE-2025-68818 CVE-2025-68819 CVE-2025-68820 CVE-2025-71064 CVE-2025-71066 CVE-2025-71069 CVE-2025-71075 CVE-2025-71077 CVE-2025-71079 CVE-2025-71084 CVE-2025-71085 CVE-2025-71086 CVE-2025-71087 CVE-2025-71091 CVE-2025-71093 CVE-2025-71096 CVE-2025-71097 CVE-2025-71098 CVE-2025-71102 CVE-2025-71104 CVE-2025-71105 CVE-2025-71108 CVE-2025-71111 CVE-2025-71112 CVE-2025-71113 CVE-2025-71114 CVE-2025-71116 CVE-2025-71118 CVE-2025-71120 CVE-2025-71123 CVE-2025-71125 CVE-2025-71127 CVE-2025-71131 CVE-2025-71136 CVE-2025-71137 CVE-2025-71154 CVE-2025-71162 CVE-2025-71182 CVE-2025-71185 CVE-2025-71186 CVE-2025-71190 CVE-2025-71191 CVE-2025-71194 CVE-2025-71196 CVE-2025-71197 CVE-2025-71199 CVE-2026-22976 CVE-2026-22977 CVE-2026-22978 CVE-2026-22980 CVE-2026-22990 CVE-2026-22991 CVE-2026-22997 CVE-2026-22998 CVE-2026-22999 CVE-2026-23001 CVE-2026-23003 CVE-2026-23011 CVE-2026-23020 CVE-2026-23021 CVE-2026-23033 CVE-2026-23038 CVE-2026-23047 CVE-2026-23049 CVE-2026-23056 CVE-2026-23058 CVE-2026-23060 CVE-2026-23061 CVE-2026-23063 CVE-2026-23064 CVE-2026-23071 CVE-2026-23073 CVE-2026-23074 CVE-2026-23075 CVE-2026-23076 CVE-2026-23080 CVE-2026-23083 CVE-2026-23084 CVE-2026-23085 CVE-2026-23087 CVE-2026-23089 CVE-2026-23090 CVE-2026-23091 CVE-2026-23095 CVE-2026-23096 CVE-2026-23097 CVE-2026-23098 CVE-2026-23101 CVE-2026-23103 CVE-2026-23105 CVE-2026-23108 CVE-2026-23110 Debian 錯誤：1122193 1123750

    在 Linux 核心中發現數個弱點，這些弱點可能會導致特權提升、拒絕服務或資訊洩漏。

    針對 Debian 11 Bullseye，已在 5.10.249-1 版本中修正這些問題。此更新還可修正報告給 Debian 的多個錯誤，
    此外它還包含來自穩定更新 5.10.248 和 5.10.249的更多錯誤修正。

    建議您升級 linux 套件。

    如需有關 linux 安全性狀態的詳細資訊，請參閱其安全追蹤頁面：
    https://security-tracker.debian.org/tracker/linux

    有關 Debian LTS 安全公告、如何將這些更新套用至您的系統以及常見問題的詳細資訊，請參閱：https://wiki.debian.org/LTSAttachment:signature.ascDescription: PGP signature

Tenable 已直接從 Debian 安全公告擷取前置描述區塊。

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

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

  - net/mlx5e：避免欄位溢位 memcpy（） 在準備FORTIFY_SOURCE對 memcpy（）、memmove（） 和 memset（） 執行編譯時和執行階段欄位邊界檢查時，請避免故意跨相鄰欄位寫入。使用靈活的陣列而不是零元素陣列（看起來總是溢位），並將跨欄位 memcpy（） 分成兩半，編譯器可以適當地進行邊界檢查。我們正在做： #define ETH_HLEN 14 #define VLAN_HLEN 4 ... #define MLX5E_XDP_MIN_INLINE （ETH_HLEN + VLAN_HLEN） ...結構mlx5e_tx_wqe *wqe = mlx5_wq_cyc_get_wqe（wq， pi）;...結構 mlx5_wqe_eth_seg *eseg = &wqe->eth;結構mlx5_wqe_data_seg *dseg = wqe->data;...
    memcpy（eseg->inline_hdr.start， xdptxd->data， MLX5E_XDP_MIN_INLINE）;目標是 wqe->eth.inline_hdr.start（編譯器認為其大小為 2 位元組），但複製 18，打算跨 start 寫入（實際上是 2 vlan_tci，2 位元組）。剩餘的 16 個位元組被寫入 wqe->data[0]，涵蓋 byte_count（4 個位元組）、lkey（4 個位元組）和 addr（8 個位元組）。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 */ /* 大小：32，快取行：1，成員：3 */ /* 最後一個快取行：32 位元組 */ };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 */ } 插入;/* 12 4 */
    __be32拖車;/* 12 4 */ };/* 12 4 */ /* 大小：16，快取行：1，成員：9 */ /* 最後快取行：16 位元組 */ };struct mlx5_wqe_data_seg { __be32 byte_count; /* 0 4 */ __be32 lkey; /* 4 4 */ __be64 addr; /* 8 8 */ /* size： 16， 快取列： 1， members： 3 */ /* 最後快取列： 16 位元組 */ };因此，拆分 memcpy（），以便編譯器可以推理緩衝區大小。Pahole 未顯示結構mlx5e_tx_wqe或結構mlx5e_umr_wqe的大小或構件偏移變更。objdump -d 沒有顯示有意義的物件程式碼變更 （即
    只有源行號引起的差異和優化）。(CVE-2022-48744)

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

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

  - 已解決 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 核心中的下列弱點：Bluetooth: L2CAP: Fix user-after-free This uses l2cap_chan_hold_unless_zero() after calling __l2cap_get_chan_blah() to prevent the following trace: Bluetooth: l2cap_core.c:static void l2cap_chan_destroy(struct kref *kref) Bluetooth: chan 0000000023c4974d Bluetooth: parent 00000000ae861c08 ================================================================== BUG: KASAN: use-after-free in
    __mutex_waiter_is_first kernel/locking/mutex.c:191 [inline] BUG: KASAN: use-after-free in
    __mutex_lock_common kernel/locking/mutex.c:671 [inline] BUG: KASAN: use-after-free in
    __mutex_lock+0x278/0x400 kernel/locking/mutex.c:729 Read of size 8 at addr ffff888006a49b08 by task kworker/u3:2/389 (CVE-2022-50386)

  - 已解決 Linux 核心中的下列弱點：scsi: libsas: Fix use-after-free bug in smp_execute_task_sg() When executing SMP task failed, the smp_execute_task_sg() calls del_timer() to delete slow_task->timer. However, if the timer handler sas_task_internal_timedout() is running, the del_timer() in smp_execute_task_sg() will not stop it and a UAF will happen. The process is shown below:
    (thread 1) | (thread 2) smp_execute_task_sg() | sas_task_internal_timedout() ... | del_timer() | ... | ...
    sas_free_task(task) | kfree(task->slow_task) //FREE| | task->slow_task->... //USE Fix by calling del_timer_sync() in smp_execute_task_sg(), which makes sure the timer handler have finished before the task->slow_task is deallocated. (CVE-2022-50422)

  - 已解決 Linux 核心中的下列弱點：kernfs: fix use-after-free in
    __kernfs_remove Syzkaller managed to trigger concurrent calls to kernfs_remove_by_name_ns() for the same file resulting in a KASAN detected use-after-free. The race occurs when the root node is freed during kernfs_drain(). To prevent this acquire an additional reference for the root of the tree that is removed before calling __kernfs_remove(). Found by syzkaller with the following reproducer (slab_nomerge is required): syz_mount_image$ext4(0x0, &(0x7f0000000100)='./file0\x00', 0x100000, 0x0, 0x0, 0x0, 0x0) r0 = openat(0xffffffffffffff9c, &(0x7f0000000080)='/proc/self/exe\x00', 0x0, 0x0) close(r0) pipe2(&(0x7f0000000140)={0xffffffffffffffff, <r1=>0xffffffffffffffff}, 0x800) mount$9p_fd(0x0, &(0x7f0000000040)='./file0\x00', &(0x7f00000000c0), 0x408, &(0x7f0000000280)={'trans=fd,', {'rfdno', 0x3d, r0}, 0x2c, {'wfdno', 0x3d, r1}, 0x2c, {[{@cache_loose}, {@mmap}, {@loose}, {@loose}, {@mmap}], [{@mask={'mask', 0x3d, '^MAY_EXEC'}}, {@fsmagic={'fsmagic', 0x3d, 0x10001}}, {@dont_hash}]}}) Sample report: ================================================================== BUG: KASAN: use-after-free in kernfs_type include/linux/kernfs.h:335 [inline] BUG: KASAN: use-after-free in kernfs_leftmost_descendant fs/kernfs/dir.c:1261 [inline] BUG: KASAN: use-after-free in __kernfs_remove.part.0+0x843/0x960 fs/kernfs/dir.c:1369 Read of size 2 at addr ffff8880088807f0 by task syz-executor.2/857 CPU: 0 PID: 857 Comm: syz-executor.2 Not tainted 6.0.0-rc3-00363-g7726d4c3e60b #5 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x6e/0x91 lib/dump_stack.c:106 print_address_description mm/kasan/report.c:317 [inline] print_report.cold+0x5e/0x5e5 mm/kasan/report.c:433 kasan_report+0xa3/0x130 mm/kasan/report.c:495 kernfs_type include/linux/kernfs.h:335 [inline] kernfs_leftmost_descendant fs/kernfs/dir.c:1261 [inline]
    __kernfs_remove.part.0+0x843/0x960 fs/kernfs/dir.c:1369 __kernfs_remove fs/kernfs/dir.c:1356 [inline] kernfs_remove_by_name_ns+0x108/0x190 fs/kernfs/dir.c:1589 sysfs_slab_add+0x133/0x1e0 mm/slub.c:5943
    __kmem_cache_create+0x3e0/0x550 mm/slub.c:4899 create_cache mm/slab_common.c:229 [inline] kmem_cache_create_usercopy+0x167/0x2a0 mm/slab_common.c:335 p9_client_create+0xd4d/0x1190 net/9p/client.c:993 v9fs_session_init+0x1e6/0x13c0 fs/9p/v9fs.c:408 v9fs_mount+0xb9/0xbd0 fs/9p/vfs_super.c:126 legacy_get_tree+0xf1/0x200 fs/fs_context.c:610 vfs_get_tree+0x85/0x2e0 fs/super.c:1530 do_new_mount fs/namespace.c:3040 [inline] path_mount+0x675/0x1d00 fs/namespace.c:3370 do_mount fs/namespace.c:3383 [inline] __do_sys_mount fs/namespace.c:3591 [inline] __se_sys_mount fs/namespace.c:3568 [inline] __x64_sys_mount+0x282/0x300 fs/namespace.c:3568 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x38/0x90 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP: 0033:0x7f725f983aed Code: 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f725f0f7028 EFLAGS: 00000246 ORIG_RAX: 00000000000000a5 RAX: ffffffffffffffda RBX: 00007f725faa3f80 RCX: 00007f725f983aed RDX:
    00000000200000c0 RSI: 0000000020000040 RDI: 0000000000000000 RBP: 00007f725f9f419c R08: 0000000020000280 R09: 0000000000000000 R10: 0000000000000408 R11: 0000000000000246 R12: 0000000000000000 R13:
    0000000000000006 R14: 00007f725faa3f80 R15: 00007f725f0d7000 </TASK> Allocated by task 855:
    kasan_save_stack+0x1e/0x40 mm/kasan/common.c:38 kasan_set_track mm/kasan/common.c:45 [inline] set_alloc_info mm/kasan/common.c:437 [inline] __kasan_slab_alloc+0x66/0x80 mm/kasan/common.c:470 kasan_slab_alloc include/linux/kasan.h:224 [inline] slab_post_alloc_hook mm/slab.h:7 ---truncated--- (CVE-2022-50432)

請注意，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
298680	Debian dla-4475ata-modules-5.10.0-35-armmp-di - 安全性更新	Nessus	Debian Local Security Checks	2026/2/11	2026/3/23	high
225653	Linux Distros 未修補弱點：CVE-2022-48744	Nessus	Misc.	2025/3/5	2026/9/30	high
361020	CentOS Linux 8.4 [TuxCare] 安全性更新：bpftool / kernel / kernel-core / kernel-cross-headers / etc多個弱點（CENTOS8.4：CLSA-2026：1773048865）	Nessus	CentOS Local Security Checks	2026/10/1	2026/10/1	high

偵測

搜尋 Plugin

high

high

high

high