Kushalkhemka/embedding-cve-nvd-dataset huggingface dataset:
CVE ID: CVE-2022-49545 State: PUBLISHED Published: 2025-02-26T02:13:58.363Z Last Updated: 2025-05-04T08:40:14.387Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: Cancel pending work at closing a MIDI substream At closing a USB MIDI output substream, there might be still a pending work, which would eventually access the rawmidi runtime object that is being released. For fixing the race, make sure to cancel the pending work at closing. References: - https://git.kernel.org/stable/c/40bdb5ec957aca5c5c1924602bef6b0ab18e22d3 - https://git.kernel.org/stable/c/11868ca21585561659c2575b0d6508ef8e9c4291 - https://git.kern
5c5c1924602bef6b0ab18e22d3 - https://git.kernel.org/stable/c/11868ca21585561659c2575b0d6508ef8e9c4291 - https://git.kernel.org/stable/c/5e5fe2b6065541c6216a7a003b0cddf386be0d2d - https://git.kernel.org/stable/c/517dcef4d2dda0132648f1e4c079ed17bba4d1a4 - https://git.kernel.org/stable/c/0125de38122f0f66bf61336158d12a1aabfe6425
CVE ID: CVE-2022-49546 State: PUBLISHED Published: 2025-02-26T02:13:58.867Z Last Updated: 2025-11-03T19:27:52.873Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: x86/kexec: fix memory leak of elf header buffer This is reported by kmemleak detector: unreferenced object 0xffffc900002a9000 (size 4096): comm "kexec", pid 14950, jiffies 4295110793 (age 373.951s) hex dump (first 32 bytes): 7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00 .ELF............ 04 00 3e 00 01 00 00 00 00 00 00 00 00 00 00 00 ..>............. backtrace: [<0000000016a8ef9f>] __vmalloc_node_range+0x101/0x170 [<000000002b66b6c0>] __vmalloc_node+0xb4/0x160 [<0000
. backtrace: [<0000000016a8ef9f>] __vmalloc_node_range+0x101/0x170 [<000000002b66b6c0>] __vmalloc_node+0xb4/0x160 [<00000000ad40107d>] crash_prepare_elf64_headers+0x8e/0xcd0 [<0000000019afff23>] crash_load_segments+0x260/0x470 [<0000000019ebe95c>] bzImage64_load+0x814/0xad0 [<0000000093e16b05>] arch_kexec_kernel_image_load+0x1be/0x2a0 [<000000009ef2fc88>] kimage_file_alloc_init+0x2ec/0x5a0 [<0000000038f5a97a>] __do_sys_kexec_file_load+0x28d/0x530 [<0000000087c19992>] do_syscall_64+0x3b/0x90 [<0000000066e063a4>] entry_SYSCALL_64_after_hwframe+0x44/0xae In crash_prepare_elf64_headers(), a buffer is allocated via vmalloc() to store elf headers. While it's not freed back to system correctly when
_headers(), a buffer is allocated via vmalloc() to store elf headers. While it's not freed back to system correctly when kdump kernel is reloaded or unloaded. Then memory leak is caused. Fix it by introducing x86 specific function arch_kimage_file_post_load_cleanup(), and freeing the buffer there. And also remove the incorrect elf header buffer freeing code. Before calling arch specific kexec_file loading function, the image instance has been initialized. So 'image->elf_headers' must be NULL. It doesn't make sense to free the elf header buffer in the place. Three different people have reported three bugs about the memory leak on x86_64 inside Redhat. Additional Analyst Notes: - CVE Program C
people have reported three bugs about the memory leak on x86_64 inside Redhat. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/23cf39dccf7653650701a6f39b119e9116a27f1a - https://git.kernel.org/stable/c/8765a423a87d74ef24ea02b43b2728fe4039f248 - https://git.kernel.org/stable/c/115ee42a4c2f26ba2b4ace2668a3f004621f6833 - https://git.kernel.org/stable/c/f675e3a9189d84a9324ab45b0cb19906c2bc8fcb - https://git.kernel.org/stable/c/b3e34a47f98974d0844444c5121aaff123004e57
CVE ID: CVE-2022-49547 State: PUBLISHED Published: 2025-02-26T02:13:59.343Z Last Updated: 2025-10-01T19:46:39.704Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: btrfs: fix deadlock between concurrent dio writes when low on free data space When reserving data space for a direct IO write we can end up deadlocking if we have multiple tasks attempting a write to the same file range, there are multiple extents covered by that file range, we are low on available space for data and the writes don't expand the inode's i_size. The deadlock can happen like this: 1) We have a file with an i_size of 1M, at offset 0 it has an extent with a
s i_size. The deadlock can happen like this: 1) We have a file with an i_size of 1M, at offset 0 it has an extent with a size of 128K and at offset 128K it has another extent also with a size of 128K; 2) Task A does a direct IO write against file range [0, 256K), and because the write is within the i_size boundary, it takes the inode's lock (VFS level) in shared mode; 3) Task A locks the file range [0, 256K) at btrfs_dio_iomap_begin(), and then gets the extent map for the extent covering the range [0, 128K). At btrfs_get_blocks_direct_write(), it creates an ordered extent for that file range ([0, 128K)); 4) Before returning from btrfs_dio_iomap_begin(), it unlocks the file range [0, 256K); 5
or that file range ([0, 128K)); 4) Before returning from btrfs_dio_iomap_begin(), it unlocks the file range [0, 256K); 5) Task A executes btrfs_dio_iomap_begin() again, this time for the file range [128K, 256K), and locks the file range [128K, 256K); 6) Task B starts a direct IO write against file range [0, 256K) as well. It also locks the inode in shared mode, as it's within the i_size limit, and then tries to lock file range [0, 256K). It is able to lock the subrange [0, 128K) but then blocks waiting for the range [128K, 256K), as it is currently locked by task A; 7) Task A enters btrfs_get_blocks_direct_write() and tries to reserve data space. Because we are low on available free space, i
A enters btrfs_get_blocks_direct_write() and tries to reserve data space. Because we are low on available free space, it triggers the async data reclaim task, and waits for it to reserve data space; 8) The async reclaim task decides to wait for all existing ordered extents to complete (through btrfs_wait_ordered_roots()). It finds the ordered extent previously created by task A for the file range [0, 128K) and waits for it to complete; 9) The ordered extent for the file range [0, 128K) can not complete because it blocks at btrfs_finish_ordered_io() when trying to lock the file range [0, 128K). This results in a deadlock, because: - task B is holding the file range [0, 128K) locked, waiting
file range [0, 128K). This results in a deadlock, because: - task B is holding the file range [0, 128K) locked, waiting for the range [128K, 256K) to be unlocked by task A; - task A is holding the file range [128K, 256K) locked and it's waiting for the async data reclaim task to satisfy its space reservation request; - the async data reclaim task is waiting for ordered extent [0, 128K) to complete, but the ordered extent can not complete because the file range [0, 128K) is currently locked by task B, which is waiting on task A to unlock file range [128K, 256K) and task A waiting on the async data reclaim task. This results in a deadlock between 4 task: task A, task B, the async data reclaim
iting on the async data reclaim task. This results in a deadlock between 4 task: task A, task B, the async data reclaim task and the task doing ordered extent completion (a work queue task). This type of deadlock can sporadically be triggered by the test case generic/300 from fstests, and results in a stack trace like the following: [12084.033689] INFO: task kworker/u16:7:123749 blocked for more than 241 seconds. [12084.034877] Not tainted 5.18.0-rc2-btrfs-next-115 #1 [12084.035562] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [12084.036548] task:kworker/u16:7 state:D stack: 0 pid:123749 ppid: 2 flags:0x00004000 [12084.036554] Workqueue: btrfs-flush_delalloc btrf
k:kworker/u16:7 state:D stack: 0 pid:123749 ppid: 2 flags:0x00004000 [12084.036554] Workqueue: btrfs-flush_delalloc btrfs_work_helper [btrfs] [12084.036599] Call Trace: [12084.036601] <TASK> [12084.036606] __schedule+0x3cb/0xed0 [12084.036616] schedule+0x4e/0xb0 [12084.036620] btrfs_start_ordered_extent+0x109/0x1c0 [btrfs] [12084.036651] ? prepare_to_wait_exclusive+0xc0/0xc0 [12084.036659] btrfs_run_ordered_extent_work+0x1a/0x30 [btrfs] [12084.036688] btrfs_work_helper+0xf8/0x400 [btrfs] [12084.0367 ---truncated--- Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/cfae6f765b3c40882ee90dae8fbf9325c8de9c35 - https://git.kernel.org/stable/c/f5585f4
es: - https://git.kernel.org/stable/c/cfae6f765b3c40882ee90dae8fbf9325c8de9c35 - https://git.kernel.org/stable/c/f5585f4f0ef5b17026bbd60fbff6fcc91b99d5bf
CVE ID: CVE-2022-49548 State: PUBLISHED Published: 2025-02-26T02:13:59.797Z Last Updated: 2025-10-01T19:46:39.557Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: bpf: Fix potential array overflow in bpf_trampoline_get_progs() The cnt value in the 'cnt >= BPF_MAX_TRAMP_PROGS' check does not include BPF_TRAMP_MODIFY_RETURN bpf programs, so the number of the attached BPF_TRAMP_MODIFY_RETURN bpf programs in a trampoline can exceed BPF_MAX_TRAMP_PROGS. When this happens, the assignment '*progs++ = aux->prog' in bpf_trampoline_get_progs() will cause progs array overflow as the progs field in the bpf_tramp_progs struct can only hold a
_trampoline_get_progs() will cause progs array overflow as the progs field in the bpf_tramp_progs struct can only hold at most BPF_MAX_TRAMP_PROGS bpf programs. Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/7f845de2863334bed4f362e95853f5e7bc323737 - https://git.kernel.org/stable/c/e36452d5da6325df7c10cffc60a9e68d21e2606d - https://git.kernel.org/stable/c/32c4559c61652f24c9fdd5440342196fe37453bc - https://git.kernel.org/stable/c/4f8897bcc20b9ae44758e0572538d741ab66f0dc - https://git.kernel.org/stable/c/a2aa95b71c9bbec793b5c5fa50f0a80d882b3e8d
CVE ID: CVE-2022-49549 State: PUBLISHED Published: 2025-02-26T02:14:00.256Z Last Updated: 2025-10-01T19:46:39.391Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: x86/MCE/AMD: Fix memory leak when threshold_create_bank() fails In mce_threshold_create_device(), if threshold_create_bank() fails, the previously allocated threshold banks array @bp will be leaked because the call to mce_threshold_remove_device() will not free it. This happens because mce_threshold_remove_device() fetches the pointer through the threshold_banks per-CPU variable but bp is written there only after the bank creation is successful, and not before, when th
shold_banks per-CPU variable but bp is written there only after the bank creation is successful, and not before, when threshold_create_bank() fails. Add a helper which unwinds all the bank creation work previously done and pass into it the previously allocated threshold banks array for freeing. [ bp: Massage. ] Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/b4acb8e7f1594607bc9017ef0aacb40b24a003d6 - https://git.kernel.org/stable/c/cc0dd4456f9573bf8af9b4d8754433918e809e1e - https://git.kernel.org/stable/c/9708f1956eeb70c86943e0bc62fa3b0101b59616 - https://git.kernel.org/stable/c/396b8e7ab2a99ddac57d3522b3da5e58cb608d37 - https://git.kernel.org
e0bc62fa3b0101b59616 - https://git.kernel.org/stable/c/396b8e7ab2a99ddac57d3522b3da5e58cb608d37 - https://git.kernel.org/stable/c/e5f28623ceb103e13fc3d7bd45edf9818b227fd0
CVE ID: CVE-2022-49550 State: PUBLISHED Published: 2025-02-26T02:14:00.717Z Last Updated: 2025-10-01T20:17:06.490Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: provide block_invalidate_folio to fix memory leak The ntfs3 filesystem lacks the 'invalidate_folio' method and it causes memory leak. If you write to the filesystem and then unmount it, the cached written data are not freed and they are permanently leaked. Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/0753245a72ec99824677586499ee2e0919164b3f - https://git.kernel.org/stable/c/724bbe49c5e427cb077357d72d240a649f
g/stable/c/0753245a72ec99824677586499ee2e0919164b3f - https://git.kernel.org/stable/c/724bbe49c5e427cb077357d72d240a649f2e4054
CVE ID: CVE-2022-49551 State: PUBLISHED Published: 2025-02-26T02:14:01.196Z Last Updated: 2025-10-01T19:46:39.237Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: usb: isp1760: Fix out-of-bounds array access Running the driver through kasan gives an interesting splat: BUG: KASAN: global-out-of-bounds in isp1760_register+0x180/0x70c Read of size 20 at addr f1db2e64 by task swapper/0/1 (...) isp1760_register from isp1760_plat_probe+0x1d8/0x220 (...) This happens because the loop reading the regmap fields for the different ISP1760 variants look like this: for (i = 0; i < HC_FIELD_MAX; i++) { ... } Meaning it expects the arrays to b
different ISP1760 variants look like this: for (i = 0; i < HC_FIELD_MAX; i++) { ... } Meaning it expects the arrays to be at least HC_FIELD_MAX - 1 long. However the arrays isp1760_hc_reg_fields[], isp1763_hc_reg_fields[], isp1763_hc_volatile_ranges[] and isp1763_dc_volatile_ranges[] are dynamically sized during compilation. Fix this by putting an empty assignment to the [HC_FIELD_MAX] and [DC_FIELD_MAX] array member at the end of each array. This will make the array one member longer than it needs to be, but avoids the risk of overwriting whatever is inside [HC_FIELD_MAX - 1] and is simple and intuitive to read. Also add comments explaining what is going on. Additional Analyst Notes: - CISA
1] and is simple and intuitive to read. Also add comments explaining what is going on. Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/bf2558bbdce3ab1d6bcba09f354914e4515d0a2b - https://git.kernel.org/stable/c/47d39cb57e8669e507d17d9e0d067d2b3e3a87ae - https://git.kernel.org/stable/c/463bddd3ff1acf4036ddb80c34a715eb99debf46 - https://git.kernel.org/stable/c/26ae2c942b5702f2e43d36b2a4389cfb7d616b6a
CVE ID: CVE-2022-49552 State: PUBLISHED Published: 2025-02-26T02:14:01.696Z Last Updated: 2025-05-04T08:40:23.364Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: bpf: Fix combination of jit blinding and pointers to bpf subprogs. The combination of jit blinding and pointers to bpf subprogs causes: [ 36.989548] BUG: unable to handle page fault for address: 0000000100000001 [ 36.990342] #PF: supervisor instruction fetch in kernel mode [ 36.990968] #PF: error_code(0x0010) - not-present page [ 36.994859] RIP: 0010:0x100000001 [ 36.995209] Code: Unable to access opcode bytes at RIP 0xffffffd7. [ 37.004091] Call Trace: [ 37.004351] <T
0x100000001 [ 36.995209] Code: Unable to access opcode bytes at RIP 0xffffffd7. [ 37.004091] Call Trace: [ 37.004351] <TASK> [ 37.004576] ? bpf_loop+0x4d/0x70 [ 37.004932] ? bpf_prog_3899083f75e4c5de_F+0xe3/0x13b The jit blinding logic didn't recognize that ld_imm64 with an address of bpf subprogram is a special instruction and proceeded to randomize it. By itself it wouldn't have been an issue, but jit_subprogs() logic relies on two step process to JIT all subprogs and then JIT them again when addresses of all subprogs are known. Blinding process in the first JIT phase caused second JIT to miss adjustment of special ld_imm64. Fix this issue by ignoring special ld_imm64 instructions that don
sed second JIT to miss adjustment of special ld_imm64. Fix this issue by ignoring special ld_imm64 instructions that don't have user controlled constants and shouldn't be blinded. References: - https://git.kernel.org/stable/c/a029b02b47dd5bb87a21550d9d9a80cb4dd3f714 - https://git.kernel.org/stable/c/d106a3e96fca30e44081eae9c27aab28fc132a46 - https://git.kernel.org/stable/c/4b6313cf99b0d51b49aeaea98ec76ca8161ecb80
CVE ID: CVE-2022-49553 State: PUBLISHED Published: 2025-02-26T02:14:02.183Z Last Updated: 2025-05-04T08:40:24.975Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: validate BOOT sectors_per_clusters When the NTFS BOOT sectors_per_clusters field is > 0x80, it represents a shift value. Make sure that the shift value is not too large before using it (NTFS max cluster size is 2MB). Return -EVINVAL if it too large. This prevents negative shift values and shift values that are larger than the field size. Prevents this UBSAN error: UBSAN: shift-out-of-bounds in ../fs/ntfs3/super.c:673:16 shift exponent -192 is negative Referen
vents this UBSAN error: UBSAN: shift-out-of-bounds in ../fs/ntfs3/super.c:673:16 shift exponent -192 is negative References: - https://git.kernel.org/stable/c/58cf68a1886d14ffdc5c892ce483a82156769e88 - https://git.kernel.org/stable/c/4746c49b11b2403f5b5b07c6eac9e60663dcd9a3 - https://git.kernel.org/stable/c/a2b6986316a2d106f6951e76db70fa4b2fde64a9 - https://git.kernel.org/stable/c/a3b774342fa752a5290c0de36375289dfcf4a260
CVE ID: CVE-2022-49554 State: PUBLISHED Published: 2025-02-26T02:14:02.649Z Last Updated: 2025-05-04T08:40:26.141Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: zsmalloc: fix races between asynchronous zspage free and page migration The asynchronous zspage free worker tries to lock a zspage's entire page list without defending against page migration. Since pages which haven't yet been locked can concurrently migrate off the zspage page list while lock_zspage() churns away, lock_zspage() can suffer from a few different lethal races. It can lock a page which no longer belongs to the zspage and unsafely dereference page_private()
different lethal races. It can lock a page which no longer belongs to the zspage and unsafely dereference page_private(), it can unsafely dereference a torn pointer to the next page (since there's a data race), and it can observe a spurious NULL pointer to the next page and thus not lock all of the zspage's pages (since a single page migration will reconstruct the entire page list, and create_page_chain() unconditionally zeroes out each list pointer in the process). Fix the races by using migrate_read_lock() in lock_zspage() to synchronize with page migration. References: - https://git.kernel.org/stable/c/3674d8a8dadd03a447dd21069d4dacfc3399b63b - https://git.kernel.org/stable/c/645996efc2ae
https://git.kernel.org/stable/c/3674d8a8dadd03a447dd21069d4dacfc3399b63b - https://git.kernel.org/stable/c/645996efc2ae391246d595832aaa6f9d3cc338c7 - https://git.kernel.org/stable/c/fc658c083904427abbf8f18280d517ee2668677c - https://git.kernel.org/stable/c/fae05b2314b147a78fbed1dc4c645d9a66313758 - https://git.kernel.org/stable/c/3ec459c8810e658401be428d3168eacfc380bdd0 - https://git.kernel.org/stable/c/8ba7b7c1dad1f6503c541778f31b33f7f62eb966 - https://git.kernel.org/stable/c/c5402fb5f71f1a725f1e55d9c6799c0c7bec308f - https://git.kernel.org/stable/c/2505a981114dcb715f8977b8433f7540854851d8
CVE ID: CVE-2022-49555 State: PUBLISHED Published: 2025-02-26T02:14:03.150Z Last Updated: 2025-05-04T08:40:27.341Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_qca: Use del_timer_sync() before freeing While looking at a crash report on a timer list being corrupted, which usually happens when a timer is freed while still active. This is commonly triggered by code calling del_timer() instead of del_timer_sync() just before freeing. One possible culprit is the hci_qca driver, which does exactly that. Eric mentioned that wake_retrans_timer could be rearmed via the work queue, so also move the destruction of the wor
hat. Eric mentioned that wake_retrans_timer could be rearmed via the work queue, so also move the destruction of the work queue before del_timer_sync(). References: - https://git.kernel.org/stable/c/4989bb03342941f2b730b37dfa38bce27b543661 - https://git.kernel.org/stable/c/db03727b4bbbbb36e6ef4cb655c670eefb6448e9 - https://git.kernel.org/stable/c/37d17f63d085d601011964ade7371aeebeb6ed4b - https://git.kernel.org/stable/c/2717654ae022e6ea959a4b7b762702fe1a4690c2 - https://git.kernel.org/stable/c/72ef98445aca568a81c2da050532500a8345ad3a
CVE ID: CVE-2022-49556 State: PUBLISHED Published: 2025-02-26T02:14:03.630Z Last Updated: 2025-05-04T08:40:28.652Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: KVM: SVM: Use kzalloc for sev ioctl interfaces to prevent kernel data leak For some sev ioctl interfaces, the length parameter that is passed maybe less than or equal to SEV_FW_BLOB_MAX_SIZE, but larger than the data that PSP firmware returns. In this case, kmalloc will allocate memory that is the size of the input rather than the size of the data. Since PSP firmware doesn't fully overwrite the allocated buffer, these sev ioctl interface may return uninitialized kernel
nce PSP firmware doesn't fully overwrite the allocated buffer, these sev ioctl interface may return uninitialized kernel slab memory. References: - https://git.kernel.org/stable/c/401bef1f95de92c3a8c6eece46e02fa88d7285ee - https://git.kernel.org/stable/c/d8fdb4b24097472ff6b3c0559448200d420b1418 - https://git.kernel.org/stable/c/bbdcc644b59e01e98c68894a9fab42b9687f42b0 - https://git.kernel.org/stable/c/57a01725339f9d82b099102ba2751621b1caab93 - https://git.kernel.org/stable/c/d22d2474e3953996f03528b84b7f52cc26a39403
CVE ID: CVE-2022-49557 State: PUBLISHED Published: 2025-02-26T02:14:04.090Z Last Updated: 2025-05-04T08:40:29.927Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: x86/fpu: KVM: Set the base guest FPU uABI size to sizeof(struct kvm_xsave) Set the starting uABI size of KVM's guest FPU to 'struct kvm_xsave', i.e. to KVM's historical uABI size. When saving FPU state for usersapce, KVM (well, now the FPU) sets the FP+SSE bits in the XSAVE header even if the host doesn't support XSAVE. Setting the XSAVE header allows the VM to be migrated to a host that does support XSAVE without the new host having to handle FPU state that may or may
the VM to be migrated to a host that does support XSAVE without the new host having to handle FPU state that may or may not be compatible with XSAVE. Setting the uABI size to the host's default size results in out-of-bounds writes (setting the FP+SSE bits) and data corruption (that is thankfully caught by KASAN) when running on hosts without XSAVE, e.g. on Core2 CPUs. WARN if the default size is larger than KVM's historical uABI size; all features that can push the FPU size beyond the historical size must be opt-in. ================================================================== BUG: KASAN: slab-out-of-bounds in fpu_copy_uabi_to_guest_fpstate+0x86/0x130 Read of size 8 at addr ffff888011e
========= BUG: KASAN: slab-out-of-bounds in fpu_copy_uabi_to_guest_fpstate+0x86/0x130 Read of size 8 at addr ffff888011e33a00 by task qemu-build/681 CPU: 1 PID: 681 Comm: qemu-build Not tainted 5.18.0-rc5-KASAN-amd64 #1 Hardware name: /DG35EC, BIOS ECG3510M.86A.0118.2010.0113.1426 01/13/2010 Call Trace: <TASK> dump_stack_lvl+0x34/0x45 print_report.cold+0x45/0x575 kasan_report+0x9b/0xd0 fpu_copy_uabi_to_guest_fpstate+0x86/0x130 kvm_arch_vcpu_ioctl+0x72a/0x1c50 [kvm] kvm_vcpu_ioctl+0x47f/0x7b0 [kvm] __x64_sys_ioctl+0x5de/0xc90 do_syscall_64+0x31/0x50 entry_SYSCALL_64_after_hwframe+0x44/0xae </TASK> Allocated by task 0: (stack is not available) The buggy address belongs to the object at ffff888