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

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

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

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

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

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

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

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

    ------------------------------------------------------------------------- Debian LTS 公告 DLA-4664-1 debian-lts@lists.debian.org https://www.debian.org/lts/security/Ben Hutchings 2026 年 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.258 和 5.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.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 8.4 主機安裝的套件會受到 TuxCare CENTOS8.4：CLSA-2026：1777614651 公告中所述多個弱點影響。

  - 已解決 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（），以確保在裝置取消註冊時正確執行裝置管理的動作，即使它既沒有匯流排也沒有驅動程式。這實際上與提交 2f8d16a996da （devres： release resources on device_del（）） 相同，後者因記憶體洩漏問題而被提交 a525a3ddeaca （驅動程式核心：device_release中的釋放 devres） 還原。此修補程式有效地結合了上述兩個提交，以釋放 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 裝置驅動程式；

    - Clocksource 驅動程式；

    - 資料擷取架構和驅動程式；

    - CPU 頻率縮放架構;

    - CPU 閒置管理架構；

    - 硬體加密裝置驅動程式；

    - DMA 引擎子系統;

    - 適用於 ARMv8-A(FFA) 的 Arm 韌體架構；

    - EFI 核心；

    - GPIO 子系統；

    - GPU 驅動程式；

    - HID 子系統 ;

    - 硬體監控驅動程式 ;

    - I2C 子系統；

    - IIO 子系統；

    - IIO ADC 驅動程式；

    - InfiniBand 驅動程式；

    - 輸入裝置 (其他) 驅動程式 ;

    - IOMMU 子系統;

    - 信箱架構；

    - 多個裝置驅動程式；

    - 媒體驅動程式；

    - 聯發科SMI驅動程式;

    - NVIDIA Tegra 記憶體控制器驅動程式;

    - 多功能裝置驅動程式；

    - IBM Advanced System Management 驅動程式;

    - MMC 子系統；

    - MTD 區塊裝置驅動程式；

    - 網路驅動程式；

    - 乙太網路綁定驅動程式;

    - Mellanox 網路驅動程式；

    - Microsoft Azure 網路介面卡 (MANA) 驅動程式 ;

    - STMicroelectronics 網路驅動程式；

    - MediaTek 網路驅動程式；

    - 近距離無線通訊 (NFC) 驅動程式 ;

    - NTB 驅動程式；

    - NVDIMM (非易失性記憶體裝置) 驅動程式；

    - NVME 驅動程式；

    - PCI (支付卡產業) 子系統;

    - 針腳控制器子系統;

    - x86 平台驅動程式；

    - Broadcom BCM2835 電源域驅動程式;

    - 電源驅動程式；

    - RapidIO 驅動程式;

    - Remote Processor 子系統;

    - RPMSG 子系統；

    - SCSI 子系統；

    - Freescale SoC 驅動程式；

    - Texas Instruments SoC  驅動程式；

    - SPI 子系統；

    - Greybus lights staging 驅動程式；

    - 媒體演示驅動程式；

    - 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 Hypervisor 驅動程式 ;

    - 檔案系統基礎架構 ;

    - BTRFS 檔案系統 ;

    - Ceph 分散式檔案系統；

    - EROFS 檔案系統；

    - Ext4 檔案系統；

    - F2FS 檔案系統；

    - FAT 檔案系統；

    - FUSE (使用者空間中的檔案系統)；

    - 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);

    - 核心 fork() 系統呼叫；

    - 核心 futex 基元；

    - 核心 kexec() 系統呼叫；

    - 核心模組支援;

    - 排程器基礎架構；

    - 密碼庫;

    - KASAN 記憶體除錯架構;

    - 非同步傳輸模式 (ATM) 子系統；

    - B.A.T.M.A.N. 網狀通訊協定；

    - 乙太網路橋接器；

    - CAIF 通訊協定；

    - CAN 網路層；

    - Ceph Core 程式庫；

    - 網路核心；

    - 分散式交換架構;

    - IPv4 網路;

    - IPv6 網路；

    - XFRM 子系統；

    - L2TP 通訊協定；

    - 管理元件傳輸通訊協定 (MCTP)；

    - 多重路徑 TCP;

    - NCSI (Network Controller Sideband Interface) 驅動程式;

    - 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 音訊驅動程式；

    - 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-23397CVE-2026-23401CVE-2026-23399CVE-2026-23420CVE-2026-23434CVE-2026-23438CVE-2026-23439CVE-2026-23442CVE-2026-23396CVE-2026-23446CVE-2026-23444CVE-2026-23452CVE-2026-23454CVE-2026-23456CVE-2026-23457CVE-2026-23458CVE-2026-23395CVE-2026-23462CVE-2026-23460CVE-2026-23463CVE-2026-23474CVE-2026-31393CVE-2026-31396CVE-2026-31417CVE-2026-31416CVE-2026-31421CVE-2026-31415CVE-2026-31411CVE-2026-31409CVE-2026-31422CVE-2026-31408CVE-2026-31407CVE-2026-31405CVE-2026-31423CVE-2026-31400CVE-2026-23392CVE-2026-23391CVE-2026-23388CVE-2026-31454CVE-2026-31428CVE-2026-31433CVE-2026-31446CVE-2026-31427CVE-2026-31450CVE-2026-31455CVE-2026-31447CVE-2026-31424CVE-2026-31425CVE-2026-31452CVE-2026-23382CVE-2026-23381CVE-2026-23379CVE-2026-23372、 、 、 、 CVE-2026-31551CVE-2026-31494CVE-2026-31489CVE-2026-31497CVE-2026-31495CVE-2026-31498CVE-2026-31507CVE-2026-31508CVE-2026-31509CVE-2026-31510CVE-2026-31485CVE-2026-31515CVE-2026-31512CVE-2026-31518CVE-2026-31521CVE-2026-31522CVE-2026-31523CVE-2026-31524CVE-2026-31483CVE-2026-31540CVE-2026-31532CVE-2026-31545CVE-2026-31546CVE-2026-31549CVE-2026-31550CVE-2026-31581CVE-2026-31580CVE-2026-31583CVE-2026-31578CVE-2026-31577CVE-2026-31576CVE-2026-31585CVE-2026-31570CVE-2026-31565CVE-2026-31555CVE-2026-31586CVE-2026-31552CVE-2026-31480CVE-2026-31476CVE-2026-31473CVE-2026-31605CVE-2026-31596CVE-2026-31597CVE-2026-31598CVE-2026-31594CVE-2026-31602CVE-2026-31615CVE-2026-31599CVE-2026-31588CVE-2026-31590CVE-2026-31603CVE-2026-31469CVE-2026-31467CVE-2026-31466CVE-2026-31464、 、 、 、 CVE-2026-31680CVE-2026-31628CVE-2026-31627CVE-2026-31630CVE-2026-31629CVE-2026-31634CVE-2026-31642CVE-2026-31651CVE-2026-31656CVE-2026-31658CVE-2026-31626CVE-2026-31661CVE-2026-31660CVE-2026-31662CVE-2026-31664CVE-2026-31665CVE-2026-31667CVE-2026-31670CVE-2026-31625CVE-2026-31672CVE-2026-31671CVE-2026-31673CVE-2026-31674CVE-2026-31676CVE-2026-31679CVE-2026-31697CVE-2026-31696CVE-2026-31698CVE-2026-31695CVE-2026-31694CVE-2026-31687CVE-2026-31699CVE-2026-31686CVE-2026-31684CVE-2026-31683CVE-2026-31701CVE-2026-31681CVE-2026-31624CVE-2026-31623CVE-2026-31622CVE-2026-31749CVE-2026-31726CVE-2026-31728CVE-2026-31737CVE-2026-31721CVE-2026-31747CVE-2026-31751CVE-2026-31738CVE-2026-31716CVE-2026-31720CVE-2026-31748CVE-2026-31619CVE-2026-31618CVE-2026-31617CVE-2026-31616、 、 、 、 CVE-2026-43051CVE-2026-31773CVE-2026-31770CVE-2026-31780CVE-2026-31778CVE-2026-31781CVE-2026-31788CVE-2026-43014CVE-2026-43015CVE-2026-43020CVE-2026-31763CVE-2026-43026CVE-2026-43024CVE-2026-43027CVE-2026-43028CVE-2026-43030CVE-2026-43032CVE-2026-43035CVE-2026-31762CVE-2026-43041CVE-2026-43040CVE-2026-43043CVE-2026-43046CVE-2026-43047CVE-2026-43050CVE-2026-43068CVE-2026-43066CVE-2026-43069CVE-2026-43065CVE-2026-43062CVE-2026-43061CVE-2026-43074CVE-2026-43060CVE-2026-43058CVE-2026-43054CVE-2026-43075CVE-2026-43052CVE-2026-31761CVE-2026-31759CVE-2026-31758CVE-2026-43104CVE-2026-43085CVE-2026-43089CVE-2026-43093CVE-2026-43080CVE-2026-43099CVE-2026-43105CVE-2026-43098CVE-2026-43076CVE-2026-43079CVE-2026-43103CVE-2026-31756CVE-2026-31755CVE-2026-31754CVE-2026-31752、 、 、 、 CVE-2026-43190CVE-2026-43135CVE-2026-43134CVE-2026-43139CVE-2026-43136CVE-2026-43140CVE-2026-43141CVE-2026-43145CVE-2026-43147CVE-2026-43148CVE-2026-43133CVE-2026-43152CVE-2026-43149CVE-2026-43156CVE-2026-43158CVE-2026-43159CVE-2026-43163CVE-2026-43168CVE-2026-43132CVE-2026-43180CVE-2026-43171CVE-2026-43182CVE-2026-43183CVE-2026-43184CVE-2026-43187CVE-2026-43209CVE-2026-43207CVE-2026-43211CVE-2026-43206CVE-2026-43205CVE-2026-43203CVE-2026-43218CVE-2026-43202CVE-2026-43200CVE-2026-43196CVE-2026-43223CVE-2026-43194CVE-2026-43130CVE-2026-43124CVE-2026-43123CVE-2026-43242CVE-2026-43230CVE-2026-43231CVE-2026-43232CVE-2026-43227CVE-2026-43236CVE-2026-43246CVE-2026-43233CVE-2026-43225CVE-2026-43226CVE-2026-43241CVE-2026-43113CVE-2026-43112CVE-2026-43111CVE-2026-43110、 、 、 、 CVE-2026-43333CVE-2026-43273CVE-2026-43270CVE-2026-43277CVE-2026-43275CVE-2026-43279CVE-2026-43281CVE-2026-43283CVE-2026-43287CVE-2026-43289CVE-2026-43269CVE-2026-43295CVE-2026-43291CVE-2026-43296CVE-2026-43302CVE-2026-43312CVE-2026-43313CVE-2026-43314CVE-2026-43268CVE-2026-43316CVE-2026-43315CVE-2026-43324CVE-2026-43327CVE-2026-43328CVE-2026-43329CVE-2026-43365CVE-2026-43363CVE-2026-43370CVE-2026-43357CVE-2026-43343CVE-2026-43342CVE-2026-43373CVE-2026-43340CVE-2026-43339CVE-2026-43336CVE-2026-43380CVE-2026-43334CVE-2026-43266CVE-2026-43264CVE-2026-43262CVE-2026-43427CVE-2026-43387CVE-2026-43405CVE-2026-43411CVE-2026-43386CVE-2026-43425CVE-2026-43428CVE-2026-43420CVE-2026-43381CVE-2026-43382CVE-2026-43426CVE-2026-43261CVE-2026-43257CVE-2026-43255CVE-2026-43251、 、 、 、 CVE-2026-45843CVE-2026-43458CVE-2026-43453CVE-2026-43466CVE-2026-43459CVE-2026-43469CVE-2026-43472CVE-2026-43473CVE-2026-43475CVE-2026-43476CVE-2026-43452CVE-2026-43484CVE-2026-43480CVE-2026-43496CVE-2026-43497CVE-2026-43502CVE-2026-45834CVE-2026-45835CVE-2026-43451CVE-2026-45838CVE-2026-45836CVE-2026-45839CVE-2026-45840CVE-2026-45841CVE-2026-45842CVE-2026-45862CVE-2026-45860CVE-2026-45864CVE-2026-45857CVE-2026-45856CVE-2026-45852CVE-2026-45866CVE-2026-45848CVE-2026-45847CVE-2026-45846CVE-2026-45867CVE-2026-45844CVE-2026-43450CVE-2026-43449CVE-2026-43445CVE-2026-45890CVE-2026-45871CVE-2026-45873CVE-2026-45875CVE-2026-45870CVE-2026-45883CVE-2026-45891CVE-2026-45879CVE-2026-45868CVE-2026-45869CVE-2026-45885CVE-2026-43439CVE-2026-43432CVE-2026-43430CVE-2026-43429、 、 、 、 CVE-2026-45994CVE-2026-45935CVE-2026-45924CVE-2026-45941CVE-2026-45936CVE-2026-45946CVE-2026-45948CVE-2026-45954CVE-2026-45956CVE-2026-45958CVE-2026-45920CVE-2026-45964CVE-2026-45960CVE-2026-45965CVE-2026-45968CVE-2026-45969CVE-2026-45970CVE-2026-45974CVE-2026-45919CVE-2026-45983CVE-2026-45978CVE-2026-45984CVE-2026-45985CVE-2026-45986CVE-2026-45987CVE-2026-46023CVE-2026-46022CVE-2026-46024CVE-2026-46019CVE-2026-46018CVE-2026-46015CVE-2026-46027CVE-2026-46009CVE-2026-46006CVE-2026-46004CVE-2026-46033CVE-2026-46002CVE-2026-45916CVE-2026-45915CVE-2026-45912CVE-2026-46062CVE-2026-46046CVE-2026-46047CVE-2026-46049CVE-2026-46044CVE-2026-46051CVE-2026-46064CVE-2026-46050CVE-2026-46037CVE-2026-46040CVE-2026-46053CVE-2026-45911CVE-2026-45904CVE-2026-45902CVE-2026-45899、 、 、 、 CVE-2026-46174CVE-2026-46107CVE-2026-46102CVE-2026-46112CVE-2026-46108CVE-2026-46120CVE-2026-46122CVE-2026-46123CVE-2026-46124CVE-2026-46127CVE-2026-46101CVE-2026-46132CVE-2026-46128CVE-2026-46133CVE-2026-46137CVE-2026-46146CVE-2026-46149CVE-2026-46150CVE-2026-46099CVE-2026-46161CVE-2026-46151CVE-2026-46163CVE-2026-46167CVE-2026-46168CVE-2026-46172CVE-2026-46205CVE-2026-46198CVE-2026-46206CVE-2026-46197CVE-2026-46189CVE-2026-46187CVE-2026-46209CVE-2026-46186CVE-2026-46184CVE-2026-46178CVE-2026-46212CVE-2026-46177CVE-2026-46098CVE-2026-46088CVE-2026-46082CVE-2026-46238CVE-2026-46227CVE-2026-46230CVE-2026-46231CVE-2026-46220CVE-2026-46234CVE-2026-46249CVE-2026-46233CVE-2026-46214CVE-2026-46219CVE-2026-46236CVE-2026-46080CVE-2026-46077CVE-2026-46072CVE-2026-46070、 、 、 、 CVE-2026-52958CVE-2026-46301CVE-2026-46294CVE-2026-46304CVE-2026-46303CVE-2026-46307CVE-2026-46319CVE-2026-46328CVE-2026-52911CVE-2026-52912CVE-2026-46285CVE-2026-52915CVE-2026-52914CVE-2026-52916CVE-2026-52919CVE-2026-52920CVE-2026-52921CVE-2026-52922CVE-2026-46275CVE-2026-52926CVE-2026-52925CVE-2026-52931CVE-2026-52954CVE-2026-52955CVE-2026-52957CVE-2026-52992CVE-2026-52986CVE-2026-52993CVE-2026-52985CVE-2026-52984CVE-2026-52982CVE-2026-52995CVE-2026-52970CVE-2026-52969CVE-2026-52963CVE-2026-52998CVE-2026-52962CVE-2026-46274CVE-2026-46273CVE-2026-46270CVE-2026-53021CVE-2026-53003CVE-2026-53004CVE-2026-53006CVE-2026-53002CVE-2026-53012CVE-2026-53022CVE-2026-53011CVE-2026-52999CVE-2026-53001CVE-2026-53016CVE-2026-46267CVE-2026-46259CVE-2026-46253CVE-2026-46250、 、 、 、 CVE-2026-53128CVE-2026-53049CVE-2026-53048CVE-2026-53059CVE-2026-53050CVE-2026-53060CVE-2026-53061CVE-2026-53062CVE-2026-53064CVE-2026-53065CVE-2026-53047CVE-2026-53069CVE-2026-53068CVE-2026-53071CVE-2026-53072CVE-2026-53073CVE-2026-53074CVE-2026-53075CVE-2026-53046CVE-2026-53082CVE-2026-53077CVE-2026-53088CVE-2026-53093CVE-2026-53096CVE-2026-53112CVE-2026-53309CVE-2026-53306CVE-2026-53320CVE-2026-53304CVE-2026-53296CVE-2026-53295CVE-2026-53369CVE-2026-53294CVE-2026-53291CVE-2026-53287CVE-2026-53379CVE-2026-53130CVE-2026-53045CVE-2026-53043CVE-2026-53041CVE-2026-64055CVE-2026-64032CVE-2026-64033CVE-2026-64034CVE-2026-64018CVE-2026-64046CVE-2026-64056CVE-2026-64039CVE-2026-63860CVE-2026-63865CVE-2026-64047CVE-2026-53040CVE-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 公告中提及的多個弱點影響。

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

因此，會受到 ALAS2023-2023-356 公告中所提及的多個弱點影響。

    在 Linux 核心 6.4.2 及其之前版本的 USB 子系統中發現一個問題。drivers/usb/core/sysfs.c 的 read_descriptors 中存在一個超出邊界和損毀問題。(CVE-2023-37453)

    nf_osf_match_one() 中的 nftables 超出邊界讀取弱點 (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()。這會留下可造成釋放後使用的懸置指標。

    建議升級過去的 commit b3d26c5702c7d6c45456326e56d2ccf3f103e60f。(CVE-2023-4623)

    Linux 核心的 net/sched: sch_qfq 元件中存在釋放後使用弱點，攻擊者可利用此弱點來提升本機權限。

    當使用 plug qdisc 做為 qfq qdisc 的類別時，傳送網路封包會在 qfq_dequeue() 中觸發釋放後使用弱點，這是因為 sch_plug 的 .peek 處置程式不正確，且缺少 agg_dequeue() 中的錯誤檢查所致。

    建議升級過去的 commit 8fc134fee27f2263988ae38920bc03da416b03d8。(CVE-2023-4921)

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

    netfilter：nftables：exthdr：修復 4 位元組堆疊 OOB 寫入弱點

    如果 priv->len 是 4 的倍數，則 dst[len / 4] 可寫入超過目的地陣列，進而導致堆疊損毀。

    這個建構對於清理暫存器的其餘部分是必要的，前提是 ->len 不是暫存器大小的倍數，因此就像 nft_payload.c 一樣，將其做為條件。

    錯誤是在 4.1 週期中新增，並在新增 tcp/sctp 和 ip 選項支援時複製/繼承。

    由零時差計劃專案報告的錯誤 (ZDI-CAN-21950、ZDI-CAN-21951、ZDI-CAN-21961)。(CVE-2023-52628)

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

    USB核心不覆寫 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 片段之前呼叫零複製函式 (CVE-2023-53354)

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

    追踪修正 cpu 緩衝區寫入和交換之間的爭用問題 (CVE-2023-53368)

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

    ACPICA將 AML_NO_OPERAND_RESOLVE 旗標新增至 Timer (CVE-2023-53395)

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

    xsk修正通訊端清理期間的 xsk_diag 釋放後使用錯誤 (CVE-2023-53426)

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

    x86/MCE發生 AMD Zen IF 毒害錯誤時一律儲存 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 核心中，下列弱點已解決：

    驅動程式hvvmbus不解除參照 ACPI root 物件處理 (CVE-2023-53647)

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

    perf 追踪實際釋放 evsel->priv 區域 (CVE-2023-53649)

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

    ext4修正 ext4_fname_{setup_filename,prepare_lookup} 中的記憶體洩漏 (CVE-2023-53662)

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

    KVMnSVM針對巢狀 TSC 縮放支援進行檢查而非宣告 (CVE-2023-53663)

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

    btrfs如果我們找不到內嵌反向參照則輸出額外的除錯資訊 (CVE-2023-53672)

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

    scsi目標iscsi修正 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() 中發生 null 指標解除參照 (CVE-2023-53817)

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

    kcm修正 kcm_sendmsg() 中 SOCK_DGRAM 的錯誤處理。 (CVE-2023-53825)

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

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

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

    bpf、sockmap修正鎖定變更後的 skb refcnt 爭用 (CVE-2023-53836)

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

    md/raid5-cache修正 r5l_exit_log() 中的鎖死 (CVE-2023-53848)

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

    of重疊提前呼叫 of_changeset_init() (CVE-2023-53856)

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

    dm不嘗試在 RCU 保護下將 IO 排入佇列 (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() 接受一個大小而非 npages (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 中的 waitqueue 記憶體洩漏 (CVE-2023-54134)

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

    vfio/type1修正 cap_migration 資訊洩漏 (CVE-2023-54137)

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

    scsi目標核心修正 target_cmd_counter 洩漏 (CVE-2023-54154)

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

    ofunittest修正 of_unittest_find_node_by_name() 中的 null 指標解除參照 (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 中發現一個 null 指標解除參照缺陷。當使用者建構具有特定通訊端組態的惡意封包時，會發生此問題，其可允許本機使用者造成系統當機或提升其在系統上的權限。(CVE-2023-6176)

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

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

ID	名稱	產品	系列	已發布	已更新	嚴重性
353232	CentOS Linux 7 [TuxCare] 安全性更新：bpftool / kernel / kernel-debug / kernel-debug-devel / kernel-devel / etc 多個漏洞（CENTOS7：CLSA-2026：1782148320）	Nessus	CentOS Local Security Checks	2026/9/30	2026/9/30	high
325018	Debian dla-4664 ： ata-modules-5.10.0-43-armmp-di - 安全性更新	Nessus	Debian Local Security Checks	2026/7/3	2026/9/18	high
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
352091	CentOS Linux 8.4 [TuxCare] 安全性更新：bpftool / kernel / kernel-core / kernel-cross-headers / etc 多個弱點（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 / etc 多個弱點（ALMALINUX9.2：CLSA-2026：1779375889）	Nessus	Alma Linux Local Security Checks	2026/9/30	2026/10/1	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

偵測

搜尋 Plugin

high

high

high

high

high

high

high

high