Kushalkhemka/embedding-cve-nvd-dataset huggingface dataset:
G W 6.6.0-rc1-e7af8d17224a-x86/gmem-vm #119 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:kworker/8:1 state:D stack:0 pid:251 ppid:2 flags:0x00004000 Workqueue: events async_pf_execute [kvm] Call Trace: <TASK> __schedule+0x33f/0xa40 schedule+0x53/0xc0 schedule_timeout+0x12a/0x140 __wait_for_common+0x8d/0x1d0 __flush_work.isra.0+0x19f/0x2c0 kvm_clear_async_pf_completion_queue+0x129/0x190 [kvm] kvm_arch_destroy_vm+0x78/0x1b0 [kvm] kvm_put_kvm+0x1c1/0x320 [kvm] async_pf_execute+0x198/0x260 [kvm] process_one_work+0x145/0x2d0 worker_thread+0x27e/0x3a0 kthread+0xba/0xe0 ret_from_fork+0x2d/0x50 ret_from_fork_asm+0x11/0x20 </TASK> If kvm_clear_async_pf_completion_que
0x3a0 kthread+0xba/0xe0 ret_from_fork+0x2d/0x50 ret_from_fork_asm+0x11/0x20 </TASK> If kvm_clear_async_pf_completion_queue() actually flushes the workqueue, then there's no need to gift async_pf_execute() a reference because all invocations of async_pf_execute() will be forced to complete before the vCPU and its VM are destroyed/freed. And that in turn fixes the module unloading bug as __fput() won't do module_put() on the last vCPU reference until the vCPU has been freed, e.g. if closing the vCPU file also puts the last reference to the KVM module. Note that kvm_check_async_pf_completion() may also take the work item off the completion queue and so also needs to flush the work queue, as the
c_pf_completion() may also take the work item off the completion queue and so also needs to flush the work queue, as the work will not be seen by kvm_clear_async_pf_completion_queue(). Waiting on the workqueue could theoretically delay a vCPU due to waiting for the work to complete, but that's a very, very small chance, and likely a very small delay. kvm_arch_async_page_present_queued() unconditionally makes a new request, i.e. will effectively delay entering the guest, so the remaining work is really just: trace_kvm_async_pf_completed(addr, cr2_or_gpa); __kvm_vcpu_wake_up(vcpu); mmput(mm); and mmput() can't drop the last reference to the page tables if the vCPU is still alive, i.e. the vCPU
vcpu); mmput(mm); and mmput() can't drop the last reference to the page tables if the vCPU is still alive, i.e. the vCPU won't get stuck tearing down page tables. Add a helper to do the flushing, specifically to deal with "wakeup all" work items, as they aren't actually work items, i.e. are never placed in a workqueue. Trying to flush a bogus workqueue entry rightly makes __flush_work() complain (kudos to whoever added that sanity check). Note, commit 5f6de5cbebee ("KVM: Prevent module exit until al ---truncated--- Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/ab2c2f5d9576112ad22cfd3798071cb74693b1f5 - https://git.ke
ogram Container: References: - https://git.kernel.org/stable/c/ab2c2f5d9576112ad22cfd3798071cb74693b1f5 - https://git.kernel.org/stable/c/82e25cc1c2e93c3023da98be282322fc08b61ffb - https://git.kernel.org/stable/c/f8730d6335e5f43d09151fca1f0f41922209a264 - https://git.kernel.org/stable/c/83d3c5e309611ef593e2fcb78444fc8ceedf9bac - https://git.kernel.org/stable/c/b54478d20375874aeee257744dedfd3e413432ff - https://git.kernel.org/stable/c/a75afe480d4349c524d9c659b1a5a544dbc39a98 - https://git.kernel.org/stable/c/4f3a3bce428fb439c66a578adc447afce7b4a750 - https://git.kernel.org/stable/c/caa9af2e27c275e089d702cfbaaece3b42bca31b - https://git.kernel.org/stable/c/3d75b8aa5c29058a512db29da7cbee8052724
table/c/caa9af2e27c275e089d702cfbaaece3b42bca31b - https://git.kernel.org/stable/c/3d75b8aa5c29058a512db29da7cbee8052724157
CVE ID: CVE-2024-26977 State: PUBLISHED Published: 2024-05-01T05:20:28.830Z Last Updated: 2025-05-04T09:01:19.979Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: pci_iounmap(): Fix MMIO mapping leak The #ifdef ARCH_HAS_GENERIC_IOPORT_MAP accidentally also guards iounmap(), which means MMIO mappings are leaked. Move the guard so we call iounmap() for MMIO mappings. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/5e4b23e7a7b33a1e56bfa3e5598138a2234d55b6 - https://git.kernel.org/stable/c/6d21d0356aa44157a62e39c0d1a13d4c69a8d0c8 - https://git.kernel.org/stabl
8138a2234d55b6 - https://git.kernel.org/stable/c/6d21d0356aa44157a62e39c0d1a13d4c69a8d0c8 - https://git.kernel.org/stable/c/b5d40f02e7222da032c2042aebcf2a07de9b342f - https://git.kernel.org/stable/c/f3749345a9b7295dd071d0ed589634cb46364f77 - https://git.kernel.org/stable/c/af280e137e273935f2e09f4d73169998298792ed - https://git.kernel.org/stable/c/7626913652cc786c238e2dd7d8740b17d41b2637
CVE ID: CVE-2024-26978 State: PUBLISHED Published: 2024-05-01T05:20:33.457Z Last Updated: 2025-05-04T09:01:21.630Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: serial: max310x: fix NULL pointer dereference in I2C instantiation When trying to instantiate a max14830 device from userspace: echo max14830 0x60 > /sys/bus/i2c/devices/i2c-2/new_device we get the following error: Unable to handle kernel NULL pointer dereference at virtual address... ... Call trace: max310x_i2c_probe+0x48/0x170 [max310x] i2c_device_probe+0x150/0x2a0 ... Add check for validity of devtype to prevent the error, and abort probe with a meaningful error mes
robe+0x150/0x2a0 ... Add check for validity of devtype to prevent the error, and abort probe with a meaningful error message. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/7d271b798add90c6196539167c019d0817285cf0 - https://git.kernel.org/stable/c/c45e53c27b78afd6c81fc25608003576f27b5735 - https://git.kernel.org/stable/c/12609c76b755dbeb1645c0aacc0f0f4743b2eff3 - https://git.kernel.org/stable/c/2160ad6861c4a21d3fa553d7b2aaec6634a37f8a - https://git.kernel.org/stable/c/5cd8af02b466e1beeae13e2de3dc58fcc7925e5a - https://git.kernel.org/stable/c/aeca49661fd02fd56fb026768b580ce301b45733 - https://git.kernel.org/stable/c/0d
c7925e5a - https://git.kernel.org/stable/c/aeca49661fd02fd56fb026768b580ce301b45733 - https://git.kernel.org/stable/c/0d27056c24efd3d63a03f3edfbcfc4827086b110
CVE ID: CVE-2024-26979 State: REJECTED Published: 2024-05-01T05:20:38.304Z Last Updated: 2024-06-12T15:58:08.674Z Description: No description available.
CVE ID: CVE-2024-26980 State: PUBLISHED Published: 2024-05-01T05:26:56.744Z Last Updated: 2025-11-04T17:14:51.828Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix slab-out-of-bounds in smb2_allocate_rsp_buf If ->ProtocolId is SMB2_TRANSFORM_PROTO_NUM, smb2 request size validation could be skipped. if request size is smaller than sizeof(struct smb2_query_info_req), slab-out-of-bounds read can happen in smb2_allocate_rsp_buf(). This patch allocate response buffer after decrypting transform request. smb3_decrypt_req() will validate transform request size and avoid slab-out-of-bound in smb2_allocate_rsp_buf(). Additional
3_decrypt_req() will validate transform request size and avoid slab-out-of-bound in smb2_allocate_rsp_buf(). Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/da21401372607c49972ea87a6edaafb36a17c325 - https://git.kernel.org/stable/c/b80ba648714e6d790d69610cf14656be222d0248 - https://git.kernel.org/stable/c/3160d9734453a40db248487f8204830879c207f1 - https://git.kernel.org/stable/c/0977f89722eceba165700ea384f075143f012085 - https://git.kernel.org/stable/c/c119f4ede3fa90a9463f50831761c28f989bfb20
CVE ID: CVE-2024-26981 State: PUBLISHED Published: 2024-05-01T05:27:06.469Z Last Updated: 2025-11-04T17:14:55.924Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix OOB in nilfs_set_de_type The size of the nilfs_type_by_mode array in the fs/nilfs2/dir.c file is defined as "S_IFMT >> S_SHIFT", but the nilfs_set_de_type() function, which uses this array, specifies the index to read from the array in the same way as "(mode & S_IFMT) >> S_SHIFT". static void nilfs_set_de_type(struct nilfs_dir_entry *de, struct inode *inode) { umode_t mode = inode->i_mode; de->file_type = nilfs_type_by_mode[(mode & S_IFMT)>>S_SHIFT]; // oob
truct inode *inode) { umode_t mode = inode->i_mode; de->file_type = nilfs_type_by_mode[(mode & S_IFMT)>>S_SHIFT]; // oob } However, when the index is determined this way, an out-of-bounds (OOB) error occurs by referring to an index that is 1 larger than the array size when the condition "mode & S_IFMT == S_IFMT" is satisfied. Therefore, a patch to resize the nilfs_type_by_mode array should be applied to prevent OOB errors. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/054f29e9ca05be3906544c5f2a2c7321c30a4243 - https://git.kernel.org/stable/c/90f43980ea6be4ad903e389be9a27a2a0018f1c8 - https://git.kernel.org/stable/c/7
1c30a4243 - https://git.kernel.org/stable/c/90f43980ea6be4ad903e389be9a27a2a0018f1c8 - https://git.kernel.org/stable/c/7061c7efbb9e8f11ce92d6b4646405ea2b0b4de1 - https://git.kernel.org/stable/c/bdbe483da21f852c93b22557b146bc4d989260f0 - https://git.kernel.org/stable/c/897ac5306bbeb83e90c437326f7044c79a17c611 - https://git.kernel.org/stable/c/2382eae66b196c31893984a538908c3eb7506ff9 - https://git.kernel.org/stable/c/90823f8d9ecca3d5fa6b102c8e464c62f416975f - https://git.kernel.org/stable/c/c4a7dc9523b59b3e73fd522c73e95e072f876b16
CVE ID: CVE-2024-26982 State: PUBLISHED Published: 2024-05-01T05:27:11.032Z Last Updated: 2025-11-04T17:15:00.359Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: Squashfs: check the inode number is not the invalid value of zero Syskiller has produced an out of bounds access in fill_meta_index(). That out of bounds access is ultimately caused because the inode has an inode number with the invalid value of zero, which was not checked. The reason this causes the out of bounds access is due to following sequence of events: 1. Fill_meta_index() is called to allocate (via empty_meta_index()) and fill a metadata index. It however suff
f events: 1. Fill_meta_index() is called to allocate (via empty_meta_index()) and fill a metadata index. It however suffers a data read error and aborts, invalidating the newly returned empty metadata index. It does this by setting the inode number of the index to zero, which means unused (zero is not a valid inode number). 2. When fill_meta_index() is subsequently called again on another read operation, locate_meta_index() returns the previous index because it matches the inode number of 0. Because this index has been returned it is expected to have been filled, and because it hasn't been, an out of bounds access is performed. This patch adds a sanity check which checks that the inode numbe
e it hasn't been, an out of bounds access is performed. This patch adds a sanity check which checks that the inode number is not zero when the inode is created and returns -EINVAL if it is. [phillip@squashfs.org.uk: whitespace fix] Additional Analyst Notes: - CVE Program Container: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/32c114a58236fe67141634774559f21f1dc96fd7 - https://git.kernel.org/stable/c/4a1b6f89825e267e156ccaeba3d235edcac77f94 - https://git.kernel.org/stable/c/cf46f88b92cfc0e32bd8a21ba1273cff13b8745f - https://git.kernel.org/stable/c/5b99dea79650b50909c50aba24fbae00f203f013 - https://git.kernel.org/stable/c/be383effaee3d89034f0828038f95065b518772e - htt
b99dea79650b50909c50aba24fbae00f203f013 - https://git.kernel.org/stable/c/be383effaee3d89034f0828038f95065b518772e - https://git.kernel.org/stable/c/7def00ebc9f2d6a581ddf46ce4541f84a10680e5 - https://git.kernel.org/stable/c/9253c54e01b6505d348afbc02abaa4d9f8a01395
CVE ID: CVE-2024-26983 State: PUBLISHED Published: 2024-05-01T05:27:15.635Z Last Updated: 2025-11-04T17:15:06.403Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: bootconfig: use memblock_free_late to free xbc memory to buddy On the time to free xbc memory in xbc_exit(), memblock may has handed over memory to buddy allocator. So it doesn't make sense to free memory back to memblock. memblock_free() called by xbc_exit() even causes UAF bugs on architectures with CONFIG_ARCH_KEEP_MEMBLOCK disabled like x86. Following KASAN logs shows this case. This patch fixes the xbc memory free problem by calling memblock_free() in early xbc in
wing KASAN logs shows this case. This patch fixes the xbc memory free problem by calling memblock_free() in early xbc init error rewind path and calling memblock_free_late() in xbc exit path to free memory to buddy allocator. [ 9.410890] ================================================================== [ 9.418962] BUG: KASAN: use-after-free in memblock_isolate_range+0x12d/0x260 [ 9.426850] Read of size 8 at addr ffff88845dd30000 by task swapper/0/1 [ 9.435901] CPU: 9 PID: 1 Comm: swapper/0 Tainted: G U 6.9.0-rc3-00208-g586b5dfb51b9 #5 [ 9.446403] Hardware name: Intel Corporation RPLP LP5 (CPU:RaptorLake)/RPLP LP5 (ID:13), BIOS IRPPN02.01.01.00.00.19.015.D-00000000 Dec 28 2023 [ 9.460789] Ca
ration RPLP LP5 (CPU:RaptorLake)/RPLP LP5 (ID:13), BIOS IRPPN02.01.01.00.00.19.015.D-00000000 Dec 28 2023 [ 9.460789] Call Trace: [ 9.463518] <TASK> [ 9.465859] dump_stack_lvl+0x53/0x70 [ 9.469949] print_report+0xce/0x610 [ 9.473944] ? __virt_addr_valid+0xf5/0x1b0 [ 9.478619] ? memblock_isolate_range+0x12d/0x260 [ 9.483877] kasan_report+0xc6/0x100 [ 9.487870] ? memblock_isolate_range+0x12d/0x260 [ 9.493125] memblock_isolate_range+0x12d/0x260 [ 9.498187] memblock_phys_free+0xb4/0x160 [ 9.502762] ? __pfx_memblock_phys_free+0x10/0x10 [ 9.508021] ? mutex_unlock+0x7e/0xd0 [ 9.512111] ? __pfx_mutex_unlock+0x10/0x10 [ 9.516786] ? kernel_init_freeable+0x2d4/0x430 [ 9.521850] ? __pfx_kernel_init+0x10
2111] ? __pfx_mutex_unlock+0x10/0x10 [ 9.516786] ? kernel_init_freeable+0x2d4/0x430 [ 9.521850] ? __pfx_kernel_init+0x10/0x10 [ 9.526426] xbc_exit+0x17/0x70 [ 9.529935] kernel_init+0x38/0x1e0 [ 9.533829] ? _raw_spin_unlock_irq+0xd/0x30 [ 9.538601] ret_from_fork+0x2c/0x50 [ 9.542596] ? __pfx_kernel_init+0x10/0x10 [ 9.547170] ret_from_fork_asm+0x1a/0x30 [ 9.551552] </TASK> [ 9.555649] The buggy address belongs to the physical page: [ 9.561875] page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x1 pfn:0x45dd30 [ 9.570821] flags: 0x200000000000000(node=0|zone=2) [ 9.576271] page_type: 0xffffffff() [ 9.580167] raw: 0200000000000000 ffffea0011774c48 ffffea0012ba1848 0000000000000000 [ 9.5
6271] page_type: 0xffffffff() [ 9.580167] raw: 0200000000000000 ffffea0011774c48 ffffea0012ba1848 0000000000000000 [ 9.588823] raw: 0000000000000001 0000000000000000 00000000ffffffff 0000000000000000 [ 9.597476] page dumped because: kasan: bad access detected [ 9.605362] Memory state around the buggy address: [ 9.610714] ffff88845dd2ff00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 9.618786] ffff88845dd2ff80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 9.626857] >ffff88845dd30000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 9.634930] ^ [ 9.638534] ffff88845dd30080: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 9.646605] ffff88845dd30100: ff ff ff ff ff ff ff ff ff ff ff
5dd30080: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 9.646605] ffff88845dd30100: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 9.654675] ================================================================== Additional Analyst Notes: - CVE Program Container: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/1e7feb31a18c197d63a5e606025ed63c762f8918 - https://git.kernel.org/stable/c/e46d3be714ad9652480c6db129ab8125e2d20ab7 - https://git.kernel.org/stable/c/5a7dfb8fcd3f29fc93161100179b27f24f3d5f35 - https://git.kernel.org/stable/c/89f9a1e876b5a7ad884918c03a46831af202c8a0
CVE ID: CVE-2024-26984 State: PUBLISHED Published: 2024-05-01T05:27:20.506Z Last Updated: 2025-11-04T17:15:10.866Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: nouveau: fix instmem race condition around ptr stores Running a lot of VK CTS in parallel against nouveau, once every few hours you might see something like this crash. BUG: kernel NULL pointer dereference, address: 0000000000000008 PGD 8000000114e6e067 P4D 8000000114e6e067 PUD 109046067 PMD 0 Oops: 0000 [#1] PREEMPT SMP PTI CPU: 7 PID: 53891 Comm: deqp-vk Not tainted 6.8.0-rc6+ #27 Hardware name: Gigabyte Technology Co., Ltd. Z390 I AORUS PRO WIFI/Z390 I AORUS PRO WIF
qp-vk Not tainted 6.8.0-rc6+ #27 Hardware name: Gigabyte Technology Co., Ltd. Z390 I AORUS PRO WIFI/Z390 I AORUS PRO WIFI-CF, BIOS F8 11/05/2021 RIP: 0010:gp100_vmm_pgt_mem+0xe3/0x180 [nouveau] Code: c7 48 01 c8 49 89 45 58 85 d2 0f 84 95 00 00 00 41 0f b7 46 12 49 8b 7e 08 89 da 42 8d 2c f8 48 8b 47 08 41 83 c7 01 48 89 ee <48> 8b 40 08 ff d0 0f 1f 00 49 8b 7e 08 48 89 d9 48 8d 75 04 48 c1 RSP: 0000:ffffac20c5857838 EFLAGS: 00010202 RAX: 0000000000000000 RBX: 00000000004d8001 RCX: 0000000000000001 RDX: 00000000004d8001 RSI: 00000000000006d8 RDI: ffffa07afe332180 RBP: 00000000000006d8 R08: ffffac20c5857ad0 R09: 0000000000ffff10 R10: 0000000000000001 R11: ffffa07af27e2de0 R12: 000000000000001
000000006d8 R08: ffffac20c5857ad0 R09: 0000000000ffff10 R10: 0000000000000001 R11: ffffa07af27e2de0 R12: 000000000000001c R13: ffffac20c5857ad0 R14: ffffa07a96fe9040 R15: 000000000000001c FS: 00007fe395eed7c0(0000) GS:ffffa07e2c980000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000008 CR3: 000000011febe001 CR4: 00000000003706f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ... ? gp100_vmm_pgt_mem+0xe3/0x180 [nouveau] ? gp100_vmm_pgt_mem+0x37/0x180 [nouveau] nvkm_vmm_iter+0x351/0xa20 [nouveau] ? __pfx_nvkm_vmm_ref_ptes+0x10/0x10 [nouveau] ? __pfx_g
pgt_mem+0x37/0x180 [nouveau] nvkm_vmm_iter+0x351/0xa20 [nouveau] ? __pfx_nvkm_vmm_ref_ptes+0x10/0x10 [nouveau] ? __pfx_gp100_vmm_pgt_mem+0x10/0x10 [nouveau] ? __pfx_gp100_vmm_pgt_mem+0x10/0x10 [nouveau] ? __lock_acquire+0x3ed/0x2170 ? __pfx_gp100_vmm_pgt_mem+0x10/0x10 [nouveau] nvkm_vmm_ptes_get_map+0xc2/0x100 [nouveau] ? __pfx_nvkm_vmm_ref_ptes+0x10/0x10 [nouveau] ? __pfx_gp100_vmm_pgt_mem+0x10/0x10 [nouveau] nvkm_vmm_map_locked+0x224/0x3a0 [nouveau] Adding any sort of useful debug usually makes it go away, so I hand wrote the function in a line, and debugged the asm. Every so often pt->memory->ptrs is NULL. This ptrs ptr is set in the nv50_instobj_acquire called from nvkm_kmap. If Thread A
y so often pt->memory->ptrs is NULL. This ptrs ptr is set in the nv50_instobj_acquire called from nvkm_kmap. If Thread A and Thread B both get to nv50_instobj_acquire around the same time, and Thread A hits the refcount_set line, and in lockstep thread B succeeds at refcount_inc_not_zero, there is a chance the ptrs value won't have been stored since refcount_set is unordered. Force a memory barrier here, I picked smp_mb, since we want it on all CPUs and it's write followed by a read. v2: use paired smp_rmb/smp_wmb. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/bba8ec5e9b16649d85bc9e9086bf7ae5b5716ff9 - https://git.ke
ogram Container: References: - https://git.kernel.org/stable/c/bba8ec5e9b16649d85bc9e9086bf7ae5b5716ff9 - https://git.kernel.org/stable/c/1bc4825d4c3ec6abe43cf06c3c39d664d044cbf7 - https://git.kernel.org/stable/c/13d76b2f443dc371842916dd8768009ff1594716 - https://git.kernel.org/stable/c/3ab056814cd8ab84744c9a19ef51360b2271c572 - https://git.kernel.org/stable/c/ad74d208f213c06d860916ad40f609ade8c13039 - https://git.kernel.org/stable/c/a019b44b1bc6ed224c46fb5f88a8a10dd116e525 - https://git.kernel.org/stable/c/21ca9539f09360fd83654f78f2c361f2f5ddcb52 - https://git.kernel.org/stable/c/fff1386cc889d8fb4089d285f883f8cba62d82ce
CVE ID: CVE-2024-26985 State: PUBLISHED Published: 2024-05-01T05:27:25.121Z Last Updated: 2025-11-04T17:15:15.152Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: drm/xe: Fix bo leak in intel_fb_bo_framebuffer_init Add a unreference bo in the error path, to prevent leaking a bo ref. Return 0 on success to clarify the success path. (cherry picked from commit a2f3d731be3893e730417ae3190760fcaffdf549) Additional Analyst Notes: - CVE Program Container: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/7d8ac0942c312abda43b407eff72d31747a7b472 - https://git.kernel.org/stable/c/652ead9b746a63e4e79d7ad66d3edf0a8a5b0
table/c/7d8ac0942c312abda43b407eff72d31747a7b472 - https://git.kernel.org/stable/c/652ead9b746a63e4e79d7ad66d3edf0a8a5b0c2f
CVE ID: CVE-2024-26986 State: PUBLISHED Published: 2024-05-01T05:27:29.951Z Last Updated: 2025-11-04T17:15:19.284Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: Fix memory leak in create_process failure Fix memory leak due to a leaked mmget reference on an error handling code path that is triggered when attempting to create KFD processes while a GPU reset is in progress. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/aa02d43367a9adf8c85fb382fea4171fb266c8d0 - https://git.kernel.org/stable/c/0dcd876411644da98a6b4d5a18d32ca94c15bdb5 - https://
3367a9adf8c85fb382fea4171fb266c8d0 - https://git.kernel.org/stable/c/0dcd876411644da98a6b4d5a18d32ca94c15bdb5 - https://git.kernel.org/stable/c/18921b205012568b45760753ad3146ddb9e2d4e2
CVE ID: CVE-2024-26987 State: PUBLISHED Published: 2024-05-01T05:27:34.523Z Last Updated: 2025-11-04T17:15:23.408Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: mm/memory-failure: fix deadlock when hugetlb_optimize_vmemmap is enabled When I did hard offline test with hugetlb pages, below deadlock occurs: ====================================================== WARNING: possible circular locking dependency detected 6.8.0-11409-gf6cef5f8c37f #1 Not tainted ------------------------------------------------------ bash/46904 is trying to acquire lock: ffffffffabe68910 (cpu_hotplug_lock){++++}-{0:0}, at: static_key_slow_dec+0x16/0x60 b
sh/46904 is trying to acquire lock: ffffffffabe68910 (cpu_hotplug_lock){++++}-{0:0}, at: static_key_slow_dec+0x16/0x60 but task is already holding lock: ffffffffabf92ea8 (pcp_batch_high_lock){+.+.}-{3:3}, at: zone_pcp_disable+0x16/0x40 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (pcp_batch_high_lock){+.+.}-{3:3}: __mutex_lock+0x6c/0x770 page_alloc_cpu_online+0x3c/0x70 cpuhp_invoke_callback+0x397/0x5f0 __cpuhp_invoke_callback_range+0x71/0xe0 _cpu_up+0xeb/0x210 cpu_up+0x91/0xe0 cpuhp_bringup_mask+0x49/0xb0 bringup_nonboot_cpus+0xb7/0xe0 smp_init+0x25/0xa0 kernel_init_freeable+0x15f/0x3e0 kernel_init+0x15/0x1b0 ret_from_fork+0x2f/0x50 r
boot_cpus+0xb7/0xe0 smp_init+0x25/0xa0 kernel_init_freeable+0x15f/0x3e0 kernel_init+0x15/0x1b0 ret_from_fork+0x2f/0x50 ret_from_fork_asm+0x1a/0x30 -> #0 (cpu_hotplug_lock){++++}-{0:0}: __lock_acquire+0x1298/0x1cd0 lock_acquire+0xc0/0x2b0 cpus_read_lock+0x2a/0xc0 static_key_slow_dec+0x16/0x60 __hugetlb_vmemmap_restore_folio+0x1b9/0x200 dissolve_free_huge_page+0x211/0x260 __page_handle_poison+0x45/0xc0 memory_failure+0x65e/0xc70 hard_offline_page_store+0x55/0xa0 kernfs_fop_write_iter+0x12c/0x1d0 vfs_write+0x387/0x550 ksys_write+0x64/0xe0 do_syscall_64+0xca/0x1e0 entry_SYSCALL_64_after_hwframe+0x6d/0x75 other info that might help us debug this: Possible unsafe locking scenario: CPU0 CPU1 ---- -