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

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

    lib/generic-radix-tree.cpeek() 中不會溢位 (CVE-2021-47432)

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

    smb：用戶端：修正 cifs_debug_data_proc_show() 中的釋放後使用錯誤 (CVE-2023-52752)

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

    smb：用戶端：修正釋放 mids 時可能發生的鎖死問題 (CVE-2023-52757)

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

    virtio-blk：修正 virtio_max_dma_size 上的隱含溢位 (CVE-2023-52762)

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

    i3c主要mipi-i3c-hci修正用於存取 DAT_data 的核心錯誤。 (CVE-2023-52763)

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

    af_unix：修正 unix_stream_read_actor() 中的使用已釋放記憶體 (CVE-2023-52772)

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

    mptcp：處理大型 GSO 大小 (CVE-2023-52778)

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

    usb：config：修正「usb_get_bos_descriptor()」中的反覆運算問題 (CVE-2023-52781)

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

    bonding：在 bond_setup_by_slave() 中停止裝置 (CVE-2023-52784)

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

    i915/perf：修正 drm_dbg() 呼叫的 NULL 指標解除參照錯誤 (CVE-2023-52788)

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

    i2c：核心：在 !preemptible 時執行 atomic i2c xfer (CVE-2023-52791)

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

    ipvlan：新增 ipvlan_route_v6_outbound() 協助程式 (CVE-2023-52796)

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

    SUNRPC：修正 RPC 用戶端清除已釋放的 pipefs dentry (CVE-2023-52803)

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

    crypto：pcrypt - 修正 PADATA_RESET 的 hangtask (CVE-2023-52813)

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

    bpf：在 BPF 程式中偵測到 IP == ksym.end (CVE-2023-52828)

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

    cpu/hotplug：不要使最後一個非隔離的 CPU 離線 (CVE-2023-52831)

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

    perf/core：如果要求 AUX 區域超出邊界，則提早結束 (CVE-2023-52835)

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

    nbd：修復 nbd_open 中的釋放後使用弱點 (CVE-2023-52837)

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

    Input：synaptics-rmi4 - 修正 rmi_unregister_function() 中的釋放後使用弱點 (CVE-2023-52840)

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

    llc：讀取 mac 標頭前驗證 mac len (CVE-2023-52843)

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

    hsr：避免 prp_create_tagged_frame() 中發生使用已釋放記憶體 (CVE-2023-52846)

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

    padata：修正 padata_free_shell() 中的 refcnt 處理 (CVE-2023-52854)

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

    perf：hisi：修正註冊 pmu 失敗時使用已釋放記憶體的問題 (CVE-2023-52859)

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

    drivers/perf：hisi：針對 Hisi_hns3_pmu uninit 處理程序使用 cpuhp_state_remove_instance_nocalls() (CVE-2023-52860)

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

    platform/x86wmi修正 char 裝置的開啟 (CVE-2023-52864)

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

    thermal：核心：避免潛在的字串溢位 (CVE-2023-52868)

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

    pstore/platform：新增 kstrdup 的檢查 (CVE-2023-52869)

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

    tracing使 trace_event_file 具有參照計數器 (CVE-2023-52879)

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

    引數 sync 為 true 時，nft_trans_gc_catchall 函式並未從 catchall_list 移除全能集元素，進而可能多次釋放全能集元素。

    建議升級過去的認可 93995bf4af2c5a99e2a87f0cd5ce547d31eb7630。(CVE-2023-6111)

    在 Linux 核心的 nf_tables 中，發現 net/netfilter/nft_dynset.c 的 nft_dynset_init() 存在 Null 指標解除參照弱點。具有 CAP_NET_ADMIN 使用者特權的本機攻擊者可藉由此問題造成拒絕服務。(CVE-2023-6622)

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

    攻擊者可惡意利用爭用情形，造成在 RCU 讀取鎖定物件上錯誤註冊一個計時器，而該物件已由另一個執行緒釋放。

    建議升級過去的 commit e2b706c691905fe78468c361aaabc719d0a496f1。(CVE-2023-6932)

    在 Linux 核心的 network 子元件中，發現 net/ipv4/igmp.c 的 igmp_start_timer 存在釋放後使用問題。此缺陷可讓本機使用者在接收 igmp 查詢封包時發現 refcnt 釋放後使用問題，進而導致核心資訊洩漏。(CVE-2024-0584)

    netfilter：nf_tables：修復 nft_byteorder_eval() 中的指標數學問題 (CVE-2024-0607)

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

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

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

  - 在 Linux 核心中，已解決下列弱點： mptcp: deal with large GSO size After the blamed commit below, the TCP sockets (and the MPTCP subflows) can build egress packets larger than 64K. That exceeds the maximum DSS data size, the length being misrepresent on the wire and the stream being corrupted, as later observed on the receiver: WARNING: CPU: 0 PID: 9696 at net/mptcp/protocol.c:705
    __mptcp_move_skbs_from_subflow+0x2604/0x26e0 CPU: 0 PID: 9696 Comm: syz-executor.7 Not tainted 6.6.0-rc5-gcd8bdf563d46 #45 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.el7 04/01/2014 netlink: 8 bytes leftover after parsing attributes in process `syz-executor.4'. RIP:
    0010:__mptcp_move_skbs_from_subflow+0x2604/0x26e0 net/mptcp/protocol.c:705 RSP: 0018:ffffc90000006e80 EFLAGS: 00010246 RAX: ffffffff83e9f674 RBX: ffff88802f45d870 RCX: ffff888102ad0000 netlink: 8 bytes leftover after parsing attributes in process `syz-executor.4'. RDX: 0000000080000303 RSI: 0000000000013908 RDI: 0000000000003908 RBP: ffffc90000007110 R08: ffffffff83e9e078 R09: 1ffff1100e548c8a R10:
    dffffc0000000000 R11: ffffed100e548c8b R12: 0000000000013908 R13: dffffc0000000000 R14: 0000000000003908 R15: 000000000031cf29 FS: 00007f239c47e700(0000) GS:ffff88811b200000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f239c45cd78 CR3: 000000006a66c006 CR4: 0000000000770ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6:
    00000000fffe0ff0 DR7: 0000000000000600 PKRU: 55555554 Call Trace: <IRQ> mptcp_data_ready+0x263/0xac0 net/mptcp/protocol.c:819 subflow_data_ready+0x268/0x6d0 net/mptcp/subflow.c:1409 tcp_data_queue+0x21a1/0x7a60 net/ipv4/tcp_input.c:5151 tcp_rcv_established+0x950/0x1d90 net/ipv4/tcp_input.c:6098 tcp_v6_do_rcv+0x554/0x12f0 net/ipv6/tcp_ipv6.c:1483 tcp_v6_rcv+0x2e26/0x3810 net/ipv6/tcp_ipv6.c:1749 ip6_protocol_deliver_rcu+0xd6b/0x1ae0 net/ipv6/ip6_input.c:438 ip6_input+0x1c5/0x470 net/ipv6/ip6_input.c:483 ipv6_rcv+0xef/0x2c0 include/linux/netfilter.h:304
    __netif_receive_skb+0x1ea/0x6a0 net/core/dev.c:5532 process_backlog+0x353/0x660 net/core/dev.c:5974
    __napi_poll+0xc6/0x5a0 net/core/dev.c:6536 net_rx_action+0x6a0/0xfd0 net/core/dev.c:6603
    __do_softirq+0x184/0x524 kernel/softirq.c:553 do_softirq+0xdd/0x130 kernel/softirq.c:454 Address the issue explicitly bounding the maximum GSO size to what MPTCP actually allows. (CVE-2023-52778)

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

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

  - 已解決 Linux 核心中的下列弱點：extcon: Modify extcon device to be created after driver data is set Currently, someone can invoke the sysfs such as state_show() intermittently before dev_set_drvdata() is done. And it can be a cause of kernel Oops because of edev is Null at that time. So modified the driver registration to after setting drviver data. - Oops's backtrace.
    Backtrace: [<c067865c>] (state_show) from [<c05222e8>] (dev_attr_show) [<c05222c0>] (dev_attr_show) from [<c02c66e0>] (sysfs_kf_seq_show) [<c02c6648>] (sysfs_kf_seq_show) from [<c02c496c>] (kernfs_seq_show) [<c02c4938>] (kernfs_seq_show) from [<c025e2a0>] (seq_read) [<c025e11c>] (seq_read) from [<c02c50a0>] (kernfs_fop_read) [<c02c5064>] (kernfs_fop_read) from [<c0231cac>] (__vfs_read) [<c0231c5c>] (__vfs_read) from [<c0231ee0>] (vfs_read) [<c0231e34>] (vfs_read) from [<c0232464>] (ksys_read) [<c02323f0>] (ksys_read) from [<c02324fc>] (sys_read) [<c02324e4>] (sys_read) from [<c00091d0>] (__sys_trace_return) (CVE-2022-49308)

  - 已解決 Linux 核心中的下列弱點：tick/nohz: unexport __init-annotated tick_nohz_full_setup() EXPORT_SYMBOL and __init is a bad combination because the .init.text section is freed up after the initialization. Hence, modules cannot use symbols annotated __init. The access to a freed symbol may end up with kernel panic. modpost used to detect it, but it had been broken for a decade.
    Commit 28438794aba4 (modpost: fix section mismatch check for exported init/exit sections) fixed it so modpost started to warn it again, then this showed up: MODPOST vmlinux.symvers WARNING: modpost:
    vmlinux.o(___ksymtab_gpl+tick_nohz_full_setup+0x0): Section mismatch in reference from the variable
    __ksymtab_tick_nohz_full_setup to the function .init.text:tick_nohz_full_setup() The symbol tick_nohz_full_setup is exported and annotated __init Fix this by removing the __init annotation of tick_nohz_full_setup or drop the export. Drop the export because tick_nohz_full_setup() is only called from the built-in code in kernel/sched/isolation.c. (CVE-2022-49675)

  - 已解決 Linux 核心中的下列弱點：ata: libata-core: fix NULL pointer deref in ata_host_alloc_pinfo() In an unlikely (and probably wrong?) case that the 'ppi' parameter of ata_host_alloc_pinfo() points to an array starting with a NULL pointer, there's going to be a kernel oops as the 'pi' local variable won't get reassigned from the initial value of NULL. Initialize 'pi' instead to '&ata_dummy_port_info' to fix the possible kernel oops for good... Found by Linux Verification Center (linuxtesting.org) with the SVACE static analysis tool. (CVE-2022-49731)

  - 已解決 Linux 核心中的下列弱點：bridge: switchdev: Fix memory leaks when changing VLAN protocol The bridge driver can offload VLANs to the underlying hardware either via switchdev or the 8021q driver. When the former is used, the VLAN is marked in the bridge driver with the 'BR_VLFLAG_ADDED_BY_SWITCHDEV' private flag. To avoid the memory leaks mentioned in the cited commit, the bridge driver will try to delete a VLAN via the 8021q driver if the VLAN is not marked with the previously mentioned flag. When the VLAN protocol of the bridge changes, switchdev drivers are notified via the 'SWITCHDEV_ATTR_ID_BRIDGE_VLAN_PROTOCOL' attribute, but the 8021q driver is also called to add the existing VLANs with the new protocol and delete them with the old protocol. In case the VLANs were offloaded via switchdev, the above behavior is both redundant and buggy. Redundant because the VLANs are already programmed in hardware and drivers that support VLAN protocol change (currently only mlx5) change the protocol upon the switchdev attribute notification. Buggy because the 8021q driver is called despite these VLANs being marked with 'BR_VLFLAG_ADDED_BY_SWITCHDEV'. This leads to memory leaks [1] when the VLANs are deleted. Fix by not calling the 8021q driver for VLANs that were already programmed via switchdev. [1] unreferenced object 0xffff8881f6771200 (size 256): comm ip, pid 446855, jiffies 4298238841 (age 55.240s) hex dump (first 32 bytes): 00 00 7f 0e 83 88 ff ff 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace:
    [<00000000012819ac>] vlan_vid_add+0x437/0x750 [<00000000f2281fad>] __br_vlan_set_proto+0x289/0x920 [<000000000632b56f>] br_changelink+0x3d6/0x13f0 [<0000000089d25f04>] __rtnl_newlink+0x8ae/0x14c0 [<00000000f6276baf>] rtnl_newlink+0x5f/0x90 [<00000000746dc902>] rtnetlink_rcv_msg+0x336/0xa00 [<000000001c2241c0>] netlink_rcv_skb+0x11d/0x340 [<0000000010588814>] netlink_unicast+0x438/0x710 [<00000000e1a4cd5c>] netlink_sendmsg+0x788/0xc40 [<00000000e8992d4e>] sock_sendmsg+0xb0/0xe0 [<00000000621b8f91>] ____sys_sendmsg+0x4ff/0x6d0 [<000000000ea26996>] ___sys_sendmsg+0x12e/0x1b0 [<00000000684f7e25>] __sys_sendmsg+0xab/0x130 [<000000004538b104>] do_syscall_64+0x3d/0x90 [<0000000091ed9678>] entry_SYSCALL_64_after_hwframe+0x46/0xb0 (CVE-2022-49812)

  - 已解決 Linux 核心中的下列弱點：capabilities: fix potential memleak on error path from vfs_getxattr_alloc() In cap_inode_getsecurity(), we will use vfs_getxattr_alloc() to complete the memory allocation of tmpbuf, if we have completed the memory allocation of tmpbuf, but failed to call handler->get(...), there will be a memleak in below logic: |-- ret = (int)vfs_getxattr_alloc(mnt_userns, ...) | /* ^^^ alloc for tmpbuf */ |-- value = krealloc(*xattr_value, error + 1, flags) | /* ^^^ alloc memory */ |-- error = handler->get(handler, ...) | /* error! */ |--
    *xattr_value = value | /* xattr_value is &tmpbuf (memory leak!) */ So we will try to free(tmpbuf) after vfs_getxattr_alloc() fails to fix it. [PM: subject line and backtrace tweaks] (CVE-2022-49890)

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

ID	名稱	產品	系列	已發布	已更新	嚴重性
186974	Amazon Linux 2023：bpftool、kernel、kernel-devel (ALAS2023-2023-461)	Nessus	Amazon Linux Local Security Checks	2023/12/15	2026/2/24	high
226086	Linux Distros 未修補弱點：CVE-2023-52778	Nessus	Misc.	2025/3/5	2026/7/17	medium
360687	AlmaLinux 9.2 [TuxCare] 安全性更新：bpftool / kernel / kernel-abi-stablelists / kernel-core / etc 多個弱點（ALMALINUX9.2：CLSA-2026：1783362244）	Nessus	Alma Linux Local Security Checks	2026/10/1	2026/10/1	high

偵測

搜尋 Plugin

high

medium

high