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

  - 经授权的用户可能通过造成缓冲区过度读取来造成 MongoDB 服务器崩溃。在某些情况下可通过在发出查询时发出 DDL 操作来完成此操作。此问题会影响低于 7.0.25的 MongoDB Server v7.0 版本、低于 8.0.15的MongoDB Server v8.0 版本以及 MongoDB Server 版本 8.2.0。 (CVE-2025-11979)

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

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

  - radare2 v5.9.8 和低于 的版本在函数 bochs_open 中包含内存泄漏。 (CVE-2025-60361)

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

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

  - 使敏感信息暴露给未经授权的执行者漏洞 Wikimedia Foundation Mediawiki - 转换扩展模块允许足迹。翻译扩展模块似乎使用作业对翻译页面进行编辑。这会造成 CheckUser 工具记录错误的 IP 和用户代理从而导致无法通过 CheckUser 工具审计这些编辑。此问题会影响 Mediawiki - Translate Extension: from master 之前的版本 1.39。 (CVE-2025-62699)

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

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

  - 网页生成期间错误中和输入XSS 或“跨站脚本”漏洞Wikimedia Foundation MediaWiki PageForms 扩展允许存储 XSS。此问题影响 MediaWiki PageForms 扩展 1.44。 (CVE-2025-62657)

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

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

  - Google Chrome 141.0.7390.122 之前版本的 V8 中存在内存访问越界漏洞，远程攻击者可利用此漏洞，通过构建的 HTML 页面执行越界内存访问攻击。（Chromium 安全严重性：高）(CVE-2025-12036)

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

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

  - radare2 v5.9.8 和低于 的版本在函数 r2r_subprocess_init 中包含内存泄漏。 (CVE-2025-60360)

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

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

  - 网页生成期间错误中和输入XSS 或“跨站脚本”漏洞The Wikimedia Foundation Mediawiki - Wikistories 中的漏洞允许存储 XSS。此问题影响 Mediawiki - Wikistories来自 之前的主控端 1.44。 (CVE-2025-62701)

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

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

  - 在网页生成期间错误中和输入XSS 或“跨站脚本”漏洞The Wikimedia Foundation Mediawiki - MultiBielerplat Extensionmaste 允许存储 XSS。此问题会影响 Mediawiki - MultiBielerlate Extensionmaste来自 1.39之前的主机。 (CVE-2025-62700)

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

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

  - 网页生成期间错误中和输入XSS 或“跨站脚本”漏洞。Wikimedia Foundation MediaWiki GlobalBlocking 扩展允许存储 XSS。此问题影响 MediaWiki GlobalBlocking 扩展 1.43、 1.44。 (CVE-2025-62656)

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

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

  - 在 Wikimedia Foundation Mediawiki Foundation - Springboard Extension 中的命令“命令注入”漏洞中使用的特殊元素不当中和允许命令注入。此问题影响 Mediawiki Foundation - Springboard Extension: master。 (CVE-2025-62696)

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

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

  - 网页生成期间错误中和输入Wikimedia Foundation Mediawiki - Wiki Love Extension 中的 (XSS 或“跨站脚本”) 漏洞允许存储 XSS。此问题影响 Mediawiki
    - Wiki Love 扩展 1.39。 (CVE-2025-62694)

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

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

  - 网页生成期间错误中和输入XSS 或“跨站脚本”漏洞 Wikimedia Foundation Mediawiki - LastModified Extension 允许存储 XSS。此问题会影响 Mediawiki - LastModified Extension: 来自 之前的主 1.39。 (CVE-2025-62693)

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

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

  - radare2 v5.9.8 和低于 的版本在函数 r_bin_object_new 中包含内存泄漏。 (CVE-2025-60359)

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

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

  - 已修复 Linux 内核中的下列漏洞：wifi: mt76: mt7921: fix error code of return in mt7921_acpi_read Kernel NULL pointer dereference when ACPI SAR table isn't implemented well. Fix the error code of return to mark the ACPI SAR table as invalid. [ 5.077128] mt7921e 0000:06:00.0: sar cnt = 0 [ 5.077381] BUG: kernel NULL pointer dereference, address: 0000000000000004 [ 5.077630] #PF:
    supervisor read access in kernel mode [ 5.077883] #PF: error_code(0x0000) - not-present page [ 5.078138] PGD 0 P4D 0 [ 5.078398] Oops: 0000 [#1] PREEMPT SMP NOPTI [ 5.079202] RIP:
    0010:mt7921_init_acpi_sar+0x106/0x220 [mt7921_common] ... [ 5.080786] Call Trace: [ 5.080786] <TASK> [5.080786] mt7921_register_device+0x37d/0x490 [mt7921_common] [ 5.080786] mt7921_pci_probe.part.0+0x2ee/0x310 [mt7921e] [ 5.080786] mt7921_pci_probe+0x52/0x70 [mt7921e] [ 5.080786] local_pci_probe+0x47/0x90 [ 5.080786] pci_call_probe+0x55/0x190 [ 5.080786] pci_device_probe+0x84/0x120 (CVE-2023-53710)

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

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

  - 已修复 Linux 内核中的下列漏洞：blk-iocost: use spin_lock_irqsave in adjust_inuse_and_calc_cost adjust_inuse_and_calc_cost() use spin_lock_irq() and IRQ will be enabled when unlock. DEADLOCK might happen if we have held other locks and disabled IRQ before invoking it. Fix it by using spin_lock_irqsave() instead, which can keep IRQ state consistent with before when unlock.
    ================================ WARNING: inconsistent lock state 5.10.0-02758-g8e5f91fd772f #26 Not tainted -------------------------------- inconsistent {IN-HARDIRQ-W} -> {HARDIRQ-ON-W} usage.
    kworker/2:3/388 [HC0[0]:SC0[0]:HE0:SE1] takes: ffff888118c00c28 (&bfqd->lock){?.-.}-{2:2}, at:
    spin_lock_irq ffff888118c00c28 (&bfqd->lock){?.-.}-{2:2}, at: bfq_bio_merge+0x141/0x390 {IN-HARDIRQ-W} state was registered at: __lock_acquire+0x3d7/0x1070 lock_acquire+0x197/0x4a0 __raw_spin_lock_irqsave
    _raw_spin_lock_irqsave+0x3b/0x60 bfq_idle_slice_timer_body bfq_idle_slice_timer+0x53/0x1d0
    __run_hrtimer+0x477/0xa70 __hrtimer_run_queues+0x1c6/0x2d0 hrtimer_interrupt+0x302/0x9e0 local_apic_timer_interrupt __sysvec_apic_timer_interrupt+0xfd/0x420 run_sysvec_on_irqstack_cond sysvec_apic_timer_interrupt+0x46/0xa0 asm_sysvec_apic_timer_interrupt+0x12/0x20 irq event stamp: 837522 hardirqs last enabled at (837521): [<ffffffff84b9419d>] __raw_spin_unlock_irqrestore hardirqs last enabled at (837521): [<ffffffff84b9419d>] _raw_spin_unlock_irqrestore+0x3d/0x40 hardirqs last disabled at (837522): [<ffffffff84b93fa3>] __raw_spin_lock_irq hardirqs last disabled at (837522):
    [<ffffffff84b93fa3>] _raw_spin_lock_irq+0x43/0x50 softirqs last enabled at (835852): [<ffffffff84e00558>]
    __do_softirq+0x558/0x8ec softirqs last disabled at (835845): [<ffffffff84c010ff>] asm_call_irq_on_stack+0xf/0x20 other info that might help us debug this: Possible unsafe locking scenario:
    CPU0 ---- lock(&bfqd->lock); <Interrupt> lock(&bfqd->lock); *** DEADLOCK *** 3 locks held by kworker/2:3/388: #0: ffff888107af0f38 ((wq_completion)kthrotld){+.+.}-{0:0}, at:
    process_one_work+0x742/0x13f0 #1: ffff8881176bfdd8 ((work_completion)(&td->dispatch_work)){+.+.}-{0:0}, at: process_one_work+0x777/0x13f0 #2: ffff888118c00c28 (&bfqd->lock){?.-.}-{2:2}, at: spin_lock_irq #2:
    ffff888118c00c28 (&bfqd->lock){?.-.}-{2:2}, at: bfq_bio_merge+0x141/0x390 stack backtrace: CPU: 2 PID: 388 Comm: kworker/2:3 Not tainted 5.10.0-02758-g8e5f91fd772f #26 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 Workqueue: kthrotld blk_throtl_dispatch_work_fn Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x107/0x167 print_usage_bug valid_state mark_lock_irq.cold+0x32/0x3a mark_lock+0x693/0xbc0 mark_held_locks+0x9e/0xe0
    __trace_hardirqs_on_caller lockdep_hardirqs_on_prepare.part.0+0x151/0x360 trace_hardirqs_on+0x5b/0x180
    __raw_spin_unlock_irq _raw_spin_unlock_irq+0x24/0x40 spin_unlock_irq adjust_inuse_and_calc_cost+0x4fb/0x970 ioc_rqos_merge+0x277/0x740 __rq_qos_merge+0x62/0xb0 rq_qos_merge bio_attempt_back_merge+0x12c/0x4a0 blk_mq_sched_try_merge+0x1b6/0x4d0 bfq_bio_merge+0x24a/0x390
    __blk_mq_sched_bio_merge+0xa6/0x460 blk_mq_sched_bio_merge blk_mq_submit_bio+0x2e7/0x1ee0
    __submit_bio_noacct_mq+0x175/0x3b0 submit_bio_noacct+0x1fb/0x270 blk_throtl_dispatch_work_fn+0x1ef/0x2b0 process_one_work+0x83e/0x13f0 process_scheduled_works worker_thread+0x7e3/0xd80 kthread+0x353/0x470 ret_from_fork+0x1f/0x30 (CVE-2023-53730)

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

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

  - ACPIx86s2idle捕获多个 ACPI_TYPE_PACKAGE 对象 在评估 AMD LPS0 _DSM 时如果构建错误的固件包含多个“ACPI_TYPE_PACKAGE”对象就会发生内存泄漏。
    明确防止此问题。 (CVE-2023-53708)

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

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

  - 已修复 Linux 内核中的下列漏洞：ext4: fix use-after-free read in ext4_find_extent for bigalloc + inline Syzbot found the following issue: loop0: detected capacity change from 0 to 2048 EXT4-fs (loop0): mounted filesystem 00000000-0000-0000-0000-000000000000 without journal.
    Quota mode: none. ================================================================== BUG: KASAN: use-after-free in ext4_ext_binsearch_idx fs/ext4/extents.c:768 [inline] BUG: KASAN: use-after-free in ext4_find_extent+0x76e/0xd90 fs/ext4/extents.c:931 Read of size 4 at addr ffff888073644750 by task syz-executor420/5067 CPU: 0 PID: 5067 Comm: syz-executor420 Not tainted 6.2.0-rc1-syzkaller #0 Hardware name:
    Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022 Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x1b1/0x290 lib/dump_stack.c:106 print_address_description+0x74/0x340 mm/kasan/report.c:306 print_report+0x107/0x1f0 mm/kasan/report.c:417 kasan_report+0xcd/0x100 mm/kasan/report.c:517 ext4_ext_binsearch_idx fs/ext4/extents.c:768 [inline] ext4_find_extent+0x76e/0xd90 fs/ext4/extents.c:931 ext4_clu_mapped+0x117/0x970 fs/ext4/extents.c:5809 ext4_insert_delayed_block fs/ext4/inode.c:1696 [inline] ext4_da_map_blocks fs/ext4/inode.c:1806 [inline] ext4_da_get_block_prep+0x9e8/0x13c0 fs/ext4/inode.c:1870 ext4_block_write_begin+0x6a8/0x2290 fs/ext4/inode.c:1098 ext4_da_write_begin+0x539/0x760 fs/ext4/inode.c:3082 generic_perform_write+0x2e4/0x5e0 mm/filemap.c:3772 ext4_buffered_write_iter+0x122/0x3a0 fs/ext4/file.c:285 ext4_file_write_iter+0x1d0/0x18f0 call_write_iter include/linux/fs.h:2186 [inline] new_sync_write fs/read_write.c:491 [inline] vfs_write+0x7dc/0xc50 fs/read_write.c:584 ksys_write+0x177/0x2a0 fs/read_write.c:637 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP:
    0033:0x7f4b7a9737b9 RSP: 002b:00007ffc5cac3668 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 RAX:
    ffffffffffffffda RBX: 0000000000000000 RCX: 00007f4b7a9737b9 RDX: 00000000175d9003 RSI: 0000000020000200 RDI: 0000000000000004 RBP: 00007f4b7a933050 R08: 0000000000000000 R09: 0000000000000000 R10:
    000000000000079f R11: 0000000000000246 R12: 00007f4b7a9330e0 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 </TASK> Above issue is happens when enable bigalloc and inline data feature. As commit 131294c35ed6 fixed delayed allocation bug in ext4_clu_mapped for bigalloc + inline. But it only resolved issue when has inline data, if inline data has been converted to extent(ext4_da_convert_inline_data_to_extent) before writepages, there is no EXT4_STATE_MAY_INLINE_DATA flag. However i_data is still store inline data in this scene. Then will trigger UAF when find extent. To resolve above issue, there is need to add judge ext4_has_inline_data(inode) in ext4_clu_mapped().
    (CVE-2023-53692)

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

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

  - ring-buffer在调整大小过程期间不交换 cpu_buffer 在调整大小过程期间调用 ring_buffer_swap_cpu 时cpu 缓冲区在中间交换从而导致不正确的状态。继续在错误的状态下运行将导致 oops。使用以下两个脚本可以轻松重现此问题/tmp # cat test1.sh //#! /bin/sh for i in `seq 0 100000` do echo 2000 > /sys/kernel/debug/tracing/buffer_size_kb sleep 0.5 echo 5000 > /sys/kernel/debug/tracing/buffer_size_kb sleep 0.5 did /tmp # cat test2.sh //#! /bin/sh for i in `seq 0 100000` do echo irqsoff > /sys/kernel/debug/tracing/current_tracer sleep 1 echo nop > /sys/kernel/debug/tracing/current_tracer sleep 1 did /tmp # ./test1 .sh & /tmp # ./test2.sh & 一个典型的 oops 日志如下所示, 有时会出现其他不同的 oops 日志。 [ 231.711293] WARNINGCPU: 0 PID: 9 at kernel/trace/ring_buffer.c:2026 rb_update_pages+0x378/0x3f8 [ 231.713375] 链接的模块[ 231.714735] CPU: 0 PID: 9 Comm: kworker/0:1 Tainted: GW 6.5.0-rc1-00276-g20edcec23f92 #15 [ 231.716750] 硬件名称linux,dummy-virt (DT) [231.718152] Workqueue事件 update_pages_handler [ 231.719714] pstate: 60000005 (nZCv daif -PAN -UAO
    -TCO -DIT -SSBS BTYPE=--) [ 231.721171] pc rb_update_pages+0x378/0x3f8 [ 231.722212] lr
    rb_update_pages+0x25c/0x3f8 [ 231.723248] sp ffff800082b9bd50 [ 231.724169] x29ffff800082b9bd50 x28
    ffff8000825f7000 x270000000000000000 [ 231.726102] x26: 0000000000000001 x25ffffffffffff010 x24
    0000000000000ff0 [ 231.728122] x23: ffff0000c3a0b600 x22: ffff0000c3a0b5c0 x21: fffffffffffffe0a [231.730203] x20: ffff0000c3a0b600 x19: ffff0000c0102400 x18: 000000 [00000] [00000] [00000] [00000 231.732329 00010]
    0000000000000000 x160000000000000000 x150000ffffe7aa8510 [ 231.734212] x14: 0000000000000000 x13
    0000000000000000 x120000000000000002 [ 231.736291] x11ffff8000826998a8 x10ffff800082b9baf0 x9
    ffff800081137558 [ 231.738195] x8 : fffffc00030e82c8 x7 : 0000000000000000 x6 : 0000000000000001 [231.740192] x5 : ffff0000ffbafe00 x4 : 0000000000000000 x3 : 0000000000000000 [ 231.742118] x2 :
    00000000000006aa x1 : 0000000000000001 x0 : ffff0000c0007208 [ 231.744196] Call trace: [ 231.744892] rb_update_pages+0x378/0x3f8 [ 231.745893] update_pages_handler+0x1c/0x38 [ 231.746893] process_one_work+0x1f0/0x468 [ 231.747852] worker_thread+0x54/0x410 [ 231.748737] kthread+0x124/0x138 [231.749549] ret_from_fork+0x10/0x20 [ 231.750434] ---[结束跟踪 0000000000000000 ]--- [ 233.720486] 无法处理虚拟地址 0000000000000000 处的内核空指针取消引用 [ 233.721696] Mem abort info[ 233.721935] ESR = 0x0000000096000004 [ 233.722283] EC = 0x25DABT当前 ELIL = 32 位 [ 233.722596] SET = 0FnV = 0 [ 233.722805] EA = 0 S1PTW = 0 [ 233.723026] FSC = 0x04级别 0 转换错误 [ 233.723458] Data 中止信息[ 233.723734] ISV = 0ISS = 0x00000004ISS2 = 0x00000000 [ 233.724176] CM = 0WnR = 0 TnD = 0, TagAccess = 0 [ 233.724589] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 233.725075] user pgtable: 4k 页面48 位 VA, pgdp=0000000104943000 [ 233.725592] [0000000000000000] pgd=0000000000000000, p4d=0000000000000000 [ 233.726231] 内部错误Oops
    0000000096000004 [#1] PREEMPT SMP [ 233.726720] 链接的模块[ 233.727007] CPU: 0 PID: 9 Comm
    kworker/0:1 受感染: GW 6.5.0-rc1-00276-g20edcec23f92 #15 [ 233.727777] 硬件名称linux,dummy-virt (DT) [ 233.728225] Workqueue: 事件 update_pages_handler [ 233.728655] pstate: 200000c5 (nzCv daIF -PAN
    -UAO -TCO -DIT -SSBS BTYPE=--) [ 233.729054] pc rb_update_pages+0x1a8/0x3f8 [ 233.729334] lr
    rb_update_pages+0x154/0x3f8 [ 233.729592] sp ffff800082b9bd50 [ 233.729792] x29ffff800082b9bd50 x28
    ffff8000825f7000 x2700000000 ---truncated--- (CVE-2023-53718)

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

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

  - scsiqla2xxx修复 qla2x00_probe_one() 中的内存泄漏 kmemleak 报告存在内存泄漏
    未引用的对象 0xffffc900003f0000 (size 12288): comm modprobe, pid 19117, jiffies 4299751452 (age 42490.264s) hex 转储 (前 32 个字节): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0 ...... ........ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ....... 回溯[<00000000629261a8>]
    __vmalloc_node_range+0xe56/0x1110 [<0000000001906886>] __vmalloc_node+0xbd/0x150 [<000000005bb4dc34>] vmalloc+0x25/0x30 [<00000000a2dc1194>] qla2x00_create_host+0x7a0/0xe30 [qla2xxx] [<0000000062b14b47>] qla2x00_probe_one+0x2eb8/0xd160 [qla2xxx] [<00000000641ccc04>] local_pci_probe+0xeb/0x1a0 适配器 base_vha 初始化失败时可追踪根本原因至 qla2x00_probe_one() 中的错误处理路径。
    fab_scan_rp scan.l 用于记录端口信息并在 qla2x00_create_host() 中分配。但是它未在错误处理路径 probe_failed 中释放。通过在适配器初始化进程中发生错误时释放 scan.l 的内存来修复此问题。
    (CVE-2023-53696)

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

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

  - posix-timers确保定时器 ID 搜索循环限制有效 posix_timer_add() 会尝试通过从上次成功分配时存储的缓存 ID 来分配 posix 定时器 ID。这是在一个循环中逐个搜索空闲插槽的 ID 空间中完成的。当搜索回到起点时循环必须终止。但是这就是“racy”与“建立起点”的对比。即无锁读取导致以下问题CPU0 CPU1 posix_timer_add() start = sig->posix_timer_id;
    lock(hash_lock); ... posix_timer_add() if (++sig->posix_timer_id < 0) start = sig->posix_timer_id;
    sig->posix_timer_id = 0因此 CPU1 可以观察到负的起始值即 -1并且永远不会发生循环中断因为条件永远不可能为真 if (sig->posix_timer_id == start) break;尽管此问题不可能变成死循环因为 ID 空间巨大 (INT_MAX)但起始值的 racy 读取还是引起了 KCSAN 的注意且由 Dmitry 发现了该错误。对其进行重写以便所有 id 操作都在哈希锁定下。 (CVE-2023-53728)

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

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

  - 已修复 Linux 内核中的下列漏洞：class: fix possible memory leak in
    __class_register() If class_add_groups() returns error, the 'cp->subsys' need be unregister, and the 'cp' need be freed. We can not call kset_unregister() here, because the 'cls' will be freed in callback function class_release() and it's also freed in caller's error path, it will cause double free. So fix this by calling kobject_del() and kfree_const(name) to cleanup kobject. Besides, call kfree() to free the 'cp'. Fault injection test can trigger this: unreferenced object 0xffff888102fa8190 (size 8): comm modprobe, pid 502, jiffies 4294906074 (age 49.296s) hex dump (first 8 bytes): 70 6b 74 63 64 76 64 00 pktcdvd. backtrace: [<00000000e7c7703d>] __kmalloc_track_caller+0x1ae/0x320 [<000000005e4d70bc>] kstrdup+0x3a/0x70 [<00000000c2e5e85a>] kstrdup_const+0x68/0x80 [<000000000049a8c7>] kvasprintf_const+0x10b/0x190 [<0000000029123163>] kobject_set_name_vargs+0x56/0x150 [<00000000747219c9>] kobject_set_name+0xab/0xe0 [<0000000005f1ea4e>] __class_register+0x15c/0x49a unreferenced object 0xffff888037274000 (size 1024): comm modprobe, pid 502, jiffies 4294906074 (age 49.296s) hex dump (first 32 bytes): 00 40 27 37 80 88 ff ff 00 40 27 37 80 88 ff ff .@'7.....@'7.... 00 00 00 00 ad 4e ad de ff ff ff ff 00 00 00 00 .....N.......... backtrace: [<00000000151f9600>] kmem_cache_alloc_trace+0x17c/0x2f0 [<00000000ecf3dd95>] __class_register+0x86/0x49a (CVE-2022-50578)

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

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

  - wifiath9k修复 ath9k_wmi_rsp_callback() 中潜在的堆栈越界写入。修复 ath9k_wmi_cmd() 中发生超时后调用的 WMI 响应回调函数中发生的堆栈越界写入。写入到 wmi->cmd_rsp_buf 的回调即堆栈分配的缓冲区在发生超时时可能不再有效。发生超时时将 wmi->last_seq_id 设置为 0。此问题由 syzkaller 的修改版本发现。缺陷KASAN大小为 4 的 ath9k_wmi_ctrl_rx 写入中堆栈越界调用追踪
    memcpy ath9k_wmi_ctrl_rx ath9k_htc_rx_msg ath9k_hif_usb_reg_in_cb __usb_hcd_giveback_urb usb_hcd_giveback_urb dummy_timer call_timer_fn run_timer_softirq __do_softirq irq_exit_rcu sysvec_apic_timer_interrupt (CVE-2023-53717]

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

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

  - 已修复 Linux 内核中的下列漏洞：nvdimm: Fix memleak of pmu attr_groups in unregister_nvdimm_pmu() Memory pointed by 'nd_pmu->pmu.attr_groups' is allocated in function 'register_nvdimm_pmu' and is lost after 'kfree(nd_pmu)' call in function 'unregister_nvdimm_pmu'.
    (CVE-2023-53697)

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

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

  - 在特别构建的包含特定畸形 DNSKEY 记录的区域中查询记录可导致 CPU 耗尽。此问题会影响 BIND 9 版本 9.18.0 至 9.18.39、 9.20.0 至 9.20.13、 9.21.0 至 9.21.12、9.18.11-S1 至 9.18.39-S1以及 9.20.9-S1 至 9.20.13-S1。 (CVE-2025-8677)

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

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

  - 已修复 Linux 内核中的下列漏洞：xsk: fix refcount underflow in error path Fix a refcount underflow problem reported by syzbot that can happen when a system is running out of memory. If xp_alloc_tx_descs() fails, and it can only fail due to not having enough memory, then the error path is triggered. In this error path, the refcount of the pool is decremented as it has incremented before. However, the reference to the pool in the socket was not nulled. This means that when the socket is closed later, the socket teardown logic will think that there is a pool attached to the socket and try to decrease the refcount again, leading to a refcount underflow. I chose this fix as it involved adding just a single line. Another option would have been to move xp_get_pool() and the assignment of xs->pool to after the if-statement and using xs_umem->pool instead of xs->pool in the whole if-statement resulting in somewhat simpler code, but this would have led to much more churn in the code base perhaps making it harder to backport. (CVE-2023-53698)

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

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

  - serialarc_uart修复“arc_serial_probe”Smatch 报告中的 of_iomap 泄漏
    drivers/tty/serial/arc_uart.c:631 arc_serial_probe() 警告未在第 631 行发布来自 of_iomap() 的“port->membase”。在 arc_serial_probe() 中如果 uart_add_one_port() 失败port->membase 不会被释放从而可能导致资源泄漏。要修复此问题我将 of_iomap 替换为 devm_platform_ioremap_resource。
    (CVE-2023-53719)

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

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

  - ARM9317/1kexec使 smp 停止调用异步如果 hrtimer 中断触发错误则所有在线 cpu 将收到通知并将其设置为离线。但正如提交 19dbdcb8039c smp警告来自 softirq 上下文的函数调用所突出显示此调用不应与禁用的中断同步
    softdog发起错误内核错误 - 不同步软件监视程序定时器已过期警告CPU1 PID
    0 at kernel/smp.c:753 smp_call_function_many_cond unwind_backtrace: show_stack dump_stack_lvl __warn warn_slowpath_fmt smp_call_function_many_cond smp_call_function crash_smp_send_stop.part.0 machine_crash_shutdown __crash_kexec panic softdog_fire __hrtimer_run_queues hrtimer_interrupt Make the smp call for machine_crash_nonpanic_core() asynchronous. (CVE-2023-53712)

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

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

  - 已修复 Linux 内核中的下列漏洞：arm64: ftrace: fix module PLTs with mcount Li Huafei reports that mcount-based ftrace with module PLTs was broken by commit: a6253579977e4c6f (arm64: ftrace: consistently handle PLTs.) When a module PLTs are used and a module is loaded sufficiently far away from the kernel, we'll create PLTs for any branches which are out-of-range. These are separate from the special ftrace trampoline PLTs, which the module PLT code doesn't directly manipulate. When mcount is in use this is a problem, as each mcount callsite in a module will be initialized to point to a module PLT, but since commit a6253579977e4c6f ftrace_make_nop() will assume that the callsite has been initialized to point to the special ftrace trampoline PLT, and ftrace_find_callable_addr() rejects other cases. This means that when ftrace tries to initialize a callsite via ftrace_make_nop(), the call to ftrace_find_callable_addr() will find that the `_mcount` stub is out-of-range and is not handled by the ftrace PLT, resulting in a splat: | ftrace_test: loading out-of-tree module taints kernel. | ftrace: no module PLT for _mcount | ------------[ ftrace bug ]------------ | ftrace failed to modify | [<ffff800029180014>] 0xffff800029180014 | actual: 44:00:00:94 | Initializing ftrace call sites | ftrace record flags: 2000000 | (0) | expected tramp: ffff80000802eb3c | ------------[cut here ]------------ | WARNING: CPU: 3 PID: 157 at kernel/trace/ftrace.c:2120 ftrace_bug+0x94/0x270 | Modules linked in: | CPU: 3 PID: 157 Comm: insmod Tainted: G O 6.0.0-rc6-00151-gcd722513a189-dirty #22 | Hardware name: linux,dummy-virt (DT) | pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) | pc : ftrace_bug+0x94/0x270 | lr : ftrace_bug+0x21c/0x270 | sp : ffff80000b2bbaf0 | x29: ffff80000b2bbaf0 x28: 0000000000000000 x27: ffff0000c4d38000 | x26: 0000000000000001 x25: ffff800009d7e000 x24:
    ffff0000c4d86e00 | x23: 0000000002000000 x22: ffff80000a62b000 x21: ffff8000098ebea8 | x20:
    ffff0000c4d38000 x19: ffff80000aa24158 x18: ffffffffffffffff | x17: 0000000000000000 x16: 0a0d2d2d2d2d2d2d x15: ffff800009aa9118 | x14: 0000000000000000 x13: 6333626532303830 x12: 3030303866666666 | x11:
    203a706d61727420 x10: 6465746365707865 x9 : 3362653230383030 | x8 : c0000000ffffefff x7 : 0000000000017fe8 x6 : 000000000000bff4 | x5 : 0000000000057fa8 x4 : 0000000000000000 x3 : 0000000000000001 | x2 :
    ad2cb14bb5438900 x1 : 0000000000000000 x0 : 0000000000000022 | Call trace: | ftrace_bug+0x94/0x270 | ftrace_process_locs+0x308/0x430 | ftrace_module_init+0x44/0x60 | load_module+0x15b4/0x1ce8 |
    __do_sys_init_module+0x1ec/0x238 | __arm64_sys_init_module+0x24/0x30 | invoke_syscall+0x54/0x118 | el0_svc_common.constprop.4+0x84/0x100 | do_el0_svc+0x3c/0xd0 | el0_svc+0x1c/0x50 | el0t_64_sync_handler+0x90/0xb8 | el0t_64_sync+0x15c/0x160 | ---[ end trace 0000000000000000 ]--- |
    ---------test_init----------- Fix this by reverting to the old behaviour of ignoring the old instruction when initialising an mcount callsite in a module, which was the behaviour prior to commit a6253579977e4c6f. (CVE-2022-50579)

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

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

  - 在特定情况下由于使用的伪随机数发生器 (PRNG) 中存在漏洞攻击者可能预测 BIND 将使用的源端口和查询 ID。此问题会影响 BIND 9 版本 9.16.0 至 9.16.50、 9.18.0 至 9.18.39、 9.20.0 至 9.20.13、 9.21.0 至 9.21.12、9.16.8-S1 至 9.16.50-S1、9.18.11-S1 至 9.18。 39-S1 以及 9.20.9-S1 至 9.20.13-S1。
    (CVE-2025-40780)

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

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

  - s390/crypto仅在可用于 ChaCha20 Commit 349d03ffd5f6 时使用矢量指令 (cryptos390 - 添加用于 ChaCha20 的 crypto 库接口向 s390 特定的 ChaCha20 实现添加了一个库接口。但是，未添加任何检查，无法在分支到组装器代码之前验证是否安装了所需的设施。若编译至内核且向量指令不可用时将导致以下崩溃 data exception: 0007 ilc:3 [#1] SMP Modules 中链接的 CPU: 0 PID:
    1 Comm: swapper/0 未受感染 6.3.0-rc7+ #11 硬件名称IBM 3931 A01 704 (KVM/Linux) Krnl PSW
    0704e00180000000 000000001857277a (chacha20_vx+0x32/0x818) R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:2 PM:0 RI:0 EA:3 Krnl GPRS : 0000037f0000000a ffffffffffffff60 000000008184b000 0000000019f5c8e6 0000000000000109 0000037fffb13c58 0000037fffb13c78 0000000019bb1780 0000037fffb13c58 0000000019f5c8e6 000000008184b000 0000000000000109 00000000802d8000 0000000000000109 0000000018571ebc 0000037fffb13718 Krnl Code: 000000001857276a: c07000b1f80b larl %r7,0000000019bb1780 0000000018572770: a708000a lhi %r0,10 #0000000018572774: e78950000c36 vlm %v24,%v25,0(% r5),0 >000000001857277a: e7a060000806 vl %v26,0(%r6),0 0000000018572780: e7bf70004c36 vlm %v27,%v31,0(%r7),4 0000000018572786: e70b00000456 vlr %v0,%v27 000000001857278c: e71800000456 vlr % v1%v24 0000000018572792e74b00000456 vlr %v4%v27 调用跟踪
    [<000000001857277a>] chacha20_vx+0x32/0x818 最后中断事件地址[<0000000018571eb6>] chacha20_crypt_s390.constprop.0+0x6e/0xd8 ---[ end trace 0000000000000000 ]--- 内核错误 - 不同步
    尝试终止 init!exitcode=0x0000000b 通过添加缺少的 MACHINE_HAS_VX 检查修复此问题。
    [agordeev@linux.ibm.com删除提交消息中的重复项] (CVE-2023-53702)

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

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

  - mtd修复 add_mtd_device() 中注册设备失败时存在 kmemleak 注册设备失败时存在 kmemleak: 未引用的对象 0xffff888101aab550 (大小 8)comm insmod、pid 3922、jiffies 4295277753(age 925.408s) 十六进制转储前 8 bytes)6d 74 64 30 00 88 ff ff mtd0.... 回溯
    [<00000000bde26724>] __kmalloc_node_track_caller+0x4e/0x150 [<000000003c32b416>] kvasprintf+0xb0/0x130 [<000000001f7a8f15>] kobject_set_name_vargs+0x2f/0xb0 [<000000006e781163>] dev_set_name+0xab/0xe0 [<00000000e30d0c78>] add_mtd_device+0x4bb/0x700 [<00000000f3d34de7>] mtd_device_parse +0x2ac/0x3f0 [<00000000c0d88488>] 0xffffffffa0238457 [<00000000b40d0922>] 0xffffffffa02a008f [<0000000023d17b9d>] do_one_initcall+0x87/0x2a0 [<00000000770f6ca6>] do_init_module+0xdf/0x320 [<000000007b6768fe>] load_module+0x2f98/0x3330 [<00000000346bed5a>]/0x10_sys_finit [<00000000674c2290>] do_syscall_64+0x35/0x80 [<000000004c6a8d97>] entry_SYSCALL_64_after_hwframe+0x46/0xb0 如果注册设备失败应调用 put_device() 以放弃引用。 (CVE-2022-50566)

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

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

  - dm Thin修复 run_timer_softirq() 中的 UAF当 dm_resume() 和 dm_destroy() 并发时将导致 UAF具体如下 BUGKASAN__run_timers+0x173/0x710 处的 __run_timers+0x173/0x710 写入中存在释放后使用addr ffff88816d9490f0 by task swapper/0/0 <snip> Call Trace: <IRQ> dump_stack_lvl+0x73/0x9f print_report.cold+0x132/0xaa2 _raw_spin_lock_irqsave+0xcd/0x160 __run_timers+0x173/0x710 kasan_report+0xad/0x110 __run_timers+0x173/0x710 __asan_store8+ 0x9c/0x140 __run_timers+0x173/0x710 call_timer_fn+0x310/0x310 pvclock_clocksource_read+0xfa/0x250 kvm_clock_read+0x2c/0x70 kvm_clock_get_cycles+0xd/0x20 ktime_get+0x5c/0x110 lapic_next_event+0x38/0x50 clockevents_program_event+0xf1/0x1e0 run_timer_softirq+0x49/0x90 __do_softirq+ 0x16e/0x62c
    __irq_exit_rcu+0x1fa/0x270 irq_exit_rcu+0x12/0x20 sysvec_apic_timer_interrupt+0x8e/0xc0 其中一个并发 UAF 显示如下使用空闲 do_resume | __find_device_hash_cell | __find_device_hash_cell | __find_device_hash_cell dm_get | dm_get atomic_inc(&md->holders) | atomic_inc(&md->holders) | atomic_inc(&md->holders) | dm_destroy | __dm_destroy | if (!dm_suspended_md(md)) | if (!dm_suspended_md(md)) | if (!dm_suspended_md(md)) atomic_read(&md->holders) | dm_resume | msleep(1) __dm_resume | dm_table_resume_targets | pool_resume | do_waker #add 延迟工作 | dm_put | dm_put atomic_dec(&md->holders) | atomic_dec(&md->holders) | atomic_dec(&md->holders) | dm_table_destroy | pool_dtr | pool_dtr __pool_dec | __pool_destroy | destroy_workqueue | destroy_workqueue kfree(pool) # 释放池超时 __do_softirq run_timer_softirq # 池时已经释放 使用1. create Thin-pool 2. dmsetup suspend pool 3. dmsetup resume pool 4. dmsetup remove_all # Concurrent with 3 可轻松重现此问题造成此 UAF 缺陷的原因是 dm_destroy() 由于暂停状态而跳过取消定时器之后dm_resume() 添加定时器。超时后它将调用 run_timer_softirq()但池已被释放。会发生并发 UAF 缺陷因此__pool_destroy() 中会再次取消定时器。 (CVE-2022-50563)

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

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

  - 已修复 Linux 内核中的下列漏洞：NFS: Fix a potential data corruption We must ensure that the subrequests are joined back into the head before we can retransmit a request. If the head was not on the commit lists, because the server wrote it synchronously, we still need to add it back to the retransmission list. Add a call that mirrors the effect of nfs_cancel_remove_inode() for O_DIRECT. (CVE-2023-53711)

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

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

  - blk-throttle防止计算等待时间时的溢出。通过在 tg_with_in_bps_limit() 中进行代码审查发现一个问题“bps_limit * jiffy_elapsed_rnd”可能溢出。通过调用 mul_u64_u64_div_u64() 修复此问题。 (CVE-2022-50580)

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

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

  - 已修复 Linux 内核中的下列漏洞：iio: fix memory leak in iio_device_register_eventset() When iio_device_register_sysfs_group() returns failed, iio_device_register_eventset() needs to free attrs array. Otherwise, kmemleak would scan & report memory leak as below: unreferenced object 0xffff88810a1cc3c0 (size 32): comm 100-i2c-vcnl302, pid 728, jiffies 4295052307 (age 156.027s) backtrace: __kmalloc+0x46/0x1b0 iio_device_register_eventset at drivers/iio/industrialio-event.c:541 __iio_device_register at drivers/iio/industrialio-core.c:1959
    __devm_iio_device_register at drivers/iio/industrialio-core.c:2040 (CVE-2022-50561)

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

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

  - udf检测链接到目录层次的系统 inode。UDF 文件系统损坏时隐藏的系统 inode 可链接到目录层次这是造成进一步严重的文件系统损坏和内核混淆的途径如 syzbot 模糊图像所注意到。拒绝访问链接到目录层次结构的系统 inode，反之亦然。 (CVE-2023-53695)

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

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

  - tpmacpi调用 acpi_put_table() 以修复内存泄漏 事件日志区域的起始位置和长度是从 TPM2 或 TCPA 表中获取所以我们调用 acpi_get_table() 来获取 ACPI 信息但应结合 acpi_get_table()通过 acpi_put_table() 以释放 ACPI 内存正确添加 acpi_put_table() 以修复内存泄漏。同时删除 tpm_read_log_acpi() 末尾的多余空行。 (CVE-2022-50562)

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

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

  - 已修复 Linux 内核中的下列漏洞：regmap-irq: Use the new num_config_regs property in regmap_add_irq_chip_fwnode Commit faa87ce9196d (regmap-irq: Introduce config registers for irq types) added the num_config_regs, then commit 9edd4f5aee84 (regmap-irq: Deprecate type registers and virtual registers) suggested to replace num_type_reg with it. However, regmap_add_irq_chip_fwnode wasn't modified to use the new property. Later on, commit 255a03bb1bb3 (ASoC:
    wcd9335: Convert irq chip to config regs) removed the old num_type_reg property from the WCD9335 driver's struct regmap_irq_chip, causing a null pointer dereference in regmap_irq_set_type when it tried to index d->type_buf as it was never allocated in regmap_add_irq_chip_fwnode: [ 39.199374] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 [ 39.200006] Call trace: [ 39.200014] regmap_irq_set_type+0x84/0x1c0 [ 39.200026] __irq_set_trigger+0x60/0x1c0 [ 39.200040]
    __setup_irq+0x2f4/0x78c [ 39.200051] request_threaded_irq+0xe8/0x1a0 Use num_config_regs in regmap_add_irq_chip_fwnode instead of num_type_reg, and fall back to it if num_config_regs isn't defined to maintain backward compatibility. (CVE-2022-50558)

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

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

  - 已修复 Linux 内核中的下列漏洞：arm64: sme: Use STR P to clear FFR context field in streaming SVE mode The FFR is a predicate register which can vary between 16 and 256 bits in size depending upon the configured vector length. When saving the SVE state in streaming SVE mode, the FFR register is inaccessible and so commit 9f5848665788 (arm64/sve: Make access to FFR optional) simply clears the FFR field of the in-memory context structure. Unfortunately, it achieves this using an unconditional 8-byte store and so if the SME vector length is anything other than 64 bytes in size we will either fail to clear the entire field or, worse, we will corrupt memory immediately following the structure. This has led to intermittent kfence splats in CI [1] and can trigger kmalloc Redzone corruption messages when running the 'fp-stress' kselftest: | ============================================================================= | BUG kmalloc-1k (Not tainted): kmalloc Redzone overwritten |
    ----------------------------------------------------------------------------- | | 0xffff000809bf1e22-0xffff000809bf1e27 @offset=7714. First byte 0x0 instead of 0xcc | Allocated in do_sme_acc+0x9c/0x220 age=2613 cpu=1 pid=531 | __kmalloc+0x8c/0xcc | do_sme_acc+0x9c/0x220 | ... Replace the 8-byte store with a store of a predicate register which has been zero-initialised with PFALSE, ensuring that the entire field is cleared in memory. [1] https://lore.kernel.org/r/CA+G9fYtU7HsV0R0dp4XEH5xXHSJFw8KyDf5VQrLLfMxWfxQkag@mail.gmail.com(CVE-2023-53713)

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

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

  - 已修复 Linux 内核中的下列漏洞：ima: Fix memory leak in
    __ima_inode_hash() Commit f3cc6b25dcc5 (ima: always measure and audit files in policy) lets measurement or audit happen even if the file digest cannot be calculated. As a result, iint->ima_hash could have been allocated despite ima_collect_measurement() returning an error. Since ima_hash belongs to a temporary inode metadata structure, declared at the beginning of __ima_inode_hash(), just add a kfree() call if ima_collect_measurement() returns an error different from -ENOMEM (in that case, ima_hash should not have been allocated). (CVE-2022-50577)

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

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

  - 在某些情况下BIND 在接受来自答案的记录时过于宽松允许攻击者将伪造的数据注入缓存。此问题会影响 BIND 9 版本 9.11.0 至 9.16.50、 9.18.0 至 9.18.39、 9.20.0 至 9.20.13、 9.21.0 至 9.21.12、9.11.3-S1 至 9.16.50-S1、9.18.11-S1 至 9.18。 39-S1 以及 9.20.9-S1 至 9.20.13-S1。 (CVE-2025-40778)

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

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

  - 已修复 Linux 内核中的下列漏洞：xen/privcmd: Fix a possible warning in privcmd_ioctl_mmap_resource() As 'kdata.num' is user-controlled data, if user tries to allocate memory larger than(>=) MAX_ORDER, then kcalloc() will fail, it creates a stack trace and messes up dmesg with a warning. Call trace: -> privcmd_ioctl --> privcmd_ioctl_mmap_resource Add __GFP_NOWARN in order to avoid too large allocation warning. This is detected by static analysis using smatch. (CVE-2022-50575)

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

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

  - 已修复 Linux 内核中的下列漏洞：soc: qcom: qmi_encdec: Restrict string length in decode The QMI TLV value for strings in a lot of qmi element info structures account for null terminated strings with MAX_LEN + 1. If a string is actually MAX_LEN + 1 length, this will cause an out of bounds access when the NULL character is appended in decoding. (CVE-2023-53729)

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

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

  - 已修复 Linux 内核中的下列漏洞：clk: imx: clk-imx8mp: improve error handling in imx8mp_clocks_probe() Replace of_iomap() and kzalloc() with devm_of_iomap() and devm_kzalloc() which can automatically release the related memory when the device or driver is removed or unloaded to avoid potential memory leak. In this case, iounmap(anatop_base) in line 427,433 are removed as manual release is not required. Besides, referring to clk-imx8mq.c, check the return code of of_clk_add_hw_provider, if it returns negtive, print error info and unregister hws, which makes the program more robust. (CVE-2023-53704)

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

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

  - 已修复 Linux 内核中的下列漏洞：arm64: csum: Fix OoB access in IP checksum code for negative lengths Although commit c2c24edb1d9c (arm64: csum: Fix pathological zero-length calls) added an early return for zero-length input, syzkaller has popped up with an example of a
    _negative_ length which causes an undefined shift and an out-of-bounds read: | BUG: KASAN: slab-out-of-bounds in do_csum+0x44/0x254 arch/arm64/lib/csum.c:39 | Read of size 4294966928 at addr ffff0000d7ac0170 by task syz-executor412/5975 | | CPU: 0 PID: 5975 Comm: syz-executor412 Not tainted 6.4.0-rc4-syzkaller-g908f31f2a05b #0 | Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/25/2023 | Call trace: | dump_backtrace+0x1b8/0x1e4 arch/arm64/kernel/stacktrace.c:233 | show_stack+0x2c/0x44 arch/arm64/kernel/stacktrace.c:240 | __dump_stack lib/dump_stack.c:88 [inline] | dump_stack_lvl+0xd0/0x124 lib/dump_stack.c:106 | print_address_description mm/kasan/report.c:351 [inline] | print_report+0x174/0x514 mm/kasan/report.c:462 | kasan_report+0xd4/0x130 mm/kasan/report.c:572 | kasan_check_range+0x264/0x2a4 mm/kasan/generic.c:187 | __kasan_check_read+0x20/0x30 mm/kasan/shadow.c:31 | do_csum+0x44/0x254 arch/arm64/lib/csum.c:39 | csum_partial+0x30/0x58 lib/checksum.c:128 | gso_make_checksum include/linux/skbuff.h:4928 [inline] | __udp_gso_segment+0xaf4/0x1bc4 net/ipv4/udp_offload.c:332 | udp6_ufo_fragment+0x540/0xca0 net/ipv6/udp_offload.c:47 | ipv6_gso_segment+0x5cc/0x1760 net/ipv6/ip6_offload.c:119 | skb_mac_gso_segment+0x2b4/0x5b0 net/core/gro.c:141 | __skb_gso_segment+0x250/0x3d0 net/core/dev.c:3401 | skb_gso_segment include/linux/netdevice.h:4859 [inline] | validate_xmit_skb+0x364/0xdbc net/core/dev.c:3659 | validate_xmit_skb_list+0x94/0x130 net/core/dev.c:3709 | sch_direct_xmit+0xe8/0x548 net/sched/sch_generic.c:327 | __dev_xmit_skb net/core/dev.c:3805 [inline] | __dev_queue_xmit+0x147c/0x3318 net/core/dev.c:4210 | dev_queue_xmit include/linux/netdevice.h:3085 [inline] | packet_xmit+0x6c/0x318 net/packet/af_packet.c:276 | packet_snd net/packet/af_packet.c:3081 [inline] | packet_sendmsg+0x376c/0x4c98 net/packet/af_packet.c:3113 | sock_sendmsg_nosec net/socket.c:724 [inline] | sock_sendmsg net/socket.c:747 [inline] | __sys_sendto+0x3b4/0x538 net/socket.c:2144 Extend the early return to reject negative lengths as well, aligning our implementation with the generic code in lib/checksum.c (CVE-2023-53726)

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

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

  - ring-buffer处理 rb_move_tail 和 rb_check_pages 之间的争用 ring_buffer 写入和完整性检查之间似乎存在数据争用。即head_page 的 RB_FLAG 一直更新而同时 RB_FLAG 在执行完整性检查时已清除 rb_check_pages()rb_check_pages() rb_handle_head_page()--------
    -------- rb_head_page_deactivate() rb_head_page_set_normal() rb_head_page_activate() 我们对列表进行完整性测试以检查列表是否已损坏以及是否仍然值得这样做。因此让我们重构 rb_check_pages()以便在列表健全性检查期间不再清除和设置 标记。 [1] 和 [2] 分别是要重现的测试和崩溃报告。 1true 时为 `" read_trace.sh do # 读取 head -1 /sys/kernel/tracing/trace > /dev/null Done 之后关闭跟踪文件 `` `` repro.sh sysctl -w kernel.panic_on_warn=1 # 函数跟踪程序将写入足够的数据进入 ring_buffer echo 函数 > /sys/kernel/tracing/current_tracer ./read_trace.sh & ./read_trace.sh & ./read_trace.sh & ./read_trace.sh & ./read_trace.sh & ./read_trace.sh & 。 /read_trace.sh & ./read_trace.sh & “” 2------------[在此剪切]------------ 警告CPU9 PID : 62 at kernel/trace/ring_buffer.c:2653 rb_move_tail+0x450/0x470 模块中链接的 CPU: 9 PID: 62 Comm: ksoftirqd/9 受感染: GW 6.2.0-rc6+ 硬件名称: QEMU Standard PC (i440FX + PIIX 、1996、BIOS rel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014 RIP
    0010:rb_move_tail+0x450/0x470 代码 ff ff 4c 89 c8 f0 4d 0f b1 02 48 89 c2 48 83 e2 fc 49 39 d0 75 24 83 e0 03 83 f8 02 0f 84 e1 fb ff ff 48 8b0 ff 42 f 08 <0f> 0b 83 f8 02 0f 84 ce fb ff ff e9 db RSP
    0018:ffffb5564089bd00 EFLAGS: 00000203 RAX: 0000000000000000 RBX: ffff9db385a2bf81 RCX: ffffb5564089bd18 RDX: ffff9db281110100 RSI: 0000000000000fe4 RDI: ffff9db380145400 RBP: ffff9db385a2bf80 R08:
     R09ffff9db385a2bfc0  : ffff9db385a2bfc2 R10: ffff9db385a6c000 R11: ffff9db385a2bf80 R12: 0000000000000000 R13: 00000000000003e8 R14: ffff9db281110100 R15: ffffffffbb006108 FS: 0000000000000000(0000) GS:ffff9db3bdcc0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES0000 CR00000000080050033 CR2
    00005602323024c8 CR3: 0000000022e0c000 CR4: 00000000000006e0 Call Trace: <TASK> ring_buffer_lock_reserve+0x136/0x360 __do_softirq+0x287/0x2df ? __pfx_rcu_softirq_qs+0x10/0x10 trace_function+0x21/0x110 ? __pfx_rcu_softirq_qs+0x10/0x10 ? __do_softirq+0x287/0x2df function_trace_call+0xf6/0x120 0xffffffffc038f097 rcu_softirq_qs+0x5/0x140 rcu_softirq_qs+0x5/0x140
    __do_softirq+0x287/0x2df run_ksoftirqd+0x2a/0x30 smpboot_thread_fn+0x188/0x220
    __pfx_smpboot_thread_fn+0x10/0x10 kthread+0xe7/0x110 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x2c/0x50 </TASK> ---[ end trace 0000000000000000 ]--- [崩溃报告和测试重现者感谢 Zheng Yejian] (CVE-2023-53709]

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

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

  - mdraid1修复 raid1_remove_disk() 中潜在的 OOB 如果 rddev->raid_disk 大于 mddev->raid_disks则 raid1_remove_disk() 中将存在越界。我们已发现类似的报告如下
    1) commit d17f744e883bmd-raid10修复 KASAN 警告2) 提交 1ebc2cec0b7ddm raid修复 raid5_remove_disk 中的 KASAN 警告 通过检查 number 变量是否有效来修复此缺陷。
    (CVE-2023-53722)

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

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

  - 已修复 Linux 内核中的下列漏洞：net: fix skb leak in __skb_tstamp_tx() Commit 50749f2dd685 (tcp/udp: Fix memleaks of sk and zerocopy skbs with TX timestamp.) added a call to skb_orphan_frags_rx() to fix leaks with zerocopy skbs. But it ended up adding a leak of its own. When skb_orphan_frags_rx() fails, the function just returns, leaking the skb it just cloned. Free it before returning. This bug was discovered and resolved using Coverity Static Analysis Security Testing (SAST) by Synopsys, Inc. (CVE-2023-53716)

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

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

  - xfrm释放 ipcomp_scratches 时用 NULL 更新目前如果 ipcomp_alloc_scratches() 无法分配内存ipcomp_scratches 会保留过时地址。因此当我们尝试使用 ipcomp_free_scratches() 释放 percpu 擦除时它会尝试 vfree 不存在的 vm 区域。描述如下static void * __percpu
    *ipcomp_alloc_scratches(void) { ...cratches = alloc_percpu(void *); if (!scratches) 返回 NULL ；
    ipcomp_scratches 不知道此分配失败。因此保留了旧的过时地址。
    因此当我们释放时 static void ipcomp_free_scratches(void) { ...cratches = ipcomp_scratches;
    如果 (!scratches) 返回则分配 ipcomp_scratches 中过时的地址for_each_possible_cpu(i) vfree(*per_cpu_ptr(scratches, i));尝试释放不存在的页面造成警告尝试释放现有的 vm 区域。 ... } 通过在释放 Scratch 时将 ipcomp_scrtches 更新为 NULL 来修复此损坏 (CVE-2022-50569)

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

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

  - drm修复由于 drmm_mode_config_init() 造成的潜在 null-ptr-derefdrmm_mode_config_init() 将调用 drm_mode_create_standard_properties() 并且不会检查 ret 值。当 drm_mode_create_standard_properties() 因 alloc 而失败时属性将为空指针并可能造成 null-ptr-deref。通过添加 ret 值检查修复 null-ptr-deref。测试插入模块时发现 null-ptr-deref bochs一般保护错误可能可能是非规范地址 0xdffffc000000000c: 0000 [#1] SMP KASAN PTI KASAN范围 [0x0000000000000060-0x0000000000000067] CPU 中存在 null-ptr-deref 249 Comm: modprobe 未受感染 6.1.0-rc1+ #364 硬件名称QEMU Standard PC (i440FX + PIIX,1996)BIOS rel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org04/01/2014 RIP 0010drm_object_attach_property+0x73/0x3c0 [drm] 调用跟踪 <TASK>
    __drm_connector_init+0xb6c/0x1100 [drm] bochs_pci_probe.cold.11+0x4cb/0x7fe [bochs] pci_device_probe+0x17d/0x340 really_probe+0x1db/0x5d0 __driver_probe_device+0x1e7/0x250 driver_probe_device+0x4a/0x120 __driver_attach+0xcd/0x2c0 bus_for_each_dev+0x11a/0x1b0 bus_add_driver+0x3d7/0x500 driver_register+0x18e/0x320 do_one_initcall+0xc4/0x3e0 do_init_module+0x1b4/0x630 load_module+0x5dca/0x7230 __do_sys_finit_module+0x100/0x170 do_syscall_64+0x3f/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP: 0033:0x7ff65af9f839 (CVE-2022-50556)

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

ID	名称	严重性
271636	Linux Distros 未修补的漏洞：CVE-2025-11979	medium
271635	Linux Distros 未修补的漏洞：CVE-2025-60361	low
271634	Linux Distros 未修补的漏洞：CVE-2025-62699	medium
271633	Linux Distros 未修补的漏洞：CVE-2025-62657	medium
271632	Linux Distros 未修补的漏洞：CVE-2025-12036	high
271631	Linux Distros 未修补的漏洞：CVE-2025-60360	medium
271630	Linux Distros 未修补的漏洞：CVE-2025-62701	medium
271629	Linux Distros 未修补的漏洞：CVE-2025-62700	medium
271628	Linux Distros 未修补的漏洞：CVE-2025-62656	medium
271627	Linux Distros 未修补的漏洞：CVE-2025-62696	medium
271626	Linux Distros 未修补的漏洞：CVE-2025-62694	medium
271625	Linux Distros 未修补的漏洞：CVE-2025-62693	medium
271624	Linux Distros 未修补的漏洞：CVE-2025-60359	medium
271623	Linux Distros 未修补的漏洞：CVE-2023-53710	medium
271622	Linux Distros 未修补的漏洞：CVE-2023-53730	medium
271621	Linux Distros 未修补的漏洞：CVE-2023-53708	medium
271620	Linux Distros 未修补的漏洞：CVE-2023-53692	high
271619	Linux Distros 未修补的漏洞：CVE-2023-53718	medium
271618	Linux Distros 未修补的漏洞：CVE-2023-53696	medium
271617	Linux Distros 未修补的漏洞：CVE-2023-53728	medium
271616	Linux Distros 未修补的漏洞：CVE-2022-50578	medium
271615	Linux Distros 未修补的漏洞：CVE-2023-53717	high
271614	Linux Distros 未修补的漏洞：CVE-2023-53697	high
271613	Linux Distros 未修补的漏洞：CVE-2025-8677	high
271612	Linux Distros 未修补的漏洞：CVE-2023-53698	high
271610	Linux Distros 未修补的漏洞：CVE-2023-53719	medium
271609	Linux Distros 未修补的漏洞：CVE-2023-53712	medium
271608	Linux Distros 未修补的漏洞：CVE-2022-50579	high
271607	Linux Distros 未修补的漏洞：CVE-2025-40780	high
271606	Linux Distros 未修补的漏洞：CVE-2023-53702	medium
271605	Linux Distros 未修补的漏洞：CVE-2022-50566	medium
271604	Linux Distros 未修补的漏洞：CVE-2022-50563	high
271603	Linux Distros 未修补的漏洞：CVE-2023-53711	high
271602	Linux Distros 未修补的漏洞：CVE-2022-50580	high
271601	Linux Distros 未修补的漏洞：CVE-2022-50561	medium
271600	Linux Distros 未修补的漏洞：CVE-2023-53695	high
271599	Linux Distros 未修补的漏洞：CVE-2022-50562	medium
271598	Linux Distros 未修补的漏洞：CVE-2022-50558	medium
271597	Linux Distros 未修补的漏洞：CVE-2023-53713	medium
271596	Linux Distros 未修补的漏洞：CVE-2022-50577	medium
271595	Linux Distros 未修补的漏洞：CVE-2025-40778	high
271594	Linux Distros 未修补的漏洞：CVE-2022-50575	medium
271593	Linux Distros 未修补的漏洞：CVE-2023-53729	medium
271592	Linux Distros 未修补的漏洞：CVE-2023-53704	medium
271591	Linux Distros 未修补的漏洞：CVE-2023-53726	high
271590	Linux Distros 未修补的漏洞：CVE-2023-53709	medium
271589	Linux Distros 未修补的漏洞：CVE-2023-53722	high
271588	Linux Distros 未修补的漏洞：CVE-2023-53716	medium
271587	Linux Distros 未修补的漏洞：CVE-2022-50569	medium
271586	Linux Distros 未修补的漏洞：CVE-2022-50556	medium

检测

Nessus 的 Misc. 系列

medium

low

medium

medium

high

medium

medium

medium

medium

medium

medium

medium

medium

medium

medium

medium

high

medium

medium

medium

medium

high

high

high

high

medium

medium

high

high

medium

medium

high

high

high

medium

high

medium

medium

medium

medium

high

medium

medium

medium

high

medium

high

medium

medium

medium