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

    已发现在某些 AMD CPU 上，RAS（返回地址堆栈，在某些 AMD 文档中也称为 RAP [返回地址预测器]，在 Intel 术语中也称为 RSB [返回堆栈缓冲区]）在非空闲线程之间进行动态分区。攻击者可利用此漏洞，控制邻近线程上的推测执行。(CVE-2022-27672)

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

    ovl将 buf 灵活数组用于 memcpy() 目标 (CVE-2022-49743)

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

    mm/uffd在无 fork 事件的情况下进行 fork() 时修复 pte 标记CVE-2022-49744

    上游缺陷报告对此问题的描述如下：

    在 Linux 内核的可靠数据报套接字 (RDS) 协议实现中发现了一个缺陷。rds_rm_zerocopy_callback() 在造成类型混淆的列表标头上使用 list_entry()。本地用户可通过 rds_message_put() 触发此漏洞。类型混淆导致“struct rds_msg_zcopy_info *info”实际上指向可能由本地用户控制的其他内容。触发此漏洞的方式已为用户所知，该漏洞将导致越界访问和锁定损坏。(CVE-2023-1078)

    在 Linux 内核的 Framebuffer 控制台 (fbcon) 中发现了一个缺陷。向 fbcon_set_font 提供大于 32 的 font->width 和 font->height 时，由于检查不到位，会发生 shift 越界，从而导致不明行为并可能导致拒绝服务。(CVE-2023-3161)

    drivers/nvmem/brcm_nvram.c 中的 brcm_nvram_parse 缺少对 kzalloc() 的返回值的检查，将导致空指针取消引用缺陷 (CVE-2023-3359)

    在 Linux 内核中，发现 vc_screen 中 drivers/tty/vt/vc_screen.c 的 vcs_read 存在一个释放后使用缺陷。如果攻击者具有本地用户访问权限，他们可利用此缺陷造成系统崩溃或泄露内核内部信息。(CVE-2023-3567)

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

    修复 __free_pages 中的 racy 检查造成的页面损坏 (CVE-2023-52739)

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

    cifs：修复 rdata->read_into_pages() 中的释放后使用 (CVE-2023-52741)

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

    xfrm/compat：阻止 xfrm_xlate32_attr() 中潜在的 spectre v1 小工具 (CVE-2023-52746)

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

    bpf跳过 backtrack_insn 中无效的 kfunc 调用CVE-2023-52928

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

    drm/i915修复潜在的 bit_17 双重释放 (CVE-2023-52930)

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

    drm/i915避免潜在的 vm 释放后使用 (CVE-2023-52931)

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

    mm/swapfile：在 get_swap_pages() 中添加 cond_resched() (CVE-2023-52932)

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

    Squashfs：修复 xattr_ids 计数的处理和健全性检查 (CVE-2023-52933)

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

    mm/MADV_COLLAPSEcatch !none !huge !bad pmd 查找 (CVE-2023-52934)

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

    mm/khugepaged修复 ->anon_vma 争用 (CVE-2023-52935)

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

    kernel/irq/irqdomain.c使用 debugfs_lookup() 修复内存泄漏 (CVE-2023-52936)

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

    HVhv_balloon修复使用 debugfs_lookup() 的内存泄漏 (CVE-2023-52937)

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

    mmmemcg修复 mem_cgroup_track_foreign_dirty_slowpath() 中的空指针 (CVE-2023-52939)

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

    mmmulti-gen LRU修复 cgroup 迁移期间发生的崩溃 (CVE-2023-52940)

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

    cgroup/cpuset修复 update_parent_subparts_cpumask() 中的错误检查 (CVE-2023-52942)

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

    vc_screen：移动 vcs_read() 中的结构 vc_data 指针加载以避免 UAF (CVE-2023-52973)

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

    efi修复 efi_mem_reserve_persistent 中潜在的空取消引用 (CVE-2023-52976)

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

    net: openvswitch：修复 ovs_flow_cmd_new 中的流内存泄漏问题 (CVE-2023-52977)

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

    squashfs：强化 squashfs_read_xattr_id_table 中健全性检查 (CVE-2023-52979)

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

    drm/i915修复错误捕获和 debugfs 转储期间的请求引用计数 (CVE-2023-52981)

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

    fscache使用 wait_on_bit() 等待释放已让渡的卷 (CVE-2023-52982)

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

    blockbfq修复 bic_set_bfqq() 中 bfqq 的 uafCVE-2023-52983

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

    bpfsockmap克隆侦听器时检查任何 tcp_bpf_prots (CVE-2023-52986)

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

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

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

  - ovl将 buf 灵活数组用于 memcpy() 目标 buf 灵活数组必须是 memcpy() 目标以避免来自最近的 FORTIFY_SOURCE 强化的误报运行时警告 memcpy
    检测到 fs/overlayfs/export.c:799大小 21中单个字段 &fh->fb 的字段跨度写入大小 93 (CVE-2022-49743)

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

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

  - 已修复 Linux 内核中的下列漏洞：configfs: fix a race in configfs_{,un}register_subsystem() When configfs_register_subsystem() or configfs_unregister_subsystem() is executing link_group() or unlink_group(), it is possible that two processes add or delete list concurrently. Some unfortunate interleavings of them can cause kernel panic. One of cases is: A --> B --> C --> D A <-- B <-- C <-- D delete list_head *B | delete list_head *C
    --------------------------------|----------------------------------- configfs_unregister_subsystem | configfs_unregister_subsystem unlink_group | unlink_group unlink_obj | unlink_obj list_del_init | list_del_init __list_del_entry | __list_del_entry __list_del | __list_del // next == C | next->prev = prev | | next->prev = prev prev->next = next | | // prev == B | prev->next = next Fix this by adding mutex when calling link_group() or unlink_group(), but parent configfs_subsystem is NULL when config_item is root. So I create a mutex configfs_subsystem_mutex. (CVE-2022-48931)

  - 已修复 Linux 内核中的下列漏洞：list: fix a data-race around ep->rdllist ep_poll() first calls ep_events_available() with no lock held and checks if ep->rdllist is empty by list_empty_careful(), which reads rdllist->prev. Thus all accesses to it need some protection to avoid store/load-tearing. Note INIT_LIST_HEAD_RCU() already has the annotation for both prev and next.
    Commit bf3b9f6372c4 (epoll: Add busy poll support to epoll with socket fds.) added the first lockless ep_events_available(), and commit c5a282e9635e (fs/epoll: reduce the scope of wq lock in epoll_wait()) made some ep_events_available() calls lockless and added single call under a lock, finally commit e59d3c64cba6 (epoll: eliminate unnecessary lock for zero timeout) made the last ep_events_available() lockless. BUG: KCSAN: data-race in do_epoll_wait / do_epoll_wait write to 0xffff88810480c7d8 of 8 bytes by task 1802 on cpu 0: INIT_LIST_HEAD include/linux/list.h:38 [inline] list_splice_init include/linux/list.h:492 [inline] ep_start_scan fs/eventpoll.c:622 [inline] ep_send_events fs/eventpoll.c:1656 [inline] ep_poll fs/eventpoll.c:1806 [inline] do_epoll_wait+0x4eb/0xf40 fs/eventpoll.c:2234 do_epoll_pwait fs/eventpoll.c:2268 [inline] __do_sys_epoll_pwait fs/eventpoll.c:2281 [inline] __se_sys_epoll_pwait+0x12b/0x240 fs/eventpoll.c:2275 __x64_sys_epoll_pwait+0x74/0x80 fs/eventpoll.c:2275 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x44/0xd0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae read to 0xffff88810480c7d8 of 8 bytes by task 1799 on cpu 1: list_empty_careful include/linux/list.h:329 [inline] ep_events_available fs/eventpoll.c:381 [inline] ep_poll fs/eventpoll.c:1797 [inline] do_epoll_wait+0x279/0xf40 fs/eventpoll.c:2234 do_epoll_pwait fs/eventpoll.c:2268 [inline] __do_sys_epoll_pwait fs/eventpoll.c:2281 [inline] __se_sys_epoll_pwait+0x12b/0x240 fs/eventpoll.c:2275 __x64_sys_epoll_pwait+0x74/0x80 fs/eventpoll.c:2275 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x44/0xd0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae value changed: 0xffff88810480c7d0 -> 0xffff888103c15098 Reported by Kernel Concurrency Sanitizer on: CPU: 1 PID: 1799 Comm: syz-fuzzer Tainted:
    G W 5.17.0-rc7-syzkaller-dirty #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 (CVE-2022-49443)

  - 已修复 Linux 内核中的下列漏洞：ima: Fix potential memory leak in ima_init_crypto() On failure to allocate the SHA1 tfm, IMA fails to initialize and exits without freeing the ima_algo_array. Add the missing kfree() for ima_algo_array to avoid the potential memory leak.
    (CVE-2022-49627)

  - 已修复 Linux 内核中的下列漏洞：tracing/histograms: Fix memory leak problem This reverts commit 46bbe5c671e06f070428b9be142cc4ee5cedebac. As commit 46bbe5c671e0 (tracing:
    fix double free) said, the double free problem reported by clang static analyzer is: > In parse_var_defs() if there is a problem allocating > var_defs.expr, the earlier var_defs.name is freed. > This free is duplicated by free_var_defs() which frees > the rest of the list. However, if there is a problem allocating N-th var_defs.expr: + in parse_var_defs(), the freed 'earlier var_defs.name' is actually the N-th var_defs.name; + then in free_var_defs(), the names from 0th to (N-1)-th are freed; IF ALLOCATING PROBLEM HAPPENED HERE!!! -+ \ | 0th 1th (N-1)-th N-th V +-------------+-------------+-----+-------------+----------- var_defs: | name | expr | name | expr | ... | name | expr | name | /// +-------------+-------------+-----+-------------+----------- These two frees don't act on same name, so there was no double free problem before. Conversely, after that commit, we get a memory leak problem because the above N-th var_defs.name is not freed. If enable CONFIG_DEBUG_KMEMLEAK and inject a fault at where the N-th var_defs.expr allocated, then execute on shell like: $ echo 'hist:key=call_site:val=$v1,$v2:v1=bytes_req,v2=bytes_alloc' > \ /sys/kernel/debug/tracing/events/kmem/kmalloc/trigger Then kmemleak reports: unreferenced object 0xffff8fb100ef3518 (size 8): comm bash, pid 196, jiffies 4295681690 (age 28.538s) hex dump (first 8 bytes): 76 31 00 00 b1 8f ff ff v1...... backtrace: [<0000000038fe4895>] kstrdup+0x2d/0x60 [<00000000c99c049a>] event_hist_trigger_parse+0x206f/0x20e0 [<00000000ae70d2cc>] trigger_process_regex+0xc0/0x110 [<0000000066737a4c>] event_trigger_write+0x75/0xd0 [<000000007341e40c>] vfs_write+0xbb/0x2a0 [<0000000087fde4c2>] ksys_write+0x59/0xd0 [<00000000581e9cdf>] do_syscall_64+0x3a/0x80 [<00000000cf3b065c>] entry_SYSCALL_64_after_hwframe+0x46/0xb0 (CVE-2022-49648)

  - 已修复 Linux 内核中的下列漏洞：linux/dim: Fix divide by 0 in RDMA DIM Fix a divide 0 error in rdma_dim_stats_compare() when prev->cpe_ratio == 0. CallTrace: Hardware name: H3C R4900 G3/RS33M2C9S, BIOS 2.00.37P21 03/12/2020 task: ffff880194b78000 task.stack: ffffc90006714000 RIP:
    0010:backport_rdma_dim+0x10e/0x240 [mlx_compat] RSP: 0018:ffff880c10e83ec0 EFLAGS: 00010202 RAX:
    0000000000002710 RBX: ffff88096cd7f780 RCX: 0000000000000064 RDX: 0000000000000000 RSI: 0000000000000002 RDI: 0000000000000001 RBP: 0000000000000001 R08: 0000000000000000 R09: 0000000000000000 R10:
    0000000000000000 R11: 0000000000000000 R12: 000000001d7c6c09 R13: ffff88096cd7f780 R14: ffff880b174fe800 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffff880c10e80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000a0965b00 CR3: 000000000200a003 CR4: 00000000007606e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6:
    00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: <IRQ> ib_poll_handler+0x43/0x80 [ib_core] irq_poll_softirq+0xae/0x110 __do_softirq+0xd1/0x28c irq_exit+0xde/0xf0 do_IRQ+0x54/0xe0 common_interrupt+0x8f/0x8f </IRQ> ? cpuidle_enter_state+0xd9/0x2a0 ? cpuidle_enter_state+0xc7/0x2a0 ? do_idle+0x170/0x1d0 ? cpu_startup_entry+0x6f/0x80 ? start_secondary+0x1b9/0x210 ? secondary_startup_64+0xa5/0xb0 Code: 0f 87 e1 00 00 00 8b 4c 24 14 44 8b 43 14 89 c8 4d 63 c8 44 29 c0 99 31 d0 29 d0 31 d2 48 98 48 8d 04 80 48 8d 04 80 48 c1 e0 02 <49> f7 f1 48 83 f8 0a 0f 86 c1 00 00 00 44 39 c1 7f 10 48 89 df RIP: backport_rdma_dim+0x10e/0x240 [mlx_compat] RSP: ffff880c10e83ec0 (CVE-2022-49670)

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

Rocky Linux 9.6 主机上存在安装的程序包，该程序包受到 TuxCare ALMALINUX9.6：CLSA-2026：1779434490公告中提及的多个漏洞的影响。

  - 已修复 Linux 内核中的下列漏洞：configfs: fix a race in configfs_{,un}register_subsystem() When configfs_register_subsystem() or configfs_unregister_subsystem() is executing link_group() or unlink_group(), it is possible that two processes add or delete list concurrently. Some unfortunate interleavings of them can cause kernel panic. One of cases is: A --> B --> C --> D A <-- B <-- C <-- D delete list_head *B | delete list_head *C
    --------------------------------|----------------------------------- configfs_unregister_subsystem | configfs_unregister_subsystem unlink_group | unlink_group unlink_obj | unlink_obj list_del_init | list_del_init __list_del_entry | __list_del_entry __list_del | __list_del // next == C | next->prev = prev | | next->prev = prev prev->next = next | | // prev == B | prev->next = next Fix this by adding mutex when calling link_group() or unlink_group(), but parent configfs_subsystem is NULL when config_item is root. So I create a mutex configfs_subsystem_mutex. (CVE-2022-48931)

  - 已修复 Linux 内核中的下列漏洞：list: fix a data-race around ep->rdllist ep_poll() first calls ep_events_available() with no lock held and checks if ep->rdllist is empty by list_empty_careful(), which reads rdllist->prev. Thus all accesses to it need some protection to avoid store/load-tearing. Note INIT_LIST_HEAD_RCU() already has the annotation for both prev and next.
    Commit bf3b9f6372c4 (epoll: Add busy poll support to epoll with socket fds.) added the first lockless ep_events_available(), and commit c5a282e9635e (fs/epoll: reduce the scope of wq lock in epoll_wait()) made some ep_events_available() calls lockless and added single call under a lock, finally commit e59d3c64cba6 (epoll: eliminate unnecessary lock for zero timeout) made the last ep_events_available() lockless. BUG: KCSAN: data-race in do_epoll_wait / do_epoll_wait write to 0xffff88810480c7d8 of 8 bytes by task 1802 on cpu 0: INIT_LIST_HEAD include/linux/list.h:38 [inline] list_splice_init include/linux/list.h:492 [inline] ep_start_scan fs/eventpoll.c:622 [inline] ep_send_events fs/eventpoll.c:1656 [inline] ep_poll fs/eventpoll.c:1806 [inline] do_epoll_wait+0x4eb/0xf40 fs/eventpoll.c:2234 do_epoll_pwait fs/eventpoll.c:2268 [inline] __do_sys_epoll_pwait fs/eventpoll.c:2281 [inline] __se_sys_epoll_pwait+0x12b/0x240 fs/eventpoll.c:2275 __x64_sys_epoll_pwait+0x74/0x80 fs/eventpoll.c:2275 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x44/0xd0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae read to 0xffff88810480c7d8 of 8 bytes by task 1799 on cpu 1: list_empty_careful include/linux/list.h:329 [inline] ep_events_available fs/eventpoll.c:381 [inline] ep_poll fs/eventpoll.c:1797 [inline] do_epoll_wait+0x279/0xf40 fs/eventpoll.c:2234 do_epoll_pwait fs/eventpoll.c:2268 [inline] __do_sys_epoll_pwait fs/eventpoll.c:2281 [inline] __se_sys_epoll_pwait+0x12b/0x240 fs/eventpoll.c:2275 __x64_sys_epoll_pwait+0x74/0x80 fs/eventpoll.c:2275 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x44/0xd0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae value changed: 0xffff88810480c7d0 -> 0xffff888103c15098 Reported by Kernel Concurrency Sanitizer on: CPU: 1 PID: 1799 Comm: syz-fuzzer Tainted:
    G W 5.17.0-rc7-syzkaller-dirty #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 (CVE-2022-49443)

  - 已修复 Linux 内核中的下列漏洞：ima: Fix potential memory leak in ima_init_crypto() On failure to allocate the SHA1 tfm, IMA fails to initialize and exits without freeing the ima_algo_array. Add the missing kfree() for ima_algo_array to avoid the potential memory leak.
    (CVE-2022-49627)

  - 已修复 Linux 内核中的下列漏洞：tracing/histograms: Fix memory leak problem This reverts commit 46bbe5c671e06f070428b9be142cc4ee5cedebac. As commit 46bbe5c671e0 (tracing:
    fix double free) said, the double free problem reported by clang static analyzer is: > In parse_var_defs() if there is a problem allocating > var_defs.expr, the earlier var_defs.name is freed. > This free is duplicated by free_var_defs() which frees > the rest of the list. However, if there is a problem allocating N-th var_defs.expr: + in parse_var_defs(), the freed 'earlier var_defs.name' is actually the N-th var_defs.name; + then in free_var_defs(), the names from 0th to (N-1)-th are freed; IF ALLOCATING PROBLEM HAPPENED HERE!!! -+ \ | 0th 1th (N-1)-th N-th V +-------------+-------------+-----+-------------+----------- var_defs: | name | expr | name | expr | ... | name | expr | name | /// +-------------+-------------+-----+-------------+----------- These two frees don't act on same name, so there was no double free problem before. Conversely, after that commit, we get a memory leak problem because the above N-th var_defs.name is not freed. If enable CONFIG_DEBUG_KMEMLEAK and inject a fault at where the N-th var_defs.expr allocated, then execute on shell like: $ echo 'hist:key=call_site:val=$v1,$v2:v1=bytes_req,v2=bytes_alloc' > \ /sys/kernel/debug/tracing/events/kmem/kmalloc/trigger Then kmemleak reports: unreferenced object 0xffff8fb100ef3518 (size 8): comm bash, pid 196, jiffies 4295681690 (age 28.538s) hex dump (first 8 bytes): 76 31 00 00 b1 8f ff ff v1...... backtrace: [<0000000038fe4895>] kstrdup+0x2d/0x60 [<00000000c99c049a>] event_hist_trigger_parse+0x206f/0x20e0 [<00000000ae70d2cc>] trigger_process_regex+0xc0/0x110 [<0000000066737a4c>] event_trigger_write+0x75/0xd0 [<000000007341e40c>] vfs_write+0xbb/0x2a0 [<0000000087fde4c2>] ksys_write+0x59/0xd0 [<00000000581e9cdf>] do_syscall_64+0x3a/0x80 [<00000000cf3b065c>] entry_SYSCALL_64_after_hwframe+0x46/0xb0 (CVE-2022-49648)

  - 已修复 Linux 内核中的下列漏洞：linux/dim: Fix divide by 0 in RDMA DIM Fix a divide 0 error in rdma_dim_stats_compare() when prev->cpe_ratio == 0. CallTrace: Hardware name: H3C R4900 G3/RS33M2C9S, BIOS 2.00.37P21 03/12/2020 task: ffff880194b78000 task.stack: ffffc90006714000 RIP:
    0010:backport_rdma_dim+0x10e/0x240 [mlx_compat] RSP: 0018:ffff880c10e83ec0 EFLAGS: 00010202 RAX:
    0000000000002710 RBX: ffff88096cd7f780 RCX: 0000000000000064 RDX: 0000000000000000 RSI: 0000000000000002 RDI: 0000000000000001 RBP: 0000000000000001 R08: 0000000000000000 R09: 0000000000000000 R10:
    0000000000000000 R11: 0000000000000000 R12: 000000001d7c6c09 R13: ffff88096cd7f780 R14: ffff880b174fe800 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffff880c10e80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000a0965b00 CR3: 000000000200a003 CR4: 00000000007606e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6:
    00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: <IRQ> ib_poll_handler+0x43/0x80 [ib_core] irq_poll_softirq+0xae/0x110 __do_softirq+0xd1/0x28c irq_exit+0xde/0xf0 do_IRQ+0x54/0xe0 common_interrupt+0x8f/0x8f </IRQ> ? cpuidle_enter_state+0xd9/0x2a0 ? cpuidle_enter_state+0xc7/0x2a0 ? do_idle+0x170/0x1d0 ? cpu_startup_entry+0x6f/0x80 ? start_secondary+0x1b9/0x210 ? secondary_startup_64+0xa5/0xb0 Code: 0f 87 e1 00 00 00 8b 4c 24 14 44 8b 43 14 89 c8 4d 63 c8 44 29 c0 99 31 d0 29 d0 31 d2 48 98 48 8d 04 80 48 8d 04 80 48 c1 e0 02 <49> f7 f1 48 83 f8 0a 0f 86 c1 00 00 00 44 39 c1 7f 10 48 89 df RIP: backport_rdma_dim+0x10e/0x240 [mlx_compat] RSP: ffff880c10e83ec0 (CVE-2022-49670)

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

远程主机上安装的内核版本低于 5.15.93-55.139。因此，会受到 ALAS2KERNEL-5.15-2024-037 公告中提及的多个漏洞影响。

    在 Linux 内核的第 2 层隧道协议 (L2TP) 中发现了一个缺陷。清除 sk_user_data 时缺少的锁定可导致争用条件和空指针取消引用。本地用户可能利用此缺陷来导致系统崩溃，从而发起拒绝服务攻击。(CVE-2022-4129)

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

    cpufreqgovernor使用 kobject release() 方法释放 dbs_data (CVE-2022-49513)

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

    ovl将 buf 灵活数组用于 memcpy() 目标 (CVE-2022-49743)

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

    perf/x86/amd修复位移 int 时的潜在整数溢出 (CVE-2022-49748)

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

    设备属性修复 fwnode_graph_get_next_endpoint() 中的节点引用计数泄漏 (CVE-2022-49752)

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

    dmaengine：修复 dma_chan_get() 中 client_count 的双倍递增 (CVE-2022-49753)

    在 Linux 内核中发现了一个缺陷。在用户将 capable 文件从一个 nosuid 挂载分区复制到另一个挂载分区时，在 Linux 内核的 OverlayFS 子系统中发现使用 capabilities 未经授权访问 setuid 文件执行的情况。本地用户可利用此 uid 映射错误来提升其系统权限。(CVE-2023-0386)

    在 Linux 内核的人机接口设备 (HID) 子系统中，发现用户插入恶意 USB 设备的方式存在内存损坏缺陷。本地用户可利用此缺陷导致系统崩溃或可能升级其系统权限。(CVE-2023-1073)

    在 Linux 内核的 NFS 文件系统中，在 fs/nfsd/nfs4proc.c 中的 nfsd4_ssc_setup_dul 发现了一个释放后使用缺陷。此问题允许本地攻击者造成系统崩溃或可能导致内核信息泄露问题。(CVE-2023-1652)

    在 Linux 内核 6.0.8 中，在 fs/fs-writeback.c 的 inode_cgwb_move_to_attached 中有一个与 __list_del_entry_valid 相关的释放后使用缺陷。(CVE-2023-26605)

    在 Linux 内核的 Framebuffer 控制台 (fbcon) 中发现了一个缺陷。向 fbcon_set_font 提供大于 32 的 font->width 和 font->height 时，由于检查不到位，会发生 shift 越界，从而导致不明行为并可能导致拒绝服务。(CVE-2023-3161)

    在 Linux 内核中，发现 vc_screen 中 drivers/tty/vt/vc_screen.c 的 vcs_read 存在一个释放后使用缺陷。如果攻击者具有本地用户访问权限，他们可利用此缺陷造成系统崩溃或泄露内核内部信息。(CVE-2023-3567)

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

    bpf跳过 backtrack_insn 中无效的 kfunc 调用CVE-2023-52928

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

    drm/i915修复潜在的 bit_17 双重释放 (CVE-2023-52930)

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

    mm/swapfile在 get_swap_pages() 中添加 cond_resched() (CVE-2023-52932)

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

    Squashfs修复 xattr_ids 计数的处理和健全性检查 (CVE-2023-52933)

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

    kernel/irq/irqdomain.c使用 debugfs_lookup() 修复内存泄漏 (CVE-2023-52936)

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

    vc_screen：移动 vcs_read() 中的结构 vc_data 指针加载以避免 UAF (CVE-2023-52973)

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

    efi修复 efi_mem_reserve_persistent 中潜在的空取消引用 (CVE-2023-52976)

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

    netopenvswitch修复 ovs_flow_cmd_new 中的流内存泄漏 (CVE-2023-52977)

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

    squashfs强化 squashfs_read_xattr_id_table 中健全性检查 (CVE-2023-52979)

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

    blockbfq修复 bic_set_bfqq() 中 bfqq 的 uafCVE-2023-52983

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

    bpfsockmap克隆侦听器时检查任何 tcp_bpf_prots (CVE-2023-52986)

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

    net修复 skb_segment_list 中的空指针 (CVE-2023-52991)

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

    bpf跳过 send_signal_common() 中 pid=1 的任务 (CVE-2023-52992)

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

    x86/i8259以 IRQ_LEVEL 标记旧版 PIC 中断 (CVE-2023-52993)

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

    ipv4阻止 fib_metrics_match() 中潜在的 spectre v1 小工具 (CVE-2023-52996)

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

    ipv4阻止 ip_metrics_convert() 中潜在的 spectre v1 小工具 (CVE-2023-52997)

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

    net修复 netns ops 注册错误路径中的 UaF (CVE-2023-52999)

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

    netlink阻止潜在的 spectre v1 小工具 (CVE-2023-53000)

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

    cifs修复因重新连接中未清除 server->smbd_conn 所导致的 oops (CVE-2023-53006)

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

    tracing确保 trace_printk() 在可以使用时可以输出 (CVE-2023-53007)

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

    netmdio验证 mdiobus_get_phy() 中的参数地址 (CVE-2023-53019)

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

    net/schedsch_taprio修复可能的释放后使用 (CVE-2023-53021)

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

    bpf修复因推测存储绕过缓解措施不充分而造成的指针泄漏 (CVE-2023-53024)

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

    NFSD修复 nfsd4_ssc_setup_dul() 中的释放后使用 (CVE-2023-53025)

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

    RDMA/core修复 ib 块迭代器计数器溢出 (CVE-2023-53026)

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

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

远程 Debian 11 主机上存在安装的程序包该程序包受到 dla-4475 公告中提及的多个漏洞的影响。

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

    程序包：linux 版本：5.10.249-1 CVE ID：CVE-2022-48744 CVE-2022-49168 CVE-2022-49465 CVE-2022-49711 CVE-2022-49743 CVE-2023-52975 CVE-2023-54207 CVE-2023-54321 CVE-2024-36903 CVE-2024-36927 CVE-2025-22022 CVE-2025-22121 CVE-2025-37830 CVE-2025-38022 CVE-2025-38119 CVE-2025-38556 CVE-2025-38591 CVE-2025-39702 CVE-2025-40110 CVE-2025-40215 CVE-2025-68211 CVE-2025-68255 CVE-2025-68257 CVE-2025-68258 CVE-2025-68261 CVE-2025-68264 CVE-2025-68266 CVE-2025-68282 CVE-2025-68325 CVE-2025-68332 CVE-2025-68336 CVE-2025-68337 CVE-2025-68344 CVE-2025-68346 CVE-2025-68349 CVE-2025-68354 CVE-2025-68362 CVE-2025-68364 CVE-2025-68366 CVE-2025-68367 CVE-2025-68372 CVE-2025-68724 CVE-2025-68725 CVE-2025-68733 CVE-2025-68740 CVE-2025-68757 CVE-2025-68758 CVE-2025-68759 CVE-2025-68764 CVE-2025-68767 CVE-2025-68769 CVE-2025-68771 CVE-2025-68773 CVE-2025-68774 CVE-2025-68776 CVE-2025-68777 CVE-2025-68782 CVE-2025-68783 CVE-2025-68785 CVE-2025-68787 CVE-2025-68788 CVE-2025-68795 CVE-2025-68796 CVE-2025-68797 CVE-2025-68799 CVE-2025-68800 CVE-2025-68801 CVE-2025-68803 CVE-2025-68804 CVE-2025-68808 CVE-2025-68813 CVE-2025-68815 CVE-2025-68816 CVE-2025-68818 CVE-2025-68819 CVE-2025-68820 CVE-2025-71064 CVE-2025-71066 CVE-2025-71069 CVE-2025-71075 CVE-2025-71077 CVE-2025-71079 CVE-2025-71084 CVE-2025-71085 CVE-2025-71086 CVE-2025-71087 CVE-2025-71091 CVE-2025-71093 CVE-2025-71096 CVE-2025-71097 CVE-2025-71098 CVE-2025-71102 CVE-2025-71104 CVE-2025-71105 CVE-2025-71108 CVE-2025-71111 CVE-2025-71112 CVE-2025-71113 CVE-2025-71114 CVE-2025-71116 CVE-2025-71118 CVE-2025-71120 CVE-2025-71123 CVE-2025-71125 CVE-2025-71127 CVE-2025-71131 CVE-2025-71136 CVE-2025-71137 CVE-2025-71154 CVE-2025-71162 CVE-2025-71182 CVE-2025-71185 CVE-2025-71186 CVE-2025-71190 CVE-2025-71191 CVE-2025-71194 CVE-2025-71196 CVE-2025-71197 CVE-2025-71199 CVE-2026-22976 CVE-2026-22977 CVE-2026-22978 CVE-2026-22980 CVE-2026-22990 CVE-2026-22991 CVE-2026-22997 CVE-2026-22998 CVE-2026-22999 CVE-2026-23001 CVE-2026-23003 CVE-2026-23011 CVE-2026-23020 CVE-2026-23021 CVE-2026-23033 CVE-2026-23038 CVE-2026-23047 CVE-2026-23049 CVE-2026-23056 CVE-2026-23058 CVE-2026-23060 CVE-2026-23061 CVE-2026-23063 CVE-2026-23064 CVE-2026-23071 CVE-2026-23073 CVE-2026-23074 CVE-2026-23075 CVE-2026-23076 CVE-2026-23080 CVE-2026-23083 CVE-2026-23084 CVE-2026-23085 CVE-2026-23087 CVE-2026-23089 CVE-2026-23090 CVE-2026-23091 CVE-2026-23095 CVE-2026-23096 CVE-2026-23097 CVE-2026-23098 CVE-2026-23101 CVE-2026-23103 CVE-2026-23105 CVE-2026-23108 CVE-2026-23110 Debian 缺陷：1122193 1123750

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

    对于 Debian 11 bullseye，已在 5.10.249-1 版本中修复这些问题。此更新还修复报告给 Debian 的多个错误，
    此外它还包括稳定更新 5.10.248 和 5.10.249中提供的更多缺陷补丁。

    建议您升级 linux 程序包。

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

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

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

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

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

  - 已修复 Linux 内核中的下列漏洞：net: amd-xgbe: Fix skb data length underflow There will be BUG_ON() triggered in include/linux/skbuff.h leading to intermittent kernel panic, when the skb length underflow is detected. Fix this by dropping the packet if such length underflows are seen because of inconsistencies in the hardware descriptors. (CVE-2022-48743)

  - 已修复 Linux 内核中的下列漏洞：net: bcmgenet: Use stronger register read/writes to assure ordering GCC12 appears to be much smarter about its dependency tracking and is aware that the relaxed variants are just normal loads and stores and this is causing problems like: [210.074549] ------------[ cut here ]------------ [ 210.079223] NETDEV WATCHDOG: enabcm6e4ei0 (bcmgenet):
    transmit queue 1 timed out [ 210.086717] WARNING: CPU: 1 PID: 0 at net/sched/sch_generic.c:529 dev_watchdog+0x234/0x240 [ 210.095044] Modules linked in: genet(E) nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat] [ 210.146561] ACPI CPPC: PCC check channel failed for ss: 0. ret=-110 [ 210.146927] CPU: 1 PID: 0 Comm: swapper/1 Tainted: G E 5.17.0-rc7G12+ #58 [ 210.153226] CPPC Cpufreq:cppc_scale_freq_workfn: failed to read perf counters [210.161349] Hardware name: Raspberry Pi Foundation Raspberry Pi 4 Model B/Raspberry Pi 4 Model B, BIOS EDK2-DEV 02/08/2022 [ 210.161353] pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [210.161358] pc : dev_watchdog+0x234/0x240 [ 210.161364] lr : dev_watchdog+0x234/0x240 [ 210.161368] sp :
    ffff8000080a3a40 [ 210.161370] x29: ffff8000080a3a40 x28: ffffcd425af87000 x27: ffff8000080a3b20 [210.205150] x26: ffffcd425aa00000 x25: 0000000000000001 x24: ffffcd425af8ec08 [ 210.212321] x23:
    0000000000000100 x22: ffffcd425af87000 x21: ffff55b142688000 [ 210.219491] x20: 0000000000000001 x19:
    ffff55b1426884c8 x18: ffffffffffffffff [ 210.226661] x17: 64656d6974203120 x16: 0000000000000001 x15:
    6d736e617274203a [ 210.233831] x14: 2974656e65676d63 x13: ffffcd4259c300d8 x12: ffffcd425b07d5f0 [210.241001] x11: 00000000ffffffff x10: ffffcd425b07d5f0 x9 : ffffcd4258bdad9c [ 210.248171] x8 :
    00000000ffffdfff x7 : 000000000000003f x6 : 0000000000000000 [ 210.255341] x5 : 0000000000000000 x4 :
    0000000000000000 x3 : 0000000000001000 [ 210.262511] x2 : 0000000000001000 x1 : 0000000000000005 x0 :
    0000000000000044 [ 210.269682] Call trace: [ 210.272133] dev_watchdog+0x234/0x240 [ 210.275811] call_timer_fn+0x3c/0x15c [ 210.279489] __run_timers.part.0+0x288/0x310 [ 210.283777] run_timer_softirq+0x48/0x80 [ 210.287716] __do_softirq+0x128/0x360 [ 210.291392]
    __irq_exit_rcu+0x138/0x140 [ 210.295243] irq_exit_rcu+0x1c/0x30 [ 210.298745] el1_interrupt+0x38/0x54 [210.302334] el1h_64_irq_handler+0x18/0x24 [ 210.306445] el1h_64_irq+0x7c/0x80 [ 210.309857] arch_cpu_idle+0x18/0x2c [ 210.313445] default_idle_call+0x4c/0x140 [ 210.317470] cpuidle_idle_call+0x14c/0x1a0 [ 210.321584] do_idle+0xb0/0x100 [ 210.324737] cpu_startup_entry+0x30/0x8c [210.328675] secondary_start_kernel+0xe4/0x110 [ 210.333138] __secondary_switched+0x94/0x98 The assumption when these were relaxed seems to be that device memory would be mapped non reordering, and that other constructs (spinlocks/etc) would provide the barriers to assure that packet data and in memory rings/queues were ordered with respect to device register reads/writes. This itself seems a bit sketchy, but the real problem with GCC12 is that it is moving the actual reads/writes around at will as though they were independent operations when in truth they are not, but the compiler can't know that. When looking at the assembly dumps for many of these routines its possible to see very clean, but not strictly in program order operations occurring as the compiler would be free to do if these weren't actually register reads/write operations. Its possible to suppress the timeout with a liberal bit of dma_mb()'s sprinkled around but the device still seems unable to reliably send/receive data. A better plan is to use the safer readl/writel everywhere. Since this partially reverts an older commit, which notes the use of the relaxed variants for performance reasons. I would suggest that any performance problems ---truncated--- (CVE-2022-49194)

  - 已修复 Linux 内核中的下列漏洞：ima: Fix a potential integer overflow in ima_appraise_measurement When the ima-modsig is enabled, the rc passed to evm_verifyxattr() may be negative, which may cause the integer overflow problem. (CVE-2022-49643)

  - 已修复 Linux 内核中的下列漏洞：ovl: Use buf flexible array for memcpy() destination The buf flexible array needs to be the memcpy() destination to avoid false positive run-time warning from the recent FORTIFY_SOURCE hardening: memcpy: detected field-spanning write (size 93) of single field &fh->fb at fs/overlayfs/export.c:799 (size 21) (CVE-2022-49743)

  - 已修复 Linux 内核中的下列漏洞：kprobes: Skip clearing aggrprobe's post_handler in kprobe-on-ftrace case In __unregister_kprobe_top(), if the currently unregistered probe has post_handler but other child probes of the aggrprobe do not have post_handler, the post_handler of the aggrprobe is cleared. If this is a ftrace-based probe, there is a problem. In later calls to disarm_kprobe(), we will use kprobe_ftrace_ops because post_handler is NULL. But we're armed with kprobe_ipmodify_ops. This triggers a WARN in __disarm_kprobe_ftrace() and may even cause use-after-free:
    Failed to disarm kprobe-ftrace at kernel_clone+0x0/0x3c0 (error -2) WARNING: CPU: 5 PID: 137 at kernel/kprobes.c:1135 __disarm_kprobe_ftrace.isra.21+0xcf/0xe0 Modules linked in: testKprobe_007(-) CPU: 5 PID: 137 Comm: rmmod Not tainted 6.1.0-rc4-dirty #18 [...] Call Trace: <TASK> __disable_kprobe+0xcd/0xe0
    __unregister_kprobe_top+0x12/0x150 ? mutex_lock+0xe/0x30 unregister_kprobes.part.23+0x31/0xa0 unregister_kprobe+0x32/0x40 __x64_sys_delete_module+0x15e/0x260 ? do_user_addr_fault+0x2cd/0x6b0 do_syscall_64+0x3a/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd [...] For the kprobe-on-ftrace case, we keep the post_handler setting to identify this aggrprobe armed with kprobe_ipmodify_ops. This way we can disarm it correctly. (CVE-2022-49779)

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

ID	名称	产品	系列	发布时间	最近更新时间	严重程度
173140	Amazon Linux 2023：bpftool、kernel、kernel-devel (ALAS2023-2023-132)	Nessus	Amazon Linux Local Security Checks	2023/3/21	2026/2/24	high
244911	Linux Distros 未修补的漏洞：CVE-2022-49743	Nessus	Misc.	2025/8/7	2026/10/31	medium
360724	AlmaLinux 9.6 [TuxCare] 安全更新：kernel / kernel-abi-stablelists / kernel-core / 等多个漏洞（ALMALINUX9.6：CLSA-2026：1779434490）	Nessus	Alma Linux Local Security Checks	2026/10/1	2026/10/2	high
360889	Rocky Linux 9.6 [TuxCare] 安全更新：kernel / kernel-abi-stablelists / kernel-core / 等多个漏洞（ALMALINUX9.6：CLSA-2026：1779434490）	Nessus	Rocky Linux Local Security Checks	2026/10/1	2026/10/2	high
190056	Amazon Linux 2：内核 (ALASKERNEL-5.15-2024-037)	Nessus	Amazon Linux Local Security Checks	2024/2/6	2026/2/26	high
298680	Debian dla-4475ata-modules-5.10.0-35-armmp-di - 安全更新	Nessus	Debian Local Security Checks	2026/2/11	2026/3/23	high
353122	AlmaLinux 9.2 [TuxCare] 安全更新：bpftool / kernel / kernel-64k / kernel-64k-core / kernel-64k-debug 等多个漏洞（ALMALINUX9.2：CLSA-2026：1779375889）	Nessus	Alma Linux Local Security Checks	2026/9/30	2026/10/21	high

检测

插件搜索

high

medium

high

high

high

high

high