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

  - ACPICA避免未定义的行为将零偏移应用至空指针 ACPICA commit 770653e3ba67c30a629ca7d12e352d83c2541b1e 在此变更之前我们在 Fuchsia 中发现下列 UBSAN 堆栈追踪 #0 0x000021e4213b3302 in acpi_ds_init_aml_walk(struct acpi_walkpi_space_node,8*object acpi_parse) u32、 struct acpi_evaluate_info*、u8) ../../third_party/acpica/source/components/dispatcher/dswstate.c:682 <platform-bus-x86.so>+0x233302 #1.2 ubsan_get_stack_trace() 中的 0x000020d0f660777f compiler-rt/lib/ubsan/ubsan_diag .cpp:41 <libclang_rt.asan.so>+0x3d77f #1.1 maybe_print_stack_trace() compiler-rt/lib/ubsan/ubsan_diag.cpp:51 <libclang_rt.asan.so>+0x3d77f #1 ~scoped_report() compiler-rt/lib/ubsan/ubsan_diag 中的 0x000020d0f660777f .cpp:387 <libclang_rt.asan.so>+0x3d77f #2 handlepointer_overflow_impl() compiler-rt/lib/ubsan/ubsan_handlers.cpp:809 中的 0x000020d0f660b96d <libclang_rt.asan.so>+0x4196d #3 compiler-rt/lib/ubsan/ubsan_handlers.cpp:815 中的 0x000020d0f660b50d <libclang_rt.asan.so>+0x4150d #4 acpi_ds_init_aml_walk 中的 0x000021e4213b3302(struct acpi_walk_state*, union acpi_parse_object*, struct acpi_namespace_node*, u8*, u32, struct acpi_evaluate_info*, u8) ../../third_party/acpica/source/components/dispatcher/dswstate.c:682 <platform-bus-x86.so>+0x233302 #5 0x000021e4213e2369 acpi_ds_call_control_method(struct acpi_thread_state*, struct acpi_walk_state*, union acpi_parse_object*) ../../third_party/acpica/source/components/dispatcher/dsmethod.c:605中 <platform-bus-x86.so>的  +0x262369 #6 acpi_ps_parse_aml(struct acpi_walk_state*) 中的 0x000021e421437fac ../../third_party/acpica/source/components/parser/psparse.c:550 <platform-bus-x86.so>+0x2b7fac #7 acpi_ps_execute_method(struct acpi_evaluate_info*) 中的 0x000021e4214464d2 ../../third_party/acpica/source/components/parser /psxface.c:244 <platform-bus-x86.so>+0x2c64d2 #8 acpi_ns_evaluate(struct acpi_evaluate_info*) 中的 0x000021e4213aa052 ../../third_party/acpica/source/components/namespace/nseval.c:250 <platform-bus-x86.so>+0x22a052 #9 0x000021e421413inacpi_init_one_init_devicedd8 in (acpi_handle、u32、void*、void**) ../../third_party/acpica/source/components/namespace/nsinit.c :735 <platform-bus-x86.so>+0x293dd8 #10 acpi_ns_walk_namespace(acpi_object_type, acpi_handle, u32, u32, acpi_walk_callback, acpi_walk_callback, void*, void**) 中的 0x000021e421429e98../../third_party/acpica/source/components/namespace/nswalk.c :298 <platform-bus-x86.so>+0x2a9e98 #11 acpi_ns_initialize_devices(u32) 中的 0x000021e4214131ac ../../third_party/acpica/source/components/namespace/nsinit.c:268 <platform-bus-x86.so>+0x2931ac #12 acpi_initialize_objects 中的 0x000021e42147c40d.(u32) ../third_party/acpica/source/components/utilities/utxfinit.c:304 <platform-bus-x86.so>+0x2fc40d #13 acpi::acpi_impl::initialize_acpi(acpi::acpi_impl*) 中的 0x000021e42126d603 ../../src/devices/ board/lib/acpi/acpi-impl.cc:224 <platform-bus-x86.so>+0xed603 添加简单检查避免将指针增加零但其他行为与以前相同。请注意，我们的发现依据是 ACPICA 20221020，但主控端上存在相同的代码。 (CVE-2023-53182)

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

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

  - iommu/mediatek修复 isr 上 kexec() 后的崩溃问题如果通过 isr() 重新启动系统可能会在初始化域之前触发 IRQ 处理程序。导致无效的内存访问错误。修复 [0.500930] 无法处理从虚拟地址 0000000000000070 处不可读内存的内核读取 [0.501166] 调用跟踪 [ 0.501174] report_iommu_fault+0x28/0xfc [ 0.501180] mtk_iommu_isr+0x10c/0x1c0 [joro已修复提交中的拼写消息 ] (CVE-2022-50236

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

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

  - fs/ntfs3向 attr_load_runs_vcn 添加空指针检查某些元数据文件在 MFT 之前处理。这针对某些极端情况添加了空指针检查这些极端情况在读取畸形 NTFS 图像的这些元数据文件时可能导致 NPD。 [ 240.190827] 缺陷内核空指针取消引用地址 0000000000000158 [ 240.191583] #PF内核模式下的主管读取访问 [ 240.191956] #PF: error_code (0x0000) - 不存在页面 [ 240.192391] PGD 0 P4D 0 [ 240.192897] Oops: 0000 [#1] PREEMPT SMP KASAN NOPTI [ 240.193805] CPU: 0 PID: 242 Comm: mount 受感染: GB 5.19.0+ #17 [ 240.194477] 硬件名称QEMU Standard PC (i440FX + PIIX1996, BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 [ 240.195152] RIP
    0010:ni_find_attr+0xae/0x300 [ 240.195679] 代码c8 48 c7 45 88 c0 4e 5e 86 c7 00 f1 f1 f1 f1 c7 40 04 00 f3 f3 f3 65 48 8b 04 25 28 00 00 00 48 89 45 d0 31 c0 31 e8 e2 d9f [ 240.196642] RSP: 0018:ffff88800812f690 EFLAGS: 00000286 [ 240.197019] RAX: 0000000000000001 RBX: 0000000000000000 RCX: ffffffff85ef037a [240.197523] RDX: 0000000000000001 RSI: 0000000000000008 RDI: ffffffff88e95f60 [ 240.197877] RBP:
    ffff88800812f738 R080000000000000001 R09ffffbffff11d2bed [ 240.198292] R10ffffffff88e95f67 R11
    ffffffbff11d2bec R120000000000000000 [ 240.198647] R130000000000000080 R140000000000000000 R15
    0000000000000000 [ 240.199410] FS: 00007f233c33be40(0000) GS:ffff888058200000(0000) knlGS:0000000000000000 [ 240.199895] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 240.200314] CR2: 0000000000000158 CR3:
    0000000004d32000 CR4: 00000000000006f0 [ 240.200839] 调用跟踪 [ 240.201104] <TASK> [ 240.201502] ? ni_load_mi+0x80/0x80 [ 240.202297] ? ___slab_alloc+0x465/0x830 [ 240.202614] attr_load_runs_vcn+0x8c/0x1a0 [ 240.202886] ? __kasan_slab_alloc+0x32/0x90 [ 240.203157] attr_data_write_residue+0x250/0x250 [240.203543] mi_read+0x133/0x2c0 [ 240.203785] mi_get+0x70/0x140 [ 240.204012] ni_load_mi_ex+0xfa/0x190 [240.204346] ? ni_std5+0x90/0x90 [ 240.204588] ? __kasan_kmalloc+0x88/0xb0 [ 240.204859] ni_enum_attr_ex+0xf1/0x1c0 [ 240.205107] ? ni_fname_type.part.0+0xd0/0xd0 [ 240.205600] ntfs_load_attr_list+0xbe/0x300 [ 240.205864] ? ntfs_cmp_names_cpu+0x125/0x180 [ 240.206157] ntfs_iget5+0x56c/0x1870 [ 240.206510] ? ntfs_get_block_bmap+0x70/0x70 [ 240.206776] ?
    __kasan_kmalloc+0x88/0xb0 [ 240.207030] ? set_blocksize+0x95/0x150 [ 240.207545] ntfs_fill_super+0xb8f/0x1e20 [ 240.207839] ? put_ntfs+0x1d0/0x1d0 [ 240.208069] ? vsprintf+0x20/0x20 [240.208467] ? mutex_unlock+0x81/0xd0 [ 240.208846] ? set_blocksize+0x95/0x150 [ 240.209221] get_tree_bdev+0x232/0x370 [ 240.209804] ? put_ntfs+0x1d0/0x1d0 [ 240.210519] ntfs_fs_get_tree+0x15/0x20 [240.210991] vfs_get_tree+0x4c/0x130 [ 240.211455] path_mount+0x645/0xfd0 [ 240.211806] ? putname+0x80/0xa0 [ 240.212112] ? finish_automount+0x2e0/0x2e0 [ 240.212559] ? kmem_cache_free+0x110/0x390 [ 240.212906] putname+0x80/0xa0 [ 240.213329] do_mount+0xd6/0xf0 [ 240.213829] ? path_mount+0xfd0/0xfd0 [ 240.214246] ?
    __kasan_check_write+0x14/0x20 [ 240.214774] __x64_sys_mount+0xca/0x110 [ 240.215080] do_syscall_64+0x3b/0x90 [ 240.215442] entry_SYSCALL_64_after_hwframe+0x63/0xcd [ 240.215811] RIP
    0033:0x7f233b4e948a [ 240.216104] Code48 8b 0d 11 fa 2a 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 49 0 0 0 0 ca b [ 240.217615] RSP002b:00007fff02211ec8 EFLAGS
    00000202 ORIG_RAX: 00000000000000a5 [ 240.218718] RAX: ffffffffffffffda RBX: 0000561cdc35b060 RCX
    00007f233b4e948a [ 240.219556] RDX: 0000561cdc35b260 RSI: 0000561cdc35b2e0 RDI: 0000561cdc363af0 [240.219975] RBP: 0000000000000000 R08: 0000561cdc35b280 R09: 0000000000000020 [ 240.220403] R10:
    00000000c0ed0000 R110000000000000202 R12: 0000561cdc363af0 [ 240.220803] R13000 ---truncated--- (CVE-2022-50336)

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

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

  - ext4修复 ext4_fc_replay_scan() 中潜在的越界读取。For 扫描循环必须确保至少存在 EXT4_FC_TAG_BASE_LEN 空间。如果剩余空间小于 EXT4_FC_TAG_BASE_LEN这将在挂载损坏的文件系统映像时导致越界读取。进行日志扫描时需要 ADD_RANGE/HEAD/TAIL 添加额外检查因为这三个标签将在扫描期间读取数据标签长度不能小于将读取的数据长度。 (CVE-2022-50306)

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

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

  - memoryof修复 of_get_ddr_timings() 中的 refcount 泄漏缺陷 我们应在中断 for_each_child_of_node() 时添加 of_node_put()因为它将自动增加和减少 refcount。
    (CVE-2022-50249)

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

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

  - wifimac80211_hwsim修复可能的空取消引用在对 mac80211_hwsim_select_tx_link() 的调用中sta 指针可能为空因此需要在访问之前检查其是否非空。 (CVE-2023-53209)

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

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

  - ipv6/addrconf修复 idev 的潜在引用计数下溢。现在在 addrconf_mod_rs_timer() 中引用 idev 取决于 rs_timer 是否未处于待定状态。然后修改 rs_timer 超时。[1] 中存在一个时间间隔，如果待定 rs_timer 变为非待定期间。将错过保持 idev但 rs_timer 已激活。因此将执行 rs_timer 回调函数 addrconf_rs_timer()并稍后放置 idev而不保留 idev。此问题可能是用于 idev 的 refcount 下溢问题。 if (!timer_pending(&idev->rs_timer)) in6_dev_hold(idev); <--------------[1] mod_timer(&idev->rs_timer, jiffies + when);要修复此问题请在 mod_timer() 返回 0 时按住 idev。(CVE-2023-53189)

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

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

  - 已修复 Linux 内核中的下列漏洞：usb: xhci-mtk: fix leakage of shared hcd when fail to set wakeup irq Can not set the @shared_hcd to NULL before decrease the usage count by usb_put_hcd(), this will cause the shared hcd not released. (CVE-2022-50247)

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

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

  - 已修复 Linux 内核中的下列漏洞：vxlan: Fix memory leaks in error path The memory allocated by vxlan_vnigroup_init() is not freed in the error path, leading to memory leaks [1].
    Fix by calling vxlan_vnigroup_uninit() in the error path. The leaks can be reproduced by annotating gro_cells_init() with ALLOW_ERROR_INJECTION() and then running: # echo 100 > /sys/kernel/debug/fail_function/probability # echo 1 > /sys/kernel/debug/fail_function/times # echo gro_cells_init > /sys/kernel/debug/fail_function/inject # printf %#x -12 > /sys/kernel/debug/fail_function/gro_cells_init/retval # ip link add name vxlan0 type vxlan dstport 4789 external vnifilter RTNETLINK answers: Cannot allocate memory [1] unreferenced object 0xffff88810db84a00 (size 512): comm ip, pid 330, jiffies 4295010045 (age 66.016s) hex dump (first 32 bytes): f8 d5 76 0e 81 88 ff ff 01 00 00 00 00 00 00 02 ..v............. 03 00 04 00 48 00 00 00 00 00 00 01 04 00 01 00 ....H........... backtrace: [<ffffffff81a3097a>] kmalloc_trace+0x2a/0x60 [<ffffffff82f049fc>] vxlan_vnigroup_init+0x4c/0x160 [<ffffffff82ecd69e>] vxlan_init+0x1ae/0x280 [<ffffffff836858ca>] register_netdevice+0x57a/0x16d0 [<ffffffff82ef67b7>] __vxlan_dev_create+0x7c7/0xa50 [<ffffffff82ef6ce6>] vxlan_newlink+0xd6/0x130 [<ffffffff836d02ab>] __rtnl_newlink+0x112b/0x18a0 [<ffffffff836d0a8c>] rtnl_newlink+0x6c/0xa0 [<ffffffff836c0ddf>] rtnetlink_rcv_msg+0x43f/0xd40 [<ffffffff83908ce0>] netlink_rcv_skb+0x170/0x440 [<ffffffff839066af>] netlink_unicast+0x53f/0x810 [<ffffffff839072d8>] netlink_sendmsg+0x958/0xe70 [<ffffffff835c319f>] ____sys_sendmsg+0x78f/0xa90 [<ffffffff835cd6da>]
    ___sys_sendmsg+0x13a/0x1e0 [<ffffffff835cd94c>] __sys_sendmsg+0x11c/0x1f0 [<ffffffff8424da78>] do_syscall_64+0x38/0x80 unreferenced object 0xffff88810e76d5f8 (size 192): comm ip, pid 330, jiffies 4295010045 (age 66.016s) hex dump (first 32 bytes): 04 00 00 00 00 00 00 00 db e1 4f e7 00 00 00 00 ..........O..... 08 d6 76 0e 81 88 ff ff 08 d6 76 0e 81 88 ff ff ..v.......v..... backtrace:
    [<ffffffff81a3162e>] __kmalloc_node+0x4e/0x90 [<ffffffff81a0e166>] kvmalloc_node+0xa6/0x1f0 [<ffffffff8276e1a3>] bucket_table_alloc.isra.0+0x83/0x460 [<ffffffff8276f18b>] rhashtable_init+0x43b/0x7c0 [<ffffffff82f04a1c>] vxlan_vnigroup_init+0x6c/0x160 [<ffffffff82ecd69e>] vxlan_init+0x1ae/0x280 [<ffffffff836858ca>] register_netdevice+0x57a/0x16d0 [<ffffffff82ef67b7>] __vxlan_dev_create+0x7c7/0xa50 [<ffffffff82ef6ce6>] vxlan_newlink+0xd6/0x130 [<ffffffff836d02ab>] __rtnl_newlink+0x112b/0x18a0 [<ffffffff836d0a8c>] rtnl_newlink+0x6c/0xa0 [<ffffffff836c0ddf>] rtnetlink_rcv_msg+0x43f/0xd40 [<ffffffff83908ce0>] netlink_rcv_skb+0x170/0x440 [<ffffffff839066af>] netlink_unicast+0x53f/0x810 [<ffffffff839072d8>] netlink_sendmsg+0x958/0xe70 [<ffffffff835c319f>] ____sys_sendmsg+0x78f/0xa90 (CVE-2023-53190)

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

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

  - 已修复 Linux 内核中的下列漏洞：ovl: fix null pointer dereference in ovl_permission() Following process: P1 P2 path_lookupat link_path_walk inode_permission ovl_permission ovl_i_path_real(inode, &realpath) path->dentry = ovl_i_dentry_upper(inode) drop_cache
    __dentry_kill(ovl_dentry) iput(ovl_inode) ovl_destroy_inode(ovl_inode) dput(oi->__upperdentry) dentry_kill(upperdentry) dentry_unlink_inode upperdentry->d_inode = NULL realinode = d_inode(realpath.dentry) // return NULL inode_permission(realinode) inode->i_sb // NULL pointer dereference , will trigger an null pointer dereference at realinode: [ 335.664979] BUG: kernel NULL pointer dereference, address: 0000000000000002 [ 335.668032] CPU: 0 PID: 2592 Comm: ls Not tainted 6.3.0 [335.669956] RIP: 0010:inode_permission+0x33/0x2c0 [ 335.678939] Call Trace: [ 335.679165] <TASK> [335.679371] ovl_permission+0xde/0x320 [ 335.679723] inode_permission+0x15e/0x2c0 [ 335.680090] link_path_walk+0x115/0x550 [ 335.680771] path_lookupat.isra.0+0xb2/0x200 [ 335.681170] filename_lookup+0xda/0x240 [ 335.681922] vfs_statx+0xa6/0x1f0 [ 335.682233] vfs_fstatat+0x7b/0xb0 Fetch a reproducer in [Link]. Use the helper ovl_i_path_realinode() to get realinode and then do non-nullptr checking. (CVE-2023-53260)

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

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

  - drm/amdkfd修复双重释放计算 pasid 将 vm 转换为计算 vm 并将 vm->pasid 设置为计算 pasid 之后如果 kfd_process_device_init_vm 返回 failure 则 KFD 将不会采用 pdd->drm_file 引用。因此可能会在 KFD 进程破坏工作线程之前调用 drm 关闭文件处理程序以释放计算 pasid从而释放相同的 pasid 并将 vm->pasid 设置为零这会生成以下警告回溯和空指针访问。添加辅助函数 amdgpu_amdkfd_gpuvm_set_vm_pasid 并在 kfd_process_device_init_vm 的最后一步调用以确保在获取 vm 失败时vm pasid 为原始 pasid或是计算 pasid 并引用了 pdd->drm_file 以避免双重释放相同的 pasid。 amdgpu无法创建进程 ida_free 调用了 id=32770 的VM 对象该对象未分配。WARNING: CPU: 57 PID: 72542 at ../lib/idr.c:522 ida_free+0x96/0x140 RIP: 0010:ida_free+0x96/0x140 调用追踪
    amdgpu_pasid_free_delayed+0xe1/0x2a0 [amdgpu] amdgpu_driver_postclose_kms+0x2d8/0x340 [amdgpu] drm_file_free.part.13+0x216/0x270 [drm] drm_close_helper.isra.14+0x60/0x70 [drm] drf+__f0x6e/drm] [drm] drm_release+0x6e/drm 0xcc/0x280____fput+0xe/0x20 task_work_run+0x96/0xc0 do_exit+0x3d0/0xc10 缺陷内核空指针取消引用解决0000000000000000 RIP0010ida_free+0x76/0x140 调用跟踪
    amdgpu_pasid_free_delayed+0xe1/0x2a0 [amdgpu] amdgpu_driver_postclose_kms+0x2d8/0x340 [amdgpu] drm_file_free.part.13+0x216/0x270 [drm] drm_close_helper.isra.14+0x60/0x70 [drm] drf+__f0x6e/drm] [drm] drm_release+0x6e/drm 0xcc/0x280____fput+0xe/0x20 task_work_run+0x96/0xc0 do_exit+0x3d0/0xc10 (CVE-2022-50303)

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

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

  - mmhugetlb减少 h->resv_huge_pages 之前获取 hugetlb_lock h->*_huge_pages 计数器受 hugetlb_lock 保护但 alloc_huge_page 存在极端情况可在锁定之外减少计数器。这可导致 h->resv_huge_pages 的值损坏已在我们的系统上发现此问题。递减 h->resv_huge_pages 之前先获取 hugetlb_lock 以避免潜在的争用。
    (CVE-2022-50285)

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

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

  - 已修复 Linux 内核中的下列漏洞：ocxl: fix pci device refcount leak when calling get_function_0() get_function_0() calls pci_get_domain_bus_and_slot(), as comment says, it returns a pci device with refcount increment, so after using it, pci_dev_put() needs be called. Get the device reference when get_function_0() is not called, so pci_dev_put() can be called in the error path and callers unconditionally. And add comment above get_dvsec_vendor0() to tell callers to call pci_dev_put().
    (CVE-2022-50337)

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

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

  - 已修复 Linux 内核中的下列漏洞：vdpasim: fix memory leak when freeing IOTLBs After commit bda324fd037a (vdpasim: control virtqueue support), vdpasim->iommu became an array of IOTLB, so we should clean the mappings of each free one by one instead of just deleting the ranges in the first IOTLB which may leak maps. (CVE-2022-50263)

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

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

  - video/aperture删除 PCI 设备之前调用 sysfb_disable() 删除 PCI 设备之前从 Adobe Aperture_remove_conflicting_pci_devices() 调用 sysfb_disable()。如果没有此选项，simpledrm 在硬件驱动程序接管硬件后仍可绑定到 simple-framebuffer 设备。两个驱动程序会互相干扰且结果不明。报告的模式设置错误 [1] 如下所示。 ---- snap ---- rcu: INFO: rcu_sched 检测到 CPU/任务上有加速停止{ 13-.... } 7 jiffies s: 165 root
    0x2000/。 rcu阻断 rcu_node 结构内部 RCU 调试CPU 13 的任务转储 task:X state:R 运行任务 stack: 0 pid: 4242 ppid: 4228 flags:0x00000008 调用跟踪 <TASK> ? commit_tail+0xd7/0x130 ? drm_atomic_helper_commit+0x126/0x150 ? drm_atomic_commit+0xa4/0xe0 ? drm_plane_get_damage_clips.cold+0x1c/0x1c ? drm_atomic_helper_dirtyfb+0x19e/0x280 ? drm_mode_dirtyfb_ioctl+0x10f/0x1e0 ? drm_mode_getfb2_ioctl+0x2d0/0x2d0 ? drm_ioctl_kernel+0xc4/0x150 ? drm_ioctl+0x246/0x3f0 ? drm_mode_getfb2_ioctl+0x2d0/0x2d0 ? __x64_sys_ioctl+0x91/0xd0 ? do_syscall_64+0x60/0xd0 ? entry_SYSCALL_64_after_hwframe+0x4b/0xb5 </TASK>... rcuINFO rcu_sched 检测到 CPU/任务上有加速停止{ 13-.... } 30 jiffies s: 169 root0x2000/。 rcu阻断 rcu_node 结构内部 RCU 调试CPU 13: task:X state:R 的任务转储正在运行的任务 stack: 0 pid
    4242 ppid4228 flags0x0000400e 调用跟踪 <TASK> ? memcpy_toio+0x76/0xc0 ? memcpy_toio+0x1b/0xc0 ? drm_fb_memcpy_toio+0x76/0xb0 ? drm_fb_blit_toio+0x75/0x2b0 ? simpledrm_simple_display_pipe_update+0x132/0x150 ? drm_atomic_helper_commit_planes+0xb6/0x230 ? drm_atomic_helper_commit_tail+0x44/0x80 ? commit_tail+0xd7/0x130 ? drm_atomic_helper_commit+0x126/0x150 ? drm_atomic_commit+0xa4/0xe0 ? drm_plane_get_damage_clips.cold+0x1c/0x1c ? drm_atomic_helper_dirtyfb+0x19e/0x280 ? drm_mode_dirtyfb_ioctl+0x10f/0x1e0 ? drm_mode_getfb2_ioctl+0x2d0/0x2d0 ? drm_ioctl_kernel+0xc4/0x150 ? drm_ioctl+0x246/0x3f0 ? drm_mode_getfb2_ioctl+0x2d0/0x2d0 ? __x64_sys_ioctl+0x91/0xd0 ? do_syscall_64+0x60/0xd0 ? entry_SYSCALL_64_after_hwframe+0x4b/0xb5 </TASK> 问题是通过向 v6.0.3 提交 5e0137612430 (video/aperture通过 Apperture 帮助程序禁用和取消注册 sysfb 设备)添加到干线分支中。干线提交 5e0137612430视频/aperture通过 Apperture 帮助程序禁用和取消注册 sysfb 设备已从重构 fbdev 帧缓冲区所有权的较大修补程序系列 [2] 从 v6.0-rc1 向后移植到稳定 v6.0.3。向后移植缺少对 vulnerabilities_remove_conflicting_pci_devices() 的变更。主线本身没有问题因为这是系列修补程序的结果该函数并不存在。不向后移植整个 系列而是修复附加函数。 (CVE-2022-50332)

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

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

  - clkimxclk-imx8mn修复 imx8mn_clocks_probe 中的内存泄漏 使用 devm_of_iomap() 代替 of_iomap() 自动处理未使用的 ioremap 区域。如果发生任何错误由 kzalloc() 分配的区域将会泄漏但使用 devm_kzalloc() 则会使用 devm_kfree() 自动释放内存。
    (CVE-2023-53249)

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

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

  - scsicore修复 device_add() 失败时可能的内存泄漏 如果 device_add() 返回错误则需要释放由 dev_set_name() 分配的名称。正如 device_add() 的注释所述应该使用 put_device() 减少错误路径中的引用计数。因此可通过调用 put_device() 修复此问题然后可在 kobject_cleanp() 中释放该名称。 (CVE-2023-53174)

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

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

  - btrfs拔除某个范围的范围项目时不要在 ENOMEM 上执行 BUG_ON() 如果由于在尝试递增引用计数时无法分配内存在 btrfs_drop_extents() 处拔除给定范围中的文件范围项目时获得 -ENOMEM ”，或放弃引用计数时，我们使用 BUG_ON() 处理。这太过分了，我们可以简单地中止事务并将错误返回给调用程序。实际上如果 btrfs_drop_extents() 返回任何错误大多数 btrfs_drop_extents() 调用方已经直接或间接中止事务。此外我们在 btrfs_drop_extents() 中已经有了可能返回 -ENOMEM 的错误路径在这些情况下我们会中止事务例如像COW 现有范围缓冲区例如调用 btrfs_duplicate_item()。因此使用正确的逻辑替换 BUG_ON() 调用以中止事务并返回错误。 (CVE-2022-50293)

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

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

  - 已修复 Linux 内核中的下列漏洞：wifi: iwlwifi: pcie: fix NULL pointer dereference in iwl_pcie_irq_rx_msix_handler() rxq can be NULL only when trans_pcie->rxq is NULL and entry->entry is zero. For the case when entry->entry is not equal to 0, rxq won't be NULL even if trans_pcie->rxq is NULL. Modify checker to check for trans_pcie->rxq. (CVE-2023-53251)

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

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

  - scsiqla2xxx指针可能被取消引用 Klocwork 工具报告调用函数 fc_bsg_to_rport() 返回的指针“rport”可能为 NULL 且将被取消引用。添加一个补丁以在取消引用之前验证 rport。 (CVE-2023-53150)

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

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

  - wifibrcmfmac修复 brcmf_netdev_start_xmit() 中的潜在内存泄漏。在 pskb_expand_head() 失败的情况下brcmf_netdev_start_xmit() 返回 NETDEV_TX_OK 而不释放 skb添加 dev_kfree_skb() 以修复此问题。仅测试编译文件。(CVE-2022-50321)

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

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

  - fs/ntfs3在 indx_get_root 中添加长度检查 这将添加长度检查以保证检索的索引根合法。 [ 162.459513] BUGKASANhdr_find_e.isra.0+0x10c/0x320 中的释放后使用 [ 162.460176] 通过任务 mount/243 在 addr ffff8880037bca99 读取大小 2 的数据 [ 162.460851] [ 162.461252] CPU: 0 PID: 243 Comm: mount Not tainted 6.0.0-rc7 #42 [ 162.461744] Hardware name: QEMU Standard PC (i440FX + PIIX,1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04 /01/2014 [ 162.462609] 调用跟踪[ 162.462954] <TASK> [162.463276] dump_stack_lvl+0x49/0x63 [ 162.463822] print_report.cold+0xf5/0x689 [ 162.464608] ? unwind_get_return_address+0x3a/0x60 [ 162.465766] ? hdr_find_e.isra.0+0x10c/0x320 [ 162.466975] kasan_report+0xa7/0x130 [ 162.467506] ? _raw_spin_lock_irq+0xc0/0xf0 [ 162.467998] hdr_find_e.isra.0+0x10c/0x320 [ 162.468536] __asan_load2+0x68/0x90 [ 162.468923] hdr_find_e.isra.0+0x10c/0x320 [ 162.469282] ? cmp_uints+0xe0/0xe0 [ 162.469557] ? cmp_sdh+0x90/0x90 [162.469864] ? ni_find_attr+0x214/0x300 [ 162.470217] ? ni_load_mi+0x80/0x80 [ 162.470479] ? entry_SYSCALL_64_after_hwframe+0x63/0xcd [ 162.470931] ? ntfs_bread_run+0x190/0x190 [ 162.471307] ? indx_get_root+0xe4/0x190 [ 162.471556] ? indx_get_root+0x140/0x190 [ 162.471833] ? indx_init+0x1e0/0x1e0 [162.472069] ? fnd_clear+0x115/0x140 [ 162.472363] ? _raw_spin_lock_irqsave+0x100/0x100 [ 162.472731] indx_find+0x184/0x470 [ 162.473461] ? sysvec_apic_timer_interrupt+0x57/0xc0 [ 162.474429] ? indx_find_buffer+0x2d0/0x2d0 [ 162.474704] ? do_syscall_64+0x3b/0x90 [ 162.474962] dir_search_u+0x196/0x2f0 [ 162.475381] ? ntfs_nls_to_utf16+0x450/0x450 [ 162.475661] ? ntfs_security_init+0x3d6/0x440 [ 162.475906] ? is_sd_valid+0x180/0x180 [ 162.476191] ntfs_extend_init+0x13f/0x2c0 [ 162.476496] ? ntfs_fix_post_read+0x130/0x130 [ 162.476861] ? iput.part.0+0x286/0x320 [ 162.477325] ntfs_fill_super+0x11e0/0x1b50 [ 162.477709] ? put_ntfs+0x1d0/0x1d0 [162.477970] ? vsprintf+0x20/0x20 [ 162.478258] ? set_blocksize+0x95/0x150 [ 162.478538] get_tree_bdev+0x232/0x370 [ 162.478789] ? put_ntfs+0x1d0/0x1d0 [ 162.479038] ntfs_fs_get_tree+0x15/0x20 [162.479374] vfs_get_tree+0x4c/0x130 [ 162.479729] path_mount+0x654/0xfe0 [ 162.480124] ? putname+0x80/0xa0 [ 162.480484] ? finish_automount+0x2e0/0x2e0 [ 162.480894] ? putname+0x80/0xa0 [ 162.481467] ? kmem_cache_free+0x1c4/0x440 [ 162.482280] ? putname+0x80/0xa0 [ 162.482714] do_mount+0xd6/0xf0 [162.483264] ? path_mount+0xfe0/0xfe0 [ 162.484782] ? __kasan_check_write+0x14/0x20 [ 162.485593]
    __x64_sys_mount+0xca/0x110 [ 162.486024] do_syscall_64+0x3b/0x90 [ 162.486543] entry_SYSCALL_64_after_hwframe+0x63/0xcd [ 162.487141] RIP0033:0x7f9d374e948a [ 162.488324] 代码48 8b 0d 11 fa 2a 89 617 f 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 [ 162.489728] RSP: 002b:00007ffe30e73d18 EFLAGS: 00000206 ORIG_RAX: 00000000000000a5 [162.490971] RAX: ffffffffffffffda RBX: 0000561cdb43a060 RCX: 00007f9d374e948a [ 162.491669] RDX:
    0000561cdb43a260 RSI0000561cdb43a2e0 RDI0000561cdb442af0 [ 162.492050] RBP0000000000000000 R08
    0000561cdb43a280 R090000000000000020 [ 162.492459] R1000000000c0ed0000 R110000000000000206 R12
    0000561cdb442af0 [ 162.493183] R13: 0000561cdb43a260 R14: 0000000000000000 R15: 00000000ffffffff [162.493644] </TASK> [ 162.493908] [ 162.494214] 有缺陷的地址属于物理页: [162.494761] page:000000003e38a3d0d mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x37bc [162.496064] flags: 0xfffffc0000000(node=0|zone=1|lastcpupid=0x1fffff) [ 162.497278] raw: 000fffffc0000000 ffffea00000df1c8 ffffea00000df008 0000000000000000 [ 162.498928] raw: 0000000000000000 0000000000240000 00000000ffffffff 0000000000000000 [ 162.500542] 页面已转储 ---truncated--- (CVE-2023-53194)

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

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

  - tracing修复 tracing_err_log_open() 中的空指针取消引用 修复函数“tracing_err_log_open”中的一个问题。如果仅使用写入权限打开文件则函数不会调用“seq_open”这将导致“file->private_data”保留为空。如果我们之后在该打开的文件上使用“lseek”则“seq_lseek”会取消引用“mutex_lock(&m->lock)”中的“file->private_data”从而导致内核错误。写入此节点需要根权限因此此缺陷的安全影响非常小。Tracefs 节点/sys/kernel/tracing/error_log 示例内核错误无法处理虚拟地址 0000000000000038 处的内核空指针取消引用调用跟踪mutex_lock+0x30/0x110 seq_lseek+0x34/0xb8 __arm64_sys_lseek+0x6c/0xb8 invoke_syscall+0x58/0x1_vc_common +0xc4/0x10c do_el0_svc+0x24/0x98 el0_svc+0x24/0x88 el0t_64_sync_handler+0x84/0xe4 el0t_64_sync+0x1b4/0x1b8 代码
    d503201f aa0803e0 aa1f03e1 aa0103e9 (c8e97d02) ---[ 结束跟踪 561d1b49c12cf8a5 ]--- 内核错误 - 不同步Oops致命异常 (CVE-2023-53167)

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

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

  - fs/ntfs3验证 BOOT record_size 当 NTFS BOOT record_size 字段 < 0 时代表位移值。
    但是没有对位移结果进行健全性检查并且通过 blksize_bits() 进行的 sbi->record_bits 计算假设大小始终大于 256这可导致挂载畸形 NTFS 图像时发生 NPD。 [ 318.675159] 缺陷内核空指针取消引用地址0000000000000158 [ 318.675682] #PF
    内核模式中的主管读取访问 [ 318.675869] #PF: error_code(0x0000) - not-present 页面 [318.676246] PGD 0 P4D 0 [ 318.676502] Oops: 0000 [#1] PREEMPT SMP NOPTI [ 318.676934] CPU 0 PID259 Commmount Not tainted 5.19.0 #5 [ 318.677289] Hardware nameQEMU Standard PC (i440FX + PIIX,1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 [ 318.678136] RIP
    0010:ni_find_attr+0x2d/0x1c0 [ 318.678656] Code89 ca 4d 89 c7 41 56 41 55 41 54 41 89 cc 55 48 89 fd 53 48 89 d3 48 83 ec 20 65 48 8b 04 250 28 090 8 44 24 180 [ 318.679848] RSP: 0018:ffffa6c8c0297bd8 EFLAGS: 00000246 [ 318.680104] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000080 [318.680790] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 [ 318.681679] RBP:
    0000000000000000 R080000000000000000 R090000000000000000 [ 318.682577] R100000000000000000 R11
    0000000000000005 R120000000000000080 [ 318.683015] R13ffff8d5582e68400 R140000000000000100 R15
    0000000000000000 [ 318.683618] FS: 00007fd9e1c81e40(0000) GS:ffff8d55fdc00000(0000) knlGS:0000000000000000 [ 318.684280] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 318.684651] CR2: 0000000000000158 CR3:
    0000000002e1a000 CR4: 00000000000006f0 [ 318.685623] 调用跟踪[ 318.686607] <TASK> [ 318.686872] ? ntfs_alloc_inode+0x1a/0x60 [ 318.687235] attr_load_runs_vcn+0x2b/0xa0 [ 318.687468] mi_read+0xbb/0x250 [318.687576] ntfs_iget5+0x114/0xd90 [ 318.687750] ntfs_fill_super+0x588/0x11b0 [ 318.687953] ? put_ntfs+0x130/0x130 [ 318.688065] ? snprintf+0x49/0x70 [ 318.688164] ? put_ntfs+0x130/0x130 [ 318.688256] get_tree_bdev+0x16a/0x260 [ 318.688407] vfs_get_tree+0x20/0xb0 [ 318.688519] path_mount+0x2dc/0x9b0 [318.688877] do_mount+0x74/0x90 [ 318.689142] __x64_sys_mount+0x89/0xd0 [ 318.689636] do_syscall_64+0x3b/0x90 [ 318.689998] entry_SYSCALL_64_after_hwframe+0x63/0xcd [ 318.690318] RIP
    0033:0x7fd9e133c48a [ 318.690687] Code48 8b 0d 11 fa 2a 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 49 0 0 0 0 ca b [ 318.691357] RSP002b:00007ffd374406c8 EFLAGS
    00000202 ORIG_RAX: 00000000000000a5 [ 318.691632] RAX: ffffffffffffffda RBX: 0000564d0b051080 RCX:
    00007fd9e133c48a [ 318.691920] RDX: 0000564d0b051280 RSI: 0000564d0b051300 RDI: 0000564d0b0596a0 [318.692123] RBP: 0000000000000000 R08: 0000564d0b0512a0 R09: 0000000000000020 [ 318.692349] R10:
    00000000c0ed0000 R110000000000000202 R120000564d0b0596a0 [ 318.692673] R130000564d0b051280 R14
    0000000000000000 R15: 00000000ffffffff [ 318.693007] </TASK> [ 318.693271] 模块中链接的模块[318.693614] CR2: 0000000000000158 [ 318.694446] ---[ end trace 0000000000000000 ]--- [ 318.694779] RIP
    0010:ni_find_attr+0x2d/0x1c0 [ 318.694952] Code89 ca 4d 89 c7 41 56 41 55 41 54 41 89 cc 55 48 89 fd 53 48 89 d3 48 83 ec 20 65 48 8b 04 250 28 090 8 44 24 180 [ 318.696042] RSP: 0018:ffffa6c8c0297bd8 EFLAGS: 00000246 [ 318.696531] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000080 [318.698114] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 [ 318.699286] RBP:
    0000000000000000 R080000000000000000 R090000000000000000 [ 318.699795] R100000000000000000 R11
    0000000000000005 R120000000000000080 [ 318.700236] R13ffff8d5582e68400 R140000000000000100 R15
    0000000000000000 [ 318.700973] FS: 00007fd9e1c81e40(0000) GS:ffff8d55fdc00000(0000) knlGS:0000000000000000 [ ---truncated--- (CVE-2022-50262)

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

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

  - bpf确保在重定向到隧道设备时skb->len != 0 syzkaller 设法触发另一种情况其中 skb->len == 0 当我们在 include/linux/ 中输入 __dev_queue_xmit: WARNING: CPU: 0 PID: 2470 skbuff.h:2576 skb_assert_len include/linux/skbuff.h:2576 [inline] 警告CPU:0 PID: 2470 include/linux/skbuff.h:2576 __dev_queue_xmit+0x2069/0x35e0 net/core/dev.c:4295调用跟踪
    dev_queue_xmit+0x17/0x20 net/core/dev.c:4406 __bpf_tx_skb net/core/filter.c:2115 [内联]
    __bpf_redirect_no_mac net/core/filter.c:2140 [内联] __bpf_redirect+0x5fb/0xda0 net/core/filter.c:2163
    ____bpf_clone_redirect net/core/filter.c:2447 [内联] bpf_clone_redirect+0x247/0x390 net/core/filter.c:2419 bpf_prog_48159a89cb4a9a16+0x59/0x5e bpf_dispatcher_nop_func include/linux/bpf.h:897 [内联] __runf_prog filter.h:596 [inline] bpf_prog_run include/linux/filter.h:603 [inline] bpf_test_run+0x46c/0x890 net/bpf/test_run.c:402 bpf_prog_test_run_skb+0xbdc/0x14c0 net/bpf/test_run.c:1170 bpf_prog_test_run +0x345/0x3c0 kernel/bpf/syscall.c:3648 __sys_bpf+0x43a/0x6c0 kernel/bpf/syscall.c:5005 __do_sys_bpf kernel/bpf/syscall.c:5091 [inline] __se_sys_bpf kernel/bpf/syscall.c:5089 [inline] __x64_sys_bpf+0x7c/0x90 kernel/bpf/syscall.c:5089 do_syscall_64+0x54/0x70 arch/x86/entry/common.c:48 entry_SYSCALL_64_after_hwframe+0x61/0xc6 复制程序不会在 syzkaller 环境之外真正复制。因此我在此进行猜测。看起来我们确实生成了正确的 ETH_HLEN 大小的数据包，但我们将该数据包重定向到了隧道设备。执行此操作之前我们会 __skb_pull l2 标头并再次到达 skb->len == 0。除了在 __skb_pull 之后进行明确检查似乎我们无路可走？ (CVE-2022-50253)

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

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

  - drm/msm使 .remove 和 .shutdown HW 关机一致。驱动程序的 .remove 和 .shutdown 回调在不同的代码路径中执行。当从总线删除设备时调用前者而在系统关闭以使设备停顿时调用后者。这意味着两者之间存在某些重叠，因为两者都必须注意正确关闭硬件。但是目前这两个回调中使用的逻辑在 msm 驱动程序中不一致可能会造成内核错误。例如，在 .remove 上，组件被删除，其 .unbind 回调会导致硬件关闭，但前提是 DRM 设备已被标记为已注册。该检查在 .shutdown 逻辑中不存在，这可导致驱动程序为尚未正确初始化的 DRM 设备调用 drm_atomic_helper_shutdown()。如果预期子设备的驱动程序探测失败则可能发生此类情况因为永远不会执行 .bind 回调。如果是这种情况drm_atomic_helper_shutdown() 将尝试获取仅当在设备绑定期间调用 drm_mode_config_init() 时才初始化的互斥体。尝试在提交 623f279c7781 中修复此缺陷 drm/msm修复 GPU 组件绑定失败时的关闭挂钩但遗憾的是在某些情况下仍然会发生上述情况即 systemd-shutdown[1]正在关闭电源。 kvm退出硬件虚拟化平台 wifi-firmware.0
    Removing from iommu group 12 platform video-firmware.0Removing from iommu group 10 ------------[ cut here ]------------ WARNING: CPU: 6 PID: 1 (drivers/gpu/drm/drm_modeset_lock.c:317 drm_modeset_lock_all_ctx+0x3c4/0x3d0 ... 硬件名称 Google CoachZ (rev3+) (DT) pstatea0400009 (NzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc drm_modeset_lock_all_ctx+0x3c4/0x3d0 lr
    drm_modeset_lock_all_ctx+0x48/0x3d0 sp ffff80000805bb80 x29ffff80000805bb80 x28ffff327c00128000 x27
    0000000000000000 x26: 0000000000000000 x25: 0000000000000001 x24: ffffc95d820ec030 x23: ffff327c00bbd090 x22: ffffc95d8215eca0 x21: ffff327c039c5800 x20: ffff327c039c5988 x19: ffff80000805bbe8 x18:
    0000000000000034 x17: 000000040044ffff x16: ffffc95d80cac920 x15: 0000000000000000 x14: 0000000000000315 x13: 0000000000000315 x12: 0000000000000000 x11: 0000000000000000 x10: 0000000000000000 x9 :
    0000000000000000 x8 : ffff80000805bc28 x7 : 0000000000000000 x6 : 0000000000000000 x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000 x2 : ffff327c00128000 x1 : 0000000000000000 x0 :
    ffff327c039c59b0 Call trace: drm_modeset_lock_all_ctx+0x3c4/0x3d0 drm_atomic_helper_shutdown+0x70/0x134 msm_drv_shutdown+0x30/0x40 platform_shutdown+0x28/0x40 device_shutdown+0x148/0x350 kernel_power_off+0x38/0x80 __do_sys_reboot+0x288/0x2c0 __arm64_sys_reboot+0x28/0x34 invoke_syscall+0x48/0x114 el0_svc_common .constprop.0+0x44/0xec do_el0_svc+0x2c/0xc0 el0_svc+0x2c/0x84 el0t_64_sync_handler+0x11c/0x150 el0t_64_sync+0x18c/0x190 ---[ end trace 0000000000000000 ]--- Unable to handle kernel NULL pointer dereference at virtual address 0000000000000018内存中止信息ESR = 0x0000000096000004 EC = 0x25DABT当前 ELIL = 32 位 SET = 0FnV = 0 EA = 0S1PTW = 0 FSC = 0x04级别 0 转换错误数据中止信息ISV = 0 ISS = 0x00000004 CM = 0WnR = 0 用户 pgtable
    4k 页面、48 位 VA、 pgdp=000000010eab1000 [0000000000000018] pgd=0000000000000000、p4d=0000000000000000 内部错误Oops: 96000004 [#1] PREEMPT SMP ... 硬件名称Google CoachZ (rev3+) (DT) pstate
    a0400009 (NzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc ww_mutex_lock+0x28/0x32c lr
    drm_modeset_lock_all_ctx+0x1b0/0x3d0 spffff80000805bb50 x29ffff80000805bb50 x28ffff327c00128000 x270000000000000000 x26: 00000 ---truncated--- (CVE-2022-50260)

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

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

  - 已修复 Linux 内核中的下列漏洞：coresight: trbe: remove cpuhp instance node before remove cpuhp state cpuhp_state_add_instance() and cpuhp_state_remove_instance() should be used in pairs. Or there will lead to the warn on cpuhp_remove_multi_state() since the cpuhp_step list is not empty. The following is the error log with 'rmmod coresight-trbe': Error: Removing state 215 which has instances left. Call trace: __cpuhp_remove_state_cpuslocked+0x144/0x160 __cpuhp_remove_state+0xac/0x100 arm_trbe_device_remove+0x2c/0x60 [coresight_trbe] platform_remove+0x34/0x70 device_remove+0x54/0x90 device_release_driver_internal+0x1e4/0x250 driver_detach+0x5c/0xb0 bus_remove_driver+0x64/0xc0 driver_unregister+0x3c/0x70 platform_driver_unregister+0x20/0x30 arm_trbe_exit+0x1c/0x658 [coresight_trbe]
    __arm64_sys_delete_module+0x1ac/0x24c invoke_syscall+0x50/0x120 el0_svc_common.constprop.0+0x58/0x1a0 do_el0_svc+0x38/0xd0 el0_svc+0x2c/0xc0 el0t_64_sync_handler+0x1ac/0x1b0 el0t_64_sync+0x19c/0x1a0 ---[ end trace 0000000000000000 ]--- (CVE-2022-50319)

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

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

  - smbclient修复 cifs_smb3_do_mount() 中的警告 这修复了内核测试机器人 fs/smb/client/cifsfs.c:982 cifs_smb3_do_mount() 警告可能的“cifs_sb”内存泄漏 (CVE-2023-53230)

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

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

  - 已修复 Linux 内核中的下列漏洞：dma-buf/dma-resv: Stop leaking on krealloc() failure Currently dma_resv_get_fences() will leak the previously allocated array if the fence iteration got restarted and the krealloc_array() fails. Free the old array by hand, and make sure we still clear the returned *fences so the caller won't end up accessing freed memory. Some (but not all) of the callers of dma_resv_get_fences() seem to still trawl through the array even when dma_resv_get_fences() failed. And let's zero out *num_fences as well for good measure. (CVE-2023-53181)

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

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

  - drm/radeon添加缺少的 acpi_put_table() 以修复内存泄漏当 radeon 驱动程序从 radeon_acpi_vfct_bios() 中的 ACPI 表读取 bios 信息时会错过调用 acpi_put_table() 以在 init 后释放 ACPI 内存因此添加 acpi_put_table () 正确修复内存泄漏。 v2修复文本格式 (Alex) (CVE-2022-50275)

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

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

  - 已修复 Linux 内核中的下列漏洞：s390/cio: fix out-of-bounds access on cio_ignore free The channel-subsystem-driver scans for newly available devices whenever device-IDs are removed from the cio_ignore list using a command such as: echo free >/proc/cio_ignore Since an I/O device scan might interfer with running I/Os, commit 172da89ed0ea (s390/cio: avoid excessive path-verification requests) introduced an optimization to exclude online devices from the scan. The newly added check for online devices incorrectly assumes that an I/O-subchannel's drvdata points to a struct io_subchannel_private. For devices that are bound to a non-default I/O subchannel driver, such as the vfio_ccw driver, this results in an out-of-bounds read access during each scan. Fix this by changing the scan logic to rely on a driver-independent online indication. For this we can use struct subchannel->config.ena, which is the driver's requested subchannel-enabled state. Since I/Os can only be started on enabled subchannels, this matches the intent of the original optimization of not scanning devices where I/O might be running. (CVE-2022-50307)

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

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

  - 已修复 Linux 内核中的下列漏洞：x86/resctrl: Clear staged_config[] before and after it is used As a temporary storage, staged_config[] in rdt_domain should be cleared before and after it is used. The stale value in staged_config[] could cause an MSR access error. Here is a reproducer on a system with 16 usable CLOSIDs for a 15-way L3 Cache (MBA should be disabled if the number of CLOSIDs for MB is less than 16.) : mount -t resctrl resctrl -o cdp /sys/fs/resctrl mkdir /sys/fs/resctrl/p{1..7} umount /sys/fs/resctrl/ mount -t resctrl resctrl /sys/fs/resctrl mkdir /sys/fs/resctrl/p{1..8} An error occurs when creating resource group named p8: unchecked MSR access error:
    WRMSR to 0xca0 (tried to write 0x00000000000007ff) at rIP: 0xffffffff82249142 (cat_wrmsr+0x32/0x60) Call Trace: <IRQ> __flush_smp_call_function_queue+0x11d/0x170 __sysvec_call_function+0x24/0xd0 sysvec_call_function+0x89/0xc0 </IRQ> <TASK> asm_sysvec_call_function+0x16/0x20 When creating a new resource control group, hardware will be configured by the following process: rdtgroup_mkdir() rdtgroup_mkdir_ctrl_mon() rdtgroup_init_alloc() resctrl_arch_update_domains() resctrl_arch_update_domains() iterates and updates all resctrl_conf_type whose have_new_ctrl is true.
    Since staged_config[] holds the same values as when CDP was enabled, it will continue to update the CDP_CODE and CDP_DATA configurations. When group p8 is created, get_config_index() called in resctrl_arch_update_domains() will return 16 and 17 as the CLOSIDs for CDP_CODE and CDP_DATA, which will be translated to an invalid register - 0xca0 in this scenario. Fix it by clearing staged_config[] before and after it is used. [reinette: re-order commit tags] (CVE-2023-53169)

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

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

  - USBuhci使用 debugfs_lookup() 修复内存泄漏调用 debugfs_lookup() 时结果必须调用 dput()否则内存将随着时间泄漏。要使事情更简单只需调用 debugfs_lookup_and_remove()其会同时处理所有逻辑。 (CVE-2023-53197)

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

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

  - mediadvbdev采用 refcnt 以避免 UAF 已知dvb_unregister_device() 容易受到释放后使用的影响。
    即即使 file->private_data 中存储的指针仍然引用dvb_unregister_device() 中的清理也会释放 dvb_device。此修补程序将引用计数器添加到 struct dvb_device 中并延迟其解除分配直到没有指针指向该对象为止。 (CVE-2022-50274)

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

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

  - qlcnic阻止 qlcnic_dcb_enable() 失败上的 ->dcb 释放后使用以防 qlcnic_dcb_attach() 返回错误在 OOM 条件下始终发生这种情况适配器->dcb 会在 qlcnic_dcb_enable() 内部静默地释放。这会导致释放后使用因为两个现有调用程序都在所获取的指针上调用 qlcnic_dcb_get_info()而该指针可能在此时已释放。传播 qlcnic_dcb_enable() 中的错误并使用 qlcnic_dcb_free() 释放调用站点上的 dcb 指针。此操作还会删除现已未使用的 qlcnic_clear_dcb_ops() 辅助函数该辅助函数是 kfree() 的简单包装程序也会对部分初始化的 dcb 造成内存泄漏。由 Linux Verification Center (linuxtesting.org) 通过 SVACE 静态分析工具发现。 (CVE-2022-50288)

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

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

  - 已修复 Linux 内核中的下列漏洞：cpufreq: qcom: fix writes in read-only memory region This commit fixes a kernel oops because of a write in some read-only memory: [ 9.068287] Unable to handle kernel write to read-only memory at virtual address ffff800009240ad8 ..snip.. [ 9.138790] Internal error: Oops: 9600004f [#1] PREEMPT SMP ..snip.. [ 9.269161] Call trace: [ 9.276271]
    __memcpy+0x5c/0x230 [ 9.278531] snprintf+0x58/0x80 [ 9.282002] qcom_cpufreq_msm8939_name_version+0xb4/0x190 [ 9.284869] qcom_cpufreq_probe+0xc8/0x39c ..snip.. The following line defines a pointer that point to a char buffer stored in read-only memory: char *pvs_name = speedXX-pvsXX-vXX; This pointer is meant to hold a template speedXX-pvsXX-vXX where the XX values get overridden by the qcom_cpufreq_krait_name_version function. Since the template is actually stored in read-only memory, when the function executes the following call we get an oops: snprintf(*pvs_name, sizeof(speedXX-pvsXX-vXX), speed%d-pvs%d-v%d, speed, pvs, pvs_ver); To fix this issue, we instead store the template name onto the stack by using the following syntax: char pvs_name_buffer[] = speedXX-pvsXX-vXX; Because the `pvs_name` needs to be able to be assigned to NULL, the template buffer is stored in the pvs_name_buffer and not under the pvs_name variable. (CVE-2022-50239)

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

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

  - 已修复 Linux 内核中的下列漏洞：Bluetooth: use RCU for hci_conn_params and iterate safely in hci_sync hci_update_accept_list_sync iterates over hdev->pend_le_conns and hdev->pend_le_reports, and waits for controller events in the loop body, without holding hdev lock.
    Meanwhile, these lists and the items may be modified e.g. by le_scan_cleanup. This can invalidate the list cursor or any other item in the list, resulting to invalid behavior (eg use-after-free). Use RCU for the hci_conn_params action lists. Since the loop bodies in hci_sync block and we cannot use RCU or hdev->lock for the whole loop, copy list items first and then iterate on the copy. Only the flags field is written from elsewhere, so READ_ONCE/WRITE_ONCE should guarantee we read valid values. Free params everywhere with hci_conn_params_free so the cleanup is guaranteed to be done properly. This fixes the following, which can be triggered e.g. by BlueZ new mgmt-tester case Add + Remove Device Nowait - Success, or by changing hci_le_set_cig_params to always return false, and running iso-tester:
    ================================================================== BUG: KASAN: slab-use-after-free in hci_update_passive_scan_sync (net/bluetooth/hci_sync.c:2536 net/bluetooth/hci_sync.c:2723 net/bluetooth/hci_sync.c:2841) Read of size 8 at addr ffff888001265018 by task kworker/u3:0/32 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-1.fc38 04/01/2014 Workqueue: hci0 hci_cmd_sync_work Call Trace: <TASK> dump_stack_lvl (./arch/x86/include/asm/irqflags.h:134 lib/dump_stack.c:107) print_report (mm/kasan/report.c:320 mm/kasan/report.c:430) ? __virt_addr_valid (./include/linux/mmzone.h:1915 ./include/linux/mmzone.h:2011 arch/x86/mm/physaddr.c:65) ? hci_update_passive_scan_sync (net/bluetooth/hci_sync.c:2536 net/bluetooth/hci_sync.c:2723 net/bluetooth/hci_sync.c:2841) kasan_report (mm/kasan/report.c:538) ? hci_update_passive_scan_sync (net/bluetooth/hci_sync.c:2536 net/bluetooth/hci_sync.c:2723 net/bluetooth/hci_sync.c:2841) hci_update_passive_scan_sync (net/bluetooth/hci_sync.c:2536 net/bluetooth/hci_sync.c:2723 net/bluetooth/hci_sync.c:2841) ? __pfx_hci_update_passive_scan_sync (net/bluetooth/hci_sync.c:2780) ? mutex_lock (kernel/locking/mutex.c:282) ? __pfx_mutex_lock (kernel/locking/mutex.c:282) ?
    __pfx_mutex_unlock (kernel/locking/mutex.c:538) ? __pfx_update_passive_scan_sync (net/bluetooth/hci_sync.c:2861) hci_cmd_sync_work (net/bluetooth/hci_sync.c:306) process_one_work (./arch/x86/include/asm/preempt.h:27 kernel/workqueue.c:2399) worker_thread (./include/linux/list.h:292 kernel/workqueue.c:2538) ? __pfx_worker_thread (kernel/workqueue.c:2480) kthread (kernel/kthread.c:376) ?
    __pfx_kthread (kernel/kthread.c:331) ret_from_fork (arch/x86/entry/entry_64.S:314) </TASK> Allocated by task 31: kasan_save_stack (mm/kasan/common.c:46) kasan_set_track (mm/kasan/common.c:52) __kasan_kmalloc (mm/kasan/common.c:374 mm/kasan/common.c:383) hci_conn_params_add (./include/linux/slab.h:580 ./include/linux/slab.h:720 net/bluetooth/hci_core.c:2277) hci_connect_le_scan (net/bluetooth/hci_conn.c:1419 net/bluetooth/hci_conn.c:1589) hci_connect_cis (net/bluetooth/hci_conn.c:2266) iso_connect_cis (net/bluetooth/iso.c:390) iso_sock_connect (net/bluetooth/iso.c:899) __sys_connect (net/socket.c:2003 net/socket.c:2020) __x64_sys_connect (net/socket.c:2027) 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) Freed by task 15: kasan_save_stack (mm/kasan/common.c:46) kasan_set_track (mm/kasan/common.c:52) kasan_save_free_info (mm/kasan/generic.c:523) __kasan_slab_free (mm/kasan/common.c:238 mm/kasan/common.c:200 mm/kasan/common.c:244) __kmem_cache_free (mm/slub.c:1807 mm/slub.c:3787 mm/slub.c:3800) hci_conn_params_del (net/bluetooth/hci_core.c:2323) le_scan_cleanup (net/bluetooth/hci_conn.c:202) process_one_work (./arch/x86/include/asm/preempt. ---truncated--- (CVE-2023-53252)

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

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

  - igb除非分配了新的 q_vector否则不释放 q_vector 避免在内存紧张的情况下潜在的释放后使用情况。如果 kzalloc() 失败q_vector 将被释放但会留在原始 adapter->q_vector[v_idx] 数组位置。 (CVE-2022-50252)

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

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

  - PM:domains修复使用 debugfs_lookup() 的内存泄漏调用 debugfs_lookup() 时结果必须调用 dput()否则内存将随着时间泄漏。要使事情更简单只需调用 debugfs_lookup_and_remove()其会同时处理所有逻辑。 (CVE-2023-53202)

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

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

  - 已修复 Linux 内核中的下列漏洞：wifi: iwlwifi: mvm: fix double free on tx path. We see kernel crashes and lockups and KASAN errors related to ax210 firmware crashes. One of the KASAN dumps pointed at the tx path, and it appears there is indeed a way to double-free an skb. If iwl_mvm_tx_skb_sta returns non-zero, then the 'skb' sent into the method will be freed. But, in case where we build TSO skb buffer, the skb may also be freed in error case. So, return 0 in that particular error case and do cleanup manually. BUG: KASAN: use-after-free in __list_del_entry_valid+0x12/0x90 iwlwifi 0000:06:00.0: 0x00000000 | tsf hi Read of size 8 at addr ffff88813cfa4ba0 by task btserver/9650 CPU: 4 PID: 9650 Comm: btserver Tainted: G W 5.19.8+ #5 iwlwifi 0000:06:00.0: 0x00000000 | time gp1 Hardware name: Default string Default string/SKYBAY, BIOS 5.12 02/19/2019 Call Trace: <TASK> dump_stack_lvl+0x55/0x6d print_report.cold.12+0xf2/0x684 iwlwifi 0000:06:00.0: 0x1D0915A8 | time gp2 ?
    __list_del_entry_valid+0x12/0x90 kasan_report+0x8b/0x180 iwlwifi 0000:06:00.0: 0x00000001 | uCode revision type ? __list_del_entry_valid+0x12/0x90 __list_del_entry_valid+0x12/0x90 iwlwifi 0000:06:00.0: 0x00000048 | uCode version major tcp_update_skb_after_send+0x5d/0x170 __tcp_transmit_skb+0xb61/0x15c0 iwlwifi 0000:06:00.0: 0xDAA05125 | uCode version minor ? __tcp_select_window+0x490/0x490 iwlwifi 0000:06:00.0:
    0x00000420 | hw version ? trace_kmalloc_node+0x29/0xd0 ? __kmalloc_node_track_caller+0x12a/0x260 ? memset+0x1f/0x40 ? __build_skb_around+0x125/0x150 ? __alloc_skb+0x1d4/0x220 ? skb_zerocopy_clone+0x55/0x230 iwlwifi 0000:06:00.0: 0x00489002 | board version ? kmalloc_reserve+0x80/0x80 ? rcu_read_lock_bh_held+0x60/0xb0 tcp_write_xmit+0x3f1/0x24d0 iwlwifi 0000:06:00.0: 0x034E001C | hcmd ?
    __check_object_size+0x180/0x350 iwlwifi 0000:06:00.0: 0x24020000 | isr0 tcp_sendmsg_locked+0x8a9/0x1520 iwlwifi 0000:06:00.0: 0x01400000 | isr1 ? tcp_sendpage+0x50/0x50 iwlwifi 0000:06:00.0: 0x48F0000A | isr2 ? lock_release+0xb9/0x400 ? tcp_sendmsg+0x14/0x40 iwlwifi 0000:06:00.0: 0x00C3080C | isr3 ? lock_downgrade+0x390/0x390 ? do_raw_spin_lock+0x114/0x1d0 iwlwifi 0000:06:00.0: 0x00200000 | isr4 ? rwlock_bug.part.2+0x50/0x50 iwlwifi 0000:06:00.0: 0x034A001C | last cmd Id ? rwlock_bug.part.2+0x50/0x50 ? lockdep_hardirqs_on_prepare+0xe/0x200 iwlwifi 0000:06:00.0: 0x0000C2F0 | wait_event ?
    __local_bh_enable_ip+0x87/0xe0 ? inet_send_prepare+0x220/0x220 iwlwifi 0000:06:00.0: 0x000000C4 | l2p_control tcp_sendmsg+0x22/0x40 sock_sendmsg+0x5f/0x70 iwlwifi 0000:06:00.0: 0x00010034 | l2p_duration
    __sys_sendto+0x19d/0x250 iwlwifi 0000:06:00.0: 0x00000007 | l2p_mhvalid ? __ia32_sys_getpeername+0x40/0x40 iwlwifi 0000:06:00.0: 0x00000000 | l2p_addr_match ? rcu_read_lock_held_common+0x12/0x50 ? rcu_read_lock_sched_held+0x5a/0xd0 ? rcu_read_lock_bh_held+0xb0/0xb0 ? rcu_read_lock_sched_held+0x5a/0xd0 ? rcu_read_lock_sched_held+0x5a/0xd0 ? lock_release+0xb9/0x400 ? lock_downgrade+0x390/0x390 ? ktime_get+0x64/0x130 ? ktime_get+0x8d/0x130 ? rcu_read_lock_held_common+0x12/0x50 ? rcu_read_lock_sched_held+0x5a/0xd0 ? rcu_read_lock_held_common+0x12/0x50 ? rcu_read_lock_sched_held+0x5a/0xd0 ? rcu_read_lock_bh_held+0xb0/0xb0 ? rcu_read_lock_bh_held+0xb0/0xb0
    __x64_sys_sendto+0x6f/0x80 do_syscall_64+0x34/0xb0 entry_SYSCALL_64_after_hwframe+0x46/0xb0 RIP:
    0033:0x7f1d126e4531 Code: 00 00 00 00 0f 1f 44 00 00 f3 0f 1e fa 48 8d 05 35 80 0c 00 41 89 ca 8b 00 85 c0 75 1c 45 31 c9 45 31 c0 b8 2c 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 67 c3 66 0f 1f 44 00 00 55 48 83 ec 20 48 89 RSP: 002b:00007ffe21a679d8 EFLAGS: 00000246 ORIG_RAX: 000000000000002c RAX: ffffffffffffffda RBX:
    000000000000ffdc RCX: 00007f1d126e4531 RDX: 0000000000010000 RSI: 000000000374acf0 RDI: 0000000000000014 RBP: 00007ffe21a67ac0 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11:
    0000000000000246 R ---truncated--- (CVE-2022-50248)

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

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

  - 已修复 Linux 内核中的下列漏洞：net/smc: fix deadlock triggered by cancel_delayed_work_syn() The following LOCKDEP was detected: Workqueue: events smc_lgr_free_work [smc] WARNING: possible circular locking dependency detected 6.1.0-20221027.rc2.git8.56bc5b569087.300.fc36.s390x+debug #1 Not tainted
    ------------------------------------------------------ kworker/3:0/176251 is trying to acquire lock:
    00000000f1467148 ((wq_completion)smc_tx_wq-00000000#2){+.+.}-{0:0}, at: __flush_workqueue+0x7a/0x4f0 but task is already holding lock: 0000037fffe97dc8 ((work_completion)(&(&lgr->free_work)->work)){+.+.}-{0:0}, at: process_one_work+0x232/0x730 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #4 ((work_completion)(&(&lgr->free_work)->work)){+.+.}-{0:0}:
    __lock_acquire+0x58e/0xbd8 lock_acquire.part.0+0xe2/0x248 lock_acquire+0xac/0x1c8 __flush_work+0x76/0xf0
    __cancel_work_timer+0x170/0x220 __smc_lgr_terminate.part.0+0x34/0x1c0 [smc] smc_connect_rdma+0x15e/0x418 [smc] __smc_connect+0x234/0x480 [smc] smc_connect+0x1d6/0x230 [smc] __sys_connect+0x90/0xc0
    __do_sys_socketcall+0x186/0x370 __do_syscall+0x1da/0x208 system_call+0x82/0xb0 -> #3 (smc_client_lgr_pending){+.+.}-{3:3}: __lock_acquire+0x58e/0xbd8 lock_acquire.part.0+0xe2/0x248 lock_acquire+0xac/0x1c8 __mutex_lock+0x96/0x8e8 mutex_lock_nested+0x32/0x40 smc_connect_rdma+0xa4/0x418 [smc] __smc_connect+0x234/0x480 [smc] smc_connect+0x1d6/0x230 [smc] __sys_connect+0x90/0xc0
    __do_sys_socketcall+0x186/0x370 __do_syscall+0x1da/0x208 system_call+0x82/0xb0 -> #2 (sk_lock-AF_SMC){+.+.}-{0:0}: __lock_acquire+0x58e/0xbd8 lock_acquire.part.0+0xe2/0x248 lock_acquire+0xac/0x1c8 lock_sock_nested+0x46/0xa8 smc_tx_work+0x34/0x50 [smc] process_one_work+0x30c/0x730 worker_thread+0x62/0x420 kthread+0x138/0x150 __ret_from_fork+0x3c/0x58 ret_from_fork+0xa/0x40 -> #1 ((work_completion)(&(&smc->conn.tx_work)->work)){+.+.}-{0:0}: __lock_acquire+0x58e/0xbd8 lock_acquire.part.0+0xe2/0x248 lock_acquire+0xac/0x1c8 process_one_work+0x2bc/0x730 worker_thread+0x62/0x420 kthread+0x138/0x150 __ret_from_fork+0x3c/0x58 ret_from_fork+0xa/0x40 -> #0 ((wq_completion)smc_tx_wq-00000000#2){+.+.}-{0:0}: check_prev_add+0xd8/0xe88 validate_chain+0x70c/0xb20
    __lock_acquire+0x58e/0xbd8 lock_acquire.part.0+0xe2/0x248 lock_acquire+0xac/0x1c8
    __flush_workqueue+0xaa/0x4f0 drain_workqueue+0xaa/0x158 destroy_workqueue+0x44/0x2d8 smc_lgr_free+0x9e/0xf8 [smc] process_one_work+0x30c/0x730 worker_thread+0x62/0x420 kthread+0x138/0x150
    __ret_from_fork+0x3c/0x58 ret_from_fork+0xa/0x40 other info that might help us debug this: Chain exists of: (wq_completion)smc_tx_wq-00000000#2 --> smc_client_lgr_pending --> (work_completion)(&(&lgr->free_work)->work) Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock((work_completion)(&(&lgr->free_work)->work)); lock(smc_client_lgr_pending); lock((work_completion) (&(&lgr->free_work)->work)); lock((wq_completion)smc_tx_wq-00000000#2); *** DEADLOCK *** 2 locks held by kworker/3:0/176251: #0: 0000000080183548 ((wq_completion)events){+.+.}-{0:0}, at:
    process_one_work+0x232/0x730 #1: 0000037fffe97dc8 ((work_completion) (&(&lgr->free_work)->work)){+.+.}-{0:0}, at: process_one_work+0x232/0x730 stack backtr ---truncated--- (CVE-2023-53233)

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

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

  - mediadvb-usbaz6027修复 az6027_i2c_xfer() 中的 null-ptr-deref Wei Chen 报告一个内核缺陷如下
    一般性保护错误可能针对非规范地址 KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017] ... 调用跟踪 <TASK> __i2c_transfer+0x77e/0x1930 drivers/i2c/i2c-core-base.c:2109 i2c_transfer+0x1d5/0x3d0 drivers/i2c/i2c-core-base.c:2170 i2cdev_ioctl_rdwr+0x393/0x660 drivers/i2c/ i2c-dev.c:297 i2cdev_ioctl+0x75d/0x9f0 drivers/i2c/i2c-dev.c:458 vfs_ioctl fs/ioctl.c:51 [内联] __do_sys_ioctl fs/ioctl.c:870 [内联] __se_sys_ioctl+0xfb/0x170 fs/ioctl.c:856 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3d/0x90 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP: 0033:0x7fd834a8bded az6027xfer_i2c_i2c_In ()如果 msg[i].addr 为 0x99则会在访问 msg[i].buf 时造成 null-ptr-deref。对于 msg[i].len 为 0而 msg[i].buf 为空。通过检查 az6027_i2c_xfer() 中的 msg[i].len 修复此问题。
    (CVE-2022-50272)

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

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

  - jbd2修复 jbd2_fc_wait_bufs 中潜在的释放后使用。在“jbd2_fc_wait_bufs”使用“bh”后放置缓冲区头引用计数可能会导致释放后使用。因此判断缓冲区是否在放置缓冲区头引用计数之前进行了更新。 (CVE-2022-50328)

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

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

  - 已修复 Linux 内核中的下列漏洞：NFSD: Protect against send buffer overflow in NFSv2 READDIR Restore the previous limit on the @count argument to prevent a buffer overflow attack. (CVE-2022-50235)

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

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

  - mediaaz6007修复 az6007_i2c_xfer() 中的 null-ptr-deref 在 az6007_i2c_xfer 中msg 由用户控制。当 msg[i].buf 为空且 msg[i].len 为零时将通过前者对 msg[i].buf 的检查。恶意数据最终到达 az6007_i2c_xfer。如果在未进行健全性检查的情况下访问 msg[i].buf[0]会发生空指针取消引用。我们在 msg[i].len 上添加了检查以防止崩溃。simple commit: commit 0ed554fd769a (media: dvb-usb
    az6027修复 az6027_i2c_xfer() 中的 null-ptr-deref (CVE-2023-53220)

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

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

  - 已修复 Linux 内核中的下列漏洞：wwan_hwsim: fix possible memory leak in wwan_hwsim_dev_new() Inject fault while probing module, if device_register() fails, but the refcount of kobject is not decreased to 0, the name allocated in dev_set_name() is leaked. Fix this by calling put_device(), so that name can be freed in callback function kobject_cleanup(). unreferenced object 0xffff88810152ad20 (size 8): comm modprobe, pid 252, jiffies 4294849206 (age 22.713s) hex dump (first 8 bytes): 68 77 73 69 6d 30 00 ff hwsim0.. backtrace: [<000000009c3504ed>]
    __kmalloc_node_track_caller+0x44/0x1b0 [<00000000c0228a5e>] kvasprintf+0xb5/0x140 [<00000000cff8c21f>] kvasprintf_const+0x55/0x180 [<0000000055a1e073>] kobject_set_name_vargs+0x56/0x150 [<000000000a80b139>] dev_set_name+0xab/0xe0 (CVE-2022-50331)

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

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

  - driversseriajsm修复探测中的一些泄漏此错误路径需要展开而不仅仅是直接返回。 (CVE-2022-50312)

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

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

  - erofs修复原子上下文的检测对原子上下文的当前检查不充分因为可在 rcu 锁定下从 blk_mq_flush_plug_list() 调用 z_erofs_decompressqueue_endio。请参阅堆栈跟踪 [1] 在这种情况下我们应该移交异步处理的解压缩工作而不是尝试在当前上下文中执行同步解压缩。修补程序通过检查 rcu_read_lock_any_held() 来修复检测 当它使用比 in_atomic() 更适当的 !in_task() 检查时。
    背景：历史上erofs 将始终计划 kworker 进行解压缩，这将导致计划成本与上下文无关。但是 z_erofs_decompressqueue_endio() 可能并不总是在原子上下文中如果在线程上下文中例如通过 dm-verity 运行时我们实际上可以从在 z_erofs_decompressqueue_endio() 中执行解压缩中受益。此优化后来添加到修补程序 [2] 中其显示了性能基准方面的改进。
    ============================================== [1] 问题stacktrace [name:core&]BUG从 kernel/locking/mutex.c:291 的无效上下文调用的休眠函数 [name:core&]in_atomic()0, irqs_disabled(): 0, non_block: 0, pid: 1615, name CpuMonitorServi [名称：core&]preempt_count0，预期：0 [名称：core&]RCU 嵌套深度：1，预期：0 CPU：7 PID：1615 Comm：CpuMonitorServi Tainted：GSW OE 6.1.25-android14-5-maybe -dirty-mainline #1 硬件名称 MT6897 (DT) 调用跟踪
    dump_backtrace+0x108/0x15c show_stack+0x20/0x30 dump_stack_lvl+0x6c/0x8c dump_stack+0x20/0x48
    __might_resched+0x1fc/0x308 __might_sleep+0x50/0x88 mutex_lock+0x2c/0x110 z_erofs_decompress_queue+0x11c/0xc10 z_erofs_decompress_kickoff+0x110/0x1a4 z_erofs_decompressqueue_endio+0x154/0x180 bio_endio+0x1b0/0x1d8 __dm_io_complete+0x22c/0x280 clone_endio+0xe4/0x280 bio_endio+0x1b0/0x1d8 blk_update_request+0x138/0x3a4 blk_mq_plug_issue_direct+0xd4/0x19c blk_mq_flush_plug_list+0x2b0/0x354 __blk_flush_plug+0x110/0x160 blk_finish_plug+0x30/0x4c read_pages+0x2fc/0x370 page_cache_ra_unbounded+0xa4/0x23c page_cache_ra_order+0x290/0x320 do_sync_mmap_readahead+0x108/0x2c0 filemap_fault+0x19c/0x52c
    __do_fault+0xc4/0x114 handle_mm_fault+0x5b4/0x1168 do_page_fault+0x338/0x4b4 do_translation_fault+0x40/0x60 do_mem_abort+0x60/0xc8 el0_da+0x4c/0xe0 el0t_64_sync_handler+0xd4/0xfc el0t_64_sync+0x1a0/0x1a4 [2] Link:
    https://lore.kernel.org/all/20210317035448.13921-1-huangjianan@oppo.com/ (CVE-2023-53231)

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

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

  - wifi: ath9k不允许覆盖 ENDPOINT0 属性不良 USB 设备能够构建服务连接响应消息其目标端点是 ENDPOINT0其专为 HTC_CTRL_RSVD_SVC 保留且不应修改为用于任何其他服务。拒绝此类服务连接响应。
    由 Linux Verification Center (linuxtesting.org) 通过 Syzkaller 发现。 (CVE-2023-53185)

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

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

  - 已修复 Linux 内核中的下列漏洞：skbuff: Fix a race between coalescing and releasing SKBs Commit 1effe8ca4e34 (skbuff: fix coalescing for page_pool fragment recycling) allowed coalescing to proceed with non page pool page and page pool page when @from is cloned, i.e. to->pp_recycle
    --> false from->pp_recycle --> true skb_cloned(from) --> true However, it actually requires skb_cloned(@from) to hold true until coalescing finishes in this situation. If the other cloned SKB is released while the merging is in process, from_shinfo->nr_frags will be set to 0 toward the end of the function, causing the increment of frag page _refcount to be unexpectedly skipped resulting in inconsistent reference counts. Later when SKB(@to) is released, it frees the page directly even though the page pool page is still in use, leading to use-after-free or double-free errors. So it should be prohibited. The double-free error message below prompted us to investigate: BUG: Bad page state in process swapper/1 pfn:0e0d1 page:00000000c6548b28 refcount:-1 mapcount:0 mapping:0000000000000000 index:0x2 pfn:0xe0d1 flags: 0xfffffc0000000(node=0|zone=1|lastcpupid=0x1fffff) raw: 000fffffc0000000 0000000000000000 ffffffff00000101 0000000000000000 raw: 0000000000000002 0000000000000000 ffffffffffffffff 0000000000000000 page dumped because: nonzero _refcount CPU: 1 PID: 0 Comm: swapper/1 Tainted: G E 6.2.0+ Call Trace: <IRQ> dump_stack_lvl+0x32/0x50 bad_page+0x69/0xf0 free_pcp_prepare+0x260/0x2f0 free_unref_page+0x20/0x1c0 skb_release_data+0x10b/0x1a0 napi_consume_skb+0x56/0x150 net_rx_action+0xf0/0x350 ? __napi_schedule+0x79/0x90 __do_softirq+0xc8/0x2b1 __irq_exit_rcu+0xb9/0xf0 common_interrupt+0x82/0xa0 </IRQ> <TASK> asm_common_interrupt+0x22/0x40 RIP: 0010:default_idle+0xb/0x20 (CVE-2023-53186)

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

ID	名称	严重性
264979	Linux Distros 未修补的漏洞：CVE-2023-53182	medium
264978	Linux Distros 未修补的漏洞：CVE-2022-50236	medium
264977	Linux Distros 未修补的漏洞：CVE-2022-50336	medium
264976	Linux Distros 未修补的漏洞：CVE-2022-50306	high
264975	Linux Distros 未修补的漏洞：CVE-2022-50249	medium
264974	Linux Distros 未修补的漏洞：CVE-2023-53209	medium
264973	Linux Distros 未修补的漏洞：CVE-2023-53189	medium
264972	Linux Distros 未修补的漏洞：CVE-2022-50247	medium
264971	Linux Distros 未修补的漏洞：CVE-2023-53190	medium
264970	Linux Distros 未修补的漏洞：CVE-2023-53260	medium
264969	Linux Distros 未修补的漏洞：CVE-2022-50303	high
264968	Linux Distros 未修补的漏洞：CVE-2022-50285	medium
264967	Linux Distros 未修补的漏洞：CVE-2022-50337	medium
264966	Linux Distros 未修补的漏洞：CVE-2022-50263	medium
264965	Linux Distros 未修补的漏洞：CVE-2022-50332	medium
264964	Linux Distros 未修补的漏洞：CVE-2023-53249	medium
264963	Linux Distros 未修补的漏洞：CVE-2023-53174	medium
264962	Linux Distros 未修补的漏洞：CVE-2022-50293	medium
264961	Linux Distros 未修补的漏洞：CVE-2023-53251	medium
264960	Linux Distros 未修补的漏洞：CVE-2023-53150	medium
264959	Linux Distros 未修补的漏洞：CVE-2022-50321	medium
264958	Linux Distros 未修补的漏洞：CVE-2023-53194	high
264957	Linux Distros 未修补的漏洞：CVE-2023-53167	medium
264956	Linux Distros 未修补的漏洞：CVE-2022-50262	medium
264955	Linux Distros 未修补的漏洞：CVE-2022-50253	high
264954	Linux Distros 未修补的漏洞：CVE-2022-50260	medium
264953	Linux Distros 未修补的漏洞：CVE-2022-50319	medium
264952	Linux Distros 未修补的漏洞：CVE-2023-53230	medium
264951	Linux Distros 未修补的漏洞：CVE-2023-53181	medium
264950	Linux Distros 未修补的漏洞：CVE-2022-50275	medium
264949	Linux Distros 未修补的漏洞：CVE-2022-50307	high
264948	Linux Distros 未修补的漏洞：CVE-2023-53169	medium
264947	Linux Distros 未修补的漏洞：CVE-2023-53197	medium
264946	Linux Distros 未修补的漏洞：CVE-2022-50274	high
264945	Linux Distros 未修补的漏洞：CVE-2022-50288	medium
264943	Linux Distros 未修补的漏洞：CVE-2022-50239	high
264942	Linux Distros 未修补的漏洞：CVE-2023-53252	high
264941	Linux Distros 未修补的漏洞：CVE-2022-50252	high
264940	Linux Distros 未修补的漏洞：CVE-2023-53202	medium
264939	Linux Distros 未修补的漏洞：CVE-2022-50248	high
264938	Linux Distros 未修补的漏洞：CVE-2023-53233	medium
264937	Linux Distros 未修补的漏洞：CVE-2022-50272	medium
264936	Linux Distros 未修补的漏洞：CVE-2022-50328	high
264935	Linux Distros 未修补的漏洞：CVE-2022-50235	high
264934	Linux Distros 未修补的漏洞：CVE-2023-53220	medium
264933	Linux Distros 未修补的漏洞：CVE-2022-50331	medium
264932	Linux Distros 未修补的漏洞：CVE-2022-50312	medium
264931	Linux Distros 未修补的漏洞：CVE-2023-53231	medium
264930	Linux Distros 未修补的漏洞：CVE-2023-53185	medium
264929	Linux Distros 未修补的漏洞：CVE-2023-53186	medium

检测

Nessus 的 Misc. 系列

medium

medium

medium

high

medium

medium

medium

medium

medium

medium

high

medium

medium

medium

medium

medium

medium

medium

medium

medium

medium

high

medium

medium

high

medium

medium

medium

medium

medium

high

medium

medium

high

medium

high

high

high

medium

high

medium

medium

high

high

medium

medium

medium

medium

medium

medium