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

  - Omnibox 中的不当实现。 (CVE-2025-11213)

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

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

  - Omnibox 中的不当实现。 (CVE-2025-11209)

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

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

  - ext4在 DIO 写入之后创建内联数据时避免崩溃使用直接 IO 创建和写入 inode 时不执行任何操作清除 EXT4_STATE_MAY_INLINE_DATA 标记。因此当 inode 稍后被截断为 1 个字节并使用正常写入方式写入时我们将尝试将数据存储为内联数据。这会混淆之后的代码因为 inode 现在同时分配了普通块和内联数据并且混淆会显示为 kernel BUG at fs/ext4/inode.c:2721!无效 opcode0000 [#1] PREEMPT SMP KASAN CPU: 0 PID: 359 Comm: repro Not tainted 5.19.0-rc8-00001-g31ba1e3b8305-dirty #15 硬件名称
    QEMU Standard PC (i440FX + PIIX, 1996)、BIOS 1.16.0-1.fc36 04/01/2014 RIP
    0010:ext4_writepages+0x363d/0x3660 RSP0018:ffffc90000ccf260 EFLAGS00010293 RAX: ffffffff81e1abcd RBX
    0000008000000000 RCX: ffff88810842a180 RDX: 0000000000000000 RSI: 0000008000000000 RDI: 0000000000000000 RBP: ffffc90000ccf650 R08: ffffffff81e17d58 R09: ffffed10222c680b R10: dfffe910222c680c R11:
     R121ffff110222c680a  : ffff888111634128 R13: ffffc90000ccf880 R14: 0000008410000000 R15: 0000000000000001 FS: 00007f72635d2640(0000) GS:ffff88811b000000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000565243379180 CR3: 000000010aa74000 CR4: 0000000000150eb0 Call Trace: <TASK> do_writepages+0x397/0x640 filemap_fdatawrite_wbc+0x151/0x1b0 file_write_and_wait_range+0x1c9/0x2b0 ext4_sync_file+0x19e/0xa00 vfs_fsync_range+0x17b/0x190 ext4_buffered_write_iter+0x488/0x530 ext4_file_write_iter+0x449/0x1b90 vfs_write+0xbcd/0xf40 ksys_write+ 0x198/0x2c0 __x64_sys_write+0x7b/0x90 do_syscall_64+0x3d/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd </TASK> 通过对文件执行直接 IO 写入通过清除 EXT4_STATE_MAY_INLINE_DATA 来修复此问题。 (CVE-2022-50435)

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

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

  - ext4修复快速提交区块填充中的差一错误 由于多个不同的差一错误或者可能由于后期的设计变更未完全反映在实际合并的代码中关于如何用 tlv 条目填充快速提交区块有几个很奇怪的限制- 即使最小 tlv 长度为 8仍必须在区块结束前至少 10 个字节开始。
    否则，重放代码将忽略它们。缺陷如果使用长度为 blocksize - 9 或 blocksize - 8 的调用ext4_fc_reserve_space() 可能会违反此要求。幸运的是目前似乎不会发生这种情况。 - tlvs 必须在区块结束前至少 1 个字节结束。否则回放代码将认为它们无效。此 quirk 导致了一个缺陷已由较早的提交修复其中未初始化的内存在区块的最后一个字节中被泄漏到磁盘。此外奇怪的是这些限制不适用于 e2fsprogs 中的重放代码该代码将接受区块中的任何 tlvs完全没有边界检查但这是一个单独的问题...。鉴于这似乎都是一个缺陷我们来通过以自然方式使用 tlv 条目填充区块来修复它请注意旧内核将无法重播具有此提交的内核所创建的快速提交日志。 (CVE-2022-50428)

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

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

  - mediacx23885修复 buffer_prepare() 和 buffer_finish() 中的 null-ptr-deref 缺陷当驱动程序调用 cx23885_risc_buffer() 以准备缓冲区时函数调用 dma_alloc_coherent 可能会失败从而导致空缓冲区 risc->cpu。稍后释放缓冲区或访问缓冲区时会触发空指针取消引用。
    此缺陷类似于以下缺陷
    https://git.linuxtv.org/media_stage.git/commit/?id=2b064d91440b33fba5b452f2d1b31f13ae911d71。我们认为也可从用户端动态触发此缺陷。同样，我们通过在缓冲区释放之前检查 cx23885_risc_buffer() 的返回值和 risc->cpu 的值来修复此问题。 (CVE-2023-53458)

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

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

  - 在 4.2.25 版之前的 Django 4.2、5.1.13 版之前的 Django 5.1 以及 5.2.7 版之前的 Django 5.2 中发现一个问题。startapp --template 和 startproject --template 命令使用的 django.utils.archive.extract() 函数允许通过文件路径与目标目录共享通用前缀的存档进行部分目录遍历。 (CVE-2025-59682)

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

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

  - nbd修复 ioctl arg 的不完整验证。我们测试后发现未经验证的 nbd_ioctl arg 会引起警报。类似下面的 UBSAN 警告 calltrace： UBSAN: Undefined Behaviour in fs/buffer.c:1709:35 signed Integer溢出: -9223372036854775808 - 1 cannot be present in type 'long long int' CPU: 3 PID: 2523 Comm: syz-executor .0 未受感染 4.19.90 #1 硬件名称linux,dummy-virt (DT) 调用跟踪
    dump_backtrace+0x0/0x3f0 arch/arm64/kernel/time.c:78 show_stack+0x28/0x38 arch/arm64/kernel/traps.c:158
    __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x170/0x1dc lib/dump_stack.c:118 ubsan_epilogue+0x18/0xb4 lib/ubsan.c:161 handle_overflow+0x188/0x1dc lib/ubsan.c:192
    __ubsan_handle_sub_overflow+0x34/0x44 lib/ubsan.c:206 __block_write_full_page+0x94c/0xa20 fs/buffer.c:1709 block_write_full_page+0x1f0/0x280 fs/buffer.c:2934 blkdev_writepage+0x34/0x40 fs/block_dev.c:607
    __writepage+0x68/0xe8 mm/page-writeback.c:2305 write_cache_pages+0x44c/0xc70 mm/page-writeback.c:2240 generic_writepages+0xdc/0x148 mm/page-writeback.c:2329 blkdev_writepages+0x2c/0x38 fs/block_dev .c:2114 do_writepages+0xd4/0x250 mm/page-writeback.c:2344 触发此警告的原因是
    __block_write_full_page() -> i_size_read(inode) - 1 溢出。 inode->i_size 在 __nbd_ioctl() 中分配
    -> nbd_set_size() -> bytesize。我们认为有必要限制 arg 的大小以防止错误。
    此外__nbd_ioctl() -> nbd_add_socket()arg 将转换为 int。假设 arg 的值为 0x80000000000000001)64 位计算机在执行强制转换后将变为 1这将返回意外结果。通过添加检查防止传递过大数字来修复此问题。 (CVE-2023-53513)

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

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

  - wifirtw88修复 rtw_usb_probe() drivers/net/wireless/realtek/rtw88/usb.c:876 rtw_usb_probe() 警告中的内存泄漏未在行上释放 ieee80211_alloc_hw() 的 'hw'811 通过修改返回来修复此问题跳转到 goto 语句。 (CVE-2023-53460)

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

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

  - mmcvub300修复警告 - 当 !TASK_RUNNING vub300_enable_sdio_irq() 用于互斥体并需要 TASK_RUNNING 时不调用阻断 ops。确保将当前标记为可休眠上下文的 TASK_RUNNING。 [77.554641] !TASK_RUNNING; 时不调用阻断 ops在 [<ffffffff92a72c1d>] sdio_irq_thread+0x17d/0x5b0 设置的 state=1 [ 77.554652] 警告CPU:2 PID1983在 kernel/sched/core.c:9813
    __might_sleep+0x116/0x160 [ 77.554905] CPU2 PID1983 Comm: ksdioirqd/mmc1 受感染: G OE 6.1.0-rc5 #1 [77.554910] 硬件名称Intel(R) Client Systems NUC8i7BEH/NUC8BEB、BIOS BECFL357.86A.0081.2020.0504.1834 05/04/2020 [ 77.554912] RIP: 0010:__might_sleep+0x116/0x160 [ 77.554920] RSP: 0018:ffff888107b7fdb8 EFLAGS: 00010282 [ 77.554923] RAX: 0000000000000000 RBX: ffff888118c1b740 RCX: 0000000000000000 [77.554926] RDX: 0000000000000001 RSI: 0000000000000004 RDI: ffffed1020f6ffa9 [ 77.554928] RBP
    ffff888107b7fde0 R080000000000000001 R09ffffed1043ea60ba [ 77.554930] R10ffff88821f5305cb R11
    ffffed1043ea60b9 R12ffffffff93aa3a60 [ 77.554932] R13000000000000011b R147ffffffffffffff R15
    ffffffffc0558660 [ 77.554934] FS: 0000000000000000(0000) GS:ffff88821f500000(0000) knlGS:0000000000000000 [ 77.554937] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 77.554939] CR2: 00007f8a44010d68 CR3:
    000000024421a003 CR4: 00000000003706e0 [ 77.554942] 调用跟踪[ 77.554944] <TASK> [ 77.554952] mutex_lock+0x78/0xf0 [ 77.554973] vub300_enable_sdio_irq+0x103/0x3c0 [vub300] [ 77.554981] [ 77.555006/] sdio_irq_thread+0x25c ] kthread+0x2b8/0x370 [ 77.555017] ret_from_fork+0x1f/0x30 [77.555023] </TASK> [ 77.555025] ---[ 结束跟踪 0000000000000000 ]--- (CVE-2022-50430)

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

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

  - 已修复 Linux 内核中的下列漏洞：wifi: mt76: mt7921: resource leaks at mt7921_check_offload_capability() Fixed coverity issue with resource leaks at variable fw going out of scope leaks the storage it points to mt7921_check_offload_capability(). Addresses-Coverity-ID: 1527806 (Resource leaks) (CVE-2022-50424)

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

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

  - start_kernel添加 __no_stack_protector 函数属性 Back 在讨论提交 a9a3ed1eff36x86修复 gcc-10 中的过早启动崩溃第三次尝试时我们讨论了对函数属性来按每个函数控制堆栈保护程序忽略的需求;此时 Clang 支持 no_stack_protector 但 GCC 不支持。此问题已在 gcc-11 中修复。现在 function 属性已经可用了让我们开始使用它。除非 boot_init_stack_canary 的调用程序由 -fno-stack-protector 编译否则需要使用此函数属性否则调用程序堆栈槽中存储的 canary 在调用 boot_init_stack_canary 时将有所不同。这将导致调用 __stack_chk_fail() 然后发生错误。 (CVE-2023-53491)

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

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

  - kernfs修复 __kernfs_remove 中的释放后使用 Syzkaller 设法针对同一个文件触发对 kernfs_remove_by_name_ns() 的并发调用从而导致 KASAN 检测到释放后使用。在 kernfs_drain() 期间释放根节点时会发生争用。为防止这种情况获取在调用 __kernfs_remove() 之前删除的对树根的额外引用。由 syzkaller 通过以下重现器发现需要 slab_nomergesyz_mount_image$ext4(0x0, &(0x7f0000000100)='./file0\x00', 0x100000, 0x0, 0x0, 0x0, 0x0) r0 = openat(0xffffffffffffff9c, & (0x7f0000000080)='/proc/self/exe\x00', 0x0, 0x0) close(r0) pipe2(&(0x7f0000000140)={0xffffffffffffffff,<r1=> 0xffffffffffffffff}、0x800mount$9p_fd(0x0, &(0x7f0000000040)='./file0\x00', &(0x7f00000000c0)、0x408、 &(0x7f0000000280)={'trans=fd,', {'rfdno', 0x3d 、r0}、0x2c、{'wfdno'、0x3d、r1}、0x2c、{[{@cache_loose}、{@mmap}、{@loose}、{@loose}、{@mmap}]、[{@mask ={'mask', 0x3d, '^MAY_EXEC'}}, {@fsmagic={'fsmagic', 0x3d, 0x10001}}, {@dont_hash}]}}) 报告示例
    ================================================== ================ 缺陷KASANkernfs_type include/linux/kernfs.h:335 中存在释放后使用 [内联] 缺陷KASANkernfs_leftmost_descendant 中存在释放后使用fs/kernfs/dir.c:1261 [内联] 缺陷KASAN__kernfs_remove.part.0+0x843/0x960 中的释放后使用 fs/kernfs/dir.c:1369 通过任务 syz 在地址 ffff8880088807f0 处执行大小为 2 的读取-executor.2/857 CPU0 PID857 Commsyz-executor.2 Not tainted 6.0.0-rc3-00363-g7726d4c3e60b #5 硬件名称QEMU Standard PC (i440FX + PIIX,1996)、BIOS 1.15.0-1 04 /01/2014 调用跟踪 <TASK> __dump_stack lib/dump_stack.c:88 [内联] dump_stack_lvl+0x6e/0x91 lib/dump_stack.c:106 print_address_description mm/kasan/report.c:317 [内联] print_report.cold+0x5e /0x5e5 mm/kasan/report.c:433 kasan_report+0xa3/0x130 mm/kasan/report.c:495 kernfs_type include/linux/kernfs.h:335 [内联] kernfs_leftmost_descendant fs/kernfs/dir.c:1261 [内联]
    __kernfs_remove.part.0+0x843/0x960 fs/kernfs/dir.c:1369 __kernfs_remove fs/kernfs/dir.c:1356 [inline] kernfs_remove_by_name_ns+0x108/0x190 fs/kernfs/dir.c:1589 sysfs_slab_add+0x103/ mm/slub.c:5943
    __kmem_cache_create+0x3e0/0x550 mm/slub.c:4899 create_cache mm/slab_common.c:229 [内联] kmem_cache_create_usercopy+0x167/0x2a0 mm/slab_common.c:335 p9_client_create+0xd4d/0x1190 net/9p/client.c:993 v9fs_session_init +0x1e6/0x13c0 fs/9p/v9fs.c:408 v9fs_mount+0xb9/0xbd0 fs/9p/vfs_super.c:126旧有_get_tree+0xf1/0x200 fs/fs_context.c:610 vfs_get_tree+0x85/0x2e0 fs/super.c 1530 do_new_mount fs/namespace.c:3040 [inline] path_mount+0x675/0x1d00 fs/namespace.c:3370 do_mount fs/namespace.c:3383 [inline] __do_sys_mount fs/namespace.c:3591 [inline] __se_sys_mount fs/namespace .c:3568 [inline] __x64_sys_mount+0x282/0x300 fs/namespace.c:3568 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x38/0x90 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP0033:0x7f725f983aed 代码02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 8c 4c 4c 48 9 ca 89 4d 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 0 1 48 RSP: 002b:00007f725f0f7028 EFLAGS: 00000246 ORIG_RAX: 00000000000000a5 RAX: ffffffffffffffda RBX: 00007f725faa3f80 RCX: 00007f725f983aed RDX
    00000000200000c0 RSI: 0000000020000040 RDI: 0000000000000000 RBP: 00007f725f9f419c R08: 0000000020000280 R09: 0000000000000000 R10: 0000000000000408 R11: 0000000000000246 R12: 0000000000000000 R13:
    0000000000000006 R1400007f725faa3f80 R1500007f725f0d7000 </TASK> 由任务 855 分配
    kasan_save_stack+0x1e/0x40 mm/kasan/common.c:38 kasan_set_track mm/kasan/common.c:45 [内联] set_alloc_info mm/kasan/common.c:437 [内联] __kasan_slab_alloc+0x66/0x80 mm/kasan/common .c:470 kasan_slab_alloc include/linux/kasan.h:224 [inline] slab_post_alloc_hook mm/slab.h:7 ---truncated--- (CVE-2022-50432)

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

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

  - ipv6在 nexthop 计算中添加所有同级的 lwtunnel encap 大小在函数 rt6_nlmsg_size() 中nexthop 的长度可通过将 fib6_info 的 nexthop 长度乘以同级进行计算计算。
    但是如果 fib6_info 没有 lwtunnel但同级有 lwtunnel则 nexthop 长度小于其应有的长度并将在 inet6_rt_notify() 中触发警告如下所示 WARNING: CPU: 0 PID: 6082 at net/ipv6/route .c:6180 inet6_rt_notify+0x120/0x130 ...... Call Trace: <TASK> fib6_add_rt2node+0x685/0xa30 fib6_add+0x96/0x1b0 ip6_route_add+0x50/0xd0 inet6_rtm_newroute+0x97/0xa0 rtnetlink_rcv_msg+0x156/0x3d0 netlink_rcv_skb+0x5a/0x110 netlink_unicast+0x246/0x350 netlink_sendmsg+0x250/0x4c0 sock_sendmsg+0x66/0x70
    ___sys_sendmsg+0x7c/0xd0 __sys_sendmsg+0x5d/0xb0 do_syscall_64+0x3f/0x90 entry_SYSCALL_64_after_hwframe+0x72/0xdc 此缺陷可通过脚本重现 ip -6 addr add 2002::2/64 dev ens2 ip -6 route add 100::/ 64 通过 2002::1 dev ens2 metric 100 for i in 10 20 30 40 50 60 70 do ip link add link ens2 name ipv_$i type ipvlan ip -6 addr add 2002::$i/64 dev ipv_$i ifconfig ipv_$i up did for i in 10 20 30 40 50 60;执行 ip -6 route append 100::/64 encap ip6 dst 2002::$i 通过 2002::1 dev ipv_$i metric 100 通过 2002::1 dev ipv_70 metric 100 完成 ip -6 route append 100::/64此修补程序通过添加使用 rt6_nh_nlmsg_size() 的每个同级的 nexthop_len 以修复此问题。 (CVE-2023-53477)

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

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

  - 在 4.2.25 版之前的 Django 4.2、5.1.13 版之前的 Django 5.1 以及 5.2.7 版之前的 Django 5.2 中发现一个问题。
    当使用带有字典扩展的适当构建的字典作为
    传递到这些方法的 **kwargs在 MySQL 和 MariaDB 中。 (CVE-2025-59681)

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

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

  - 已修复 Linux 内核中的下列漏洞：Bluetooth: hci_conn: Fix crash on hci_create_cis_sync When attempting to connect multiple ISO sockets without using DEFER_SETUP may result in the following crash: BUG: KASAN: null-ptr-deref in hci_create_cis_sync+0x18b/0x2b0 Read of size 2 at addr 0000000000000036 by task kworker/u3:1/50 CPU: 0 PID: 50 Comm: kworker/u3:1 Not tainted 6.0.0-rc7-02243-gb84a13ff4eda #4373 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.0-1.fc36 04/01/2014 Workqueue: hci0 hci_cmd_sync_work Call Trace: <TASK> dump_stack_lvl+0x19/0x27 kasan_report+0xbc/0xf0 ? hci_create_cis_sync+0x18b/0x2b0 hci_create_cis_sync+0x18b/0x2b0 ? get_link_mode+0xd0/0xd0 ? __ww_mutex_lock_slowpath+0x10/0x10 ? mutex_lock+0xe0/0xe0 ? get_link_mode+0xd0/0xd0 hci_cmd_sync_work+0x111/0x190 process_one_work+0x427/0x650 worker_thread+0x87/0x750 ? process_one_work+0x650/0x650 kthread+0x14e/0x180 ? kthread_exit+0x50/0x50 ret_from_fork+0x22/0x30 </TASK> (CVE-2022-50447)

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

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

  - HIDmultitouch修正 hidinput input_dev 名称的 devm 设备引用 为 input_dev 名称的 devm 分配引用 HID 设备而不是输入设备。引用 input_dev 会在未注册 input_dev 时导致释放后使用并随后触发依赖于该名称的 uevent。在触发 uevent 时devres 管理部门将释放该名称。使用 devm_kasprintf 以简化分配内存和格式化 input_dev 名称字符串的逻辑。
    (CVE-2023-53454)

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

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

  - 已修复 Linux 内核中的下列漏洞：RDMA/rxe: Fix unsafe drain work queue code If create_qp does not fully succeed it is possible for qp cleanup code to attempt to drain the send or recv work queues before the queues have been created causing a seg fault. This patch checks to see if the queues exist before attempting to drain them. (CVE-2023-53528)

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

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

  - 已修复 Linux 内核中的下列漏洞：mptcp: fix disconnect vs accept race Despite commit 0ad529d9fd2b (mptcp: fix possible divide by zero in recvmsg()), the mptcp protocol is still prone to a race between disconnect() (or shutdown) and accept. The root cause is that the mentioned commit checks the msk-level flag, but mptcp_stream_accept() does acquire the msk-level lock, as it can rely directly on the first subflow lock. As reported by Christoph than can lead to a race where an msk socket is accepted after that mptcp_subflow_queue_clean() releases the listener socket lock and just before it takes destructive actions leading to the following splat: BUG: kernel NULL pointer dereference, address: 0000000000000012 PGD 5a4ca067 P4D 5a4ca067 PUD 37d4c067 PMD 0 Oops: 0000 [#1] PREEMPT SMP CPU: 2 PID: 10955 Comm: syz-executor.5 Not tainted 6.5.0-rc1-gdc7b257ee5dd #37 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.el7 04/01/2014 RIP: 0010:mptcp_stream_accept+0x1ee/0x2f0 include/net/inet_sock.h:330 Code: 0a 09 00 48 8b 1b 4c 39 e3 74 07 e8 bc 7c 7f fe eb a1 e8 b5 7c 7f fe 4c 8b 6c 24 08 eb 05 e8 a9 7c 7f fe 49 8b 85 d8 09 00 00 <0f> b6 40 12 88 44 24 07 0f b6 6c 24 07 bf 07 00 00 00 89 ee e8 89 RSP: 0018:ffffc90000d07dc0 EFLAGS: 00010293 RAX: 0000000000000000 RBX: ffff888037e8d020 RCX: ffff88803b093300 RDX: 0000000000000000 RSI: ffffffff833822c5 RDI: ffffffff8333896a RBP:
    0000607f82031520 R08: ffff88803b093300 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000003e83 R12: ffff888037e8d020 R13: ffff888037e8c680 R14: ffff888009af7900 R15: ffff888009af6880 FS:
    00007fc26d708640(0000) GS:ffff88807dd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0:
    0000000080050033 CR2: 0000000000000012 CR3: 0000000066bc5001 CR4: 0000000000370ee0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7:
    0000000000000400 Call Trace: <TASK> do_accept+0x1ae/0x260 net/socket.c:1872 __sys_accept4+0x9b/0x110 net/socket.c:1913 __do_sys_accept4 net/socket.c:1954 [inline] __se_sys_accept4 net/socket.c:1951 [inline]
    __x64_sys_accept4+0x20/0x30 net/socket.c:1951 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x47/0xa0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 Address the issue by temporary removing the pending request socket from the accept queue, so that racing accept() can't touch them. After depleting the msk - the ssk still exists, as plain TCP sockets, re-insert them into the accept queue, so that later inet_csk_listen_stop() will complete the tcp socket disposal.
    (CVE-2023-53490)

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

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

  - drm/radeon驱动程序关闭时为 atombios 释放 iio 修复卸载 radeon 驱动程序时的 kmemleak 下
    未引用的对象 0xffff9f8608ede200 (size 512): comm systemd-udevd, pid 326, jiffies 4294682822 (age 716.338s) hex dump前 32 字节: 00 00 00 00 c4 aa ec aa 14 ab 00 00 00 00 00 00 ... 00 00 00 00 00 00 00 00 00 00 00 00<0000000062fadebe>00 00 00 00 .. ] kmem_cache_alloc_trace+0x2f1/0x500 [<00000000b6883cea>] atom_parse+0x117/0x230 [radeon] [<00000000158c23fd>] radeon_atombios_init+0xab/0x170 [radeon] [<00000000683f672e>] si_init+0x57/0x750 [radeon] [<00000000566cc31f>] radeon_device_init+0x559/ 0x9c0 [radeon] [<0000000046efabb3>] radeon_driver_load_kms+0xc1/0x1a0 [radeon] [<00000000b5155064>] drm_dev_register+0xdd/0x1d0 [<0000000045fec835>] radeon_pci_probe+0xbd/0x100 [radeon] [<00000000e69ecca3>] pci_device_probe+0xe1/0x160 [<0000000019484b76>] real_probe.part.0+0xc1/0x2c0 [<000000003f2649da>] __driver_probe_device+0x96/0x130 [<00000000231c5bb1>] driver_probe_device+0x24/0xf0 [<0000000000a42377>] __driver_attach+0x77/0x190 [<00000000d7574da6>] bus_for_each_dev+0x7f/0xd0 [<00000000633166d2>] driver_attach +0x1e/0x30 [<00000000313b05b8>] bus_add_driver+0x12c/0x1e0 iio 已在 atom_parse() 调用的 atom_index_iio() 中分配但在dirver 已关闭。通过在 radeon_atombios_fini() 中释放来修复此 kmemleak。 (CVE-2023-53453)

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

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

  - V8 中的差一错误。 (CVE-2025-11215)

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

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

  - 已修复 Linux 内核中的下列漏洞：net: sched: cake: fix null pointer access issue when cake_init() fails When the default qdisc is cake, if the qdisc of dev_queue fails to be inited during mqprio_init(), cake_reset() is invoked to clear resources. In this case, the tins is NULL, and it will cause gpf issue. The process is as follows: qdisc_create_dflt() cake_init() q->tins = kvcalloc(...) --->failed, q->tins is NULL ... qdisc_put() ... cake_reset() ... cake_dequeue_one() b = &q->tins[...] --->q->tins is NULL The following is the Call Trace information: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] RIP: 0010:cake_dequeue_one+0xc9/0x3c0 Call Trace: <TASK> cake_reset+0xb1/0x140 qdisc_reset+0xed/0x6f0 qdisc_destroy+0x82/0x4c0 qdisc_put+0x9e/0xb0 qdisc_create_dflt+0x2c3/0x4a0 mqprio_init+0xa71/0x1760 qdisc_create+0x3eb/0x1000 tc_modify_qdisc+0x408/0x1720 rtnetlink_rcv_msg+0x38e/0xac0 netlink_rcv_skb+0x12d/0x3a0 netlink_unicast+0x4a2/0x740 netlink_sendmsg+0x826/0xcc0 sock_sendmsg+0xc5/0x100
    ____sys_sendmsg+0x583/0x690 ___sys_sendmsg+0xe8/0x160 __sys_sendmsg+0xbf/0x160 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x46/0xb0 RIP: 0033:0x7f89e5122d04 </TASK> (CVE-2022-50452)

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

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

  - ASoCmediatek: mt8173pdata 就绪时启用 IRQ 如果设备重置后未直接恢复正常我们可能会在准备好处理 IRQ 之前就对其进行处理。 [ 2.334737] 无法处理来自虚拟地址 00000000000001e4 的不可读内存的内核读取 [ 2.522601] 调用跟踪[ 2.525040] regmap_read+0x1c/0x80 [ 2.528434] mt8173_afe_irq_handler+0x40/0xf0 ... [ 2.598921] start_kernel+ 0x338/0x42cCVE-2022-50439

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

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

  - cifs修复 cifs_flock() 中的 xid 泄漏 如果不是 flock应在返回 -ENOLCK 之前释放 xid否则xid将被泄漏。 (CVE-2022-50460)

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

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

  - 已修复 Linux 内核中的下列漏洞：usb: xhci: tegra: fix sleep in atomic call When we set the dual-role port to Host mode, we observed the following splat: [ 167.057718] BUG:
    sleeping function called from invalid context at include/linux/sched/mm.h:229 [ 167.057872] Workqueue:
    events tegra_xusb_usb_phy_work [ 167.057954] Call trace: [ 167.057962] dump_backtrace+0x0/0x210 [167.057996] show_stack+0x30/0x50 [ 167.058020] dump_stack_lvl+0x64/0x84 [ 167.058065] dump_stack+0x14/0x34 [ 167.058100] __might_resched+0x144/0x180 [ 167.058140] __might_sleep+0x64/0xd0 [ 167.058171] slab_pre_alloc_hook.constprop.0+0xa8/0x110 [ 167.058202] __kmalloc_track_caller+0x74/0x2b0 [ 167.058233] kvasprintf+0xa4/0x190 [ 167.058261] kasprintf+0x58/0x90 [ 167.058285] tegra_xusb_find_port_node.isra.0+0x58/0xd0 [ 167.058334] tegra_xusb_find_port+0x38/0xa0 [ 167.058380] tegra_xusb_padctl_get_usb3_companion+0x38/0xd0 [ 167.058430] tegra_xhci_id_notify+0x8c/0x1e0 [ 167.058473] notifier_call_chain+0x88/0x100 [ 167.058506] atomic_notifier_call_chain+0x44/0x70 [ 167.058537] tegra_xusb_usb_phy_work+0x60/0xd0 [ 167.058581] process_one_work+0x1dc/0x4c0 [ 167.058618] worker_thread+0x54/0x410 [ 167.058650] kthread+0x188/0x1b0 [ 167.058672] ret_from_fork+0x10/0x20 The function tegra_xusb_padctl_get_usb3_companion eventually calls tegra_xusb_find_port and this in turn calls kasprintf which might sleep and so cannot be called from an atomic context. Fix this by moving the call to tegra_xusb_padctl_get_usb3_companion to the tegra_xhci_id_work function where it is really needed.
    (CVE-2023-53475)

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

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

  - IB/hfi1修复热插拔删除期间可能的错误在热插拔删除期间更新计数器的工作可能会待定并且可能在内存释放后运行。释放内存前取消更新计数器工作。 (CVE-2023-53488)

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

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

  - 已修复 Linux 内核中的下列漏洞：io_uring: fix fget leak when fs don't support nowait buffered read Heming reported a BUG when using io_uring doing link-cp on ocfs2. [1] Do the following steps can reproduce this BUG: mount -t ocfs2 /dev/vdc /mnt/ocfs2 cp testfile /mnt/ocfs2/ ./link-cp /mnt/ocfs2/testfile /mnt/ocfs2/testfile.1 umount /mnt/ocfs2 Then umount will fail, and it outputs:
    umount: /mnt/ocfs2: target is busy. While tracing umount, it blames mnt_get_count() not return as expected. Do a deep investigation for fget()/fput() on related code flow, I've finally found that fget() leaks since ocfs2 doesn't support nowait buffered read. io_issue_sqe |-io_assign_file // do fget() first |-io_read |-io_iter_do_read |-ocfs2_file_read_iter // return -EOPNOTSUPP |-kiocb_done |-io_rw_done |-__io_complete_rw_common // set REQ_F_REISSUE |-io_resubmit_prep |-io_req_prep_async // override req->file, leak happens This was introduced by commit a196c78b5443 in v5.18. Fix it by don't re-assign req->file if it has already been assigned. [1] https://lore.kernel.org/ocfs2-devel/ab580a75-91c8-d68a-3455-40361be1bfa8@linux.alibaba.com/T/#t(CVE-2023-53511)

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

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

  - scsiqla2xxx修复潜在的空指针取消引用 Klocwork 工具报告的“cur_dsd”可能已取消引用。添加补丁以在取消引用指针之前验证指针。 (CVE-2023-53451)

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

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

  - qed允许 qed_mcp_trace_dump() 中的休眠 默认情况下qed_mcp_cmd_and_union() 在可运行 500K 次的循环中一次延迟 10us因此对 qed_mcp_nvm_rd_cmd() 的调用可能会将当前线程阻断 5s 以上。
    我们发现在生产环境中存在超过 700 毫秒的线程计划延迟其堆栈跟踪指向此代码为元首。从 ethtool 调用 qed_mcp_trace_dump()因此允许休眠。它已可在调用 qed_mcp_cmd() 的 qed_mcp_halt() 中休眠。向 qed_find_nvram_image() 和 qed_nvram_read() 添加休眠参数以便其在 qed_mcp_trace_dump() 期间休眠。 qed_mcp_trace_get_meta_info() 和 qed_mcp_trace_read_meta() 仅由 qed_mcp_trace_dump() 调用允许这些函数休眠。我无法判断其他调用程序 (qed_grc_dump_mcp_hw_dump()) 是否可以休眠因此在调用这些函数时请将 b_can_sleep 设置为 false。我们添加到内核的自定义警告中的一个示例堆栈跟踪，显示了一个线程尽管需要重新调度但尚未调度：[ 2745.362925,17] ------------[ 从此处剪切]------------ [ 2745.362941,17] 警告：CPU：23 PID：5640 at arch/x86/kernel/irq.c:233 do_IRQ+0x15e/0x1a0() [ 2745.362946,17] 线程在 irq 99 后 744 毫秒内未重新调度 [ 2745.362956,17] 链接的模块：... [ 2745.363339,17] CPU：23 PID：5640 通信：lldpd 污染：P O 4.4.182+ #202104120910+6d1da174272d.61x [ 2745.363343,17] 硬件名称：FOXCONN MercuryB/Quicksilver 控制器，BIOS H11P1N09 07/08/2020 [ 2745.363346,17] 0000000000000000 ffff885ec07c3ed8 ffffffff8131eb2f ffff885ec07c3f20 [ 2745.363358,17] ffffffff81d14f64 ffff885ec07c3f10 ffffffff81072ac2 ffff88be98ed0000 [2745.363369,17] 0000000000000063 0000000000000174 0000000000000074 0000000000000000 [ 2745.363379,17] 调用跟踪：[ 2745.363382,17] <IRQ> [<ffffffff8131eb2f>] dump_stack+0x8e/0xcf [ 2745.363393,17] [<ffffffff81072ac2>] warn_slowpath_common+0x82/0xc0 [ 2745.363398,17] [<ffffffff81072b4c>] warn_slowpath_fmt+0x4c/0x50 [ 2745.363404,17] [<ffffffff810d5a8e>] ? rcu_irq_exit+0xae/0xc0 [2745.363408,17] [<ffffffff817c99fe>] do_IRQ+0x15e/0x1a0 [ 2745.363413,17] [<ffffffff817c7ac9>] common_interrupt+0x89/0x89 [ 2745.363416,17] <EOI> [<ffffffff8132aa74>] ? delay_tsc+0x24/0x50 [2745.363425,17] [<ffffffff8132aa04>] __udelay+0x34/0x40 [ 2745.363457,17] [<ffffffffa04d45ff>] qed_mcp_cmd_and_union+0x36f/0x7d0 [qed] [ 2745.363473,17] [<ffffffffa04d5ced>] qed_mcp_nvm_rd_cmd+0x4d/0x90 [qed] [ 2745.363490,17] [<ffffffffa04e1dc7>] qed_mcp_trace_dump+0x4a7/0x630 [qed] [ 2745.363504,17] [<ffffffffa04e2556>] ? qed_fw_asserts_dump+0x1d6/0x1f0 [qed] [ 2745.363520,17] [<ffffffffa04e4ea7>] qed_dbg_mcp_trace_get_dump_buf_size+0x37/0x80 [qed] [ 2745.363536,17] [<ffffffffa04ea881>] qed_dbg_feature_size+0x61/0xa0 [qed] [ 2745.363551,17] [<ffffffffa04eb427>] qed_dbg_all_data_size+0x247/0x260 [qed] [ 2745.363560,17] [<ffffffffa0482c10>] qede_get_regs_len+0x30/0x40 [qede] [ 2745.363566,17] [<ffffffff816c9783>] ethtool_get_drvinfo+0xe3/0x190 [ 2745.363570,17] [<ffffffff816cc152>] dev_ethtool+0x1362/0x2140 [ 2745.363575,17] [<ffffffff8109bcc6>] ? finish_task_switch+0x76/0x260 [ 2745.363580,17] [<ffffffff817c2116>] ? __schedule+0x3c6/0x9d0 [2745.363585,17] [<ffffffff810dbd50>] ? hrtimer_start_range_ns+0x1d0/0x370 [ 2745.363589,17] [<ffffffff816c1e5b>] ? dev_get_by_name_rcu+0x6b/0x90 [ 2745.363594,17] [<ffffffff816de6a8>] dev_ioctl+0xe8/0x710 [ 2745.363599,17] [<ffffffff816a58a8>] sock_do_ioctl+0x48/0x60 [ 2745.363603,17] [<ffffffff816a5d87>] sock_ioctl+0x1c7/0x280 [ 2745.363608,17] [<ffffffff8111f393>] ? seccomp_phase1+0x83/0x220 [ 2745.363612,17] [<ffffffff811e3503>] do_vfs_ioctl+0x2b3/0x4e0 [2745.363616,17] [<ffffffff811e3771>] SyS_ioctl+0x41/0x70 [ 2745.363619,17] [<ffffffff817c6ffe>] entry_SYSCALL_64_fastpath+0x1e/0x79 [ 2745.363622,17] ---[ 结束跟踪 f6954aa440266421 ]--- (CVE-2023-53509)

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

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

  - scsises修复 ses_intf_remove() 中的 slab 越界 针对以下问题的补丁BUGKASANses_intf_remove+0x23f/0x270 中的 slab 越界 [ses] 通过任务读取 addr ffff88a10d32e5d8 中的大小 8 rmmod/12013 当 edev->components 为零时访问 edev->component[0] 成员是错误的。 (CVE-2023-53521)

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

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

  - iommu/amd/iommu_v2修复 pasid 取消绑定的 pasid_state refcount dec hit 0 警告。在取消绑定 pasid 时 - 存在一个争用条件与未解决的页面错误。为防止发生这种情况pasid_state 对象包含了 refcount。 * 在 pasid 绑定时设置为 1 * 在每个 ppr 通知开始时递增 * 在每个 ppr 通知完成时递减 * 在 pasid 取消绑定时递减 由于 refcount_dec 假设 refcount 永不达到 0当前实现导致在 pasid 取消绑定时调用以下内容: REFCOUNT_WARN递减命中 0泄露内存通过将 refcount_dec 更改为 refcount_dec_and_test 以明确处理 refcount=1来修复此问题。 (CVE-2023-53501)

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

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

  - Bluetooth修复 hci_suspend_sync 崩溃 如果 hci_unregister_dev() 释放了 hci_dev 对象但 hci_suspend_notifier 可能仍在访问它则可能导致程序崩溃。调用轨迹如下
    <4>[102152.653246] 调用跟踪 <4>[102152.653254] hci_suspend_sync+0x109/0x301 [蓝牙] <4>[102152.653259] hci_suspend_dev+0x78/0xcd [蓝牙] <4>[102152.653263] hci_suspend_notifier+0x42/0x7a [蓝牙] <4>[102152.653268] notifier_call_chain+0x43/0x6b <4>[102152.653271]
    __blocking_notifier_call_chain+0x48/0x69 <4>[102152.653273] __pm_notifier_call_chain+0x22/0x39 <4>[102152.653276] pm_suspend+0x287/0x57c <4>[102152.653278] state_store+0xae/0xe5 <4>[102152.653281] kernfs_fop_write+0x109/0x173 <4>[102152.653284] __vfs_write+0x16f/0x1a2 <4>[102152.653287] ? selinux_file_permission+0xca/0x16f <4>[102152.653289] ? security_file_permission+0x36/0x109 <4>[102152.653291] vfs_write+0x114/0x21d <4>[102152.653293] __x64_sys_write+0x7b/0xdb <4>[102152.653296] do_syscall_64+0x59/0x194 <4>[102152.653299] entry_SYSCALL_64_after_hwframe+0x5c/0xc1 这个在 hci_suspend_notifier 中处理 hci_dev 对象时修补程序会保留 hci_dev 对象的引用计数以避免争用条件造成的潜在崩溃。 (CVE-2023-53520)

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

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

  - netethernettiam65-cpsw修复 am65_cpsw_nuss_ndo_slave_open() 中的 PM 运行时泄漏 确保在错误路径中发出 pm_runtime_put()。 (CVE-2022-50461)

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

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

  - cgroup,freezer在 freezer_mutex syzbot 报告 cpu_hotplug_lock 和 freezer_mutex 之间的循环锁定依存关系之前保留 cpu_hotplug_lock用于提交 f5d39b020809freezer,sched重写核心 freezer 逻辑将 freezer_apply_state() 中的 atomic_inc() 替换为保存 cpu_hotplug_lock 的 static_branch_inc()。 cpu_hotplug_lock => cgroup_threadgroup_rwsem => freezer_mutex cgroup_file_write() {cgroup_procs_write() { __cgroup_procs_write() { cgroup_procs_write_start() { cgroup_attach_lock() {cpus_read_lock() { percpu_down_read(&cpu_hotplug_lock); } } percpu_down_write(&cgroup_threadgroup_rwsem); }} cgroup_attach_task() { cgroup_migrate() { cgroup_migrate_execute() { freezer_attach() {mutex_lock(&freezer_mutex); } (...snipped...) } } } }(...snipped...) } } } freezer_mutex => cpu_hotplug_lock cgroup_file_write() { freezer_write() { freezer_change_state() {mutex_lock(&freezer_mutex); } freezer_apply_state() { static_branch_inc(&freezer_active) { static_key_slow_inc() { cpus_read_lock(); } } static_key_slow_inc_cpuslocked(); cpus_read_unlock(); mutex_unlock(&freezer_mutex);通过将 freezer_apply_state() 中的 cpus_read_lock() 移动到 freezer_change_state() 中的 mutex_lock(&freezer_mutex) 之前交换锁定顺序。 (CVE-2023-53522)

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

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

  - fs/ntfs3增强属性大小检查这将溢出和边界检查相结合以便枚举属性大小时能够正确检查这些大小。 [ 169.181521] BUGKASANrun_unpack+0x2e3/0x570 中的 slab 越界 [ 169.183161] 通过任务 mount/247 在 addr ffff8880094b6240 读取大小为 1 的数据 [169.184046] [ 169.184925] CPU0 PID 247 Commmount Not tainted 6.0.0-rc7+ #3 [ 169.185908] 硬件名称QEMU Standard PC (i440FX + PIIX, 1996)、BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01 /2014 [ 169.187066] 调用跟踪[ 169.187492] <TASK> [ 169.188049] dump_stack_lvl+0x49/0x63 [ 169.188495] print_report.cold+0xf5/0x689 [ 169.188964] ? run_unpack+0x2e3/0x570 [ 169.189331] kasan_report+0xa7/0x130 [ 169.189714] ? run_unpack+0x2e3/0x570 [ 169.190079] __asan_load1+0x51/0x60 [ 169.190634] run_unpack+0x2e3/0x570 [ 169.191290] ? run_pack+0x840/0x840 [ 169.191569] ? run_lookup_entry+0xb3/0x1f0 [169.192443] ? mi_enum_attr+0x20a/0x230 [ 169.192886] run_unpack_ex+0xad/0x3e0 [ 169.193276] ? run_unpack+0x570/0x570 [ 169.193557] ? ni_load_mi+0x80/0x80 [ 169.193889] ? debug_smp_processor_id+0x17/0x20 [ 169.194236] mi_init+0x4a/0x70 [ 169.194496] attr_load_runs_vcn+0x166/0x1c0 [ 169.194851] ? attr_data_write_residue+0x250/0x250 [ 169.195188] mi_read+0x133/0x2c0 [ 169.195481] ntfs_iget5+0x277/0x1780 [ 169.196017] ? call_rcu+0x1c7/0x330 [169.196392] ? ntfs_get_block_bmap+0x70/0x70 [ 169.196708] ? evict+0x223/0x280 [ 169.197014] ?
    __kmalloc+0x33/0x540 [ 169.197305] ? wnd_init+0x15b/0x1b0 [ 169.197599] ntfs_fill_super+0x1026/0x1ba0 [169.197994] ? put_ntfs+0x1d0/0x1d0 [ 169.198299] ? vsprintf+0x20/0x20 [ 169.198583] ? mutex_unlock+0x81/0xd0 [ 169.198930] ? set_blocksize+0x95/0x150 [ 169.199269] get_tree_bdev+0x232/0x370 [169.199750] ? put_ntfs+0x1d0/0x1d0 [ 169.200094] ntfs_fs_get_tree+0x15/0x20 [ 169.200431] vfs_get_tree+0x4c/0x130 [ 169.200714] path_mount+0x654/0xfe0 [ 169.201067] ? putname+0x80/0xa0 [169.201358] ? finish_automount+0x2e0/0x2e0 [ 169.201965] ? putname+0x80/0xa0 [ 169.202445] ? kmem_cache_free+0x1c4/0x440 [ 169.203075] ? putname+0x80/0xa0 [ 169.203414] do_mount+0xd6/0xf0 [169.203719] ? path_mount+0xfe0/0xfe0 [ 169.203977] ? __kasan_check_write+0x14/0x20 [ 169.204382]
    __x64_sys_mount+0xca/0x110 [ 169.204711] do_syscall_64+0x3b/0x90 [ 169.205059] entry_SYSCALL_64_after_hwframe+0x63/0xcd [ 169.205571] RIP0033:0x7f67a80e948a [ 169.206327] Code48 8b 0d 11 fa 0d894 894 817 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 49 89 ca b8 a5 00 00 008 [ 169.208296] RSP: 002b:00007ffddf020f58 EFLAGS: 00000202 ORIG_RAX: 00000000000000a5 [169.209253] RAX: ffffffffffffffda RBX: 000055e2547a6060 RCX: 00007f67a80e948a [ 169.209777] RDX:
    000055e2547a6260 RSI: 000055e2547a62e0 RDI: 000055e2547aeaf0 [ 169.210342] RBP: 0000000000000000 R08
    000055e2547a6280 R090000000000000020 [ 169.210843] R1000000000c0ed0000 R110000000000000202 R12
    000055e2547aeaf0 [ 169.211307] R13: 000055e2547a6260 R14: 0000000000000000 R15: 00000000ffffffff [169.211913] </TASK> [ 169.212304] [ 169.212680] 任务分配 0 [ 169.212963] 堆栈不可用 [ 169.213200] [ 169.213472] 缺陷地址属于 ffff8880094b5e00 的对象 [169.213472]该地址属于大小为 1152 的缓存 UDP [ 169.214095] ] 缺陷地址位于 [ 169.214095] 1152 字节区域 [ffff8880094b5e00, ffff8880094b6280) [ 169.214639] [169.215004] 有缺陷的地址属于物理页 [ 169.215766] page:000000002e324c8c refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x94b4 [ 169.218412] head:000000002e324c8c order 2 compound_mapcount:0 compound_pincount:0 [ 169.219078] flags
    0xfffffc0010200(slab|head|node=0|zone=1|lastcpupid=0x1fffff) [ 169.220272] raw: 000fffffc0010200
    ---truncated--- (CVE-2023-53486)

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

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

  - 已修复 Linux 内核中的下列漏洞：rpmsg: char: Avoid double destroy of default endpoint The rpmsg_dev_remove() in rpmsg_core is the place for releasing this default endpoint. So need to avoid destroying the default endpoint in rpmsg_chrdev_eptdev_destroy(), this should be the same as rpmsg_eptdev_release(). Otherwise there will be double destroy issue that ept->refcount report warning:
    refcount_t: underflow; use-after-free. Call trace: refcount_warn_saturate+0xf8/0x150 virtio_rpmsg_destroy_ept+0xd4/0xec rpmsg_dev_remove+0x60/0x70 The issue can be reproduced by stopping remoteproc before closing the /dev/rpmsgX. (CVE-2022-50421)

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

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

  - af_unix修复 unix_stream_sendpage() 中的 null-ptr-deref。Bing-Jhong Billy Jheng 报告了 unix_stream_sendpage() 中的 null-ptr-deref其中包含详细的分析和良好的重现。 unix_stream_sendpage() 尝试在不锁定队列的情况下将数据添加到对等机的 recv 队列中的最后一个 skb。如果对等机的 FD 被传递到另一个套接字并且该套接字的 FD 被传递到对等机则它们之间会形成循环。如果在未收到 FD 的情况下关闭这两个套接字则垃圾回收将清除这两个套接字。垃圾回收会迭代此类套接字并在队列锁定下取消 skb 与来自套接字接收队列的 FD 的链接。因此存在争用其中 unix_stream_sendpage() 可无锁地访问垃圾回收正在释放的 skb从而导致释放后使用。要避免 问题unix_stream_sendpage() 必须锁定对等机的 recv 队列。请注意 6.5+ 感谢最近的 sendpage() 重构中不存在 问题。此修补程序最初由 Linus Torvalds 编写。BUG：无法处理地址的页面错误：
    ffff988004dd6870 PF内核模式 PF 中的监控程序读取访问error_code (0x0000) - not-present page PGD 0 P4D 0 PREEMPT SMP PTI CPU: 4 PID: 297 Commgarbage_uaf 未受感染 6.1.46 #1 硬件名称QEMU Standard PC (i440FX + PIIX) ，1996，BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP
    0010:kmem_cache_alloc_node+0xa2/0x1e0 代码 c0 0f 84 32 01 00 00 41 83 fd ff 74 10 48 8b 00 48 c1 e8 3a 41 39 c5 0f 85 1c 01 00 00 41 8b 44 24 28 39 8b 4c 8 2d 4c 8 8 40 <49> 8b 1c 06 4c 89 f0 65 48 0f c7 0f 0f 94 c0 84 c0 74 a1 41 8b 44 RSP: 0018:ffffc9000079fac0 EFLAGS: 00000246 RAX: 0000000000000070 RBX
    0000000000000005 RCX: 000000000001a284 RDX: 000000000001a244 RSI: 0000000000400cc0 RDI: 000000000002eee0 RBP: 0000000000400cc0 R08: 0000000000400cc0 R09: 0000000000000003 R10: 0000000000000001 R11:
     R120000000000000000  : ffff888003970f00 R13: 00000000ffffffff R14: ffff988004dd6800 R15: 00000000000000e8 FS: 00007f174d6f3600(0000) GS:ffff88807db00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffff988004dd6870 CR3: 00000000092be000 CR4: 00000000007506e0 PKRU: 55555554 调用跟踪 <TASK> ? __die_body.cold+0x1a/0x1f page_fault_oops+0xa9/0x1e0 fixup_exception+0x1d/0x310 ? exc_page_fault+0xa8/0x150 ? asm_exc_page_fault+0x22/0x30 ? kmem_cache_alloc_node+0xa2/0x1e0 ?
    __alloc_skb+0x16c/0x1e0 __alloc_skb+0x16c/0x1e0 alloc_skb_with_frags+0x48/0x1e0 sock_alloc_send_pskb+0x234/0x270 unix_stream_sendmsg+0x1f5/0x690 sock_sendmsg+0x5d/0x60
    ____sys_sendmsg+0x210/0x260 ___sys_sendmsg+0x83/0xd0 ? kmem_cache_alloc+0xc6/0x1c0 ? avc_disable+0x20/0x20 ? percpu_counter_add_batch+0x53/0xc0 ? alloc_empty_file+0x5d/0xb0 ? alloc_file+0x91/0x170 ? alloc_file_pseudo+0x94/0x100 ? __fget_light+0x9f/0x120 __sys_sendmsg+0x54/0xa0 do_syscall_64+0x3b/0x90 entry_SYSCALL_64_after_hwframe+0x69/0xd3 RIP: 0033:0x7f174d639a7d Code: 28 89 54 24 1c 48 89 74 24 10 89 7c 24 08 e8 8a c1 f4 ff 8b 54 24 1c 48 8b 74 24 10 41 89 c0 8b 7c 24 08 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 33 44 89 c7 48 89 44 24 08 e8 de c1 f4 ff 48 RSP: 002b:000007EFLA ORIG_RAX000000000000002e RAXffffffffffffffda RBX0000000000000000 RCX00007f174d639a7d RDX
    0000000000000000 RSI: 00007ffcb563eab0 RDI: 0000000000000007 RBP: 00007ffcb563eb10 R08: 0000000000000000 R09: 00000000ffffffff R10: 00000000004040a0 R11: 0000000000000293 R12: 00007ffcb563ec28 R13:
    0000000000401398 R140000000000403e00 R1500007f174d72c000 </TASK> (CVE-2023-53469)

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

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

  - 已修复 Linux 内核中的下列漏洞：ext4: don't set up encryption key during jbd2 transaction Commit a80f7fcf1867 (ext4: fixup ext4_fc_track_* functions' signature) extended the scope of the transaction in ext4_unlink() too far, making it include the call to ext4_find_entry().
    However, ext4_find_entry() can deadlock when called from within a transaction because it may need to set up the directory's encryption key. Fix this by restoring the transaction to its original scope.
    (CVE-2022-50436)

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

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

  - fs/ntfs3修复 ntfs_fill_super() 错误路径上的内存泄漏 syzbot 报告 kmemleak 如下 BUG内存泄漏未引用对象 0xffff8880122f1540大小 32comm a.out, pid 6664, jiffies 4294939771(存在时间 25.500s) 十六进制转储前 32 字节00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ 00 00 00 00 00 00 00 00 ed ff ed ff 00<ffffffff81627e7c>00<ffffffff81b16052>00<ffffffff81626dd4>00<ffffffff8164aaa7>...  ] __x64_sys_mount+0x18c/0x1d0 [<ffffffff84593e14>] do_syscall_64+0x34/0xb0 [<ffffffff84600087>] entry_SYSCALL_64_after_hwframe+0x63/0xcd 此修补程序通过释放 ntfs_fill_super() 错误路径上的挂载选项修复此问题。 (CVE-2022-50451)

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

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

  - x86/fpu修复 copy_xstate_to_uabi() 以正确复制 init 状态。当扩展状态组件未处于 fpstate 中但处于 init 状态时函数将通过 copy_feature() 从 init_fpsstate 进行复制。但是动态状态不存在于 init_fpsate 中因为 init 状态为全零。然后从 init_fpsstate 检索它们将会像下面一样发生爆炸缺陷: 内核空指针取消引用, 地址: 0000000000000000 ...
    RIP: 0010:memcpy_erms+0x6/0x10 ? __copy_xstate_to_uabi_buf+0x381/0x870 fpu_copy_guest_fpsate_to_uabi+0x28/0x80 kvm_arch_vcpu_ioctl+0x14c/0x1460 [kvm] ?
    __this_cpu_preempt_check+0x13/0x20 ? vmx_vcpu_put+0x2e/0x260 [kvm_intel] kvm_vcpu_ioctl+0xea/0x6b0 [kvm] ? kvm_vcpu_ioctl+0xea/0x6b0 [kvm] ? __fget_light+0xd4/0x130 __x64_sys_ioctl+0xe3/0x910 ? debug_smp_processor_id+0x17/0x20 ? fpregs_assert_state_consistent+0x27/0x50 do_syscall_64+0x3f/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd 针对无法通过 fpstate 和 init_fpsstate 使用的功能调整“掩码”以将用户空间缓冲区归零。动态功能依赖于压缩的 XSAVE 格式。读取 init_fpsstate 中的 XCOMP_BV 之前确保其已启用。 (CVE-2022-50425)

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

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

  - 已修复 Linux 内核中的下列漏洞：efi: ssdt: Don't free memory if ACPI table was loaded successfully Amadeusz reports KASAN use-after-free errors introduced by commit 3881ee0b1edc (efi: avoid efivars layer when loading SSDTs from variables). The problem appears to be that the memory that holds the new ACPI table is now freed unconditionally, instead of only when the ACPI core reported a failure to load the table. So let's fix this, by omitting the kfree() on success.
    (CVE-2022-50433)

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

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

  - platform/chromecros_usbpd_notify修复 cros_usbpd_notify_init() 中的错误处理 rmmod cros_usbpd_notify: Unexpected driver unregister! 时出现以下 WARNING 消息WARNINGCPU0 PID 253 at drivers/base/driver.c:270 driver_unregister+0x8a/0xb0 模块中链接的 cros_usbpd_notify(-) CPU0 PID
    253 Commrmmod 未受感染 6.1.0-rc3 #24... 调用跟踪 <TASK> cros_usbpd_notify_exit+0x11/0x1e [cros_usbpd_notify] __x64_sys_delete_module+0x3c7/0x570 ? __ia32_sys_delete_module+0x570/0x570 ? lock_is_held_type+0xe3/0x140 ? syscall_enter_from_user_mode+0x17/0x50 rcu_read_lock_sched_held+0xa0/0xd0 ? syscall_enter_from_user_mode+0x1c/0x50 do_syscall_64+0x37/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP: 0033:0x7f333fe9b1b7 原因是 cros_usbpd_notify_init() 未检查 platform_driver_register() 的返回值而失败。通过检查 platform_driver_register() 的返回值和在失败时取消注册 cros_usbpd_notify_plat_driver来修复。 (CVE-2022-50468)

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

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

  - ext4改善 ext4_dirhash() 中的错误处理 ext4_dirhash() *几乎*不会失败尤其是首次引入哈希树功能时。但是，通过增加对加密的、大小写文件名的支持，该功能现在肯定会失败。因此请确保 ext4_dirhash() 的调用程序正确检查故障并将错误反映回其调用程序。
    (CVE-2023-53473)

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

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

  - cryptohisilicon/hpre - 修复删除进程中的资源泄漏在 hpre_remove() 中当 qm sriov 的禁用操作失败时应继续执行以下逻辑而不是直接返回否则将会出现资源泄漏。
    (CVE-2022-50420)

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

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

  - scsilibsas修复 smp_execute_task_sg() 中的释放后使用缺陷 当执行 SMP 任务失败时smp_execute_task_sg() 调用 del_timer() 以删除 slow_task->timer。但是如果定时器处理程序 sas_task_internal_timedout() 正在运行smp_execute_task_sg() 中的 del_timer() 将不会停止并将发生 UAF。进程如下所示：(线程 1) |线程 2smp_execute_task_sg() | smp_execute_task_sg() sas_task_internal_timedout() ... del_timer() | del_timer ... ... sas_free_task(task) | kfree(task->slow_task) //FREE| | task->slow_task->... //USE 通过在 smp_execute_task_sg() 中调用 del_timer_sync() 来修复这可确保定时器处理程序在 task->slow_task 取消分配之前已完成。 (CVE-2022-50422)

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

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

  - 已修复 Linux 内核中的下列漏洞：remoteproc: imx_dsp_rproc: Add mutex protection for workqueue The workqueue may execute late even after remoteproc is stopped or stopping, some resources (rpmsg device and endpoint) have been released in rproc_stop_subdevices(), then rproc_vq_interrupt() accessing these resources will cause kennel dump. Call trace:
    virtqueue_add_split+0x1ac/0x560 virtqueue_add_inbuf+0x4c/0x60 rpmsg_recv_done+0x15c/0x294 vring_interrupt+0x6c/0xa4 rproc_vq_interrupt+0x30/0x50 imx_dsp_rproc_vq_work+0x24/0x40 [imx_dsp_rproc] process_one_work+0x1d0/0x354 worker_thread+0x13c/0x470 kthread+0x154/0x160 ret_from_fork+0x10/0x20 Add mutex protection in imx_dsp_rproc_vq_work(), if the state is not running, then just skip calling rproc_vq_interrupt(). Also the flush workqueue operation can't be added in rproc stop for the same reason.
    The call sequence is rproc_shutdown -> rproc_stop ->rproc_stop_subdevices ->rproc->ops->stop()
    ->imx_dsp_rproc_stop ->flush_work -> rproc_vq_interrupt The resource needed by rproc_vq_interrupt has been released in rproc_stop_subdevices, so flush_work is not safe to be called in imx_dsp_rproc_stop.
    (CVE-2022-50426)

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

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

  - V8 中的释放后使用。(CVE-2025-11219)

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

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

  - libcpu_rmap避免 rmap->obj 数组条目中释放后使用在通知参数为 NULL 的情况下调用 irq_set_affinity_notifier() 时会导致释放相应数组条目中的胶水指针但将指针保留在数组中。对 free_irq_cpu_rmap() 的后续调用将尝试再次释放此条目从而可能导致释放后使用。对此进行修复的方法是将数组条目设置为 NULL并在迭代 free_irq_cpu_rmap() 中的数组时检查数组条目是否具有非零值。
    当前代码不受此问题影响因为在任何情况下都不会调用 irq_set_affinity_notifier(irq, NULL)请注意为通知参数传递的 NULL然后调用 free_irq_cpu_rmap()因此不会命中并发出 。此系列的后续修补程序解决了此流程因此需要补丁。
    (CVE-2023-53484)

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

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

  - 已修复 Linux 内核中的下列漏洞：null_blk: fix poll request timeout handling When doing io_uring benchmark on /dev/nullb0, it's easy to crash the kernel if poll requests timeout triggered, as reported by David. [1] BUG: kernel NULL pointer dereference, address:
    0000000000000008 Workqueue: kblockd blk_mq_timeout_work RIP: 0010:null_timeout_rq+0x4e/0x91 Call Trace: ? null_timeout_rq+0x4e/0x91 blk_mq_handle_expired+0x31/0x4b bt_iter+0x68/0x84 ? bt_tags_iter+0x81/0x81
    __sbitmap_for_each_set.constprop.0+0xb0/0xf2 ? __blk_mq_complete_request_remote+0xf/0xf bt_for_each+0x46/0x64 ? __blk_mq_complete_request_remote+0xf/0xf ? percpu_ref_get_many+0xc/0x2a blk_mq_queue_tag_busy_iter+0x14d/0x18e blk_mq_timeout_work+0x95/0x127 process_one_work+0x185/0x263 worker_thread+0x1b5/0x227 This is indeed a race problem between null_timeout_rq() and null_poll().
    null_poll() null_timeout_rq() spin_lock(&nq->poll_lock) list_splice_init(&nq->poll_list, &list) spin_unlock(&nq->poll_lock) while (!list_empty(&list)) req = list_first_entry() list_del_init() ...
    blk_mq_add_to_batch() // req->rq_next = NULL spin_lock(&nq->poll_lock) // rq->queuelist->next == NULL list_del_init(&rq->queuelist) spin_unlock(&nq->poll_lock) Fix these problems by setting requests state to MQ_RQ_COMPLETE under nq->poll_lock protection, in which null_timeout_rq() can safely detect this race and early return. Note this patch just fix the kernel panic when request timeout happen. [1] https://lore.kernel.org/all/3893581.1691785261@warthog.procyon.org.uk/ (CVE-2023-53531)

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

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

  - udf不打扰合并过长的范围 合并过长的范围时我们会尝试将尽可能多的长度推进第一个范围。然而这样做过于复杂而且不值得。此外逻辑中存在缺陷导致 syzbot repeater 显示的文件中的范围损坏。因此不必理会太长的盘区合并在一起。
    (CVE-2023-53506)

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

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

  - ext4允许 ext4_get_group_info() 失败 以前ext4_get_group_info() 会将无效的群组数处理为 BUG()因为理论上这种情况永远不应该发生。但是如果恶意攻击者或模糊测试者在挂载了文件系统时通过块设备修改超级块则可能将 s_first_data_block 设置为非常大的数字。在此情况下计算某个块的块组编号如预分配区域的起始块时 可能导致下溢和极大的块组编号。然后ext4_get_group_info() 中的 BUG_ON 检查会触发根用户或对区块设备具有写入访问权限的人触发的拒绝服务攻击。
    从实现质量的角度来说，最好即使系统管理员执行了他们不应该执行的操作，也不会触发 BUG。因此ext4_get_group_info() 将调用 ext4_error 并返回 NULL而不是进行 BUG'ing。我们还在其可能为空的 ext4_get_group_info() 的所有调用程序中添加了回退代码。此外由于 ext4_get_group_info() 已接近内联函数因此请将其取消内联。结果下一次将 ext4 的已编译文本大小减少大约 2k。 (CVE-2023-53503)

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

ID	名称	严重性
269587	Linux Distros 未修补的漏洞：CVE-2025-11213	critical
269586	Linux Distros 未修补的漏洞：CVE-2025-11209	critical
269585	Linux Distros 未修补的漏洞：CVE-2022-50435	high
269584	Linux Distros 未修补的漏洞：CVE-2022-50428	medium
269583	Linux Distros 未修补的漏洞：CVE-2023-53458	medium
269582	Linux Distros 未修补的漏洞：CVE-2025-59682	low
269581	Linux Distros 未修补的漏洞：CVE-2023-53513	high
269580	Linux Distros 未修补的漏洞：CVE-2023-53460	medium
269579	Linux Distros 未修补的漏洞：CVE-2022-50430	medium
269578	Linux Distros 未修补的漏洞：CVE-2022-50424	medium
269577	Linux Distros 未修补的漏洞：CVE-2023-53491	medium
269576	Linux Distros 未修补的漏洞：CVE-2022-50432	high
269575	Linux Distros 未修补的漏洞：CVE-2023-53477	high
269574	Linux Distros 未修补的漏洞：CVE-2025-59681	critical
269573	Linux Distros 未修补的漏洞：CVE-2022-50447	medium
269572	Linux Distros 未修补的漏洞：CVE-2023-53454	high
269571	Linux Distros 未修补的漏洞：CVE-2023-53528	high
269570	Linux Distros 未修补的漏洞：CVE-2023-53490	medium
269568	Linux Distros 未修补的漏洞：CVE-2023-53453	medium
269567	Linux Distros 未修补的漏洞：CVE-2025-11215	critical
269566	Linux Distros 未修补的漏洞：CVE-2022-50452	medium
269565	Linux Distros 未修补的漏洞：CVE-2022-50439	high
269564	Linux Distros 未修补的漏洞：CVE-2022-50460	high
269563	Linux Distros 未修补的漏洞：CVE-2023-53475	medium
269562	Linux Distros 未修补的漏洞：CVE-2023-53488	medium
269561	Linux Distros 未修补的漏洞：CVE-2023-53511	medium
269560	Linux Distros 未修补的漏洞：CVE-2023-53451	medium
269559	Linux Distros 未修补的漏洞：CVE-2023-53509	medium
269558	Linux Distros 未修补的漏洞：CVE-2023-53521	high
269557	Linux Distros 未修补的漏洞：CVE-2023-53501	medium
269556	Linux Distros 未修补的漏洞：CVE-2023-53520	medium
269555	Linux Distros 未修补的漏洞：CVE-2022-50461	high
269554	Linux Distros 未修补的漏洞：CVE-2023-53522	medium
269553	Linux Distros 未修补的漏洞：CVE-2023-53486	medium
269552	Linux Distros 未修补的漏洞：CVE-2022-50421	high
269551	Linux Distros 未修补的漏洞：CVE-2023-53469	high
269550	Linux Distros 未修补的漏洞：CVE-2022-50436	medium
269549	Linux Distros 未修补的漏洞：CVE-2022-50451	medium
269548	Linux Distros 未修补的漏洞：CVE-2022-50425	medium
269547	Linux Distros 未修补的漏洞：CVE-2022-50433	high
269546	Linux Distros 未修补的漏洞：CVE-2022-50468	medium
269545	Linux Distros 未修补的漏洞：CVE-2023-53473	medium
269544	Linux Distros 未修补的漏洞：CVE-2022-50420	medium
269543	Linux Distros 未修补的漏洞：CVE-2022-50422	high
269542	Linux Distros 未修补的漏洞：CVE-2022-50426	medium
269541	Linux Distros 未修补的漏洞：CVE-2025-11219	critical
269540	Linux Distros 未修补的漏洞：CVE-2023-53484	high
269539	Linux Distros 未修补的漏洞：CVE-2023-53531	medium
269538	Linux Distros 未修补的漏洞：CVE-2023-53506	medium
269537	Linux Distros 未修补的漏洞：CVE-2023-53503	medium

检测

Nessus 的 Misc. 系列

critical

critical

high

medium

medium

low

high

medium

medium

medium

medium

high

high

critical

medium

high

high

medium

medium

critical

medium

high

high

medium

medium

medium

medium

medium

high

medium

medium

high

medium

medium

high

high

medium

medium

medium

high

medium

medium

medium

high

medium

critical

high

medium

medium

medium