CentOS Linux 8.5 主机上存在安装的程序包，该程序包受到 TuxCare CENTOS8.5：CLSA-2026：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-4664 公告中提及的多个漏洞的影响。

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

    程序包：linux 版本：5.10.259-1 CVE ID：CVE-2021-47188 CVE-2021-47211 CVE-2022-48703 CVE-2022-49135 CVE-2022-49158 CVE-2022-49183 CVE-2022-49822 CVE-2022-50073 CVE-2022-50472 CVE-2022-50493 CVE-2022-50552 CVE-2023-53133 CVE-2023-53421 CVE-2023-53596 CVE-2023-54129 CVE-2024-43902 CVE-2025-10263 CVE-2025-21863 CVE-2025-22026 CVE-2025-22107 CVE-2025-38129 CVE-2025-38250 CVE-2025-38584 CVE-2025-38710 CVE-2025-39929 CVE-2025-40164 CVE-2025-68340 CVE-2026-23066 CVE-2026-23099 CVE-2026-23442 CVE-2026-23444 CVE-2026-31407 CVE-2026-31449 CVE-2026-31489 CVE-2026-31532 CVE-2026-31576 CVE-2026-31577 CVE-2026-31578 CVE-2026-31580 CVE-2026-31581 CVE-2026-31583 CVE-2026-31585 CVE-2026-31586 CVE-2026-31588 CVE-2026-31590 CVE-2026-31596 CVE-2026-31597 CVE-2026-31598 CVE-2026-31599 CVE-2026-31602 CVE-2026-31603 CVE-2026-31605 CVE-2026-31607 CVE-2026-31615 CVE-2026-31616 CVE-2026-31617 CVE-2026-31618 CVE-2026-31619 CVE-2026-31622 CVE-2026-31623 CVE-2026-31624 CVE-2026-31625 CVE-2026-31626 CVE-2026-31627 CVE-2026-31629 CVE-2026-31630 CVE-2026-31634 CVE-2026-31637 CVE-2026-31642 CVE-2026-31656 CVE-2026-31657 CVE-2026-31664 CVE-2026-31673 CVE-2026-31676 CVE-2026-31681 CVE-2026-31684 CVE-2026-31685 CVE-2026-31686 CVE-2026-31696 CVE-2026-31697 CVE-2026-31698 CVE-2026-31699 CVE-2026-31700 CVE-2026-31701 CVE-2026-31708 CVE-2026-31715 CVE-2026-43052 CVE-2026-43058 CVE-2026-43075 CVE-2026-43076 CVE-2026-43080 CVE-2026-43085 CVE-2026-43089 CVE-2026-43093 CVE-2026-43103 CVE-2026-43104 CVE-2026-43105 CVE-2026-43110 CVE-2026-43111 CVE-2026-43113 CVE-2026-43114 CVE-2026-43117 CVE-2026-43281 CVE-2026-43350 CVE-2026-43492 CVE-2026-43493 CVE-2026-43494 CVE-2026-43496 CVE-2026-43497 CVE-2026-43501 CVE-2026-43502 CVE-2026-45834 CVE-2026-45835 CVE-2026-45836 CVE-2026-45838 CVE-2026-45840 CVE-2026-45841 CVE-2026-45842 CVE-2026-45843 CVE-2026-45844 CVE-2026-45846 CVE-2026-45850 CVE-2026-45986 CVE-2026-45987 CVE-2026-45991 CVE-2026-45994 CVE-2026-46002 CVE-2026-46003 CVE-2026-46004 CVE-2026-46006 CVE-2026-46018 CVE-2026-46019 CVE-2026-46021 CVE-2026-46022 CVE-2026-46023 CVE-2026-46026 CVE-2026-46027 CVE-2026-46033 CVE-2026-46038 CVE-2026-46040 CVE-2026-46043 CVE-2026-46044 CVE-2026-46046 CVE-2026-46047 CVE-2026-46049 CVE-2026-46051 CVE-2026-46052 CVE-2026-46053 CVE-2026-46056 CVE-2026-46064 CVE-2026-46069 CVE-2026-46070 CVE-2026-46077 CVE-2026-46078 CVE-2026-46080 CVE-2026-46086 CVE-2026-46088 CVE-2026-46090 CVE-2026-46091 CVE-2026-46098 CVE-2026-46101 CVE-2026-46102 CVE-2026-46103 CVE-2026-46107 CVE-2026-46108 CVE-2026-46109 CVE-2026-46120 CVE-2026-46122 CVE-2026-46124 CVE-2026-46127 CVE-2026-46128 CVE-2026-46132 CVE-2026-46133 CVE-2026-46137 CVE-2026-46146 CVE-2026-46149 CVE-2026-46150 CVE-2026-46151 CVE-2026-46159 CVE-2026-46160 CVE-2026-46161 CVE-2026-46163 CVE-2026-46167 CVE-2026-46169 CVE-2026-46172 CVE-2026-46177 CVE-2026-46178 CVE-2026-46180 CVE-2026-46184 CVE-2026-46187 CVE-2026-46189 CVE-2026-46191 CVE-2026-46196 CVE-2026-46198 CVE-2026-46205 CVE-2026-46206 CVE-2026-46208 CVE-2026-46209 CVE-2026-46212 CVE-2026-46214 CVE-2026-46220 CVE-2026-46227 CVE-2026-46231 CVE-2026-46233 CVE-2026-46234 CVE-2026-46236 CVE-2026-46238 CVE-2026-46275 CVE-2026-46276 CVE-2026-46285 CVE-2026-46291 CVE-2026-46292 CVE-2026-46294 CVE-2026-46299 CVE-2026-46301 CVE-2026-46303 CVE-2026-46304 CVE-2026-46307 CVE-2026-46319 CVE-2026-46320 CVE-2026-46321 CVE-2026-46322 CVE-2026-52909 CVE-2026-52910 CVE-2026-52912 CVE-2026-52913 CVE-2026-52914 CVE-2026-52915 CVE-2026-52916 CVE-2026-52917 CVE-2026-52918 CVE-2026-52919 CVE-2026-52920 CVE-2026-52921 CVE-2026-52922 CVE-2026-52923 CVE-2026-52924 CVE-2026-52925 CVE-2026-52926 CVE-2026-52927 CVE-2026-52929 CVE-2026-52930 CVE-2026-52931 CVE-2026-52934 CVE-2026-52935 CVE-2026-52939 CVE-2026-52943 CVE-2026-52946 CVE-2026-52947 CVE-2026-52948 CVE-2026-52954 CVE-2026-52955 CVE-2026-52957 CVE-2026-52958 CVE-2026-52962 CVE-2026-52963 CVE-2026-52970 CVE-2026-52972 CVE-2026-52982 CVE-2026-52984 CVE-2026-52985 CVE-2026-52986 CVE-2026-52992 CVE-2026-52993 CVE-2026-52995 CVE-2026-52998 CVE-2026-52999 CVE-2026-53001 CVE-2026-53002 CVE-2026-53003 CVE-2026-53004 CVE-2026-53006 CVE-2026-53011 CVE-2026-53012 CVE-2026-53016 CVE-2026-53021 CVE-2026-53037 CVE-2026-53039 CVE-2026-53040 CVE-2026-53041 CVE-2026-53043 CVE-2026-53045 CVE-2026-53047 CVE-2026-53050 CVE-2026-53059 CVE-2026-53060 CVE-2026-53061 CVE-2026-53062 CVE-2026-53064 CVE-2026-53065 CVE-2026-53068 CVE-2026-53071 CVE-2026-53072 CVE-2026-53073 CVE-2026-53074 CVE-2026-53075 CVE-2026-53077 CVE-2026-53080 CVE-2026-53082 CVE-2026-53088 CVE-2026-53093 CVE-2026-53112 CVE-2026-53128 CVE-2026-53130 CVE-2026-53133 CVE-2026-53134 CVE-2026-53135 CVE-2026-53137 CVE-2026-53146 CVE-2026-53148 CVE-2026-53149 CVE-2026-53150 CVE-2026-53161 CVE-2026-53168 CVE-2026-53176 CVE-2026-53181 CVE-2026-53186 CVE-2026-53189 CVE-2026-53194 CVE-2026-53195 CVE-2026-53196 CVE-2026-53199 CVE-2026-53208 CVE-2026-53212 CVE-2026-53217 CVE-2026-53218 CVE-2026-53219 CVE-2026-53221 CVE-2026-53223 CVE-2026-53225 CVE-2026-53227 CVE-2026-53228 CVE-2026-53238 CVE-2026-53239 CVE-2026-53242 CVE-2026-53245 CVE-2026-53249 CVE-2026-53255 CVE-2026-53256 CVE-2026-53263 CVE-2026-53264 CVE-2026-53266 CVE-2026-53268 CVE-2026-53269 CVE-2026-53270 CVE-2026-53273 CVE-2026-53287 CVE-2026-53294 CVE-2026-53295 CVE-2026-53296 CVE-2026-53304 CVE-2026-53309 CVE-2026-53320 CVE-2026-53337 CVE-2026-53339 CVE-2026-53352 CVE-2026-53354 CVE-2026-53355 CVE-2026-53356 CVE-2026-53357 Debian 缺陷：1130365 1119093

    在 Linux 内核中发现多个可能导致权限升级、拒绝服务或信息泄漏的漏洞。

    对于 Debian 11 bullseye，已在 5.10.259-1 版本中修复这些问题。此版本还包括来自稳定更新5.10.2585.10.259和 的更多缺陷补丁。

    建议您升级 linux 程序包。

    如需了解 linux 的详细安全状态，请参阅其安全跟踪页面：
    https://security-tracker.debian.org/tracker/linux

    有关 Debian LTS 安全公告、如何将这些更新应用到系统以及常见问题解答的更多信息，请访问以下网址：https://wiki.debian.org/LTSAttachment:signature.ascDescription: PGP signature

Tenable 已直接从 Debian 安全公告中提取上述描述块。

请注意，Nessus 尚未测试这些问题，而是只依据应用程序自我报告的版本号进行判断。

CentOS Linux 8.4 主机上存在安装的程序包，该程序包受到 TuxCare CENTOS8.4：CLSA-2026：2026：1777614651 1 公告中提及的多个漏洞的影响。

  - 已修复 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 内核中的下列漏洞：RDMA/srpt: Fix a use-after-free Change the LIO port members inside struct srpt_port from regular members into pointers. Allocate the LIO port data structures from inside srpt_make_tport() and free these from inside srpt_make_tport(). Keep struct srpt_device as long as either an RDMA port or a LIO target port is associated with it. This patch decouples the lifetime of struct srpt_port (controlled by the RDMA core) and struct srpt_port_id (controlled by LIO). This patch fixes the following KASAN complaint: BUG: KASAN: use-after-free in srpt_enable_tpg+0x31/0x70 [ib_srpt] Read of size 8 at addr ffff888141cc34b8 by task check/5093 Call Trace:
    <TASK> show_stack+0x4e/0x53 dump_stack_lvl+0x51/0x66 print_address_description.constprop.0.cold+0xea/0x41e print_report.cold+0x90/0x205 kasan_report+0xb9/0xf0 __asan_load8+0x69/0x90 srpt_enable_tpg+0x31/0x70 [ib_srpt] target_fabric_tpg_base_enable_store+0xe2/0x140 [target_core_mod] configfs_write_iter+0x18b/0x210 new_sync_write+0x1f2/0x2f0 vfs_write+0x3e3/0x540 ksys_write+0xbb/0x140 __x64_sys_write+0x42/0x50 do_syscall_64+0x34/0x80 entry_SYSCALL_64_after_hwframe+0x46/0xb0 </TASK> (CVE-2022-50129)

  - 已修复 Linux 内核中的下列漏洞：drm/amdkfd: Fix double release compute pasid If kfd_process_device_init_vm returns failure after vm is converted to compute vm and vm->pasid set to compute pasid, KFD will not take pdd->drm_file reference. As a result, drm close file handler maybe called to release the compute pasid before KFD process destroy worker to release the same pasid and set vm->pasid to zero, this generates below WARNING backtrace and NULL pointer access. Add helper amdgpu_amdkfd_gpuvm_set_vm_pasid and call it at the last step of kfd_process_device_init_vm, to ensure vm pasid is the original pasid if acquiring vm failed or is the compute pasid with pdd->drm_file reference taken to avoid double release same pasid. amdgpu: Failed to create process VM object ida_free called for id=32770 which is not allocated. WARNING: CPU: 57 PID: 72542 at ../lib/idr.c:522 ida_free+0x96/0x140 RIP:
    0010:ida_free+0x96/0x140 Call Trace: amdgpu_pasid_free_delayed+0xe1/0x2a0 [amdgpu] amdgpu_driver_postclose_kms+0x2d8/0x340 [amdgpu] drm_file_free.part.13+0x216/0x270 [drm] drm_close_helper.isra.14+0x60/0x70 [drm] drm_release+0x6e/0xf0 [drm] __fput+0xcc/0x280 ____fput+0xe/0x20 task_work_run+0x96/0xc0 do_exit+0x3d0/0xc10 BUG: kernel NULL pointer dereference, address:
    0000000000000000 RIP: 0010:ida_free+0x76/0x140 Call Trace: amdgpu_pasid_free_delayed+0xe1/0x2a0 [amdgpu] amdgpu_driver_postclose_kms+0x2d8/0x340 [amdgpu] drm_file_free.part.13+0x216/0x270 [drm] drm_close_helper.isra.14+0x60/0x70 [drm] drm_release+0x6e/0xf0 [drm] __fput+0xcc/0x280 ____fput+0xe/0x20 task_work_run+0x96/0xc0 do_exit+0x3d0/0xc10 (CVE-2022-50303)

  - 已修复 Linux 内核中的下列漏洞：ACPI: processor: idle: Check acpi_fetch_acpi_dev() return value The return value of acpi_fetch_acpi_dev() could be NULL, which would cause a NULL pointer dereference to occur in acpi_device_hid(). [ rjw: Subject and changelog edits, added empty line after if () ] (CVE-2022-50327)

  - 已修复 Linux 内核中的下列漏洞：NFSD: Protect against send buffer overflow in NFSv2 READ Since before the git era, NFSD has conserved the number of pages held by each nfsd thread by combining the RPC receive and send buffers into a single array of pages. This works because there are no cases where an operation needs a large RPC Call message and a large RPC Reply at the same time. Once an RPC Call has been received, svc_process() updates svc_rqst::rq_res to describe the part of rq_pages that can be used for constructing the Reply. This means that the send buffer (rq_res) shrinks when the received RPC record containing the RPC Call is large. A client can force this shrinkage on TCP by sending a correctly- formed RPC Call header contained in an RPC record that is excessively large. The full maximum payload size cannot be constructed in that case. (CVE-2022-50410)

请注意，Nessus 尚未测试这些问题，而是只依据应用程序自我报告的版本号进行判断。

Linux/Unix 主机中安装的一个或多个程序包受到一个漏洞影响，而供应商没有提供补丁程序。

  - drivers：base：取消设备注册时释放 devm 资源 在当前代码中，仅当设备总线且经过探测时才调用 devres_release_all（）。这会导致使用无总线或无驱动程序设备时出现问题，如果托管资源持有对设备的引用，则设备可能永远无法释放。例如，这发生在 DRM 框架中。因此，我们应当在 device_del（） 函数中调用 devres_release_all（） 以确保当设备未注册时正确执行设备管理的操作，即使设备既没有总线也没有驱动程序。这实际上与提交 a525a3ddeaca（驱动程序核心：释放 device_release 中的 devres）因内存泄漏问题而恢复的提交 2f8d16a996da（devres：释放 device_del（））的更改相同。此修补程序有效地结合了上述两个提交，以释放 device_del（） 和 device_release（） 上的资源，并获得两全其美的效果。（CVE-2023-53596）

请注意，Nessus 依赖供应商报告的程序包是否存在进行判断。

远程 Ubuntu 20.04 LTS 主机上安装的一个程序包受到 USN-8668-1 公告中提及的多个漏洞影响。

    Maxim Suhanov 发现在某些情况下，Linux 内核中的 NTFS 文件系统实现未正确验证文件名长度，从而导致越界读取。攻击者可利用此问题构建恶意 NTFS 图像，挂载并操作该图像可暴露敏感信息（内核内存）。（CVE-2023-45896）

    发现某些 AMD 处理器在推测执行期间，未能正确清除浮点拆分器单元中的数据。本地攻击者可利用此问题泄露敏感信息。
    (CVE-2025-54505)

    某些 AMD Zen 2 处理器未能正确隔离操作缓存中的共享资源。本地攻击者可能会利用此问题损坏以较高权限级别执行的指令，从而导致权限升级。（CVE-2025-54518）

    在 Linux 内核中发现多个安全问题。攻击者可能利用这些问题入侵系统。此更新修正了以下子系统中的缺陷：

    - ARM32 架构；

    - ARM64 架构；

    - MIPS 架构；

    - PowerPC 架构；

    - S390 架构；

    - x86 架构；

    - 区块层子系统；

    - 加密 API；

    - ACPI 驱动程序；

    - ATM 驱动程序；

    - 驱动程序核心；

    - 电源管理核心；

    - DRBD 分布式复制块设备驱动程序；

    - RNBD 块设备驱动程序；

    - 蓝牙驱动程序；

    - 总线设备；

    - 字符设备驱动程序；

    - TPM 设备驱动程序；

    - 时钟源驱动程序；

    - 数据采集框架和驱动程序；

    - CPU 频率缩放框架；

    - CPU 空闲管理框架；

    - 硬件加密设备驱动程序；

    - DMA 引擎子系统；

    - Arm Firmware Framework for ARMv8-A(FFA)；

    - EFI 核心；

    - GPIO 子系统；

    - GPU 驱动程序；

    - HID 子系统；

    - 硬件监控驱动程序；

    - I2C 子系统；

    - IIO 子系统；

    - IIO ADC 驱动程序；

    - InfiniBand 驱动程序；

    - 输入设备（多种）驱动程序；

    - IOMMU 子系统；

    - Mailbox 框架；

    - 多设备驱动程序；

    - 媒体驱动程序；

    - 联发科 SMI 驱动程序;

    - NVIDIA Tegra 内存控制器驱动程序；

    - 多功能设备驱动程序；

    - IBM Advanced System Management 驱动程序;

    - MMC 子系统；

    - MTD 块设备驱动程序；

    - 网络驱动程序；

    - 以太网绑定驱动程序；

    - Mellanox 网络驱动程序；

    - Microsoft Azure Network Adapter (MANA) 驱动程序；

    - STMicroelectronics 网络驱动程序；

    - MediaTek 网络驱动程序；

    - 近场通信 (NFC) 驱动程序；

    - NTB 驱动程序；

    - NVDIMM (Non-Volatile Memory Device) 驱动程序；

    - NVME 驱动程序；

    - PCI 子系统；

    - Pin 控制器子系统；

    - x86 平台驱动程序；

    - Broadcom BCM2835 power 域驱动程序;

    - 电源驱动程序；

    - RapidIO 驱动程序；

    - 远程处理器子系统；

    - RPMSG 子系统；

    - SCSI 子系统；

    - Freescale SoC 驱动程序；

    - Texas Instruments SoC 驱动程序；

    - SPI 子系统；

    - Greybus lights 分段驱动程序；

    - 媒体分段驱动程序；

    - Realtek RTL8723BS SDIO 驱动程序；

    - SM750 帧缓冲暂存驱动程序;

    - TCM 子系统；

    - TTY 驱动程序；

    - UFS 子系统；

    - Cadence USB3 驱动程序；

    - USB 设备类驱动程序；

    - ULPI总线;

    - USB 核心驱动程序；

    - DesignWare USB2 驱动程序;

    - USB Gadget 驱动程序；

    - USB 主机控制器驱动程序；

    - Mustek MDC800 USB 数码相机驱动程序;

    - USB YUREX 驱动程序;

    - Renesas USBHS 控制器驱动程序；

    - Framebuffer 层；

    - Xen 管理程序驱动程序；

    - 文件系统基础设施；

    - BTRFS 文件系统；

    - Ceph 分布式文件系统；

    - EROFS 文件系统；

    - Ext4 文件系统；

    - F2FS 文件系统；

    - FAT 文件系统；

    - FUSE（Userspace 中的文件系统）；

    - GFS2 文件系统；

    - HFS+ 文件系统；

    - JFS 文件系统；

    - 网络文件系统 (NFS) 服务器后台程序；

    - NILFS2 文件系统；

    - 文件系统通知基础设施；

    - NTFS3 文件系统；

    - OCFS2 文件系统；

    - Proc 文件系统；

    - Pstore 文件系统；

    - Diskquota 系统；

    - SMB 网络文件系统；

    - SquashFS 文件系统；

    - UDF 文件系统；

    - XFS 文件系统；

    - 审计子系统；

    - RAS（可靠性、可用性、可服务性）子系统；

    - 软件节点和设备属性;

    - 内存管理；

    - KVM 子系统；

    - 内存管理；

    - PPP 协议驱动程序和压缩器;

    - Linux 安全模块 (LSM) 框架；

    - 网络流量控制；

    - 蓝牙子系统；

    - MAC80211 子系统；

    - Netfilter；

    - IP 隧道定义；

    - 跟踪基础设施；

    - 用户空间 API (UAPI)；

    - io_uring 子系统；

    - BPF 子系统；

    - 控制群组 (cgroup)；

    - Kernel fork() syscall；

    - Kernel futex 原语；

    - Kernel kexec() syscall；

    - 内核模块支持;

    - 计划程序基础设施；

    - 密码库;

    - KASAN 内存调试框架；

    - 异步传输模式 (ATM) 子系统；

    - B.A.T.M.A.N. 网格协议；

    - 以太网桥接；

    - CAIF 协议；

    - CAN 网络层；

    - Ceph Core 库；

    - Networking 核心；

    - Distributed Switch 架构；

    - IPv4 联网；

    - IPv6 联网；

    - XFRM 子系统；

    - L2TP 协议；

    - 管理组件传输协议 (MCTP)；

    - 多路径 TCP；

    - NCSI（网络控制器边带接口）驱动程序；

    - NFC 子系统；

    - Open vSwitch；

    - Phonet 协议；

    - 高通IPC路由器（QRTR）;

    - RDS 协议；

    - RF 交换子系统；

    - Rose 网络层；

    - RxRPC 会话套接字；

    - SCTP 协议；

    - SMC 套接字；

    - 流解析器;

    - Sun RPC 协议；

    - TIPC 协议；

    - TLS 协议；

    - Unix 域套接字；

    - VMware vSockets 驱动程序；

    - 无线网络；

    - X.25 network layer;

    - eXpress 数据路径；

    - AppArmor 安全模块；

    - 简化了强制访问控制内核框架；

    - ALSA 框架；

    - FireWire 声音驱动程序；

    - HD-audio 驱动程序；

    - AudioScience HPI 驱动程序；

    - Creative Sound Blaster X-Fi 驱动程序；

    - AMD SoC Alsa 驱动程序；

    - SoC 音频核心驱动程序；

    - STI ASoC 驱动程序;

    - USB音响设备;（CVE-2022-49803 ， ， ， CVE-2022-50073， CVE-2022-50116CVE-2025-38659CVE-2024-56719CVE-2024-56727CVE-2024-41079CVE-2024-46715CVE-2024-36922CVE-2024-47809CVE-2024-46770CVE-2024-50012CVE-2024-53221CVE-2024-56557CVE-2024-56584CVE-2024-56657CVE-2024-36898CVE-2025-21739CVE-2025-21712CVE-2025-21863CVE-2025-22107CVE-2025-23141CVE-2025-37786CVE-2025-38006CVE-2024-35865CVE-2025-38192CVE-2025-38105CVE-2025-38250CVE-2025-38562CVE-2025-38626CVE-2025-38710CVE-2025-39748CVE-2024-27389CVE-2025-40005CVE-2025-39764CVE-2025-71150CVE-2025-68358CVE-2025-71161CVE-2025-68307CVE-2025-68256CVE-2025-68239CVE-2025-71221CVE-2025-68206CVE-2025-40323CVE-2025-40103CVE-2025-71232CVE-2025-40016CVE-2023-53629CVE-2025-71233CVE-2025-71238CVE-2025-71237CVE-2025-71239CVE-2025-71236CVE-2025-71265CVE-2025-71266CVE-2022-50552CVE-2023-52737CVE-2025-71267CVE-2023-52682CVE-2023-53545CVE-2023-53596CVE-2025-71235CVE-2022-49961、 、 、 CVE-2026-23289CVE-2026-23204CVE-2026-23169CVE-2026-23220CVE-2026-23221CVE-2026-23222CVE-2026-23227CVE-2026-23228CVE-2026-23157CVE-2026-23234CVE-2026-23229CVE-2026-23235CVE-2026-23236CVE-2026-23237CVE-2026-23238CVE-2026-23241CVE-2026-23141CVE-2026-23243CVE-2026-23242CVE-2026-23253CVE-2026-23266CVE-2026-23270CVE-2026-23277CVE-2026-23279CVE-2026-23113CVE-2026-23286CVE-2026-23281CVE-2026-23290CVE-2026-23291CVE-2026-23293CVE-2026-23324CVE-2026-23318CVE-2026-23312CVE-2026-23335CVE-2026-23307CVE-2026-23304CVE-2026-23303CVE-2026-23336CVE-2026-23300CVE-2026-23298CVE-2026-23296CVE-2026-23339CVE-2026-23100CVE-2026-23031CVE-2026-23368CVE-2026-23359CVE-2026-23367CVE-2026-23352CVE-2026-23356CVE-2026-23357CVE-2026-23365CVE-2026-23370CVE-2026-23066CVE-2026-23362CVE-2025-71304CVE-2026-23340CVE-2025-71292CVE-2025-71287CVE-2025-71274、 、 、 CVE-2026-31399CVE-2026-23398CVE-2026-23399CVE-2026-23401CVE-2026-23397CVE-2026-23434CVE-2026-23420CVE-2026-23438CVE-2026-23439CVE-2026-23442CVE-2026-23444CVE-2026-23446CVE-2026-23396CVE-2026-23454CVE-2026-23452CVE-2026-23456CVE-2026-23457CVE-2026-23458CVE-2026-23460CVE-2026-23462CVE-2026-23395CVE-2026-23474CVE-2026-23463CVE-2026-31393CVE-2026-31396CVE-2026-31400CVE-2026-31421CVE-2026-31417CVE-2026-31416CVE-2026-31422CVE-2026-31415CVE-2026-31411CVE-2026-31409CVE-2026-31423CVE-2026-31408CVE-2026-31407CVE-2026-31405CVE-2026-31424CVE-2026-23392CVE-2026-23388CVE-2026-31454CVE-2026-31446CVE-2026-31452CVE-2026-31427CVE-2026-31428CVE-2026-31433CVE-2026-31450CVE-2026-31455CVE-2026-23391CVE-2026-31447CVE-2026-23382CVE-2026-31425CVE-2026-23381CVE-2026-23379CVE-2026-23372、 、 、 CVE-2026-31551CVE-2026-31494CVE-2026-31495CVE-2026-31497CVE-2026-31489CVE-2026-31507CVE-2026-31498CVE-2026-31508CVE-2026-31509CVE-2026-31510CVE-2026-31512CVE-2026-31515CVE-2026-31485CVE-2026-31521CVE-2026-31518CVE-2026-31522CVE-2026-31523CVE-2026-31524CVE-2026-31532CVE-2026-31540CVE-2026-31483CVE-2026-31546CVE-2026-31545CVE-2026-31549CVE-2026-31550CVE-2026-31552CVE-2026-31583CVE-2026-31581CVE-2026-31580CVE-2026-31585CVE-2026-31578CVE-2026-31577CVE-2026-31576CVE-2026-31586CVE-2026-31570CVE-2026-31565CVE-2026-31555CVE-2026-31588CVE-2026-31480CVE-2026-31473CVE-2026-31605CVE-2026-31598CVE-2026-31603CVE-2026-31594CVE-2026-31596CVE-2026-31597CVE-2026-31602CVE-2026-31615CVE-2026-31476CVE-2026-31599CVE-2026-31469CVE-2026-31590CVE-2026-31467CVE-2026-31466CVE-2026-31464、 、 、 CVE-2026-31680CVE-2026-31628CVE-2026-31629CVE-2026-31630CVE-2026-31627CVE-2026-31642CVE-2026-31634CVE-2026-31651CVE-2026-31656CVE-2026-31658CVE-2026-31660CVE-2026-31661CVE-2026-31626CVE-2026-31664CVE-2026-31662CVE-2026-31665CVE-2026-31667CVE-2026-31670CVE-2026-31671CVE-2026-31672CVE-2026-31625CVE-2026-31674CVE-2026-31673CVE-2026-31676CVE-2026-31679CVE-2026-31681CVE-2026-31698CVE-2026-31697CVE-2026-31696CVE-2026-31699CVE-2026-31695CVE-2026-31694CVE-2026-31687CVE-2026-31701CVE-2026-31686CVE-2026-31684CVE-2026-31683CVE-2026-31716CVE-2026-31624CVE-2026-31622CVE-2026-31749CVE-2026-31737CVE-2026-31748CVE-2026-31721CVE-2026-31726CVE-2026-31728CVE-2026-31747CVE-2026-31751CVE-2026-31623CVE-2026-31738CVE-2026-31619CVE-2026-31720CVE-2026-31618CVE-2026-31617CVE-2026-31616、 、 、 CVE-2026-43051CVE-2026-31773CVE-2026-31778CVE-2026-31780CVE-2026-31770CVE-2026-31788CVE-2026-31781CVE-2026-43014CVE-2026-43015CVE-2026-43020CVE-2026-43024CVE-2026-43026CVE-2026-31763CVE-2026-43028CVE-2026-43027CVE-2026-43030CVE-2026-43032CVE-2026-43035CVE-2026-43040CVE-2026-43041CVE-2026-31762CVE-2026-43046CVE-2026-43043CVE-2026-43047CVE-2026-43050CVE-2026-43052CVE-2026-43069CVE-2026-43068CVE-2026-43066CVE-2026-43074CVE-2026-43065CVE-2026-43062CVE-2026-43061CVE-2026-43075CVE-2026-43060CVE-2026-43058CVE-2026-43054CVE-2026-43076CVE-2026-31761CVE-2026-31758CVE-2026-43104CVE-2026-43093CVE-2026-43103CVE-2026-43080CVE-2026-43085CVE-2026-43089CVE-2026-43099CVE-2026-43105CVE-2026-31759CVE-2026-43098CVE-2026-31756CVE-2026-43079CVE-2026-31755CVE-2026-31754CVE-2026-31752、 、 、 CVE-2026-43190CVE-2026-43135CVE-2026-43136CVE-2026-43139CVE-2026-43134CVE-2026-43141CVE-2026-43140CVE-2026-43145CVE-2026-43147CVE-2026-43148CVE-2026-43149CVE-2026-43152CVE-2026-43133CVE-2026-43158CVE-2026-43156CVE-2026-43159CVE-2026-43163CVE-2026-43168CVE-2026-43171CVE-2026-43180CVE-2026-43132CVE-2026-43183CVE-2026-43182CVE-2026-43184CVE-2026-43187CVE-2026-43194CVE-2026-43211CVE-2026-43209CVE-2026-43207CVE-2026-43218CVE-2026-43206CVE-2026-43205CVE-2026-43203CVE-2026-43223CVE-2026-43202CVE-2026-43200CVE-2026-43196CVE-2026-43225CVE-2026-43130CVE-2026-43123CVE-2026-43242CVE-2026-43232CVE-2026-43241CVE-2026-43227CVE-2026-43230CVE-2026-43231CVE-2026-43236CVE-2026-43246CVE-2026-43124CVE-2026-43233CVE-2026-43113CVE-2026-43226CVE-2026-43112CVE-2026-43111CVE-2026-43110、 、 、 CVE-2026-43333CVE-2026-43273CVE-2026-43275CVE-2026-43277CVE-2026-43270CVE-2026-43281CVE-2026-43279CVE-2026-43283CVE-2026-43287CVE-2026-43289CVE-2026-43291CVE-2026-43295CVE-2026-43269CVE-2026-43302CVE-2026-43296CVE-2026-43312CVE-2026-43313CVE-2026-43314CVE-2026-43315CVE-2026-43316CVE-2026-43268CVE-2026-43327CVE-2026-43324CVE-2026-43328CVE-2026-43329CVE-2026-43334CVE-2026-43370CVE-2026-43365CVE-2026-43363CVE-2026-43373CVE-2026-43357CVE-2026-43343CVE-2026-43342CVE-2026-43380CVE-2026-43340CVE-2026-43339CVE-2026-43336CVE-2026-43381CVE-2026-43266CVE-2026-43262CVE-2026-43427CVE-2026-43411CVE-2026-43426CVE-2026-43386CVE-2026-43387CVE-2026-43405CVE-2026-43425CVE-2026-43428CVE-2026-43264CVE-2026-43420CVE-2026-43261CVE-2026-43382CVE-2026-43257CVE-2026-43255CVE-2026-43251、 、 、 CVE-2026-45843CVE-2026-43458CVE-2026-43459CVE-2026-43466CVE-2026-43453CVE-2026-43472CVE-2026-43469CVE-2026-43473CVE-2026-43475CVE-2026-43476CVE-2026-43480CVE-2026-43484CVE-2026-43452CVE-2026-43497CVE-2026-43496CVE-2026-43502CVE-2026-45834CVE-2026-45835CVE-2026-45836CVE-2026-45838CVE-2026-43451CVE-2026-45840CVE-2026-45839CVE-2026-45841CVE-2026-45842CVE-2026-45844CVE-2026-45864CVE-2026-45862CVE-2026-45860CVE-2026-45866CVE-2026-45857CVE-2026-45856CVE-2026-45852CVE-2026-45867CVE-2026-45848CVE-2026-45847CVE-2026-45846CVE-2026-45868CVE-2026-43450CVE-2026-43445CVE-2026-45890CVE-2026-45875CVE-2026-45885CVE-2026-45870CVE-2026-45871CVE-2026-45873CVE-2026-45883CVE-2026-45891CVE-2026-43449CVE-2026-45879CVE-2026-43439CVE-2026-45869CVE-2026-43432CVE-2026-43430CVE-2026-43429、 、 、 CVE-2026-45994CVE-2026-45935CVE-2026-45936CVE-2026-45941CVE-2026-45924CVE-2026-45948CVE-2026-45946CVE-2026-45954CVE-2026-45956CVE-2026-45958CVE-2026-45960CVE-2026-45964CVE-2026-45920CVE-2026-45968CVE-2026-45965CVE-2026-45969CVE-2026-45970CVE-2026-45974CVE-2026-45978CVE-2026-45983CVE-2026-45919CVE-2026-45985CVE-2026-45984CVE-2026-45986CVE-2026-45987CVE-2026-46002CVE-2026-46024CVE-2026-46023CVE-2026-46022CVE-2026-46027CVE-2026-46019CVE-2026-46018CVE-2026-46015CVE-2026-46033CVE-2026-46009CVE-2026-46006CVE-2026-46004CVE-2026-46037CVE-2026-45916CVE-2026-45912CVE-2026-46062CVE-2026-46049CVE-2026-46053CVE-2026-46044CVE-2026-46046CVE-2026-46047CVE-2026-46051CVE-2026-46064CVE-2026-45915CVE-2026-46050CVE-2026-45911CVE-2026-46040CVE-2026-45904CVE-2026-45902CVE-2026-45899、 、 、 CVE-2026-46174CVE-2026-46107CVE-2026-46108CVE-2026-46112CVE-2026-46102CVE-2026-46122CVE-2026-46120CVE-2026-46123CVE-2026-46124CVE-2026-46127CVE-2026-46128CVE-2026-46132CVE-2026-46101CVE-2026-46137CVE-2026-46133CVE-2026-46146CVE-2026-46149CVE-2026-46150CVE-2026-46151CVE-2026-46161CVE-2026-46099CVE-2026-46167CVE-2026-46163CVE-2026-46168CVE-2026-46172CVE-2026-46177CVE-2026-46206CVE-2026-46205CVE-2026-46198CVE-2026-46209CVE-2026-46197CVE-2026-46189CVE-2026-46187CVE-2026-46212CVE-2026-46186CVE-2026-46184CVE-2026-46178CVE-2026-46214CVE-2026-46098CVE-2026-46082CVE-2026-46238CVE-2026-46231CVE-2026-46236CVE-2026-46220CVE-2026-46227CVE-2026-46230CVE-2026-46234CVE-2026-46249CVE-2026-46088CVE-2026-46233CVE-2026-46080CVE-2026-46219CVE-2026-46077CVE-2026-46072CVE-2026-46070、 、 、 CVE-2026-52958CVE-2026-46301CVE-2026-46303CVE-2026-46304CVE-2026-46294CVE-2026-46319CVE-2026-46307CVE-2026-46328CVE-2026-52911CVE-2026-52912CVE-2026-52914CVE-2026-52915CVE-2026-46285CVE-2026-52919CVE-2026-52916CVE-2026-52920CVE-2026-52921CVE-2026-52922CVE-2026-52925CVE-2026-52926CVE-2026-46275CVE-2026-52954CVE-2026-52931CVE-2026-52955CVE-2026-52957CVE-2026-52962CVE-2026-52993CVE-2026-52992CVE-2026-52986CVE-2026-52995CVE-2026-52985CVE-2026-52984CVE-2026-52982CVE-2026-52998CVE-2026-52970CVE-2026-52969CVE-2026-52963CVE-2026-52999CVE-2026-46274CVE-2026-46270CVE-2026-53021CVE-2026-53006CVE-2026-53016CVE-2026-53002CVE-2026-53003CVE-2026-53004CVE-2026-53012CVE-2026-53022CVE-2026-46273CVE-2026-53011CVE-2026-46267CVE-2026-53001CVE-2026-46259CVE-2026-46253CVE-2026-46250、 、 、 CVE-2026-53128CVE-2026-53049CVE-2026-53050CVE-2026-53059CVE-2026-53048CVE-2026-53061CVE-2026-53060CVE-2026-53062CVE-2026-53064CVE-2026-53065CVE-2026-53068CVE-2026-53069CVE-2026-53047CVE-2026-53072CVE-2026-53071CVE-2026-53073CVE-2026-53074CVE-2026-53075CVE-2026-53077CVE-2026-53082CVE-2026-53046CVE-2026-53093CVE-2026-53088CVE-2026-53096CVE-2026-53112CVE-2026-53130CVE-2026-53320CVE-2026-53309CVE-2026-53306CVE-2026-53369CVE-2026-53304CVE-2026-53296CVE-2026-53295CVE-2026-53379CVE-2026-53294CVE-2026-53291CVE-2026-53287CVE-2026-63860CVE-2026-53045CVE-2026-53041CVE-2026-64055CVE-2026-64034CVE-2026-64047CVE-2026-64018CVE-2026-64032CVE-2026-64033CVE-2026-64046CVE-2026-64056CVE-2026-53043CVE-2026-64039CVE-2026-53040CVE-2026-63865CVE-2026-53039CVE-2026-53037CVE-2026-53023、 、 、 CVE-2026-64185CVE-2026-64096CVE-2026-64102CVE-2026-64103CVE-2026-64164CVE-2026-64155CVE-2026-64153CVE-2026-64165CVE-2026-64135CVE-2026-64133CVE-2026-64125CVE-2026-64166CVE-2026-64115CVE-2026-64114CVE-2026-64113CVE-2026-64168CVE-2026-64089CVE-2026-64087CVE-2026-64221CVE-2026-64179CVE-2026-64220CVE-2026-64174CVE-2026-64177CVE-2026-64178CVE-2026-64219CVE-2026-64587CVE-2026-64088CVE-2026-64218CVE-2026-64086CVE-2026-64173CVE-2026-64085CVE-2026-64084CVE-2026-64083

Tenable 已直接从 Ubuntu 安全公告中提取上述描述块。

请注意，Nessus 尚未测试这些问题，而是只依据应用程序自我报告的版本号进行判断。

AlmaLinux 9.2 主机上存在安装的程序包，该程序包受到 TuxCare ALMALINUX9.2：CLSA-2026：1779375889 1公告中提及的多个漏洞的影响。

  - 已修复 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 尚未测试这些问题，而是只依据应用程序自我报告的版本号进行判断。

如 TuxCare CENTOS7：CLSA-2026：1782148320公告所述，CentOS Linux 7 主机上存在安装的程序包，该漏洞会受到多个漏洞的影响。

  - 已修复 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 尚未测试这些问题，而是只依据应用程序自我报告的版本号进行判断。

因此，该软件受到 ALAS2023-2023-356 公告中提及的多个漏洞影响。

    在 Linux 内核 6.4.2 及之前版本的 USB 子系统中发现了一个问题。drivers/usb/core/sysfs.c 中的 read_descriptors 出现越界和崩溃漏洞。(CVE-2023-37453)

    nftables nf_osf_match_one() 中的越界读取漏洞 (CVE-2023-39189)

    在 Linux 内核的 Netfilter 子系统中发现了一个缺陷。xt_u32 模块未验证 xt_u32 结构中的字段。本地特权攻击者可利用此缺陷，通过以数组边界外的值设置尺寸字段来触发越界读取，从而导致程序崩溃或信息泄露。(CVE-2023-39192)

    在 Linux 内核的 Netfilter 子系统中发现了一个缺陷。sctp_mt_check 未验证 flag_count 字段。本地特权 (CAP_NET_ADMIN) 攻击者可利用此缺陷触发越界读取，从而导致程序崩溃或信息泄露。(CVE-2023-39193)

    Linux 内核中 kmalloc_reserve() 中的整数溢出可能允许本地用户导致系统崩溃，或在某些情况下在内核空间中执行代码。(CVE-2023-42752)

    上游提交对此问题的描述如下：

    如果 ip_set_hash_netportnet 中缺少 IP_SET_HASH_WITH_NET0 宏，在计算数组偏移时可能会使用错误的“CIDR_POS(c)”，造成整数下溢，最终导致 slab 越界访问问题。(CVE-2023-42753)

    在 rsvp_change() 中发现了一个缺陷。根本原因是 slab 越界访问，但由于原始指针的偏移是“unsign int”，完全由用户控制，因此该行为通常为失控指针访问。(CVE-2023-42755)

    在 6.5.3 版本之前 Linux 内核中，发现 IGB 驱动程序中的 drivers/net/ethernet/intel/igb/igb_main.c 存在问题。缓冲区大小可能不足以容纳大于 MTU 的框架。(CVE-2023-45871)

    Linux 内核 net/sched: sch_hfsc（HFSC qdisc 流量控制）组件中存在一个释放后使用漏洞，攻击者可利用此漏洞实现本地特权提升。

    如果包含链接共享曲线（如设有 HFSC_FSC 标志）的类的父类不含链接共享曲线，init_vf() 将在父类上调用 vttree_insert()，但 update_vf() 中会跳过 vttree_remove()。这会留下一个悬摆指针，可能导致释放后使用。

    我们建议升级过去的提交 b3d26c5702c7d6c45456326e56d2ccf3f103e60f。(CVE-2023-4623)

    Linux 内核 net/sched: sch_qfq 组件中存在一个释放后使用漏洞，攻击者可利用此漏洞实现本地特权提升。

    当 plug qdisc 被用作 qfq qdisc 的类时，由于 sch_plug 的 .peek 处理程序不正确，且 agg_dequeue() 中缺少错误检查，发送网络数据包则会触发 qfq_dequeue() 中的释放后使用情形。

    我们建议升级过去的提交 8fc134fee27f2263988ae38920bc03da416b03d8。(CVE-2023-4921)

    在 Linux 内核中，以下漏洞已修复：

    netfilter: nftables: exthdr：修复 4 字节堆栈 OOB 写入

    如果 priv->len 为 4 的倍数，则 dst[len / 4] 可写入经过目标数组，导致堆栈损坏。

    如果 ->len 不是寄存器大小的倍数，则必须使用此构造来清除寄存器的其余部分，以便为其添加与 nft_payload.c 相同的条件。

    该错误已在 4.1 周期中添加，然后会在添加 whentcp/sctp 和 ip 选项支持的情况下被复制/继承。

    Zero Day Initiative 计划报告的错误（ZDI-CAN-21950、ZDI-CAN-21951、ZDI-CAN-21961）。(CVE-2023-52628)

    在 Linux 内核中，以下漏洞已修复：

    USBcore通过不覆盖 hub_port_init() 中的 udev->descriptor 修复争用 (CVE-2023-52886)

    在 Linux 内核中，以下漏洞已修复：

    netfilteripset为 ip_set_hash_netportnet.c 添加缺少的 IP_SET_HASH_WITH_NET0 宏 (CVE-2023-53179)

    在 Linux 内核中，以下漏洞已修复：

    af_unix修复有关 user->unix_inflight 的数据争用。 (CVE-2023-53204)

    在 Linux 内核中，以下漏洞已修复：

    KVMnSVM基于 L1 状态而非 L2 状态加载 L1 的 TSC 乘数 (CVE-2023-53208)

    在 Linux 内核中，以下漏洞已修复：

    md/raid5-cache修复 r5l_flush_stripe_to_raid() 的 null-ptr-deref (CVE-2023-53210)

    在 Linux 内核中，以下漏洞已修复：

    drm/msm/mdp5不泄漏某些平面状态CVE-2023-53324

    在 Linux 内核中，以下漏洞已修复：

    pstore/ram检查 init 期间空 przs 的开头 (CVE-2023-53331)

    在 Linux 内核中，以下漏洞已修复：

    lwt修复 BPF xmit ops 的返回值 (CVE-2023-53338)

    在 Linux 内核中，以下漏洞已修复：

    skbuffskb_segment使用 skbuff frags 前调用零复制函数 (CVE-2023-53354)

    在 Linux 内核中，以下漏洞已修复：

    tracing修复 cpu 缓冲区写入与交换之间的争用问题CVE-2023-53368

    在 Linux 内核中，以下漏洞已修复：

    ACPICA将 AML_NO_OPERAND_RESOLVE 标记添加到定时器 (CVE-2023-53395)

    在 Linux 内核中，以下漏洞已修复：

    xsk修复套接字清理期间的 xsk_diag 释放后使用错误 (CVE-2023-53426)

    在 Linux 内核中，以下漏洞已修复：

    x86/MCE始终保存 AMD Zen IF Poison 错误的 CS 寄存器 (CVE-2023-53438)

    在 Linux 内核中，以下漏洞已修复：

    HIDmultitouch修正 hidinput input_dev 名称的 devm 设备引用 (CVE-2023-53454)

    在 Linux 内核中，以下漏洞已修复：

    scsiqla4xxx解析 nlattrs 时添加长度检查 (CVE-2023-53456)

    在 Linux 内核中，以下漏洞已修复：

    hsr修复 fill_frame_info() 中的 uninit-value 访问 (CVE-2023-53462)

    在 Linux 内核中，以下漏洞已修复：

    kobject在 kset_register() 中为 kset->kobj.ktype 添加健全性检查 (CVE-2023-53480)

    在 Linux 内核中，以下漏洞已修复：

    iommu/amd/iommu_v2修复 pasid 取消绑定时的 pasid_state refcount dec hit 0 警告 (CVE-2023-53501)

    在 Linux 内核中，以下漏洞已修复：

    PM / devfreq修复 devfreq_dev_release() 中的泄漏 (CVE-2023-53518)

    在 Linux 内核中，以下漏洞已修复：

    jbd2从检查点删除“jh->b_transaction”之前先对其进行检查 (CVE-2023-53526)

    在 Linux 内核中，以下漏洞已修复：

    null_blk修复轮询请求超时处理 (CVE-2023-53531)

    在 Linux 内核中，以下漏洞已修复：

    drm/i915标记 GuC 虚拟引擎的请求以避免释放后使用 (CVE-2023-53552)

    在 Linux 内核中，以下漏洞已修复：

    bpf拒绝 bpf_sk_assign 中的未哈希套接字 (CVE-2023-53585)

    在 Linux 内核中，以下漏洞已修复：

    driversbase取消注册设备时释放 devm 资源 (CVE-2023-53596)

    在 Linux 内核中，以下漏洞已修复：

    Drivershvvmbus不要取消引用 ACPI 根对象句柄 (CVE-2023-53647)

    在 Linux 内核中，以下漏洞已修复：

    perf trace实际释放 evsel->priv 区域 (CVE-2023-53649)

    在 Linux 内核中，以下漏洞已修复：

    ext4修复 ext4_fname_{setup_filename,prepare_lookup} 中的内存泄漏 (CVE-2023-53662)

    在 Linux 内核中，以下漏洞已修复：

    KVMnSVM对嵌套 TSC 缩放支持进行检查而非断言 (CVE-2023-53663)

    在 Linux 内核中，以下漏洞已修复：

    btrfs如果未能找到内联 backref则输出额外的调试信息 (CVE-2023-53672)

    在 Linux 内核中，以下漏洞已修复：

    scsitargetiscsi修复 lio_target_nacl_info_show() 中的缓冲区溢出 (CVE-2023-53676)

    在 Linux 内核中，以下漏洞已修复：

    NFS修复一个潜在的数据损坏 (CVE-2023-53711)

    在 Linux 内核中，以下漏洞已修复：

    mdraid1修复 raid1_remove_disk() 中潜在的 OOB (CVE-2023-53722)

    在 Linux 内核中，以下漏洞已修复：

    arm64csum修复 IP 校验和代码中负长度的 OoB 访问 (CVE-2023-53726)

    在 Linux 内核中，以下漏洞已修复：

    net/schedfq_pie避免 fq_pie_timer() 中的停止CVE-2023-53727]

    在 Linux 内核中，以下漏洞已修复：

    PCI在 coalescing 之后释放已释放的资源CVE-2023-53743

    在 Linux 内核中，以下漏洞已修复：

    net处理 kmalloc_reserve() 中的整数溢出 (CVE-2023-53752)

    在 Linux 内核中，以下漏洞已修复：

    cryptoapi - 使用 crypto_destroy_instance 中的工作队列 (CVE-2023-53799)

    在 Linux 内核中，以下漏洞已修复：

    cryptolib/mpi - 避免 mpi_cmp_ui() 中的空指针取消引用 (CVE-2023-53817)

    在 Linux 内核中，以下漏洞已修复：

    kcm修复 kcm_sendmsg() 中 SOCK_DGRAM 的错误处理。 (CVE-2023-53825)

    在 Linux 内核中，以下漏洞已修复：

    net在 sk_mc_loop() 中读取一次 sk->sk_family (CVE-2023-53831)

    在 Linux 内核中，以下漏洞已修复：

    bpfsockmap修复锁定更改后的 skb refcnt 争用 (CVE-2023-53836)

    在 Linux 内核中，以下漏洞已修复：

    md/raid5-cache修复 r5l_exit_log() 中的死锁 (CVE-2023-53848)

    在 Linux 内核中，以下漏洞已修复：

    ofoverlay提前调用 of_changeset_init() (CVE-2023-53856)

    在 Linux 内核中，以下漏洞已修复：

    dm不尝试将 IO 置于 RCU 保护之下 (CVE-2023-53860)

    在 Linux 内核中，以下漏洞已修复：

    ext4修正 ext4_mb_good_group 中的 grp 验证 (CVE-2023-53861)

    在 Linux 内核中，以下漏洞已修复：

    netipv4修复 __inet_del_ifa() 中的一个内存泄漏 (CVE-2023-53995)

    在 Linux 内核中，以下漏洞已修复：

    x86/sev使 enc_dec_hypercall() 接受大小而不是 npage (CVE-2023-53996)

    在 Linux 内核中，以下漏洞已修复：

    af_unix修复有关 unix_tot_inflight 的数据争用。 (CVE-2023-54006)

    在 Linux 内核中，以下漏洞已修复：

    audit修复 __audit_inode_child() 中可能的软锁定 (CVE-2023-54045)

    在 Linux 内核中，以下漏洞已修复：

    kcm修复 kcm_sendmsg() 错误路径中的内存泄漏 (CVE-2023-54112)

    在 Linux 内核中，以下漏洞已修复：

    rcu安全转储 vmalloc 内存信息 (CVE-2023-54113)

    在 Linux 内核中，以下漏洞已修复：

    s390/dcssblk修复 list_add 损坏导致的内核崩溃 (CVE-2023-54117)

    在 Linux 内核中，以下漏洞已修复：

    autofs修复 autofs_catatonic_mode 中 waitqueues 的内存泄漏 (CVE-2023-54134)

    在 Linux 内核中，以下漏洞已修复：

    vfio/type1修复 cap_migration 信息泄漏 (CVE-2023-54137)

    在 Linux 内核中，以下漏洞已修复：

    scsitargetcore修复 target_cmd_counter 泄漏 (CVE-2023-54154)

    在 Linux 内核中，以下漏洞已修复：

    of unittest修复 of_unittest_find_node_by_name() 中的空指针取消引用 (CVE-2023-54178)

    在 Linux 内核中，以下漏洞已修复：

    bpf修复验证 allow_ptr_leaks 中的问题 (CVE-2023-54181)

    在 Linux 内核中，以下漏洞已修复：

    btrfs修复 lockdep 崩溃以及运行延迟的项目失败后可能发生的死锁 (CVE-2023-54224)

    在 Linux 内核中，以下漏洞已修复：

    ambabus修复 refcount 泄漏 (CVE-2023-54230)

    在 Linux 内核中，以下漏洞已修复：

    btrfs设置在 relocate_one_page 中的 read_folio 之后映射的页面范围 (CVE-2023-54253)

    在 Linux 内核中，以下漏洞已修复：

    btrfs在 ino 查找 ioctl 期间在 inode 查找之前释放路径CVE-2023-54281

    在 Linux 内核中，以下漏洞已修复：

    KVMSVM从源 VM 获取源 vCPU 以进行 SEV-ES 主机内迁移 (CVE-2023-54296)

    在 Linux 内核中，以下漏洞已修复：

    usbtypecbus验证合作伙伴在 typec_altmode_attention 中存在 (CVE-2023-54299)

    在用于加密算法 scatterwalk 功能的 Linux 内核 API 中发现了空指针取消引用缺陷。当用户使用特定套接字配置构造恶意数据包时，就会出现此问题，这可能允许本地用户崩溃系统或提升其在系统上的权限。(CVE-2023-6176)

Tenable 已直接从测试产品的安全公告中提取上述描述块。

请注意，Nessus 尚未测试这些问题，而是只依据应用程序自我报告的版本号进行判断。

ID	名称	产品	系列	发布时间	最近更新时间	严重程度
352370	CentOS Linux 8.5 [TuxCare] 安全更新：bpftool / kernel / kernel-core / kernel-cross-headers / 等多个漏洞（CENTOS8.5：CLSA-2026：1773047921）	Nessus	CentOS Local Security Checks	2026/9/30	2026/9/30	high
325018	Debian dla-4664：ata-modules-5.10.0-43-armmp-di - 安全更新	Nessus	Debian Local Security Checks	2026/7/3	2026/9/18	high
352091	CentOS Linux 8.4 [TuxCare] 安全更新：bpftool / kernel / kernel-core / kernel-cross-headers / 等多个漏洞（CENTOS8.4：CLSA-2026：1777614651）	Nessus	CentOS Local Security Checks	2026/9/30	2026/10/1	high
269432	Linux Distros 未修补的漏洞：CVE-2023-53596	Nessus	Misc.	2025/10/8	2026/9/21	high
340682	Ubuntu 20.04 LTS：Linux 内核 (GCP) 漏洞 (USN-8668-1)	Nessus	Ubuntu Local Security Checks	2026/8/26	2026/9/24	high
353122	AlmaLinux 9.2 [TuxCare] 安全更新：bpftool / kernel / kernel-abi-stablelists / kernel-core / 等多个漏洞（ALMALINUX9.2：CLSA-2026：1779375889）	Nessus	Alma Linux Local Security Checks	2026/9/30	2026/10/1	high
353232	CentOS Linux 7 [TuxCare] 安全更新：bpftool / kernel / kernel-debug / kernel-debug-devel / kernel-devel / 等多个漏洞（CENTOS7：CLSA-2026：1782148320）	Nessus	CentOS Local Security Checks	2026/9/30	2026/9/30	high
182458	Amazon Linux 2023：bpftool、kernel、kernel-devel (ALAS2023-2023-356)	Nessus	Amazon Linux Local Security Checks	2023/10/3	2026/2/12	high

检测

插件搜索

high

high

high

high

high

high

high

high