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

  - md修复来自 export_rdev() 的持有者不匹配的警告提交 a1d767191096md使用 mddev->external 以在 export_rdev() 中选择持有者修复“claim_rdev”用于 blkdev_get_by_dev()而“rdev”用于 的问题blkdev_put()。但是如果 mddev->external 从 0 变更为 1则“rdev”将用于 blkdev_get_by_dev()而“claim_rdev”则用于 blkdev_put()。并且此问题可以通过执行以下操作可靠地重现新文件mdadm/tests/23rdev-lifetime devname=${dev0##*/} devt=`cat /sys/block/$devname/dev` pid= runtime=2 clean_up_test() { pulp -9 $pid echo clear > /sys/block/md0/md/array_state } trap 'clean_up_test' EXIT add_by_sysfs() { while true; do echo $devt > /sys/block/md0/md/new_dev did } remove_by_sysfs(){ while true;执行 echo remove > /sys/block/md0/md/dev-${devname}/state Done } echo md0 > /sys/module/md_mod/parameters/new_array || die 创建 md0 失败 add_by_sysfs & pid=$pid $! remove_by_sysfs & pid=$pid $! sleep $runtime exit 0 测试 cmd./test --save-logs --logdir=/tmp/ --keep-going --dev=loop --tests=23rdev-lifetime 测试结果
    ------------[在此切换 ]------------ 警告CPU:0 PID:960 at block/bdev.c:618 blkdev_put+0x27c/0x330 模块中链接了multipath md_mod loop CPU: 0 PID: 960 Comm: test Not tainted 6.5.0-rc2-00121-g01e55c376936-dirty #50 RIP: 0010:blkdev_put+0x27c/0x330 调用跟踪 <TASK> export_rdev.isra.23+ 0x50/0xa0 [md_mod] mddev_unlock+0x19d/0x300 [md_mod] rdev_attr_store+0xec/0x190 [md_mod] sysfs_kf_write+0x52/0x70 kernfs_fop_write_iter+0x19a/0x2a0 vfs_write+0x3b5/0x770 ksys_write+0x74/0x150 __x64_sys_write+0x22/0x30 do_syscall_64+0x40 /0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd 通过记录“rdev”是否用作容器来修复此问题。
    (CVE-2023-53791)

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

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

  - drmbridgedw_hdmi修复对 scdc 的连接器访问 Commit 5d844091f237drm/scdc-helperPimp SCDC 调试更改了 scdc 接口以从连接器中拾取 i2c 适配器。然而就 dw-hdmi而言错误的连接器被用来传递 i2c 适配器信息因为 dw-hdmi 的嵌入式连接器结构仅在桥接附件回调明确要求时才会填充。
    drm-meson 正在处理连接器创建因此这种情况不会发生从而导致空指针取消引用。通过让 scdc 函数访问 dw-hdmi 的当前连接器指针来修复此指针在桥接启用阶段分配。 [narmstrong已将修复标签移动到第一个 Sob 之前并添加了报告者标签] (CVE-2023-53784)

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

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

  - ARMzynq修复 zynq_early_slcr_init 中的 refcount 泄漏如果 of_find_compatible_node() 返回引用计数递增的节点指针应该在错误路径上使用 of_node_put()。添加缺少的 of_node_put() 以避免 refcount 泄漏。 (CVE-2023-53818)

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

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

  - dmflakey修复无效表行的崩溃此命令将因空指针取消引用而崩溃
    dmsetup create flakey --table \ 0 `blockdev --getsize /dev/ram0` flkey /dev/ram0 0 0 1 2 corruption_bio_byte 512 通过在比较 arg_name 之前检查其是否非 NULL 来修复崩溃。
    (CVE-2023-53786)

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

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

  - scsises修复 ses_enclosure_data_process() 中的 slab 越界 针对以下问题的补丁BUGKASANses_enclosure_data_process+0x949/0xe30 中发生 slab 越界 [ses] 通过任务在 addr ffff88a1b043a451 中读取大小 1 systemd-udevd/3271 在 addl_desc_ptr[1] 之后及在下一个循环中之前进行检查就足够我们预期在首次访问 addl_desc_ptr[1] 之前先审查大小。确保我们的内容不超出页末。
    (CVE-2023-53803)

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

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

  - l2tp避免 l2tp_tunnel_register() 中可能发生的递归死锁当 pppol2tp 套接字的文件描述符作为 UDP 套接字的文件描述符传递时在 l2tp_tunnel_register() 中会发生递归死锁。
    以下程序会重现这种情况int main(void) { int sock; } struct sockaddr_pppol2tp addr; sock = socket(AF_PPPOX, SOCK_DGRAM, PX_PROTO_OL2TP); if (sock < 0) { perror(socket); return 1 } addr.sa_family = AF_PPPOX; addr.sa_protocol = PX_PROTO_OL2TP; addr.pppol2tp.pid = 0 addr.pppol2tp.fd = sock; addr.pppol2tp.addr.sin_family = PF_INET; addr.pppol2tp.addr.sin_port = htons(0);
    addr.pppol2tp.addr.sin_addr.s_addr = inet_addr(192.168.0.1); addr.pppol2tp.s_tunnel = 1;
    addr.pppol2tp.s_session = 0 addr.pppol2tp.d_tunnel = 0 addr.pppol2tp.d_session = 0 if (connect(sock, (const struct sockaddr *)&addr, sizeof(addr)) < 0) { perror(connect); return 1 return 0此程序会导致以下 lockdep 警告 ========================================= === 警告
    检测到可能的递归锁定 6.2.0-rc5-00205-gc96618275234 #56 未受感染
    ------------------------------------------- repro/8607 尝试获取锁定ffff8880213c8130 (sk_lock-AF_PPPOX){+.+.}-{0:0}位于 l2tp_tunnel_register+0x2b7/0x11c0但任务已持有锁定
    ffff8880213c8130 (sk_lock-AF_PPPOX){+.+.}-{0:0}来自 pppol2tp_connect+0xa82/0x1a30 可能有助于我们调试此问题的其他信息可能不安全的锁定情况CPU0 ---- lock(sk_lock-AF_PPPOX) ; lock(sk_lock-AF_PPPOX); *** DEADLOCK *** 可能是由于 repro/8607 保持的缺少锁定嵌套符号 1 锁定 #0
    ffff8880213c8130 (sk_lock-AF_PPPOX){+.+.}-{0:0}, atpppol2tp_connect+0xa82/0x1a30 堆栈回溯CPU: 0 PID: 8607 Commrepro 未受感染 6.2.0-rc5-00205-gc96618275234 #56 硬件名称QEMU Standard PC (i440FX + PIIX, 1996)，BIOS 1.16.1-2.fc37 04/01/2014 调用跟踪 <TASK> dump_stack_lvl+0x100/0x178
    __lock_acquire.cold+0x119/0x3b9 ? lockdep_hardirqs_on_prepare+0x410/0x410 lock_acquire+0x1e0/0x610 l2tp_tunnel_register+0x2b7/0x11c0 lock_downgrade+0x710/0x710 ? __fget_files+0x283/0x3e0 lock_sock_nested+0x3a/0xf0 ? l2tp_tunnel_register+0x2b7/0x11c0 l2tp_tunnel_register+0x2b7/0x11c0 sprintf+0xc4/0x100 ? l2tp_tunnel_del_work+0x6b0/0x6b0 debug_object_deactivate+0x320/0x320 ? lockdep_init_map_type+0x16d/0x7a0 ? lockdep_init_map_type+0x16d/0x7a0 ? l2tp_tunnel_create+0x2bf/0x4b0 l2tp_tunnel_create+0x3c6/0x4b0 pppol2tp_connect+0x14e1/0x1a30 pppol2tp_put_sk+0xd0/0xd0 aa_sk_perm+0x2b7/0xa80 ? aa_af_perm+0x260/0x260 ? bpf_lsm_socket_connect+0x9/0x10 pppol2tp_put_sk+0xd0/0xd0 __sys_connect_file+0x14f/0x190 __sys_connect+0x133/0x160
    __sys_connect_file+0x190/0x190 ? lockdep_hardirqs_on+0x7d/0x100 ? ktime_get_coarse_real_ts64+0x1b7/0x200 ? ktime_get_coarse_real_ts64+0x147/0x200 ? __audit_syscall_entry+0x396/0x500 __x64_sys_connect+0x72/0xb0 do_syscall_64+0x38/0xb0 entry_SYSCALL_64_after_hwframe+0x63/0xcd 此修补程序通过在锁定 pppol2tp 套接字之前获取/创建隧道来修复该问题。 (CVE-2023-53809)

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

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

  - amdgpu验证 drm_amdgpu_gem_va 的 offset_in_bo 当 offset_in_bo+map_size 溢出时此问题的诱因是 amdgpu_vm_update_range 中的 OOB 访问。 v2保留 amdgpu_vm_bo_map 中的验证 v3将验证添加至 amdgpu_vm_bo_map/amdgpu_vm_bo_replace_map 而不是 amdgpu_gem_va_ioctl (CVE-2023-53819)

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

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

  - posix-timers防止 itimer_delete() 中的 RT 活锁。itimer_delete() 在定时器同时到期时会出现重试循环。在非 RT 内核上这只旋转等待直到定时器回调完成为止启用了 HAVE_POSIX_CPU_TIMERS_TASK_WORK 的 posix CPU 定时器除外。在此情况下在 RT 内核上现有任务可能会在抢占进行定时器传送的任务时处于活锁状态。将 spin_unlock() 替换为 timer_wait_running() 的调用以与 posix timer 代码中的其他重试循环相同的方式处理此问题。 (CVE-2023-53815)

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

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

  - erofs在使用去重后的压缩镜像上终止挂钩的链以避免循环在使用数个镜像其中包含手动构建的重复模式镜像超过 46 天对 EROFS 造成重压后我发现两个链几乎可同时相互链接并形成循环这样就不会提交整个循环。因此相应的文件页面将永远保持锁定状态。可以是
    _only_ 在去重压缩图像上观察到。例如，考虑总共有 5 个 pcluster 的两个链： 链 1：2->3->4->5 -- 尾部 pcluster 为 5；链 2: 5->1->2 -- 尾部 pcluster 为 2。链 2 可链接到链 1其 pcluster 为 5；并且链 1 可以通过 pcluster 2 同时链接到链 2。由于挂钩的链现在全部为无锁链接因此我不知道如何避免争用。相反，我们应该完全避免挂钩链，直到我找到妥善修复此问题且最终用户最终告知需要将其添加回为止。实际上可以在多线程工作负载中发现此优化尤其是在去重压缩图像上更常见但与实现复杂性相比我不确定不进行此优化对整体系统的影响如何。
    (CVE-2023-53777)

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

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

  - iommufdIOMMUFD_DESTROY 不应增加引用计数 syzkaller 发现争用其中 IOMMUFD_DESTROY 递增 refcountobj = iommufd_get_object(ucmd->ictx, cmd->id, IOMMUFD_OBJ_ANY); if (IS_ERR(obj)) return PTR_ERR(obj); iommufd_ref_to_users(obj); /*See iommufd_ref_to_users() */ if (!iommufd_object_destroy_user(ucmd->ictx, obj)) 作为序列的一部分将两个现有原语连接在一起。允许在不保留 destroy_rwsem 的情况下提升 refcount 违反了所有临时提升 refcount 提升都受到 destroy_rwsem 保护的假设。IOMMUFD_DESTROY 与 iommufd_object_destroy_user() 争用将造成虚假故障WARNING: CPU: 0 PID: 3076 at drivers/iommu/iommufd/device.c:477 iommufd_access_destroy+0x18/0x20 drivers/iommu/iommufd/device.c:478 中链接的模块CPU: 0 PID: 3076 Comm: syz-executor.0 Not tainted 6.3.0-rc1-syzkaller #0 硬件名称
    Google Google Compute Engine/Google Compute Engine、BIOS Google 2023 年 7 月 3 日 RIP
    0010iommufd_access_destroy+0x18/0x20 drivers/iommu/iommufd/device.c:477 代码e8 3d 4e 00 00 84 c0 74 01 c3 0f 0b c3 0f 1f 44 00 00 f3 0f 1e fa 48 89 fe 48 8b bf a8 00 00 00 e8 1d 4e 00 00 84 c0 74 01 c3 <0f> 0b c3 0f 1f 44 00 00 41 57 41 56 41 55 4c 8d ae d0 00 00 00 41 RSP: 0018:ffffc90003067e08 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff888109ea0300 RCX : 0000000000000000 RDX: 0000000000000001 RSI:
    0000000000000000 RDI: 00000000ffffffff RBP: 0000000000000004 R08: 0000000000000000 R09: ffff88810bbb3500 R10: ffff88810bbb3e48 R11: 0000000000000000 R12: ffffc90003067e88 R13: ffffc90003067ea8 R14:
     R15ffff888101249800  : 00000000fffffffe FS: 00007ff7254fe6c0(0000) GS:ffff888237c00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000555557262da8 CR3:
    000000010a6fd000 CR4: 0000000000350ef0 调用跟踪 <TASK> iommufd_test_create_access drivers/iommu/iommufd/selftest.c:596 [inline] iommufd_test+0x71c/0xcf0 drivers/iommu/iommufd/selftest.c:813 iommufd_fops_ioctl/bu0f0x10x1ummioctl/ /main.c:337 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:870 [inline] __se_sys_ioctl fs/ioctl.c:856 [inline] __x64_sys_ioctl+0x84/0xc0 fs/ioctl.c 856 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x38/0x80 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd 解决方案是不增加 IOMMUFD_DESTROY 路径上的 refcount所有。而是使用 xa_lock 序列化所有内容。可在单个关键区域下执行 refcount 检查 == 1 和 xa_erase。这可避免任何递增 refcount 的需要。它的缺点是如果用户空间争用被其他操作破坏它将得到一个 EBUSY 而不是等待但这种争用已经是危险的。
    (CVE-2023-53795)

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

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

  - ethtool修复未初始化的通道数 使用旧的 IOCTL ethtool 接口设置链接模式时无法设置通道数。由于此路径中的“struct ethtool_link_ksettings”未初始化因此驱动程序会在“struct ethtool_link_ksettings::lanes”中收到数量未初始化的通道。
    稍后从驱动程序查询此信息时会导致 ethtool 代码根据未初始化的内存做出决策进而导致以下 KMSAN splat [1]。实际上这很可能只在 tun 驱动程序仅返回在设置操作中获得的内容时才会发生。据我所知由于在 linkmodes_prepare_data() 中检查了“ethtool_ops->cap_link_lanes_supported”该未初始化的内存并未泄漏给用户空间。通过初始化 IOCTL 路径中的结构进行修复。未发现在调用“ethtool_ops::set_link_ksettings()”时有更多传递未初始化结构的调用站点。 [1] BUGKMSANethnl_update_linkmodes net/ethtool/linkmodes.c:273 [内联] 中的 uninit-value ethnl_set_linkmodes+0x190b/0x19d0 net/ethtool/linkmodes.c:333 ethnl_update_linkmodes net/ethtool 中的 uninit-value /linkmodes.c:273 [内联] ethnl_set_linkmodes+0x190b/0x19d0 net/ethtool/linkmodes.c:333 ethnl_default_set_doit+0x88d/0xde0 net/ethtool/netlink.c:640 genl_family_rcv_msg_doit net/netlink/genetlink.c:968 [内联] genl_family_rcv_msg net/netlink/genetlink.c:1048 [内联] genl_rcv_msg+0x141a/0x14c0 net/netlink/genetlink.c:1065 netlink_rcv_skb+0x3f8/0x750 net/netlink/af_netlink.c:2577 genl_rcv+0x40/0x60 net/netlink/ genetlink.c:1076 netlink_unicast_kernel net/netlink/af_netlink.c:1339 [内联] netlink_unicast+0xf41/0x1270 net/netlink/af_netlink.c:1365 netlink_sendmsg+0x127d/0x1430 net/netlink/af_netlink.c:1942 sock_sendmsg_nosec net/socket .c:724 [内联] sock_sendmsg net/socket.c:747 [内联]____sys_sendmsg+0xa24/0xe40 net/socket.c:2501 ___sys_sendmsg+0x2a1/0x3f0 net/socket.c:25 55
    __sys_sendmsg net/socket.c:2584 [内联] __do_sys_sendmsg net/socket.c:2593 [内联] __se_sys_sendmsg net/socket.c:2591 [内联] __x64_sys_sendmsg+0x36b/0x540 net/socket.c:2591 do_syscall_x64 arch/x86/ entry/common.c:50 [内联] do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd Uninit 已存储到内存tun_get_link_ksettings+0x37/0x60 drivers/net/tun.c :3544 __ethtool_get_link_ksettings+0x17b/0x260 net/ethtool/ioctl.c:441 ethnl_set_linkmodes+0xee/0x19d0 net/ethtool/linkmodes.c:327 ethnl_default_set_doit+0x88d/0xde0 net/ethtool/netlink.c:640 genl_family_rcv_netlink/netlink/ .c:968 [内联] genl_family_rcv_msg net/netlink/genetlink.c:1048 [内联] genl_rcv_msg+0x141a/0x14c0 net/netlink/genetlink.c:1065 netlink_rcv_skb+0x3f8/0x750 net/netlink/af_netlink.c:2577 genl_rcv+ 0x40/0x60 net/netlink/genetlink.c:1076 netlink_unicast_kernel net/netlink/af_netlink.c:1339 [inline] netlink_unicast+0xf41/0x1270 net/netlink/af_netlink.c:1365 net link_sendmsg+0x127d/0x1430 net/netlink/af_netlink.c:1942 sock_sendmsg_nosec net/socket.c:724 [内联] sock_sendmsg net/socket.c:747 [内联]____sys_sendmsg+0xa24/0xe40 net/socket.c:2501 ___sys_sendmsg+ 0x2a1/0x3f0 net/socket.c:2555
    __sys_sendmsg net/socket.c:2584 [内联] __do_sys_sendmsg net/socket.c:2593 [内联] __se_sys_sendmsg net/socket.c:2591 [内联] __x64_sys_sendmsg+0x36b/0x540 net/socket.c:2591 do_syscall_x64 arch/x86/ entry/common.c:50 [内联] do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd Uninit 已存储到内存tun_set_link_ksettings+0x37/0x60 drivers/net/tun.c 3553 ethtool_set_link_ksettings+0x600/0x690 net/ethtool/ioctl.c:609 __dev_ethtool net/ethtool/ioctl.c:3024 [inline] dev_ethtool+0x1db9/0x2a70 net/ethtool/ioctl.c:3078 dev_ioctl+0xb07/0x1270 net/ core/dev_ioctl.c:524 sock_do_ioctl+0x295/0x540 net/socket.c:1213 sock_i
    ---truncated--- (CVE-2023-53798)

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

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

  - ppp将 skb 与 位于 tx 的设备关联 Syzkaller 通过以下内容触发了流分析器警告r0 = openat$ppp(0xffffffffffffff9c, &(0x7f0000000000), 0xc0802, 0x0) ioctl$PPPIOCNEWUNIT(r0, 0xc004743e, &(0x7f00000000c0)) ioctl$PPPIOCSACTIVE(r0, 0x40107446, &(0x7f0000000240)={0x2, &(0x7f0000000180)=[{0x20, 0x0, 0x0, 0xfffff034}, {0x6}]}) pwritev(r0, &(0x7f0000000040)=[{&( 0x7f0000000140)='\x00!', 0x2}], 0x1, 0x0, 0x0) [ 9.485814] 警告CPU: 3 PID: 329 at net/core/flow_dissector.c:1016
    __skb_flow_dissect+0x1ee0/0x1fa0 [ 9.485929] skb_get_poff+0x53/0xa0 [ 9.485937] bpf_skb_get_pay_offset+0xe/0x20 [ 9.485944] ? ppp_send_frame+0xc2/0x5b0 [ 9.485949] ?
    _raw_spin_unlock_irqrestore+0x40/0x60 [ 9.485958] ? __ppp_xmit_process+0x7a/0xe0 [ 9.485968] ? ppp_xmit_process+0x5b/0xb0 [ 9.485974] ? ppp_write+0x12a/0x190 [ 9.485981] ? do_iter_write+0x18e/0x2d0 [9.485987] ? __import_iovec+0x30/0x130 [ 9.485997] ? do_pwritev+0x1b6/0x240 [ 9.486016] ? trace_hardirqs_on+0x47/0x50 [ 9.486023] __x64_sys_pwritev+0x24/0x30 [ 9.486026] ? do_syscall_64+0x3d/0x80 [ 9.486031] ? entry_SYSCALL_64_after_hwframe+0x63/0xcd 流分析器尝试通过设备或套接字来查找 skb net 命名空间。在 ppp_send_frame 中设置了 Neigher因此我们手动使用 ppp->dev。 (CVE-2022-50655)

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

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

  - ftrace修复 ftrace_modify_direct_caller 中的递归锁定 direct_mutex Naveen 报告了示例 ftrace-direct-modify.ko 的 direct_mutex 递归锁定[ 74.762406] 警告已检测到可能的递归锁定 [ 74.762887] 6.0.0-rc6+ #33 未受感染 [ 74.763216]
    ------------------------------------------- [ 74.763672] event- sample-fn/1084 正在尝试获取锁定
    [ 74.764152] ffffffff86c9d6b0 (direct_mutex){+.+.}-{3:3}位于 \ register_ftrace_function+0x1f/0x180 [74.764922] [ 74.764922] 但任务已持有锁定[ 74.765421] ffffffff86c9d6b0 (direct_mutex) ){+.+.}-{3:3}位于\modify_ftrace_direct+0x34/0x1f0 [ 74.766142] [ 74.766142] 其他可能帮助我们调试此问题的信息[ 74.766701] 可能不安全的锁定情况[ 74.766701] [ 74.767216] CPU0 [ 74.767437] ---- [ 74.767656] lock(direct_mutex); [ 74.767952] lock(direct_mutex); [ 74.768245] [74.768245] *** DEADLOCK *** [ 74.768245] [ 74.768750] 可能是由于缺少锁定嵌套符号所致 [74.768750] [ 74.769332] 1 个锁定由 event-sample-fn/1084 持有[ 74.769731] #0ffffffff86c9d6b0 (direct_mutex){+.+.}-{3:3}at: \ modify_ftrace_direct+0x34/0x1f0 [ 74.770496] [ 74.770496] 堆栈回溯 [ 74.770884] CPU: 4 PID1084 Commevent-sample-fn 未受感染... [ 74.771498] 硬件名称
    QEMU Standard PC(i440FX + PIIX, 1996)... [ 74.772474] 调用跟踪[ 74.772696] <TASK> [ 74.772896] dump_stack_lvl+0x44/0x5b [ 74.773223] __lock_acquire.cold.74+0xac/0x2b7 [ 74.773616] lock_acquire+0xd2/0x310 [ 74.773936] ? register_ftrace_function+0x1f/0x180 [ 74.774357] ? lock_is_held_type+0xd8/0x130 [ 74.774744] ? my_tramp2+0x11/0x11 [ftrace_direct_modify] [ 74.775213]
    __mutex_lock+0x99/0x1010 [ 74.775536] ? register_ftrace_function+0x1f/0x180 [ 74.775954] ? slab_free_freelist_hook.isra.43+0x115/0x160 [ 74.776424] ? ftrace_set_hash+0x195/0x220 [ 74.776779] ? register_ftrace_function+0x1f/0x180 [ 74.777194] ? kfree+0x3e1/0x440 [ 74.777482] ? my_tramp2+0x11/0x11 [ftrace_direct_modify] [ 74.777941] ? __schedule+0xb40/0xb40 [ 74.778258] register_ftrace_function+0x1f/0x180 [ 74.778672] ? my_tramp1+0xf/0xf [ftrace_direct_modify] [ 74.779128] register_ftrace_function+0x1f/0x180 [ 74.779527] ? ftrace_set_filter_ip+0x33/0x70 [ 74.779910] ?
    __schedule+0xb40/0xb40 [ 74.780231] my_tramp1+0xf/0xf [ftrace_direct_modify] [ 74.780678] ? my_tramp2+0x11/0x11 [ftrace_direct_modify] [ 74.781147] ftrace_modify_direct_caller+0x5b/0x90 [ 74.781563] ? 0xffffffffa0201000 [ 74.781859] my_tramp1+0xf/0xf [ftrace_direct_modify] [ 74.782309] modify_ftrace_direct+0x1b2/0x1f0 [ 74.782690] ? __schedule+0xb40/0xb40 [ 74.783014] simple_thread+0x2a/0xb0 [ftrace_direct_modify] [ 74.783508] ? __schedule+0xb40/0xb40 [ 74.783832] my_tramp2+0x11/0x11 [ftrace_direct_modify] [ 74.784294] simple_thread+0x76/0xb0 [ftrace_direct_modify] [74.784766] kthread+0xf5/0x120 [ 74.785052] ? kthread_complete_and_exit+0x20/0x20 [ 74.785464] ret_from_fork+0x22/0x30 [ 74.785781] </TASK> 通过使用 ftrace_modify_direct_caller 中的 register_ftrace_function_nolock 修复此问题。 (CVE-2022-50648)

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

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

  - scsihpsa修复 hpsa_init_one() 中可能的内存泄漏 hpda_alloc_ctlr_info() 分配 h 及其字段 reply_map。但是在 hpsa_init_one() 中如果 alloc_percpu() 失败hpsa_init_one() 会直接跳转到 clean1这会释放 h 并泄露 h->reply_map。通过调用 hpda_free_ctlr_info() 释放 h->replay_map 和 h 来修复而不是直接释放 h。 (CVE-2022-50646)

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

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

  - mmcatmel-mci修复 mmc_add_host() 的返回值检查 mmc_add_host() 可能返回错误如果忽略其返回值将导致两个问题1. 在 mmc_alloc_host() 中分配的内存泄漏。 2. 在 remove() 路径中将调用 mmc_remove_host() 来删除设备但尚未添加设备会将内核崩溃因为 device_del() 中的 null-ptr-deref。因此可通过检查返回值并调用错误路径中的 mmc_free_host() 来修复此问题。 (CVE-2022-50653)

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

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

  - usbdwc3qcom修复 dwc3_qcom_interconnect_init of_icc_get() 中的内存泄漏为路径句柄分配资源我们应在不再需要时将其释放。与 dwc3_qcom_interconnect_exit() 函数中的释放类似。在错误处理中添加 icc_put() 以修复此问题。 (CVE-2022-50633)

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

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

  - driversperfmarvell_cn10k修复 tad_pmu_init() 中的热插拔回调泄漏当 platform_driver_register() 失败时tad_pmu_init() 将不会删除 cpuhp_setup_state_multi() 添加的回调。通过失败路径中的 cpuhp_remove_multi_state() 删除回调。与提交 26242b330093 中 arm_ccn_init() 的处理类似busarm-ccn防止热插拔回调泄漏(CVE-2022-50632)

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

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

  - mmccore修复卸下非标准 SDIO 卡时的内核错误仅为标准 SDIO 卡分配 SDIO 元组尤其是它会在卸下非标准 SDIO 卡时造成内存损坏问题这是因为卡设备的引用计数器不会在 sdio_init_func() 上增加计数但会减少 sdio_release_func() 上的所有 SDIO 卡设备引用计数器。 (CVE-2022-50640)

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

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

  - ethtooleeprom修复转储中 genl_info 上的 null-deref 与 commit 46cdedf2a0fa 类似的补丁ethtool
    pse-pd修复转储中 genl_info 上的 null-deref也需要 ethtool eeprom。 (CVE-2022-50651)

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

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

  - seccomp将 copy_seccomp() 移动到无故障路径。syzbot 实例报告在 do_seccomp() [0] 中存在内存泄漏问题与报告 [1] 类似。这表明我们缺少释放 struct seccomp_filter 和其中包含的某些对象。我们可以通过下面的程序 [2] 该程序调用一个 seccomp() 和两个 clone() syscall 来重现该问题。第一个 clone()d 子进程比其父进程更早退出并在第二个 clone() 期间更准确地在 copy_process() 中的 fatal_signal_pending() 测试之前发送信号以终止其父进程。当父进程收到信号时它必须破坏初始进程并将 -EINTR 返回给用户空间。
    在故障路径中，我们必须调用 seccomp_filter_release() 以减少过滤器的 refcount。
    最初我们在从故障路径调用的 free_task() 中调用了它但是提交 3a15fb6ed92cseccomp在任务完全停止后释放过滤器将其移动到 release_task()以尽早通知用户空间过滤器不再工作。使用过。为了保留更改和当前 seccomp refcount 语义我们将 copy_seccomp() 移动到紧接着信号检查之后的位置并在 free_task() 中添加 WARN_ON_ONCE() 以供未来调试。 [0]未引用的对象 0xffff8880063add00（大小 256）：comm repro_seccomp，pid 230，jiffies 4294687090（时间 9.914s）十六进制转储前 32 个字节：01 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 。 ............ ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ..
    do_seccomp (./include/linux/slab.h:600 ./include/linux/slab.h:733 kernel/seccomp.c:666 kernel/seccomp.c:708 kernel/seccomp.c:1871 kernel/seccomp.c 1991do_syscall_64 (arch/x86/entry/common.c:50 arch/x86/entry/common.c:80) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:120) 未引用的对象 0xffffc90000035000大小 4096 comm repro_seccomp、pid 230、jiffies 4294687090 (age 9.915s) 十六进制转储前 32 字节01 00 00 00 00 00 00 00 00 00 00 00 05 00 00 00............ ... 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ..... 回溯
    __vmalloc_node_range (mm/vmalloc.c:3226) __vmalloc_node (mm/vmalloc.c:3261标识符 4) bpf_prog_alloc_no_stats (kernel/bpf/core.c:91) bpf_prog_alloc (kernel/bpf/core.c:129) bpf_prog_create_from_user ( net/core/filter.c:1414do_seccomp (kernel/seccomp.c:671 kernel/seccomp.c:708 kernel/seccomp.c:1871 kernel/seccomp.c:1991) do_syscall_64 (arch/x86/entry/common .c:50 arch/x86/entry/common.c:80) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:120) 未引用的对象 0xffff888003fa1000（大小 1024）：comm repro_seccomp，pid 230，jiffies 4294687090（时长 9.915s） ) 十六进制转储前 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 00 00 00 00 00 00 00 00 .. /bpf/core.c:95) bpf_prog_alloc (kernel/bpf/core.c:129) bpf_prog_create_from_user (net/core/filter.c:1414) do_seccomp (kernel/seccomp.c:671 kernel/seccomp.c:708 kernel) /secc omp.c:1871 kernel/seccomp.c:1991do_syscall_64 (arch/x86/entry/common.c:50 arch/x86/entry/common.c:80) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S 120) 未引用的对象 0xffff888006360240 (size 16)comm repro_seccomp, pid 230, jiffies 4294687090 (age 9.915s) 十六进制转储前 16 个字节01 00 37 00 76 65 72 6c e0 83 01 06 80 88 ff ff .7 .verl...... 回溯bpf_prog_store_orig_filter (net/core/filter.c:1137) bpf_prog_create_from_user (net/core/filter.c:1428) do_seccomp (kernel/seccomp.c:671 kernel/seccomp.c :708 kernel/seccomp.c:1871 kernel/seccomp.c:1991) do_syscall_64 (arch/x86/entry/common.c:50 arch/x86/entry/common.c:80) entry_SYSCALL_64_after_hwframe (arch/x86/entry/ entry_64.S:120) 未引用的对象 0xffff888 ---truncated--- (CVE-2022-50661)

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

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

  - ubi修复卷大小调整失败时的释放后使用问题 KASAN 报告存在释放后使用问题
    ================================================== ================ 缺陷KASANubi_eba_copy_table+0x11f/0x1c0 中的释放后使用 [ubi] 通过任务 ubirsvol/4735 CPU 在地址 ffff888101eec008 对大小 8 的大小进行读取2 PID 4735 Commubirsvol Not tainted 6.1.0-rc1-00003-g84fa3304a7fc-dirty #14 硬件名称QEMU Standard PC (i440FX + PIIX,1996)BIOS 1.14.0-1.fc33 04/01/2014 调用跟踪 <TASK> dump_stack_lvl+0x34/0x44 print_report+0x171/0x472 kasan_report+0xad/0x130 ubi_eba_copy_table+0x11f/0x1c0 [ubi] ubi_resize_volume+0x4f9/0xbc0 [ubi] ubi_cdev_ioctl+0x701/0x1850 [ubi] __x64_sys_ioctl+0x11d/0x170 do_syscall_64+0x35/ 0x80 entry_SYSCALL_after_hwframe+0x46/0xb0 </TASK> 当 ubi_change_vtbl_record() 在 ubi_resize_volume() 中返回一个错误时new_eba_tbl 将在错误处理路径上释放但由 ubi_eba_replace_table() 中的 vol->eba_tbl 持有。这表示 vol->eba_tbl 和 vol 的提升周期不同因此当下次调整卷大小时会造成释放后使用错误。通过在 ubi_eba_replace_table() 中替换 new_eba_tbl 之后不释放它来修复此问题同时将在下一个卷大小调整中释放。 (CVE-2023-53800)

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

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

  - ext4修复 ext4_mb_use_preallocation 中的 rbtree 遍历缺陷在分配期间在每个 inode rbtree 中查找预分配 (PA) 时无法直接遍历树因为 ext4_mb_discard_group_preallocation() 可能会将 pa 并行标记为已删除这可导致直接遍历以跳过某些条目。当我们错过可满足我们请求的 PA 并最终尝试创建将与错过的 PA 重叠的 PA 时这会导致 BUG_ON() 命中 [1]。
    为确保在处理该情况时仍能保持 rbtree 的性能我们利用了唯一可能重叠原始目标起点的路径是满足以下条件的路径这一事实start 紧接着原始逻辑 start 的左侧即小于原始逻辑 start 的时间。 2. 不得将其删除。为找到此 pa，我们使用以下遍历方法： 1. 正常下降至 rbtree 以查找最直接的相邻 PA。此处我们保持降序排列，而不考虑 PA 是否被删除或是否与我们的请求重叠等。目标是找到紧邻的 PA。
    2. 如果找到的 PA 在原始目标的右侧，请使用 rb_prev() 查找左侧邻近的 PA。 3. 检查此 PA 是否已删除并使用 rb_prev() 继续向左移动直到找到未删除的 PA。 4. 这就是我们要找的 PA。现在我们可以检查其是否可以满足原始请求并进行相应处理。此方法还会处理树中已删除的 PA。同时修复计算 PA 结尾时可能的溢出缺陷 [1] https://lore.kernel.org/linux-ext4/CA+G9fYv2FRpLqBZf34ZinR8bU2_ZRAUOjKAD3+tKRFaEQHtt8Q@mail.gmail.com/ (CVE-2023-53813)

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

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

  - netopenvswitch拒绝负的 ifindex net-nextcommit 759ab1edb56c (netxarray 中的 netdevs)) 中的最近更改重构了预分配 ifindexes 的处理并让 syzbot 暴露 ovs 中的潜在问题。 ovs 不验证 ifindex因此可以使用负的 ifindex 值创建 netdev 端口。使用 YNL 即可轻松重现$ ./cli.py --spec netlink/specs/ovs_datapath.yaml \ --do new \ --json '{upcall-pid: 1, name:my-dp}' $ ./cli.py --spec netlink/specs/ovs_vport.yaml \ --do 新增 \
    --json '{upcall-pid: 00000001, name:some-port0, dp-ifindex:3,ifindex:4294901760,type:2}' $ ip link show -65536:some-port0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop 状态向下mode DEFAULT 组默认 qlen 1000 link/ether 7a:48:21:ad:0b:fb brd ff:ff:ff:ff:ff:ff ... 验证输入。现在第二个命令会正确返回$ ./cli.py --spec netlink/specs/ovs_vport.yaml \ --do new \ --json '{upcall-pid: 00000001, name:some-port0, dp-ifindex:3,ifindex 4294901760,type:2}' lib.ynl.NlErrorNetlink 错误数值结果超出范围 nl_len = 108 (92) nl_flags = 0x300 nl_type = 2 错误-34 extack: {'msg': '整数超出范围', 'unknown': [[type:4 len:36] b'\x0c\x00\x02\x00\x00\x0 0\x00\x00\x00\x00\x00\x00\x0c\x00\x03\x00 \xff\xff\xff\x7f\x00\x00\x00\x00\x08\x00\x01\x00\x08\x00\x00\x00']'bad-attr': '.ifindex'} 接受 0，因为过去会被静默忽略。 (CVE-2023-53843)

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

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

  - ASoC codecswcd-mbhc-v2修复组件删除时的资源泄漏 在组件探测失败和删除时必须释放 MBHC 资源因此无法与组件设备的生命周期相关联。这是特别需要的以允许声卡的探测延迟否则声卡的探测延迟会在重新探测编解码器组件 snd-sc8280xp sound: ASoC: failed to instanceiate card -517 genirq: Flags mismatch irq 299 时失败。
    00002001 (mbhc sw intr) 与 00002001 (mbhc sw intr) wcd938x_codec 音频编解码器无法请求 mbhc 中断 -16 wcd938x_codec 音频编解码器mbhc 初始化失败 wcd938x_codec 音频编解码器: ASoC
    audio-codec 上 snd_soc_component_probe 上的错误-16 snd-sc8280xp sound: ASoC 未能实例化板卡
    -16 (CVE-2023-53842)

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

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

  - ipmi修复 _ipmi_destroy_user() 中的释放后使用 intf_free() 函数释放 intf 指针以便我们无法在下一行再次取消引用该指针。 (CVE-2022-50677)

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

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

  - cryptoapi - 在 crypto_destroy_instance 中使用工作队列 函数 crypto_drop_spawn 预期在进程环境中调用。但是，当实例在仍具有活动用户时取消注册时，最后一个用户可能会导致在原子上下文中释放该实例。通过延迟释放到工作队列来修复此问题。 (CVE-2023-53799)

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

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

  - wifimwifiex修复 mwifiex_histogram_read() 中的内存泄漏从“mwifiex_histogram_read()”返回时始终释放归零的页面。 (CVE-2023-53808)

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

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

  - drm/ttm“交换出”移动时不泄漏资源错误如果将 bo 移动到系统以进行交换出失败可能会泄漏资源。修复。 (CVE-2023-53844)

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

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

  - platform/x86think-lmi修复显示当前设置时的内存泄漏通过 tlmi_setting() 检索项目字符串时必须使用 kfree() 释放结果。但在 current_value_show() 中未释放畸形项目字符串从而导致内存泄露。通过消除造成此问题的提前返回来修复此问题。 (CVE-2023-53830)

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

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

  - PCI修复 .end = 0 的有效根总线资源的终止在 r8a7791/koelsch上kmemleak1 个新的可疑内存泄漏请参阅 /sys/kernel/debug/kmemleak # cat /sys/kernel/debug/kmemleak 未引用对象 0xc3a34e00 (size 64): comm swapper/0, pid 1, jiffies 4294937460 (age 199.080s) hex dump前 32 字节b4 5d 81 f0 b4 5d 81 f0 c0 b0 a2 c3 00 00 00 00 .]...] ............ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ....... 回溯[<fe3aa979>] __kmalloc+ 0xf0/0x140 [<34bd6bc0>] resource_list_create_entry+0x18/0x38 [<767046bc>] pci_add_resource_offset+0x20/0x68 [<b3f3edf2>] devm_of_pci_get_host_bridge_resources.constprop.0+0xb0/0x390 当合并连续孔径的两个资源时第二个资源被放大以覆盖完整的连续范围而第一个资源被标记为无效。通过清除 flags、start 和 end 成员可实现此失效。稍后将初始资源添加到总线时系统会跳过无效资源。遗憾的是对无效资源的检查仅考虑最终成员可能会造成误报。例如在 r8a7791/koelsch 上根总线资源 0 (bus 00) 被跳过且不再通过 pci_bus_insert_busn_res() 注册造成内存泄漏也不再打印: pci-rcar-gen2 ee090000.pci: host bridge /soc/pci @ee090000范围pci-rcar-gen2 ee090000.pciMEM 0x00ee080000..0x00ee08ffff -> 0x00ee080000 pci-rcar-gen2 ee090000.pciPCI修订版 11 pci-rcar-gen2 ee090000.pci总线的 PCI 主机桥 0000:00 -pci_bus 0000:00根总线资源 [bus 00] pci_bus 0000:00根总线资源 [mem 0xee080000-0xee08ffff] 通过仅跳过所有标记、开始和结束成员均为零的资源来修复此问题。 (CVE-2023-53814)

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

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

  - wifiath9k: htc_hst如果没有回调函数则在 ath9k_htc_rx_msg() 中释放 skb 据说 ath9k_htc_rx_msg() 会释放提供的 skb或将其管理权移至另一个回调函数。
    但是如果没有其他回调函数则不会释放 skb而且 Syzkaller 能够造成内存泄漏。亦有次要的注释补丁。由 Linux Verification Center (linuxtesting.org) 通过 Syzkaller 发现。 (CVE-2023-53802)

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

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

  - net在 sk_mc_loop() 中读取一次 sk->sk_family syzbot 这些天来相当频繁地操纵 IPV6_ADDRFORM并成功命中 sk_mc_loop() 中的 WARN_ON_ONCE(1) 我们还有很多类似的问题需要修复。警告：
    CPU: 1 PID: 1593 at net/core/sock.c:782 sk_mc_loop+0x165/0x260 Modules 链接于: CPU: 1 PID: 1593 Comm
    kworker/1:3 未受感染 6.1.40-syzkaller #0 硬件名称 Google Google Compute Engine/Google Compute Engine、BIOS Google 07/26/2023 Workqueueevents_power_fficient gc_worker RIP
    0010:sk_mc_loop+0x165/0x260 net/core/sock.c:782 代码34 1b fd 49 81 c7 18 05 00 00 4c 89 f8 48 c1 e8 03 42 80 3c 20 00 74 08 4c 89 ff e8 25 36 6d fd 4d 8b 37 eb 13 e8 db 33 1b fd <0f> 0b b3 01 eb 34 e8 d0 33 1b fd 45 31 f6 49 83 c6 38 4c 89 f0 48 RSP0018:ffffc90000388530 EFLAGS: 00010246 RAX86 ffffff5: ffffff5: RB
    0000000000000011 RCX: ffff88814f884980 RDX: 0000000000000102 RSI: ffffffff87ae5160 RDI: 0000000000000011 RBP: ffffc90000388550 R08: 0000000000000003 R09: ffffffff846d9a65 R10: 0000000000000002 R11:
     R12ffff88814f884980  : dffffc0000000000 R13: ffff88810dbee000 R14: 0000000000000010 R15: ffff888150084000 FS: 0000000000000000(0000) GS:ffff8881f6b00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020000180 CR3: 000000014ee5b000 CR4: 00000000003506e0 DR0
    0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <IRQ> [<ffffffff8507734f>] ip6_finish_output2+0x33f/0x1ae0 net/ipv6/ip6_output.c:83 [<ffffffff85062766>] __ip6_finish_output net/ipv6/ip6_output. c:200 [inline] [<ffffffff85062766>] ip6_finish_output+0x6c6/0xb10 net/ipv6/ip6_output.c:211 [<ffffffff85061f8c>] NF_HOOK_COND include/linux/netfilter.h:298 [inline] [<ffffffff85061f8c>] ip6_output+0x2bc/0x3d0 net/ipv6/ip6_output.c:232 [<ffffffff852071cf>] dst_output include/net/dst.h:444 [inline] [<ffffffff852071cf>] ip6_local_out+0x10f/0x140 net/ipv6/output_core.c:161 [<ffffffff83618fb4>] ipvlan_process_v6_outbound 驱动程序/net/ipvlan/ipvlan_core.c:483 [内联] [<ffffffff83618fb4>] ipvlan_process_outbound drivers/net/ipvlan/ipvlan_core.c:529 [内联] [<ffffffff83618fb4>] ipvlan_xmit_mode_l3 drivers/net/ipvlan/ipvlan_core.c:602 [内联] [<ffffffff83618fb4>] ipvlan_queue_xmit+0x1174/0x1be0 drivers/net/ipvlan/ipvlan_core.c:677 [<ffffffff8361ddd9>] ipvlan_start_xmit+0x49/0x100 drivers/net/ipvlan/ipvlan_main.c:229 [<ffffffff84763fc0>] netdev_start_xmit include/linux/ netdevice.h:4925 [内联] [<ffffffff84763fc0>] xmit_one net/core/dev.c:3644 [inline] [<ffffffff84763fc0>] dev_hard_start_xmit+0x320/0x980 net/core/dev.c:3660 [<ffffffff8494c650>] sch_direct_xmit+0x2a0/0x9c0 net/sched/sch_generic.c :342 [<ffffffff8494d883>] qdisc_restart net/sched/sch_generic.c:407 [inline] [<ffffffff8494d883>] __qdisc_run+0xb13/0x1e70 net/sched/sch_generic.c:415 [<ffffffff8478c426>] qdisc_run+0xd6/0x260 include/net/ pkt_sched.h:125 [<ffffffff84796eac>] net_tx_action+0x7ac/0x940 net/core/dev.c:5247 [<ffffffff858002bd>]
    __do_softirq+0x2bd/0x9bd kernel/softirq.c:599 [<ffffffff814c3fe8>] invoke_softirq kernel/softirq.c:430 [inline] [<ffffffff814c3fe8>] __irq_exit_rcu+0xc8/0x170 kernel/softirq.c:683 [<ffffffff814c3f09>] irq_exit_rcu+0x9 /0x20 kernel/softirq.c:695CVE-2023-53831

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

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

  - dccp修复因 dp->dccps_mss_cache 导致的数据争用。dccp_sendmsg() 在锁定套接字之前读取 dp->dccps_mss_cache。do_dccp_getsockopt() 中也一样。添加 READ_ONCE()/WRITE_ONCE() 注释并将 dccp_sendmsg() 更改为在套接字锁定之后再次检查 dccps_mss_cache。 (CVE-2023-53839)

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

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

  - ALSAhda/ca0132修复tuning_ctl_set() 中的缓冲区溢出如果没有通过匹配从循环中中断tuning_ctl_set() 可能 (X) 中存在缓冲区溢出。 static int tune_ctl_set(...) { for (i = 0; i < TUNING_CTLS_COUNT; i++) (A) if (nid == ca0132_tuning_ctls[i].nid) break; } snd_hda_power_up(...); (X) dspio_set_param(..., ca0132_tuning_ctls[i].mid, ...); snd_hda_power_down(...); ^ return 1我们将通过 cppcheck sound/pci/hda/patch_ca0132.c:4229:2: /patch_ca0132.c:4234:43note数组索引越界 dspio_set_param(codec, ca0132_tuning_ctls[i].mid, 0x20, ^ 此修补程序关注非匹配情况。
    (CVE-2023-53788)

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

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

  - md/raid10修复 raid10_sync_request init_resync() 中的 null-ptr-deref 并在同步开始时初始化内存池并设置 conf->have_replacemntclose_sync() 会在同步完成时释放内存池。
    在 [1] 之后可能会跳过恢复并调用 init_resync() 但不调用 close_sync()。 r10bio->dev[i].repl_bio 会发生 null-ptr-deref。以下是重现问题的一种方式。 1) 创建阵列等待重新同步完成mddev->recovery_cp 设置为 MaxSector。 2) 恢复被唤醒且被跳过。 conf->have_replacement 在 init_resync() 中设置为 0。未调用 close_sync()。 3) 某些 io 错误以及 rdev A 被设置为 WantReplacement。 4) 新设备已添加并设置为 A 的替代品。 5) 恢复唤醒后A 已替换但 conf->have_replacemnt 为 0。r10bio->dev[i].repl_bio 将不会分配并发生 null-ptr-deref。通过在跳过恢复时不调用 init_resync() 来修复此问题。 [1] commit 7e83ccbecd60md/raid10允许在组装 clean 数组时跳过恢复CVE-2023-53832

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

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

  - perf 工具 x86修复泄漏审查器发现的 perf_env 内存泄漏`==1632594==ERRORLeakSanitizer
    检测到内存泄漏 中的 1 个对象分配中的 #0 0x7f2953a7077b 中的 21 字节的直接泄漏
    __interceptor_strdup ../../../../src/libsanitizer/asan/asan_interceptors.cpp:439 #1 perf_env__read_cpuid util/env.c:369 中的 0x556701d6fbbf #2 perf_env__cpuid util/env.c:465 中的 0x556701d70589 #3 x86__is_amd_cpu arch/x86/util/env.c:14 中的 0x55670204bba2 #4 arch__post_evsel_config arch/x86/util/evsel.c:83 中的 0x5567020487a2 #5 evsel__config util/evsel.c:1366 中的 0x556701d8f78b inconfigutil/evsel.c:1366 #6 0x556701d8f78b in evsel__config util/evsel.c:1366 .c:108 #7 test__PERF_RECORD tests/perf-record.c:112 中的 0x556701cd6bcd #8 run_test tests/builtin-test.c:236 中的 0x556701cacd07 #9 test_and_print tests/builtin-test.c:265 中的 0x556701cacfac #10 中的 0x556701cadddb __cmd_test tests/builtin-test.c:402 #11 cmd_test tests/builtin-test.c:559 中的 0x556701caf2aa #12 run_builtin tools/perf/perf.c:323 中的 0x556701d3b557 #13 handle_internal_command tools/perf/perf.c 中的 0x556701d3bac8 :377 #14 run_argv tools/perf/perf.c:421 中的 0x556701d3be90 #15 main tools/perf/perf.c:537 中的 0x556701d3c3f8 #16 __libc_start_call_main ../sysdeps/nptl/ 中的 0x7f2952a46189 libc_start_call_main.h:58 摘要AddressSanitizer1 次分配中泄露 21 字节。
    `` (CVE-2023-53793)

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

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

  - nvme-core修复当 nvme_auth_generate_key() 返回错误时在返回之前nvme_ctrl_dhchap_ctrl_secret_store() 中 dhchap_ctrl_secret 释放 dhchap_secret 中的内存泄漏。
    (CVE-2023-53792)

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

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

  - blk-mq在报告 I/O 完成前释放 crypto keyslot 当使用 blk_crypto_key 的 I/O 完成后文件系统可调用 blk_crypto_evict_key()。然而区块层目前不会调用 blk_crypto_put_keyslot()直到释放请求才会发生这种情况发生在已通知上层通过 bio_endio()I/O 已完成 I/O 已完成之后。这会造成争用条件其中 blk_crypto_evict_key() 可以识别“slot_refs != 0”但不存在实际的缺陷。这使得 __blk_crypto_evict_key() 命中“WARN_ON_ONCE(atomic_read(&slot->slot_refs) != 0)”并返回而不执行任何操作最终在 blk_crypto_reprogram_all_keys() 中造成释放后使用。这是一个非常罕见的缺陷只有在将每个文件密钥与 fscrypt 一起使用时才会出现。有两个选项可修复此问题在请求的最后一个 bio 上调用 bio_endio() 之前释放 keyslot或使__blk_crypto_evict_key() 忽略 slot_refs。
    我们使用第一个解决方案因为它保留了报告缺陷的功能通过 WARN_ON_ONCE在密钥仍在使用时被逐出的缺陷中。 (CVE-2023-53810)

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

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

  - Bluetoothhci_sync避免 hci_add_adv_monitor() 的 dbg 中发生释放后使用 KSAN 报告 hci_add_adv_monitor() 中存在释放后使用。添加 adv 监控时hci_add_adv_monitor() 调用 -> msft_add_monitor_pattern() 调用 -> msft_add_monitor_sync() 调用 -> 在错误情况下调用 msft_le_monitor_advertisement_cb() -> 可释放 *moniter 的 hci_free_adv_monitor()。此属性由 hci_add_adv_monitor() 中的 bt_dev_dbg() 引用。使用 handle 而非 monitor->handle 修复 bt_dev_dbg()。
    (CVE-2023-53828)

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

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

  - bpf修复同步回调的引用状态管理 目前验证程序会验证回调函数同步和异步好像它们将被执行一次即其探索执行状态好像该函数会被调用一次。要探索的下一个 insn 已设置为 subprog 的开头且嵌套帧的退出使用 curframe > 0 和 prepare_func_exit 进行处理。如果是异步回调其使用 push_stack 的自定义变体模拟一种分支从而为异步回调设置自定义状态和执行上下文。虽然此方法简单且在回调实际上仅执行一次的情况下有效但对于当前所有 for_each 样式的帮助程序即多次执行回调而言这是不安全的。释放已获取的调用程序引用的回调可多次执行此操作但当前验证器将其视为框架内的一次调用框架然后会返回到调用程序。因此它认为自己释放了 cb eg 通过 callback_ctx寄存器从堆栈上溢出的类型化寄存器填充到 cb 内的某个引用。同样地它可能发现回调内获取调用未配对因此调用程序将复制回调的引用状态然后必须使用新的 ref_obj_ids 释放寄存器。但同样，回调可能执行多次，但验证程序将仅考虑针对回调的单次符号执行获取的引用，这将导致泄漏。请注意对于异步回调情况情况有所不同。虽然目前我们的 bpf_timer_set_callback 只执行一次但即使多次执行也是安全的因为引用状态为空而 check_reference_leak 会强制程序在 BPF_EXIT 之前释放状态。状态也不会受到调用程序框架分析的影响。因此异步回调是安全的。由于我们希望引用状态易于访问例如通过 callback_ctx 的 PTR_TO_STACK 从堆栈加载的指针我们仍然必须将调用者的reference_state 复制到回调的 bpf_func_state但我们强制无论添加到该reference_state 中的任何引用在命中 BPF_EXIT 之前都必须释放。这需要在引用状态中引入一个新的 callback_ref 成员以区分调用者引用与被调用者引用。因此check_reference_leak 发现我们在 callback_fn 中并且尚未释放 callback_ref refs 现在会错误输出。由于可能存在多个嵌套的回调例如 frame 0 -> cb1 -> cb2 等。
    我们还需要区分此特定 ref 是属于这个回调框架还是父框架以及我们自己框架中的错误因此我们存储 state->frameno对于回调而言始终为非零。简而言之，回调可以读取父reference_state，但不能改变它，以使用调用程序获取的指针。它们必须仅在返回前在调用程序reference_state 上撤消其更改通过在 BPF_EXIT 之前释放其自己的 acquire_refs此时调用程序和回调状态无论如何都将匹配因此无需将其复制回调用程序。 (CVE-2022-50650)

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

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

  - cifs修复 cifs_copy_file_range() 中的 xid 泄漏如果文件由交换使用则应在返回 -EOPNOTSUPP 之前释放 xid否则xid 将被泄漏。 (CVE-2022-50643)

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

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

  - mmcomap_hsmmc修复 mmc_add_host() 的返回值检查 mmc_add_host() 可能返回错误如果忽略其返回值将导致两个问题1. 在 mmc_alloc_host() 中分配的内存泄漏。 2.
    在 remove() 路径中将调用 mmc_remove_host() 以删除设备但尚未添加设备会将内核崩溃因为 device_del() 中存在 null-ptr-deref。通过检查返回值修复此问题并转到将调用 mmc_free_host() 的错误路径。 (CVE-2022-50670)

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

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

  - PCI通过检查 PF pci_device_is_present() 以前无法用于 VF的修复 pci_device_is_present()因为它读取供应商和设备 ID对于 VF而言为 0xffff而这些 ID 看起来像是不存在。请改为检查 PF。Wei Gong 报告当驱动程序未绑定或将 0 写入 /sys/.../sriov_numvfs 时如果 virtio I/O 正在进行中virtio I/O 操作会挂起这可能导致类似这样的输出task:bash state:D stack: 0 pid: 1773 ppid: 1241 flags:0x00004002 调用跟踪
    schedule+0x4f/0xc0 blk_mq_freeze_queue_wait+0x69/0xa0 blk_mq_freeze_queue+0x1b/0x20 blk_cleanup_queue+0x3d/0xd0 virtblk_remove+0x3c/0xb0 [virtio_blk] virtio_dev_remove+0x4b/0x80 ...
    device_unregister+0x1b/0x60 unregister_virtio_device+0x18/0x30 virtio_pci_remove+0x41/0x80 pci_device_remove+0x3e/0xb0 发生这种情况的原因是 pci_device_is_present(VF) 在 virtio_pci_remove() 中返回 false 因此它调用了 virtio_break_device()。vq 被破坏意味着 vring_interrupt() 会跳过本可通过 virtblk_done() 完成 virtio I/O 操作的 vq.callback()。
    [bhelgaas提交日志简化以始终使用 pci_physfn()添加稳定标签] (CVE-2022-50636)

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

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

  - cpufreqqcom-hw修复了 qcom_cpufreq_hw_read_lut() 中的内存泄露问题 如果 cpu_dev 无法获得 qcom_cpufreq_hw_read_lut() 中的 opp 表程序将返回从而导致表资源未释放。
    (CVE-2022-50637)

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

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

  - EDAC/i10nm修复 pci_get_dev_wrapper() 中的 refcount 泄漏正如 pci_get_domain_bus_and_slot() 的注释所述它将返回 refcount 增加的 PCI 设备因此它不需要调用 pci_get_dev_wrapper() 中的额外 pci_dev_get()且PCI 设备需要放入错误路径中。 (CVE-2022-50645)

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

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

  - bpf修复由于 im->image 的错误页面属性造成的错误在 livepatch 和 kretfunc 共存的场景中im->image 的页面属性在 bpf_trampoline_update 中的 arch_prepare_bpf_trampoline 之后为 rox然后 modify_fentry 或 register_fentry 从 bpf_tramp_ftrace_ops_func即 BPF_TRAMP_F_ORIG_STACK 返回 -EAGAIN将配置 标记并将重新执行 arch_prepare_bpf_trampoline。此时因为 im->image 的 pageattr 为 roxarch_prepare_bpf_trampoline 将读写 im->image从而导致错误。 insmod livepatch-sample.ko #samples/livepatch/livepatch-sample.c bpftrace -e ‘kretfunc:cmdline_proc_show {}’ 缺陷无法处理地址 的页面错误
    ffffffffa0206000 PGD 322d067 P4D 322d067 PUD 322e063 PMD 1297e067 PTE d428061 Oops: 0003 [#1] PREEMPT SMP PTI CPU: 2 PID: 270 Comm: bpftrace Tainted: GEK 6.1.0 #5 RIP
    0010arch_prepare_bpf_trampoline+0xed/0x8c0 RSP0018:ffffc90001083ad8 EFLAGS00010202 RAX
    ffffffffa0206000 RBX: 0000000000000020 RCX: 0000000000000000 RDX: ffffffffa0206001 RSI: ffffffffa0206000 RDI: 0000000000000030 RBP: ffffc90001083b70 R08: 0000000000000066 R09: ffff88800f51b400 R10:
     R11000000002e72c6e5  : 00000000d0a15080 R12: ffff8880110a68c8 R13: 0000000000000000 R14: ffff88800f51b400 R15: ffffffff814fec10 FS: 00007f87bc0dc780(0000) GS:ffff88803e600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: fffffffffa0206000 CR3: 0000000010b70000 CR4: 00000000000006e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 00000006: 00000006
    00000000fffe0ff0 DR70000000000000400 调用跟踪 <TASK> bpf_trampoline_update+0x25a/0x6b0
    __bpf_trampoline_link_prog+0x101/0x240 bpf_trampoline_link_prog+0x2d/0x50 bpf_tracing_prog_attach+0x24c/0x530 bpf_raw_tp_link_attach+0x73/0x1d0 __sys_bpf+0x100e/0x2570
    __x64_sys_bpf+0x1c/0x30 do_syscall_64+0x5b/0x80 entry_SYSCALL_64_after_hwframe+0x63/0xcd 使用此修补程序时modify_fentry 或 register_fentry 从 bpf_tramp_ftrace_ops_func 返回 -EAGAIN 时im->image 的 pageattr 将重置为 nx+rw。 (CVE-2022-50654)

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

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

  - io-wq修复工作线程创建中的内存泄漏如果节点的 CPU 掩码分配失败则为当前节点的“io_wqe”struct 分配的内存不会在错误处理路径中释放因为它没有释放尚未添加到“wqes”数组中。当使用 Syzkaller 模糊 v6.1-rc1 时发现此问题时缺陷
    内存泄漏未引用对象 0xffff8880093d5000（大小 1024）：comm syz-executor.2，pid 7701，jiffies 4295048595（使用期限 13.900s）十六进制转储前 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 00 00 00 00 00 00 00 .. . 回溯其他
    [<00000000cb463369>] __kmem_cache_alloc_node+0x18e/0x720 [<00000000147a3f9c>] kmalloc_node_trace+0x2a/0x130 [<000000004e107011>] io_wq_create+0x7b9/0xdc0 [<00000000c38b2018>] io_uring_alloc_task_context+0x31e/0x59d [<00000000867399da>] __io_uring_add_tctx_node.cold [01<000000007e0e7a79>+cold ] io_uring_setup.cold+0x1b80/0x1dce [<00000000b545e9f6>]
    __x64_sys_io_uring_setup+0x5d/0x80 [<000000008a8a7508>] do_syscall_64+0x5d/0x90 [<000000004ac08bec>] entry_SYSCALL_64_after_hwframe+0x63/0xcd (CVE-2022-50639)

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

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

  - ext4修复由错误的引导加载程序 inode 造成的 __es_tree_search 中的 bug_on 我们遇到的问题为流
    ================================================== ================ fs/ext4/extents_status.c:203! 的内核缺陷无效的 opcode: 0000 [#1] PREEMPT SMP CPU: 1 PID: 945 Comm: cat Not tainted 6.0.0-next-20221007-dirty #349 RIP: 0010:ext4_es_end.isra.0+0x34/0x42 RSP: 0018:ffffc9000143b768 EFLAGS
    00010203 RAX0000000000000000 RBXffff8881769cd0b8 RCX0000000000000000 RDX0000000000000000 RSI
    ffffffff8fc27cf7 RDI: 00000000ffffffff RBP: ffff8881769cd0bc R08: 0000000000000000 R09: ffffc9000143b5f8 R10: 0000000000000001 R11: 0000000000000001 R12: ffff8881769cd0a0 R13: ffff8881768e5668 R14:
    00000000768e52f0 R150000000000000000 FS
    00007f359f7f05c0(0000)GS:ffff88842fd00000(0000)knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0:
    0000000080050033 CR2: 00007f359f5a2000 CR3: 000000017130c000 CR4: 00000000000006e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7:
    0000000000000400 Call Trace: <TASK> __es_tree_search.isra.0+0x6d/0xf5 ext4_es_cache_extent+0xfa/0x230 ext4_cache_extents+0xd2/0x110 ext4_find_extent+0x5d5/0x8c0 ext4_ext_map_blocks+0x9c/0x1d30 ext4_map_blocks+0x431/0xa50 ext4_mpage_readpages+0x48e/0xe40 ext4_readahead+0x47/0x50 read_pages+0x82/0x530 page_cache_ra_unbounded+0x199/0x2a0 do_page_cache_ra+0x47/0x70 page_cache_ra_order+0x242/0x400 ondemand_readahead+0x1e8/0x4b0 page_cache_sync_ra+0xf4/0x110 filemap_get_pages+0x131/0xb20 filemap_read+0xda/0x4b0 generic_file_read_iter+0x13a/0x250 ext4_file_read_iter+0x59/0x1d0 vfs_read+0x28f/0x460 ksys_read+0x73/0x160 __x64_sys_read+0x1e/0x30 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x63/0xcd </TASK> ======================= =========================================== 在上述问题中ioctl 调用swap_inode_boot_loader 函数以交换 inode<5> 和 inode<12>。但是inode<5> 包含不正确的 imode 和无序范围i_nlink 设置为 1。因为 5 为 EXT4_BOOT_LOADER_INO可绕过 ext4_iget 函数中 inode 的范围检查。将 links_count 设置为 1 时swap_inode_boot_loader 中的盘区未初始化。成功执行 ioctl 命令后范围将交换至 inode<12>在这种情况下请运行“cat”命令以查看 inode<12>。且会因范围不正确而触发 Bug_ON。当引导加载程序 inode 未初始化时其 imode 可能为下列之一 1) imode 是错误类型在 ext4_iget 中被标记为 bad_inode 并被设置为 S_IFREG。 2) imode 是正确类型但 S_IFREG 不是。 3) imode 为 S_IFREG。BUG_ON 可通过绕过情况 1 和 2 中的检查来触发。因此当引导加载程序 inode 为 bad_inode或其 imode 不是 S_IFREG 时请初始化 inode 以避免触发 BUG。 (CVE-2022-50638)

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

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

  - Robocode 版本 1.9.3.6的 AutoExtract 组件中存在一个不安全的临时文件创建漏洞。createTempFile 方法无法安全地创建临时文件从而允许攻击者利用争用条件并可能执行任意代码或覆盖关键文件。通过操纵临时文件创建进程可以利用此漏洞导致潜在的未授权操作。 (CVE-2025-14307)

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

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

  - md/raid5-cache修复 r5l_exit_log() 中的死锁提交 b13015af94cfmd/raid5-cache完成工作后清除 conf->log引入一个新问题 // caller hold reconfig_mutex r5l_exit_log flush_work(&log->disable_writeback_work) r5c_disable_writeback_async wait_event /* * conf->log 不是 NULLmddev_trylock() * 将失败 wait_event() 始终无法通过。 */ conf->log = NULL通过在 wake_up() 之前将“config->log”设置为 NULL来修复此问题因为以前可以存在来自 r5c_disable_writeback_async() 的 wait_event()。同时前移 md_unregister_thread()以便仍可修复此提交修复的 null-ptr-deref。 (CVE-2023-53848)

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

ID	名称	严重性
278105	Linux Distros 未修补的漏洞：CVE-2023-53791	medium
278104	Linux Distros 未修补的漏洞：CVE-2023-53784	high
278103	Linux Distros 未修补的漏洞：CVE-2023-53818	high
278102	Linux Distros 未修补的漏洞：CVE-2023-53786	medium
278101	Linux Distros 未修补的漏洞：CVE-2023-53803	high
278100	Linux Distros 未修补的漏洞：CVE-2023-53809	medium
278099	Linux Distros 未修补的漏洞：CVE-2023-53819	high
278098	Linux Distros 未修补的漏洞：CVE-2023-53815	high
278097	Linux Distros 未修补的漏洞：CVE-2023-53777	medium
278096	Linux Distros 未修补的漏洞：CVE-2023-53795	high
278095	Linux Distros 未修补的漏洞：CVE-2023-53798	medium
278094	Linux Distros 未修补的漏洞：CVE-2022-50655	medium
278093	Linux Distros 未修补的漏洞：CVE-2022-50648	medium
278092	Linux Distros 未修补的漏洞：CVE-2022-50646	medium
278091	Linux Distros 未修补的漏洞：CVE-2022-50653	medium
278090	Linux Distros 未修补的漏洞：CVE-2022-50633	medium
278089	Linux Distros 未修补的漏洞：CVE-2022-50632	high
278088	Linux Distros 未修补的漏洞：CVE-2022-50640	medium
278087	Linux Distros 未修补的漏洞：CVE-2022-50651	medium
278072	Linux Distros 未修补的漏洞：CVE-2022-50661	high
278071	Linux Distros 未修补的漏洞：CVE-2023-53800	high
278070	Linux Distros 未修补的漏洞：CVE-2023-53813	high
278069	Linux Distros 未修补的漏洞：CVE-2023-53843	medium
278068	Linux Distros 未修补的漏洞：CVE-2023-53842	medium
278067	Linux Distros 未修补的漏洞：CVE-2022-50677	high
278066	Linux Distros 未修补的漏洞：CVE-2023-53799	medium
278065	Linux Distros 未修补的漏洞：CVE-2023-53808	medium
278064	Linux Distros 未修补的漏洞：CVE-2023-53844	medium
278063	Linux Distros 未修补的漏洞：CVE-2023-53830	medium
278062	Linux Distros 未修补的漏洞：CVE-2023-53814	medium
278061	Linux Distros 未修补的漏洞：CVE-2023-53802	medium
278060	Linux Distros 未修补的漏洞：CVE-2023-53831	high
278059	Linux Distros 未修补的漏洞：CVE-2023-53839	medium
278058	Linux Distros 未修补的漏洞：CVE-2023-53788	medium
278057	Linux Distros 未修补的漏洞：CVE-2023-53832	medium
278056	Linux Distros 未修补的漏洞：CVE-2023-53793	medium
278055	Linux Distros 未修补的漏洞：CVE-2023-53792	medium
278054	Linux Distros 未修补的漏洞：CVE-2023-53810	medium
278053	Linux Distros 未修补的漏洞：CVE-2023-53828	high
278044	Linux Distros 未修补的漏洞：CVE-2022-50650	high
278043	Linux Distros 未修补的漏洞：CVE-2022-50643	high
278042	Linux Distros 未修补的漏洞：CVE-2022-50670	medium
278041	Linux Distros 未修补的漏洞：CVE-2022-50636	medium
278040	Linux Distros 未修补的漏洞：CVE-2022-50637	medium
278039	Linux Distros 未修补的漏洞：CVE-2022-50645	high
278038	Linux Distros 未修补的漏洞：CVE-2022-50654	medium
278037	Linux Distros 未修补的漏洞：CVE-2022-50639	medium
278036	Linux Distros 未修补的漏洞：CVE-2022-50638	high
278024	Linux Distros 未修补的漏洞：CVE-2025-14307	critical
278023	Linux Distros 未修补的漏洞：CVE-2023-53848	medium

检测

Nessus 的 Misc. 系列

medium

high

high

medium

high

medium

high

high

medium

high

medium

medium

medium

medium

medium

medium

high

medium

medium

high

high

high

medium

medium

high

medium

medium

medium

medium

medium

medium

high

medium

medium

medium

medium

medium

medium

high

high

high

medium

medium

medium

high

medium

medium

high

critical

medium