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

    Linux 核心的 eBPF 子系統中可能有鎖死問題。

    Amazon Linux 主機上的預設 sysctl 設定 kernel.unprivileged_bpf_disabled 不允許非特權使用者使用 eBPF。(CVE-2023-0160)

    由於可能發生的遞迴鎖定狀況，導致拒絕服務問題，可造成 Linux Kernel Device Mapper-Multipathing 子元件中 drivers/md/dm-ioctl.c 的 table_clear 發生鎖死。(CVE-2023-2269)

    在 Linux 核心 6.3.1 及更低版本中，Netfilter nf_tables 在處理批量請求時的釋放後使用弱點可被濫用來對核心記憶體執行任意讀寫動作。無權限的本機使用者可取得 root 權限。這是因為未正確處理匿名集所致。(CVE-2023-32233)

    在 6.3.3 版之前的 Linux 核心中發現一個問題。從 fs/ext4/super.c 呼叫 lib/crc16.c 中的 crc16 時，因為 ext4_group_desc_csum 未正確檢查位移，此函式會發生超出邊界讀取問題。(CVE-2023-34256)

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

    ext4修正部分寫入情況下 i_disksize 超過 i_size 的問題 (CVE-2023-53270)

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

    ext4在 get_max_inline_xattr_value_size() 中新增邊界檢查 (CVE-2023-53285)

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

    fs/ntfs3修正 ntfs_lookup() 中 inode->i_op 上的 null-ptr-deref (CVE-2023-53294)

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

    md/raid10修正復原之 'r10bio->remaining' 的洩漏 (CVE-2023-53299)

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

    ext4修正 mb_find_extent 中的警告 (CVE-2023-53317)

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

    ext4移除 ext4_mb_release_group_pa() 中的 BUG_ON (CVE-2023-53450)

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

    ext4改善來自 ext4_dirhash() 的錯誤處理 (CVE-2023-53473)

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

    x86/MCE/AMD針對bank_map 使用 u64 (CVE-2023-53474)

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

    tcp/udp修正含有 TX 時間戳記的 sk 和 zerocopy skb 的記憶體洩漏。 (CVE-2023-53489)

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

    blk-crypto使 blk_crypto_evict_key() 更健全 (CVE-2023-53536)

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

    drm/i915使 intel_get_crtc_new_encoder() 減少 oopsy (CVE-2023-53571)

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

    scsi目標修正多個 LUN_RESET 處理 (CVE-2023-53586)

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

    ring-buffer在緩衝區解構前同步 IRQ 正常運作 (CVE-2023-53587)

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

    dm 完整性在 dm_integrity_init() 錯誤路徑中呼叫 kmem_cache_destroy() (CVE-2023-53604)

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

    net/schedsch_fq修正額度的整數溢位 (CVE-2023-53624)

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

    netfilterconntrack修正錯誤的 ct->timeout 值 (CVE-2023-53635)

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

    x86修正 clear_user_rep_good() 例外狀況處理註釋 (CVE-2023-53642)

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

    rcu避免因 __rcu_irq_enter_check_tick() 遭到入侵而造成堆疊溢位 (CVE-2023-53655)

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

    tcp修正 skb_copy_ubufs() 與 BIG TCP (CVE-2023-53669)

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

    ext4修正 bigalloc + 內嵌之 ext4_find_extent 中的釋放後使用讀取 (CVE-2023-53692)

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

    x86修正 clear_user_rep_good() 例外狀況處理註釋 (CVE-2023-53749)

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

    cifs修正 TCP_Server_Info::hostname 中的潛在釋放後使用錯誤 (CVE-2023-53751)

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

    virt/coco/sev-guest雙重緩衝區訊息 (CVE-2023-53769)

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

    dm flakey修正因無效表格行造成的當機 (CVE-2023-53786)

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

    ethtool修正未初始化的通道數 (CVE-2023-53798)

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

    blk-mq在報告 I/O 完成之前釋放密碼編譯金鑰插槽 (CVE-2023-53810)

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

    md/raid10修正 raid10_sync_request 中的 null-ptr-deref (CVE-2023-53832)

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

    ceph修正修剪端點時可能發生的釋放後使用錯誤 (CVE-2023-53867)

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

    fs/ntfs3修正 hdr_delete_de() 中的 slab-out-of-bounds 讀取 (CVE-2023-53988)

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

    SMB3新增遺漏的鎖定以保護延遲關閉檔案清單 (CVE-2023-53990)

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

    btrfs修正開始平衡時的 exclop 條件宣告 (CVE-2023-54002)

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

    vmci_host修正 vmci_host_poll() 中造成 GPF 的爭用情形 (CVE-2023-54007)

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

    spmi移除 SPMI 驅動程式時新增移除回呼的檢查 (CVE-2023-54044)

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

    kheaders使用陣列宣告而非 char (CVE-2023-54056)

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

    ext4修正 ext4_xattr_move_to_block() 中的無效釋放追踪 (CVE-2023-54062)

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

    fs/ntfs3修正 indx_insert_into_buffer 中的 OOB 讀取 (CVE-2023-54063)

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

    tpm將 !tpm_amd_is_rng_defective() 新增至 hwrng_unregister() 呼叫網站 (CVE-2023-54073)

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

    fs/ntfs3修正 ntfs_read_mft 失敗時的記憶體洩漏 (CVE-2023-54077)

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

    inotify避免報告具有無效 wd 的事件 (CVE-2023-54119)

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

    md/raid10修正 'conf->bio_split' 的記憶體洩漏 (CVE-2023-54123)

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

    btrfs除非指定否則不釋放 qgroup 空間 (CVE-2023-54158)

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

    net/schedcls_api釋放之前從 driver_list 中移除 block_cb (CVE-2023-54193)

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

    fs/ntfs3新增 kmemdup 檢查 (CVE-2023-54248)

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

    md/raid10修正 md 執行緒的記憶體洩漏 (CVE-2023-54294)

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

    ext4修正在 nojournal 模式下轉換內嵌目錄時發生的鎖死 (CVE-2023-54311)

    在 Linux 核心的 ext4 中，在 fs/ext4/super.c 的 __ext4_remount 中發現釋放後使用缺陷。此缺陷允許本機使用者在釋放舊的配額檔案名稱以觸發潛在的失敗時，造成資訊洩漏問題，進而導致釋放後使用。(CVE-2024-0775)

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

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

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

  - virt/coco/sev-guest雙重緩衝區訊息加密演算法直接讀取和寫入共用的未加密記憶體其可能會洩漏資訊並允許主機竄改訊息完整性。而是視需要將整個訊息複製入或複制出然後再對其執行任何計算。
    (CVE-2023-53769)

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

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

  - 在 KVM 的 AMD 巢狀虛擬化 (SVM) 中發現一個缺陷。惡意的 L1 來賓可有意放棄攔截合作巢狀來賓 (L2) 的關機動作，這可能導致主機 (L0) 中發生索引標籤錯誤和核心錯誤。(CVE-2022-3344)

  - 已解決 Linux 核心中的下列弱點：usbnet: Run unregister_netdev() before unbind() again Commit 2c9d6c2b871d (usbnet: run unbind() before unregister_netdev()) sought to fix a use-after-free on disconnect of USB Ethernet adapters. It turns out that a different fix is necessary to address the issue:
    https://lore.kernel.org/netdev/18b3541e5372bc9b9fc733d422f4e698c089077c.1650177997.git.lukas@wunner.de/ So the commit was not necessary. The commit made binding and unbinding of USB Ethernet asymmetrical: Before, usbnet_probe() first invoked the ->bind() callback and then register_netdev(). usbnet_disconnect() mirrored that by first invoking unregister_netdev() and then ->unbind(). Since the commit, the order in usbnet_disconnect() is reversed and no longer mirrors usbnet_probe(). One consequence is that a PHY disconnected (and stopped) in ->unbind() is afterwards stopped once more by unregister_netdev() as it closes the netdev before unregistering. That necessitates a contortion in ->stop() because the PHY may only be stopped if it hasn't already been disconnected. Reverting the commit allows making the call to phy_stop() unconditional in ->stop(). (CVE-2022-49501)

  - 已解決 Linux 核心中的下列弱點：crypto: arm64/poly1305 - fix a read out-of-bound A kasan error was reported during fuzzing: BUG: KASAN: slab-out-of-bounds in neon_poly1305_blocks.constprop.0+0x1b4/0x250 [poly1305_neon] Read of size 4 at addr ffff0010e293f010 by task syz-executor.5/1646715 CPU: 4 PID: 1646715 Comm: syz-executor.5 Kdump: loaded Not tainted 5.10.0.aarch64 #1 Hardware name: Huawei TaiShan 2280 /BC11SPCD, BIOS 1.59 01/31/2019 Call trace:
    dump_backtrace+0x0/0x394 show_stack+0x34/0x4c arch/arm64/kernel/stacktrace.c:196 __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x158/0x1e4 lib/dump_stack.c:118 print_address_description.constprop.0+0x68/0x204 mm/kasan/report.c:387 __kasan_report+0xe0/0x140 mm/kasan/report.c:547 kasan_report+0x44/0xe0 mm/kasan/report.c:564 check_memory_region_inline mm/kasan/generic.c:187 [inline] __asan_load4+0x94/0xd0 mm/kasan/generic.c:252 neon_poly1305_blocks.constprop.0+0x1b4/0x250 [poly1305_neon] neon_poly1305_do_update+0x6c/0x15c [poly1305_neon] neon_poly1305_update+0x9c/0x1c4 [poly1305_neon] crypto_shash_update crypto/shash.c:131 [inline] shash_finup_unaligned+0x84/0x15c crypto/shash.c:179 crypto_shash_finup+0x8c/0x140 crypto/shash.c:193 shash_digest_unaligned+0xb8/0xe4 crypto/shash.c:201 crypto_shash_digest+0xa4/0xfc crypto/shash.c:217 crypto_shash_tfm_digest+0xb4/0x150 crypto/shash.c:229 essiv_skcipher_setkey+0x164/0x200 [essiv] crypto_skcipher_setkey+0xb0/0x160 crypto/skcipher.c:612 skcipher_setkey+0x3c/0x50 crypto/algif_skcipher.c:305 alg_setkey+0x114/0x2a0 crypto/af_alg.c:220 alg_setsockopt+0x19c/0x210 crypto/af_alg.c:253 __sys_setsockopt+0x190/0x2e0 net/socket.c:2123 __do_sys_setsockopt net/socket.c:2134 [inline] __se_sys_setsockopt net/socket.c:2131 [inline] __arm64_sys_setsockopt+0x78/0x94 net/socket.c:2131
    __invoke_syscall arch/arm64/kernel/syscall.c:36 [inline] invoke_syscall+0x64/0x100 arch/arm64/kernel/syscall.c:48 el0_svc_common.constprop.0+0x220/0x230 arch/arm64/kernel/syscall.c:155 do_el0_svc+0xb4/0xd4 arch/arm64/kernel/syscall.c:217 el0_svc+0x24/0x3c arch/arm64/kernel/entry-common.c:353 el0_sync_handler+0x160/0x164 arch/arm64/kernel/entry-common.c:369 el0_sync+0x160/0x180 arch/arm64/kernel/entry.S:683 This error can be reproduced by the following code compiled as ko on a system with kasan enabled: #include <linux/module.h> #include <linux/crypto.h> #include <crypto/hash.h> #include <crypto/poly1305.h> char test_data[] = \x00\x01\x02\x03\x04\x05\x06\x07 \x08\x09\x0a\x0b\x0c\x0d\x0e\x0f \x10\x11\x12\x13\x14\x15\x16\x17 \x18\x19\x1a\x1b\x1c\x1d\x1e; int init(void) { struct crypto_shash *tfm = NULL; char *data = NULL, *out = NULL; tfm = crypto_alloc_shash(poly1305, 0, 0); data = kmalloc(POLY1305_KEY_SIZE - 1, GFP_KERNEL); out = kmalloc(POLY1305_DIGEST_SIZE, GFP_KERNEL); memcpy(data, test_data, POLY1305_KEY_SIZE - 1);
    crypto_shash_tfm_digest(tfm, data, POLY1305_KEY_SIZE - 1, out); kfree(data); kfree(out); return 0; } void deinit(void) { } module_init(init) module_exit(deinit) MODULE_LICENSE(GPL); The root cause of the bug sits in neon_poly1305_blocks. The logic neon_poly1305_blocks() performed is that if it was called with both s[] and r[] uninitialized, it will first try to initialize them with the data from the first block that it believed to be 32 bytes in length. First 16 bytes are used as the key and the next 16 bytes for s[]. This would lead to the aforementioned read out-of-bound. However, after calling poly1305_init_arch(), only 16 bytes were deducted from the input and s[] is initialized yet again with the following 16 bytes.
    The second initialization of s[] is certainly redundent which indicates that the first initialization should be for r[] only. This patch fixes the issue by calling poly1305_init_arm64() instead o
    ---truncated--- (CVE-2022-50231)

  - 已解決 Linux 核心中的下列弱點：bpf: Fix reference state management for synchronous callbacks Currently, verifier verifies callback functions (sync and async) as if they will be executed once, (i.e. it explores execution state as if the function was being called once). The next insn to explore is set to start of subprog and the exit from nested frame is handled using curframe > 0 and prepare_func_exit. In case of async callback it uses a customized variant of push_stack simulating a kind of branch to set up custom state and execution context for the async callback. While this approach is simple and works when callback really will be executed only once, it is unsafe for all of our current helpers which are for_each style, i.e. they execute the callback multiple times. A callback releasing acquired references of the caller may do so multiple times, but currently verifier sees it as one call inside the frame, which then returns to caller. Hence, it thinks it released some reference that the cb e.g. got access through callback_ctx (register filled inside cb from spilled typed register on stack).
    Similarly, it may see that an acquire call is unpaired inside the callback, so the caller will copy the reference state of callback and then will have to release the register with new ref_obj_ids. But again, the callback may execute multiple times, but the verifier will only account for acquired references for a single symbolic execution of the callback, which will cause leaks. Note that for async callback case, things are different. While currently we have bpf_timer_set_callback which only executes it once, even for multiple executions it would be safe, as reference state is NULL and check_reference_leak would force program to release state before BPF_EXIT. The state is also unaffected by analysis for the caller frame.
    Hence async callback is safe. Since we want the reference state to be accessible, e.g. for pointers loaded from stack through callback_ctx's PTR_TO_STACK, we still have to copy caller's reference_state to callback's bpf_func_state, but we enforce that whatever references it adds to that reference_state has been released before it hits BPF_EXIT. This requires introducing a new callback_ref member in the reference state to distinguish between caller vs callee references. Hence, check_reference_leak now errors out if it sees we are in callback_fn and we have not released callback_ref refs. Since there can be multiple nested callbacks, like frame 0 -> cb1 -> cb2 etc. we need to also distinguish between whether this particular ref belongs to this callback frame or parent, and only error for our own, so we store state->frameno (which is always non-zero for callbacks). In short, callbacks can read parent reference_state, but cannot mutate it, to be able to use pointers acquired by the caller. They must only undo their changes (by releasing their own acquired_refs before BPF_EXIT) on top of caller reference_state before returning (at which point the caller and callback state will match anyway, so no need to copy it back to caller). (CVE-2022-50650)

  - 已解決 Linux 核心中的下列弱點：net: stmmac: fix possible memory leak in stmmac_dvr_probe() The bitmap_free() should be called to free priv->af_xdp_zc_qps when create_singlethread_workqueue() fails, otherwise there will be a memory leak, so we add the err path error_wq_init to fix it. (CVE-2022-50663)

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

ID	名稱	產品	系列	已發布	已更新	嚴重性
176925	Amazon Linux 2023：bpftool、kernel、kernel-devel (ALAS2023-2023-184)	Nessus	Amazon Linux Local Security Checks	2023/6/8	2026/2/12	high
277775	Linux Distros 未修補的弱點：CVE-2023-53769	Nessus	Misc.	2025/12/8	2026/11/12	critical
352031	AlmaLinux 9.2 [TuxCare] 安全性更新：bpftool / kernel / kernel-64k / kernel-64k-core / kernel-64k-debug / etc 多個弱點（ALMALINUX9.2：CLSA-2026：1786761805）	Nessus	Alma Linux Local Security Checks	2026/9/30	2026/10/19	critical

偵測

搜尋 Plugin

high

critical

critical