远程主机上安装的内核版本低于 4.14.287-215.504。因此，该软件受到 ALAS2-2022-1825 公告中提及的多个漏洞影响。

    Linux 的 net/rose/rose_timer.c 中存在由定时器处理程序造成的释放后使用漏洞，攻击者可在没有任何特权的情况下造成 Linux 内核崩溃。(CVE-2022-2318)

    Linux 磁盘/网卡前端数据泄露 [其 CNA 信息记录与多个 CVE 有关；文本说明了哪些方面/漏洞与哪些 CVE 对应。] Linux Block 和 Network PV 设备前端未将内存区域归零便与后端共享此区域（CVE-2022-26365、CVE-2022-33740）。
    此外，授权表的粒度不允许共享小于 4K 的页面，因为与后端共享的数据也可以被此后端访问，因而这可以导致不相关的数据驻留在同一 4K 页面中（CVE-2022-33741、CVE-2022-33742）。(CVE-2022-26365)

    Linux 磁盘/网卡前端数据泄露 [其 CNA 信息记录与多个 CVE 有关；文本说明了哪些方面/漏洞与哪些 CVE 对应。] Linux Block 和 Network PV 设备前端未将内存区域归零便与后端共享此区域（CVE-2022-26365、CVE-2022-33740）。
    此外，授权表的粒度不允许共享小于 4K 的页面，因为与后端共享的数据也可以被此后端访问，因而这可以导致不相关的数据驻留在同一 4K 页面中（CVE-2022-33741、CVE-2022-33742）。(CVE-2022-33740)

    Linux 磁盘/网卡前端数据泄露 [其 CNA 信息记录与多个 CVE 有关；文本说明了哪些方面/漏洞与哪些 CVE 对应。] Linux Block 和 Network PV 设备前端未将内存区域归零便与后端共享此区域（CVE-2022-26365、CVE-2022-33740）。
    此外，授权表的粒度不允许共享小于 4K 的页面，因为与后端共享的数据也可以被此后端访问，因而这可以导致不相关的数据驻留在同一 4K 页面中（CVE-2022-33741、CVE-2022-33742）。(CVE-2022-33741)

    Linux 磁盘/网卡前端数据泄露 [其 CNA 信息记录与多个 CVE 有关；文本说明了哪些方面/漏洞与哪些 CVE 对应。] Linux Block 和 Network PV 设备前端未将内存区域归零便与后端共享此区域（CVE-2022-26365、CVE-2022-33740）。
    此外，授权表的粒度不允许共享小于 4K 的页面，因为与后端共享的数据也可以被此后端访问，因而这可以导致不相关的数据驻留在同一 4K 页面中（CVE-2022-33741、CVE-2022-33742）。(CVE-2022-33742)

    Arm 客户机可通过 PV 设备造成 Dom0 DoS。在 Arm 上映射客户机页面时，dom0 会使用 rbtree 来跟踪外部映射。该 rbtree 的更新并非总是在保留相关锁定的情况下全部完成，这会导致短时争用窗口，非特权客户机可借此通过 PV 设备造成 rbtree 不一致。这些不一致可导致 dom0 拒绝服务 (DoS)，例如造成崩溃或无法执行其他客户机内存页面的进一步映射。(CVE-2022-33744)

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

    net：bonding：修复 802.3ad 从属取消绑定之后的释放后使用问题 (CVE-2022-49667)

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

    dm raid：修复 raid5_add_disks 中的 KASAN 警告 (CVE-2022-49673)

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

    dm raid：修复超出 raid 成员数组末尾的访问 (CVE-2022-49674)

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

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

远程主机上安装的内核版本低于 5.4.204-113.362。因此，会受到 ALAS2KERNEL-5.4-2022-033 公告中提及的多个漏洞影响。

    Linux 磁盘/网卡前端数据泄露 [其 CNA 信息记录与多个 CVE 有关；文本说明了哪些方面/漏洞与哪些 CVE 对应。] Linux Block 和 Network PV 设备前端未将内存区域归零便与后端共享此区域（CVE-2022-26365、CVE-2022-33740）。
    此外，授权表的粒度不允许共享小于 4K 的页面，因为与后端共享的数据也可以被此后端访问，因而这可以导致不相关的数据驻留在同一 4K 页面中（CVE-2022-33741、CVE-2022-33742）。(CVE-2022-26365)

    Linux 磁盘/网卡前端数据泄露 [其 CNA 信息记录与多个 CVE 有关；文本说明了哪些方面/漏洞与哪些 CVE 对应。] Linux Block 和 Network PV 设备前端未将内存区域归零便与后端共享此区域（CVE-2022-26365、CVE-2022-33740）。
    此外，授权表的粒度不允许共享小于 4K 的页面，因为与后端共享的数据也可以被此后端访问，因而这可以导致不相关的数据驻留在同一 4K 页面中（CVE-2022-33741、CVE-2022-33742）。(CVE-2022-33740)

    Linux 磁盘/网卡前端数据泄露 [其 CNA 信息记录与多个 CVE 有关；文本说明了哪些方面/漏洞与哪些 CVE 对应。] Linux Block 和 Network PV 设备前端未将内存区域归零便与后端共享此区域（CVE-2022-26365、CVE-2022-33740）。
    此外，授权表的粒度不允许共享小于 4K 的页面，因为与后端共享的数据也可以被此后端访问，因而这可以导致不相关的数据驻留在同一 4K 页面中（CVE-2022-33741、CVE-2022-33742）。(CVE-2022-33741)

    Linux 磁盘/网卡前端数据泄露 [其 CNA 信息记录与多个 CVE 有关；文本说明了哪些方面/漏洞与哪些 CVE 对应。] Linux Block 和 Network PV 设备前端未将内存区域归零便与后端共享此区域（CVE-2022-26365、CVE-2022-33740）。
    此外，授权表的粒度不允许共享小于 4K 的页面，因为与后端共享的数据也可以被此后端访问，因而这可以导致不相关的数据驻留在同一 4K 页面中（CVE-2022-33741、CVE-2022-33742）。(CVE-2022-33742)

    Arm 客户机可通过 PV 设备造成 Dom0 DoS。在 Arm 上映射客户机页面时，dom0 会使用 rbtree 来跟踪外部映射。该 rbtree 的更新并非总是在保留相关锁定的情况下全部完成，这会导致短时争用窗口，非特权客户机可借此通过 PV 设备造成 rbtree 不一致。这些不一致可导致 dom0 拒绝服务 (DoS)，例如造成崩溃或无法执行其他客户机内存页面的进一步映射。(CVE-2022-33744)

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

    net：bonding：修复 802.3ad 从属取消绑定之后的释放后使用问题 (CVE-2022-49667)

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

    linux/dim修复 RDMA DIM 中的除以 0 错误CVE-2022-49670

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

    nettun破坏时取消 NAPI 与设备的链接 (CVE-2022-49672)

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

    dm raid：修复 raid5_add_disks 中的 KASAN 警告 (CVE-2022-49673)

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

    dm raid修复超出 raid 成员数组末尾的访问 (CVE-2022-49674)

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

    virtio_net：修复暂停/恢复之后的 xdp_rxq_info 缺陷 (CVE-2022-49687)

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

    afs修复动态根 getattrCVE-2022-49688

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

    erspan：不假设始终设置传输标头 (CVE-2022-49691)

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

    bpf修复 sk 查找帮助程序中的 request_sock 泄漏 (CVE-2022-49697)

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

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

远程 Redhat Enterprise Linux 8 主机上安装的程序包受到 RHSA-2026:6961 公告中提及的多个漏洞的影响。

    内核程序包中包含 Linux 内核，后者是任何 Linux 操作系统的核心。

    安全修复：

    * kernelLinux 内核Device Mapper RAID 越界访问 (CVE-2022-49674)

    * kernelLinux 内核ATM 子系统中的释放后使用漏洞 (CVE-2025-38180)

    * kernel: Linux 内核：修复 br_multicast_port_ctx_init 中网桥多播的释放后使用 (CVE-2025-38248)

    * kernelmacvlan修复 macvlan_common_newlink() 中的错误恢复 (CVE-2026-23209)

    有关上述安全问题的更多详细信息，包括其影响、CVSS 得分、致谢，以及其他相关信息，请参阅列于“参考”部分的 CVE 页面。

Tenable 已直接从 Red Hat Enterprise Linux 安全公告中提取上述描述块。

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

CentOS Linux 8.5 主机上存在安装的程序包，该程序包受到 TuxCare CENTOS8.5：CLSA-2026：U 1771077729公告中提及的多个漏洞的影响。

  - 已修复 Linux 内核中的下列漏洞：pid: take a reference when initializing `cad_pid` During boot, kernel_init_freeable() initializes `cad_pid` to the init task's struct pid. Later on, we may change `cad_pid` via a sysctl, and when this happens proc_do_cad_pid() will increment the refcount on the new pid via get_pid(), and will decrement the refcount on the old pid via put_pid(). As we never called get_pid() when we initialized `cad_pid`, we decrement a reference we never incremented, can therefore free the init task's struct pid early. As there can be dangling references to the struct pid, we can later encounter a use-after-free (e.g. when delivering signals). This was spotted when fuzzing v5.13-rc3 with Syzkaller, but seems to have been around since the conversion of `cad_pid` to struct pid in commit 9ec52099e4b8 ([PATCH] replace cad_pid by a struct pid) from the pre-KASAN stone age of v2.6.19. Fix this by getting a reference to the init task's struct pid when we assign it to `cad_pid`.
    Full KASAN splat below. ================================================================== BUG: KASAN:
    use-after-free in ns_of_pid include/linux/pid.h:153 [inline] BUG: KASAN: use-after-free in task_active_pid_ns+0xc0/0xc8 kernel/pid.c:509 Read of size 4 at addr ffff23794dda0004 by task syz-executor.0/273 CPU: 1 PID: 273 Comm: syz-executor.0 Not tainted 5.12.0-00001-g9aef892b2d15 #1 Hardware name: linux,dummy-virt (DT) Call trace: ns_of_pid include/linux/pid.h:153 [inline] task_active_pid_ns+0xc0/0xc8 kernel/pid.c:509 do_notify_parent+0x308/0xe60 kernel/signal.c:1950 exit_notify kernel/exit.c:682 [inline] do_exit+0x2334/0x2bd0 kernel/exit.c:845 do_group_exit+0x108/0x2c8 kernel/exit.c:922 get_signal+0x4e4/0x2a88 kernel/signal.c:2781 do_signal arch/arm64/kernel/signal.c:882 [inline] do_notify_resume+0x300/0x970 arch/arm64/kernel/signal.c:936 work_pending+0xc/0x2dc Allocated by task 0: slab_post_alloc_hook+0x50/0x5c0 mm/slab.h:516 slab_alloc_node mm/slub.c:2907 [inline] slab_alloc mm/slub.c:2915 [inline] kmem_cache_alloc+0x1f4/0x4c0 mm/slub.c:2920 alloc_pid+0xdc/0xc00 kernel/pid.c:180 copy_process+0x2794/0x5e18 kernel/fork.c:2129 kernel_clone+0x194/0x13c8 kernel/fork.c:2500 kernel_thread+0xd4/0x110 kernel/fork.c:2552 rest_init+0x44/0x4a0 init/main.c:687 arch_call_rest_init+0x1c/0x28 start_kernel+0x520/0x554 init/main.c:1064 0x0 Freed by task 270:
    slab_free_hook mm/slub.c:1562 [inline] slab_free_freelist_hook+0x98/0x260 mm/slub.c:1600 slab_free mm/slub.c:3161 [inline] kmem_cache_free+0x224/0x8e0 mm/slub.c:3177 put_pid.part.4+0xe0/0x1a8 kernel/pid.c:114 put_pid+0x30/0x48 kernel/pid.c:109 proc_do_cad_pid+0x190/0x1b0 kernel/sysctl.c:1401 proc_sys_call_handler+0x338/0x4b0 fs/proc/proc_sysctl.c:591 proc_sys_write+0x34/0x48 fs/proc/proc_sysctl.c:617 call_write_iter include/linux/fs.h:1977 [inline] new_sync_write+0x3ac/0x510 fs/read_write.c:518 vfs_write fs/read_write.c:605 [inline] vfs_write+0x9c4/0x1018 fs/read_write.c:585 ksys_write+0x124/0x240 fs/read_write.c:658 __do_sys_write fs/read_write.c:670 [inline] __se_sys_write fs/read_write.c:667 [inline] __arm64_sys_write+0x78/0xb0 fs/read_write.c:667 __invoke_syscall arch/arm64/kernel/syscall.c:37 [inline] invoke_syscall arch/arm64/kernel/syscall.c:49 [inline] el0_svc_common.constprop.1+0x16c/0x388 arch/arm64/kernel/syscall.c:129 do_el0_svc+0xf8/0x150 arch/arm64/kernel/syscall.c:168 el0_svc+0x28/0x38 arch/arm64/kernel/entry-common.c:416 el0_sync_handler+0x134/0x180 arch/arm64/kernel/entry-common.c:432 el0_sync+0x154/0x180 arch/arm64/kernel/entry.S:701 The buggy address belongs to the object at ffff23794dda0000 which belongs to the cache pid of size 224 The buggy address is located 4 bytes inside of 224-byte region [ff
    ---truncated--- (CVE-2021-47118)

  - 已修复 Linux 内核中的下列漏洞：scsi: target: Fix WRITE_SAME No Data Buffer crash In newer version of the SBC specs, we have a NDOB bit that indicates there is no data buffer that gets written out. If this bit is set using commands like sg_write_same --ndob we will crash in target_core_iblock/file's execute_write_same handlers when we go to access the se_cmd->t_data_sg because its NULL. This patch adds a check for the NDOB bit in the common WRITE SAME code because we don't support it. And, it adds a check for zero SG elements in each handler in case the initiator tries to send a normal WRITE SAME with no data buffer. (CVE-2022-21546)

  - 已修复 Linux 内核中的下列漏洞：be2net: Fix buffer overflow in be_get_module_eeprom be_cmd_read_port_transceiver_data assumes that it is given a buffer that is at least PAGE_DATA_LEN long, or twice that if the module supports SFF 8472. However, this is not always the case.
    Fix this by passing the desired offset and length to be_cmd_read_port_transceiver_data so that we only copy the bytes once. (CVE-2022-49581)

  - 已修复 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)

  - 已修复 Linux 内核中的下列漏洞：tracing: Fix wild-memory-access in register_synth_event() In register_synth_event(), if set_synth_event_print_fmt() failed, then both trace_remove_event_call() and unregister_trace_event() will be called, which means the trace_event_call will call __unregister_trace_event() twice. As the result, the second unregister will causes the wild-memory-access. register_synth_event set_synth_event_print_fmt failed trace_remove_event_call event_remove if call->event.funcs then __unregister_trace_event (first call) unregister_trace_event
    __unregister_trace_event (second call) Fix the bug by avoiding to call the second
    __unregister_trace_event() by checking if the first one is called. general protection fault, probably for non-canonical address 0xfbd59c0000000024: 0000 [#1] SMP KASAN PTI KASAN: maybe wild-memory-access in range [0xdead000000000120-0xdead000000000127] CPU: 0 PID: 3807 Comm: modprobe Not tainted 6.1.0-rc1-00186-g76f33a7eedb4 #299 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014 RIP: 0010:unregister_trace_event+0x6e/0x280 Code:
    00 fc ff df 4c 89 ea 48 c1 ea 03 80 3c 02 00 0f 85 0e 02 00 00 48 b8 00 00 00 00 00 fc ff df 4c 8b 63 08 4c 89 e2 48 c1 ea 03 <80> 3c 02 00 0f 85 e2 01 00 00 49 89 2c 24 48 85 ed 74 28 e8 7a 9b RSP:
    0018:ffff88810413f370 EFLAGS: 00010a06 RAX: dffffc0000000000 RBX: ffff888105d050b0 RCX: 0000000000000000 RDX: 1bd5a00000000024 RSI: ffff888119e276e0 RDI: ffffffff835a8b20 RBP: dead000000000100 R08:
    0000000000000000 R09: fffffbfff0913481 R10: ffffffff8489a407 R11: fffffbfff0913480 R12: dead000000000122 R13: ffff888105d050b8 R14: 0000000000000000 R15: ffff888105d05028 FS: 00007f7823e8d540(0000) GS:ffff888119e00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2:
    00007f7823e7ebec CR3: 000000010a058002 CR4: 0000000000330ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK>
    __create_synth_event+0x1e37/0x1eb0 create_or_delete_synth_event+0x110/0x250 synth_event_run_command+0x2f/0x110 test_gen_synth_cmd+0x170/0x2eb [synth_event_gen_test] synth_event_gen_test_init+0x76/0x9bc [synth_event_gen_test] do_one_initcall+0xdb/0x480 do_init_module+0x1cf/0x680 load_module+0x6a50/0x70a0 __do_sys_finit_module+0x12f/0x1c0 do_syscall_64+0x3f/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd (CVE-2022-49799)

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

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

    Linux 磁盘/网卡前端数据泄露 [其 CNA 信息记录与多个 CVE 有关；文本说明了哪些方面/漏洞与哪些 CVE 对应。] Linux Block 和 Network PV 设备前端未将内存区域归零便与后端共享此区域（CVE-2022-26365、CVE-2022-33740）。
    此外，授权表的粒度不允许共享小于 4K 的页面，因为与后端共享的数据也可以被此后端访问，因而这可以导致不相关的数据驻留在同一 4K 页面中（CVE-2022-33741、CVE-2022-33742）。(CVE-2022-26365)

    Linux 磁盘/网卡前端数据泄露 [其 CNA 信息记录与多个 CVE 有关；文本说明了哪些方面/漏洞与哪些 CVE 对应。] Linux Block 和 Network PV 设备前端未将内存区域归零便与后端共享此区域（CVE-2022-26365、CVE-2022-33740）。
    此外，授权表的粒度不允许共享小于 4K 的页面，因为与后端共享的数据也可以被此后端访问，因而这可以导致不相关的数据驻留在同一 4K 页面中（CVE-2022-33741、CVE-2022-33742）。(CVE-2022-33740)

    Linux 磁盘/网卡前端数据泄露 [其 CNA 信息记录与多个 CVE 有关；文本说明了哪些方面/漏洞与哪些 CVE 对应。] Linux Block 和 Network PV 设备前端未将内存区域归零便与后端共享此区域（CVE-2022-26365、CVE-2022-33740）。
    此外，授权表的粒度不允许共享小于 4K 的页面，因为与后端共享的数据也可以被此后端访问，因而这可以导致不相关的数据驻留在同一 4K 页面中（CVE-2022-33741、CVE-2022-33742）。(CVE-2022-33741)

    Linux 磁盘/网卡前端数据泄露 [其 CNA 信息记录与多个 CVE 有关；文本说明了哪些方面/漏洞与哪些 CVE 对应。] Linux Block 和 Network PV 设备前端未将内存区域归零便与后端共享此区域（CVE-2022-26365、CVE-2022-33740）。
    此外，授权表的粒度不允许共享小于 4K 的页面，因为与后端共享的数据也可以被此后端访问，因而这可以导致不相关的数据驻留在同一 4K 页面中（CVE-2022-33741、CVE-2022-33742）。(CVE-2022-33742)

    网络后端可能造成 Linux netfront 使用已释放的 SKB。在添加逻辑以支持 XDP (eXpress Data Path) 时，移动代码标签时所采用的方式允许释放被保留做进一步处理的包含引用（指针）的 SKB。(CVE-2022-33743)

    当用户输入错误的 NFT_DATA_VERDICT 类型时，在 Linux 内核的 Netfilter 子系统中发现堆缓冲区溢出缺陷。本地用户可利用此缺陷导致系统崩溃或可能升级其系统权限。(CVE-2022-34918)

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

    scsiqla2xxx修复模块加载卸载测试期间的崩溃 (CVE-2022-49160)

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

    block修复因跳过 rq_qos_done_bio() 而造成的 rq-qos 中断 (CVE-2022-49266)

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

    module修复 [e_shstrndx].sh_size=0 OOB 访问 (CVE-2022-49444)

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

    bpf修复从adjust_scalar_min_max_vals 传播不充分的边界 (CVE-2022-49658)

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

    ipv6：修复 in6_dump_addrs() 中的 lockdep 崩溃问题 (CVE-2022-49662)

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

    tunnels：不假设 mac 标头是在 skb_tunnel_check_pmtu() 中设置 (CVE-2022-49663)

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

    tipc将 bc 链接创建移回 tipc_node_create (CVE-2022-49664)

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

    net：bonding：修复 802.3ad 从属取消绑定之后的释放后使用问题 (CVE-2022-49667)

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

    linux/dim修复 RDMA DIM 中的除以 0 错误CVE-2022-49670

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

    RDMA/cm修复 ib_cm_insert_listen 中的内存泄漏 (CVE-2022-49671)

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

    nettun破坏时取消 NAPI 与设备的链接 (CVE-2022-49672)

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

    dm raid：修复 raid5_add_disks 中的 KASAN 警告 (CVE-2022-49673)

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

    dm raid修复超出 raid 成员数组末尾的访问 (CVE-2022-49674)

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

    tick/nohz取消导出 __init-annotated tick_nohz_full_setup() (CVE-2022-49675)

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

    virtio_net：修复暂停/恢复之后的 xdp_rxq_info 缺陷 (CVE-2022-49687)

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

    afs修复动态根 getattrCVE-2022-49688

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

    erspan：不假设始终设置传输标头 (CVE-2022-49691)

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

    igb：修复 igb_clean_tx_ring 中的释放后使用问题 (CVE-2022-49695)

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

    tipc修复 tipc_named_reinit 中的释放后使用读取 (CVE-2022-49696)

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

    bpf修复 sk 查找帮助程序中的 request_sock 泄漏 (CVE-2022-49697)

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

    netfilter使用 get_random_u32 而不是 prandom (CVE-2022-49698)

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

    mm/slub：添加 slab 停用时缺少的 TID 更新 (CVE-2022-49700)

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

    btrfs修复块群组回收任务运行时卸载期间的挂起 (CVE-2022-49702)

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

    sock重新执行 psock 与 ULP 保护检查 (CVE-2022-49732)

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

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

远程主机上安装的内核版本低于 5.10.130-118.517。因此，会受到 ALAS2KERNEL-5.10-2022-018 公告中提及的多个漏洞影响。

    在用户使用恶意数据触发 ioctl FBIOPUT_VSCREENINFO 的方式中，在 Linux 内核的基于帧缓冲区的控制台驱动程序功能中发现了一个越界写入缺陷。本地用户可利用此缺陷导致系统崩溃或可能升级其系统权限。(CVE-2021-33655)

    Linux 的 net/rose/rose_timer.c 中存在由定时器处理程序造成的释放后使用漏洞，攻击者可在没有任何特权的情况下造成 Linux 内核崩溃。(CVE-2022-2318)

    Linux 磁盘/网卡前端数据泄露 [其 CNA 信息记录与多个 CVE 有关；文本说明了哪些方面/漏洞与哪些 CVE 对应。] Linux Block 和 Network PV 设备前端未将内存区域归零便与后端共享此区域（CVE-2022-26365、CVE-2022-33740）。
    此外，授权表的粒度不允许共享小于 4K 的页面，因为与后端共享的数据也可以被此后端访问，因而这可以导致不相关的数据驻留在同一 4K 页面中（CVE-2022-33741、CVE-2022-33742）。(CVE-2022-26365)

    Linux 磁盘/网卡前端数据泄露 [其 CNA 信息记录与多个 CVE 有关；文本说明了哪些方面/漏洞与哪些 CVE 对应。] Linux Block 和 Network PV 设备前端未将内存区域归零便与后端共享此区域（CVE-2022-26365、CVE-2022-33740）。
    此外，授权表的粒度不允许共享小于 4K 的页面，因为与后端共享的数据也可以被此后端访问，因而这可以导致不相关的数据驻留在同一 4K 页面中（CVE-2022-33741、CVE-2022-33742）。(CVE-2022-33740)

    Linux 磁盘/网卡前端数据泄露 [其 CNA 信息记录与多个 CVE 有关；文本说明了哪些方面/漏洞与哪些 CVE 对应。] Linux Block 和 Network PV 设备前端未将内存区域归零便与后端共享此区域（CVE-2022-26365、CVE-2022-33740）。
    此外，授权表的粒度不允许共享小于 4K 的页面，因为与后端共享的数据也可以被此后端访问，因而这可以导致不相关的数据驻留在同一 4K 页面中（CVE-2022-33741、CVE-2022-33742）。(CVE-2022-33741)

    Linux 磁盘/网卡前端数据泄露 [其 CNA 信息记录与多个 CVE 有关；文本说明了哪些方面/漏洞与哪些 CVE 对应。] Linux Block 和 Network PV 设备前端未将内存区域归零便与后端共享此区域（CVE-2022-26365、CVE-2022-33740）。
    此外，授权表的粒度不允许共享小于 4K 的页面，因为与后端共享的数据也可以被此后端访问，因而这可以导致不相关的数据驻留在同一 4K 页面中（CVE-2022-33741、CVE-2022-33742）。(CVE-2022-33742)

    网络后端可能造成 Linux netfront 使用已释放的 SKB。在添加逻辑以支持 XDP (eXpress Data Path) 时，移动代码标签时所采用的方式允许释放被保留做进一步处理的包含引用（指针）的 SKB。(CVE-2022-33743)

    Arm 客户机可通过 PV 设备造成 Dom0 DoS。在 Arm 上映射客户机页面时，dom0 会使用 rbtree 来跟踪外部映射。该 rbtree 的更新并非总是在保留相关锁定的情况下全部完成，这会导致短时争用窗口，非特权客户机可借此通过 PV 设备造成 rbtree 不一致。这些不一致可导致 dom0 拒绝服务 (DoS)，例如造成崩溃或无法执行其他客户机内存页面的进一步映射。(CVE-2022-33744)

    当用户输入错误的 NFT_DATA_VERDICT 类型时，在 Linux 内核的 Netfilter 子系统中发现堆缓冲区溢出缺陷。本地用户可利用此缺陷导致系统崩溃或可能升级其系统权限。(CVE-2022-34918)

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

    usbnet：修复错误情况下的内存流失问题 (CVE-2022-49657)

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

    bpf修复从adjust_scalar_min_max_vals 传播不充分的边界 (CVE-2022-49658)

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

    tunnels：不假设 mac 标头是在 skb_tunnel_check_pmtu() 中设置 (CVE-2022-49663)

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

    tipc将 bc 链接创建移回 tipc_node_create (CVE-2022-49664)

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

    net：bonding：修复 802.3ad 从属取消绑定之后的释放后使用问题 (CVE-2022-49667)

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

    linux/dim修复 RDMA DIM 中的除以 0 错误CVE-2022-49670

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

    RDMA/cm修复 ib_cm_insert_listen 中的内存泄漏 (CVE-2022-49671)

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

    nettun破坏时取消 NAPI 与设备的链接 (CVE-2022-49672)

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

    dm raid：修复 raid5_add_disks 中的 KASAN 警告 (CVE-2022-49673)

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

    dm raid修复超出 raid 成员数组末尾的访问 (CVE-2022-49674)

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

    tick/nohz取消导出 __init-annotated tick_nohz_full_setup() (CVE-2022-49675)

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

    virtio_net：修复暂停/恢复之后的 xdp_rxq_info 缺陷 (CVE-2022-49687)

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

    afs修复动态根 getattrCVE-2022-49688

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

    erspan：不假设始终设置传输标头 (CVE-2022-49691)

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

    igb：修复 igb_clean_tx_ring 中的释放后使用问题 (CVE-2022-49695)

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

    tipc修复 tipc_named_reinit 中的释放后使用读取 (CVE-2022-49696)

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

    bpf修复 sk 查找帮助程序中的 request_sock 泄漏 (CVE-2022-49697)

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

    netfilter使用 get_random_u32 而不是 prandom (CVE-2022-49698)

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

    mm/slub：添加 slab 停用时缺少的 TID 更新 (CVE-2022-49700)

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

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

远程 Redhat Enterprise Linux 8 主机上安装的程序包受到 RHSA-2026:7003 公告中提及的多个漏洞的影响。

    内核程序包中包含 Linux 内核，后者是任何 Linux 操作系统的核心。

    安全修复：

    * kernelLinux 内核Device Mapper RAID 越界访问 (CVE-2022-49674)

    * kernelLinux 内核ATM 子系统中的释放后使用漏洞 (CVE-2025-38180)

    * kernelLinux 内核通过 drm/amdkfd 中未定义的位移操作进行整数溢出和信息泄露 (CVE-2021-4460)

    * kernel：sctp：避免在区块数据缓冲区缺失时发生空取消引用问题 (CVE-2025-40240)

    * 内核：ipv6：作为 calipso_skbuff_setattr() 的一部分，pskb_expand_head() 中存在 BUG() (CVE-2025-71085)

    * kernelmacvlan修复 macvlan_common_newlink() 中的错误恢复 (CVE-2026-23209)

    有关上述安全问题的更多详细信息，包括其影响、CVSS 得分、致谢，以及其他相关信息，请参阅列于“参考”部分的 CVE 页面。

Tenable 已直接从 Red Hat Enterprise Linux 安全公告中提取上述描述块。

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

如 TuxCare CENTOS7：CLSA-2026：1782148320公告所述，CentOS Linux 7 主机上存在安装的程序包，该漏洞会受到多个漏洞的影响。

  - 已修复 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 尚未测试这些问题，而是只依据应用程序自我报告的版本号进行判断。

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

  - 已修复 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 依赖供应商报告的程序包是否存在进行判断。

Rocky Linux 8.6 主机上安装的多个程序包受到 CIQ ciqsa-2026_1336 公告中提及的多个漏洞影响。

    此公告汇总了 CIQ LTS 8.6中内核 SRPM 的安全修复。它解决了 22 个 CVE：
    CVE-2025-38024、 CVE-2025-40240、 CVE-2025-71085、 CVE-2024-26735、 和 CVE-2023-5248617 个。

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

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

如 TuxCare CENTOS8.4：CLSA-2026：1771078945公告所述，CentOS Linux 8.4 主机上存在安装的程序包，该漏洞会受到多个漏洞的影响。

  - 已修复 Linux 内核中的下列漏洞：pid: take a reference when initializing `cad_pid` During boot, kernel_init_freeable() initializes `cad_pid` to the init task's struct pid. Later on, we may change `cad_pid` via a sysctl, and when this happens proc_do_cad_pid() will increment the refcount on the new pid via get_pid(), and will decrement the refcount on the old pid via put_pid(). As we never called get_pid() when we initialized `cad_pid`, we decrement a reference we never incremented, can therefore free the init task's struct pid early. As there can be dangling references to the struct pid, we can later encounter a use-after-free (e.g. when delivering signals). This was spotted when fuzzing v5.13-rc3 with Syzkaller, but seems to have been around since the conversion of `cad_pid` to struct pid in commit 9ec52099e4b8 ([PATCH] replace cad_pid by a struct pid) from the pre-KASAN stone age of v2.6.19. Fix this by getting a reference to the init task's struct pid when we assign it to `cad_pid`.
    Full KASAN splat below. ================================================================== BUG: KASAN:
    use-after-free in ns_of_pid include/linux/pid.h:153 [inline] BUG: KASAN: use-after-free in task_active_pid_ns+0xc0/0xc8 kernel/pid.c:509 Read of size 4 at addr ffff23794dda0004 by task syz-executor.0/273 CPU: 1 PID: 273 Comm: syz-executor.0 Not tainted 5.12.0-00001-g9aef892b2d15 #1 Hardware name: linux,dummy-virt (DT) Call trace: ns_of_pid include/linux/pid.h:153 [inline] task_active_pid_ns+0xc0/0xc8 kernel/pid.c:509 do_notify_parent+0x308/0xe60 kernel/signal.c:1950 exit_notify kernel/exit.c:682 [inline] do_exit+0x2334/0x2bd0 kernel/exit.c:845 do_group_exit+0x108/0x2c8 kernel/exit.c:922 get_signal+0x4e4/0x2a88 kernel/signal.c:2781 do_signal arch/arm64/kernel/signal.c:882 [inline] do_notify_resume+0x300/0x970 arch/arm64/kernel/signal.c:936 work_pending+0xc/0x2dc Allocated by task 0: slab_post_alloc_hook+0x50/0x5c0 mm/slab.h:516 slab_alloc_node mm/slub.c:2907 [inline] slab_alloc mm/slub.c:2915 [inline] kmem_cache_alloc+0x1f4/0x4c0 mm/slub.c:2920 alloc_pid+0xdc/0xc00 kernel/pid.c:180 copy_process+0x2794/0x5e18 kernel/fork.c:2129 kernel_clone+0x194/0x13c8 kernel/fork.c:2500 kernel_thread+0xd4/0x110 kernel/fork.c:2552 rest_init+0x44/0x4a0 init/main.c:687 arch_call_rest_init+0x1c/0x28 start_kernel+0x520/0x554 init/main.c:1064 0x0 Freed by task 270:
    slab_free_hook mm/slub.c:1562 [inline] slab_free_freelist_hook+0x98/0x260 mm/slub.c:1600 slab_free mm/slub.c:3161 [inline] kmem_cache_free+0x224/0x8e0 mm/slub.c:3177 put_pid.part.4+0xe0/0x1a8 kernel/pid.c:114 put_pid+0x30/0x48 kernel/pid.c:109 proc_do_cad_pid+0x190/0x1b0 kernel/sysctl.c:1401 proc_sys_call_handler+0x338/0x4b0 fs/proc/proc_sysctl.c:591 proc_sys_write+0x34/0x48 fs/proc/proc_sysctl.c:617 call_write_iter include/linux/fs.h:1977 [inline] new_sync_write+0x3ac/0x510 fs/read_write.c:518 vfs_write fs/read_write.c:605 [inline] vfs_write+0x9c4/0x1018 fs/read_write.c:585 ksys_write+0x124/0x240 fs/read_write.c:658 __do_sys_write fs/read_write.c:670 [inline] __se_sys_write fs/read_write.c:667 [inline] __arm64_sys_write+0x78/0xb0 fs/read_write.c:667 __invoke_syscall arch/arm64/kernel/syscall.c:37 [inline] invoke_syscall arch/arm64/kernel/syscall.c:49 [inline] el0_svc_common.constprop.1+0x16c/0x388 arch/arm64/kernel/syscall.c:129 do_el0_svc+0xf8/0x150 arch/arm64/kernel/syscall.c:168 el0_svc+0x28/0x38 arch/arm64/kernel/entry-common.c:416 el0_sync_handler+0x134/0x180 arch/arm64/kernel/entry-common.c:432 el0_sync+0x154/0x180 arch/arm64/kernel/entry.S:701 The buggy address belongs to the object at ffff23794dda0000 which belongs to the cache pid of size 224 The buggy address is located 4 bytes inside of 224-byte region [ff
    ---truncated--- (CVE-2021-47118)

  - 已修复 Linux 内核中的下列漏洞：i2c: i801: Don't generate an interrupt on bus reset Now that the i2c-i801 driver supports interrupts, setting the KILL bit in a attempt to recover from a timed out transaction triggers an interrupt. Unfortunately, the interrupt handler (i801_isr) is not prepared for this situation and will try to process the interrupt as if it was signaling the end of a successful transaction. In the case of a block transaction, this can result in an out-of-range memory access. This condition was reproduced several times by syzbot:
    https://syzkaller.appspot.com/bug?extid=ed71512d469895b5b34e https://syzkaller.appspot.com/bug?extid=8c8dedc0ba9e03f6c79e https://syzkaller.appspot.com/bug?extid=c8ff0b6d6c73d81b610e https://syzkaller.appspot.com/bug?extid=33f6c360821c399d69eb https://syzkaller.appspot.com/bug?extid=be15dc0b1933f04b043a https://syzkaller.appspot.com/bug?extid=b4d3fd1dfd53e90afd79 So disable interrupts while trying to reset the bus. Interrupts will be enabled again for the following transaction. (CVE-2021-47153)

  - 已修复 Linux 内核中的下列漏洞：scsi: target: Fix WRITE_SAME No Data Buffer crash In newer version of the SBC specs, we have a NDOB bit that indicates there is no data buffer that gets written out. If this bit is set using commands like sg_write_same --ndob we will crash in target_core_iblock/file's execute_write_same handlers when we go to access the se_cmd->t_data_sg because its NULL. This patch adds a check for the NDOB bit in the common WRITE SAME code because we don't support it. And, it adds a check for zero SG elements in each handler in case the initiator tries to send a normal WRITE SAME with no data buffer. (CVE-2022-21546)

  - 已修复 Linux 内核中的下列漏洞：net/mlx5e: IPoIB, Block PKEY interfaces with less rx queues than parent A user is able to configure an arbitrary number of rx queues when creating an interface via netlink. This doesn't work for child PKEY interfaces because the child interface uses the parent receive channels. Although the child shares the parent's receive channels, the number of rx queues is important for the channel_stats array: the parent's rx channel index is used to access the child's channel_stats. So the array has to be at least as large as the parent's rx queue size for the counting to work correctly and to prevent out of bound accesses. This patch checks for the mentioned scenario and returns an error when trying to create the interface. The error is propagated to the user. (CVE-2022-48883)

  - 已修复 Linux 内核中的下列漏洞：ath9k_htc: fix potential out of bounds access with invalid rxstatus->rs_keyix The rxstatus->rs_keyix eventually gets passed to test_bit() so we need to ensure that it is within the bitmap. drivers/net/wireless/ath/ath9k/common.c:46 ath9k_cmn_rx_accept() error: passing untrusted data 'rx_stats->rs_keyix' to 'test_bit()' (CVE-2022-49503)

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

远程 Redhat Enterprise Linux 8 主机上安装的程序包受到 RHSA-2026:6953 公告中提及的多个漏洞的影响。

    内核程序包中包含 Linux 内核，后者是任何 Linux 操作系统的核心。

    安全修复：

    * kernelLinux 内核Device Mapper RAID 越界访问 (CVE-2022-49674)

    * kernelLinux 内核ATM 子系统中的释放后使用漏洞 (CVE-2025-38180)

    * kernelLinux 内核通过 drm/amdkfd 中未定义的位移操作进行整数溢出和信息泄露 (CVE-2021-4460)

    * kernelmacvlan修复 macvlan_common_newlink() 中的错误恢复 (CVE-2026-23209)

    有关上述安全问题的更多详细信息，包括其影响、CVSS 得分、致谢，以及其他相关信息，请参阅列于“参考”部分的 CVE 页面。

Tenable 已直接从 Red Hat Enterprise Linux 安全公告中提取上述描述块。

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

ID	名称	产品	系列	发布时间	最近更新时间	严重程度
163324	Amazon Linux 2：内核 (ALAS-2022-1825)	Nessus	Amazon Linux Local Security Checks	2022/7/21	2026/2/24	high
163385	Amazon Linux 2：内核 (ALASKERNEL-5.4-2022-033)	Nessus	Amazon Linux Local Security Checks	2022/7/22	2026/2/26	high
305276	RHEL 8：内核 (RHSA-2026:6961)	Nessus	Red Hat Local Security Checks	2026/4/8	2026/4/8	high
360928	CentOS Linux 8.5 [TuxCare] 安全更新：bpftool / kernel / kernel-core / kernel-cross-headers / 等多个漏洞（CENTOS8.5：CLSA-2026：1771077729）	Nessus	CentOS Local Security Checks	2026/10/1	2026/10/18	high
163352	Amazon Linux 2：内核 (ALASKERNEL-5.15-2022-005)	Nessus	Amazon Linux Local Security Checks	2022/7/21	2026/2/26	high
163382	Amazon Linux 2：内核 (ALASKERNEL-5.10-2022-018)	Nessus	Amazon Linux Local Security Checks	2022/7/22	2026/2/26	high
305576	RHEL 8：内核 (RHSA-2026:7003)	Nessus	Red Hat Local Security Checks	2026/4/8	2026/4/8	high
353232	CentOS Linux 7 [TuxCare] 安全更新：bpftool / kernel / kernel-debug / kernel-debug-devel / kernel-devel / 等多个漏洞（CENTOS7：CLSA-2026：1782148320）	Nessus	CentOS Local Security Checks	2026/9/30	2026/9/30	high
225971	Linux Distros 未修补的漏洞：CVE-2022-49674	Nessus	Misc.	2025/3/5	2026/11/12	high
354661	Rocky Linux 8.6 [CIQ] 安全更新：bpftool / bpftool-debuginfo / kernel / kernel-abi-stablelists / 等多种漏洞（ciqsa-2026_1336）	Nessus	Rocky Linux Local Security Checks	2026/10/1	2026/10/12	high
361173	CentOS Linux 8.4 [TuxCare] 安全更新：bpftool / kernel / kernel-core / kernel-cross-headers / 等多个漏洞（CENTOS8.4：CLSA-2026：1771078945）	Nessus	CentOS Local Security Checks	2026/10/1	2026/10/1	high
305277	RHEL 8：内核 (RHSA-2026:6953)	Nessus	Red Hat Local Security Checks	2026/4/8	2026/4/8	high

检测

插件搜索

high

high

high

high

high

high

high

high

high

high

high

high