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

  - dm不嘗試在 RCU 保護下將 IO 排入佇列 dm 會根據要求類型在表格中查詢 IO並假設如果要求標記為 REQ_NOWAIT則可以在 RCU 讀取鎖定下嘗試提交該 IO保護。這並不適用因為 REQ_NOWAIT 僅表示我們不應在其他 IO 上進入休眠等待狀態並不表示我們可能無法排程。一個簡單的測試案例就足以說明這一點 int main(int argc, char *argv[]) { struct iovec iov; int fd; fd = open(/dev/dm-0, O_RDONLY | O_DIRECT); posix_memalign(&iov.iov_base, 4096, 4096); iov.iov_len = 4096 preadv2(fd, &iov, 1, 0, RWF_NOWAIT);傳回 0會立即產生錯誤︰從 include/linux/sched/mm.h:306 的無效內容呼叫休眠函式 in_atomic(): 0, irqs_disabled(): 0, non_block: 0, pid: 5580, name: dm- nowait preempt_count0、預期為 0 RCU 巢狀深度為 1、預期為 0 INFOlockdep 已關閉。CPU7 PID5580 通訊dm-nowait 未受污染的 6.6.0-rc1-g39956d2dcd81 #132 硬體名稱QEMU Standard PC (i440FX + PIIX, 1996)BIOS 1.16.2-debian-1.16.2-1 04/ 01/2014 呼叫追踪 <TASK> dump_stack_lvl+0x11d/0x1b0
    __might_resched+0x3c3/0x5e0 ? preempt_count_sub+0x150/0x150 mempool_alloc+0x1e2/0x390 ? mempool_resize+0x7d0/0x7d0 ? lock_sync+0x190/0x190 lock_release+0x4b7/0x670 internal_get_user_pages_fast+0x868/0x2d40 bio_alloc_bioset+0x417/0x8c0 bvec_alloc+0x200/0x200 ? internal_get_user_pages_fast+0xb8c/0x2d40 bio_alloc_clone+0x53/0x100 dm_submit_bio+0x27f/0x1a20 ? lock_release+0x4b7/0x670 blk_try_enter_queue+0x1a0/0x4d0 dm_dax_direct_access+0x260/0x260 ? rcu_is_watching+0x12/0xb0 blk_try_enter_queue+0x1cc/0x4d0 __submit_bio+0x239/0x310 ?
    __bio_queue_enter+0x700/0x700 ? kvm_clock_get_cycles+0x40/0x60 ? ktime_get+0x285/0x470 submit_bio_noacct_nocheck+0x4d9/0xb80 ? should_fail_request+0x80/0x80 ? preempt_count_sub+0x150/0x150 ? lock_release+0x4b7/0x670 __bio_add_page+0x143/0x2d0 ? iov_iter_revert+0x27/0x360 submit_bio_noacct+0x53e/0x1b30 submit_bio_wait+0x10a/0x230 ? submit_bio_wait_endio+0x40/0x40
    __blkdev_direct_IO_simple+0x4f8/0x780 ? blkdev_bio_end_io+0x4c0/0x4c0 stack_trace_save+0x90/0xc0 ?
    __bio_clone+0x3c0/0x3c0 ? lock_release+0x4b7/0x670 lock_sync+0x190/0x190 atime_needs_update+0x3bf/0x7e0 ? timestamp_truncate+0x21b/0x2d0 inode_owner_or_capable+0x240/0x240 blkdev_direct_IO.part.0+0x84a/0x1810 rcu_is_watching+0x12/0xb0 lock_release+0x4b7/0x670 blkdev_read_iter+0x40d/0x530 ? reacquire_held_locks+0x4e0/0x4e0 __blkdev_direct_IO_simple+0x780/0x780 ? rcu_is_watching+0x12/0xb0 __mark_inode_dirty+0x297/0xd50 ? preempt_count_add+0x72/0x140 blkdev_read_iter+0x2a4/0x530 do_iter_readv_writev+0x2f2/0x3c0 generic_copy_file_range+0x1d0/0x1d0 ? fsnotify_perm.part.0+0x25d/0x630 ? security_file_permission+0xd8/0x100 do_iter_read+0x31b/0x880 ? import_iovec+0x10b/0x140 vfs_readv+0x12d/0x1a0 ? vfs_iter_read+0xb0/0xb0 ? rcu_is_watching+0x12/0xb0 rcu_is_watching+0x12/0xb0 lock_release+0x4b7/0x670 do_preadv+0x1b3/0x260 ? do_readv+0x370/0x370
    __x64_sys_preadv2+0xef/0x150 do_syscall_64+0x39/0xb0 entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP
    0033:0x7f5af41ad806 程式碼41 54 41 89 fc 55 44 89 c5 53 48 89 cb 48 83 ec 18 80 3d e4 dd 0d 00 00 74 7a 45 89 c1 49 89 ca 45 31 c0 b8 47 01 0 [ 0 00 47 01 <48> 0 3f 00 f0 ff ff 0f 87 be 00 00 00 48 85 c0 79 4a 48 8b 0d da 55 RSP002b00007ffd3145c7f0 EFLAGS00000246 ORIG_RAX0000000000000147 RAXffffffffffffda
    0000000000000000 RCX: 00007f5af41ad806 RDX: 0000000000000001 RSI: 00007ffd3145c850 RDI: 0000000000000003 RBP: 0000000000000008 R08: 0000000000000000 R09: 0000000000000008 R10: 0000000000000000 R11:
    0000000000000246 R120000000000000003 R1300007ffd3145c850 R14000055f5f0431dd8 R150000000000000001 </TASK> 而實際上是 ---truncated--- (CVE-2023-53860)

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

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

ID	名稱	產品	系列	已發布	已更新	嚴重性
278010	Linux Distros 未修補的弱點：CVE-2023-53860	Nessus	Misc.	2025/12/9	2026/11/5	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
353122	AlmaLinux 9.2 [TuxCare] 安全性更新：bpftool / kernel / kernel-64k / kernel-64k-core / kernel-64k-debug / etc 多個弱點（ALMALINUX9.2：CLSA-2026：1779375889）	Nessus	Alma Linux Local Security Checks	2026/9/30	2026/10/21	high

偵測

搜尋 Plugin

high

high

high