Kushalkhemka/embedding-cve-nvd-dataset huggingface dataset:
x30 [i915] <4> [309.733413] i915_init+0x34/0x120 [i915] <4> [309.733655] do_one_initcall+0x62/0x3f0 <4> [309.733667] do_init_module+0x97/0x2a0 <4> [309.733671] load_module+0x25ff/0x2890 <4> [309.733688] init_module_from_file+0x97/0xe0 <4> [309.733701] idempotent_init_module+0x118/0x330 <4> [309.733711] __x64_sys_finit_module+0x77/0x100 <4> [309.733715] x64_sys_call+0x1f37/0x2650 <4> [309.733719] do_syscall_64+0x91/0x180 <4> [309.733763] entry_SYSCALL_64_after_hwframe+0x76/0x7e <4> [309.733792] </TASK> ... <4> [309.733806] ---[ end trace 0000000000000000 ]--- That scenario is most easily reproducible with igt@i915_module_load@reload-with-fault-injection. Fix the issue by moving the cleanup st
s most easily reproducible with igt@i915_module_load@reload-with-fault-injection. Fix the issue by moving the cleanup step to driver release path. (cherry picked from commit 795dbde92fe5c6996a02a5b579481de73035e7bf) References: - https://git.kernel.org/stable/c/9f5ef4a5eaa61a7a4ed31231da45deb85065397a - https://git.kernel.org/stable/c/c5a906806162aea62dbe5d327760ce3b7117ca17 - https://git.kernel.org/stable/c/4bd4bf79bcfe101f0385ab81dbabb6e3f7d96c00 - https://git.kernel.org/stable/c/f104ef4db9f8f3923cc06ed1fafb3da38df6006d - https://git.kernel.org/stable/c/e3ea2eae70692a455e256787e4f54153fb739b90
CVE ID: CVE-2025-37755 State: PUBLISHED Published: 2025-05-01T12:55:59.499Z Last Updated: 2025-05-26T05:20:10.503Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: net: libwx: handle page_pool_dev_alloc_pages error page_pool_dev_alloc_pages could return NULL. There was a WARN_ON(!page) but it would still proceed to use the NULL pointer and then crash. This is similar to commit 001ba0902046 ("net: fec: handle page_pool_dev_alloc_pages error"). This is found by our static analysis tool KNighter. References: - https://git.kernel.org/stable/c/c17ef974bfcf1a50818168b47c4606b425a957c4 - https://git.kernel.org/stable/c/ad81d666e114ebf98
s://git.kernel.org/stable/c/c17ef974bfcf1a50818168b47c4606b425a957c4 - https://git.kernel.org/stable/c/ad81d666e114ebf989fc9994d4c93d451dc60056 - https://git.kernel.org/stable/c/1dd13c60348f515acd8c6f25a561b9c4e3b04fea - https://git.kernel.org/stable/c/90bec7cef8805f9a23145e070dff28a02bb584eb - https://git.kernel.org/stable/c/7f1ff1b38a7c8b872382b796023419d87d78c47e
CVE ID: CVE-2025-37756 State: PUBLISHED Published: 2025-05-01T12:56:00.539Z Last Updated: 2025-11-03T19:54:29.034Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: net: tls: explicitly disallow disconnect syzbot discovered that it can disconnect a TLS socket and then run into all sort of unexpected corner cases. I have a vague recollection of Eric pointing this out to us a long time ago. Supporting disconnect is really hard, for one thing if offload is enabled we'd need to wait for all packets to be _acked_. Disconnect is not commonly used, disallow it. The immediate problem syzbot run into is the warning in the strp, but that's
connect is not commonly used, disallow it. The immediate problem syzbot run into is the warning in the strp, but that's just the easiest bug to trigger: WARNING: CPU: 0 PID: 5834 at net/tls/tls_strp.c:486 tls_strp_msg_load+0x72e/0xa80 net/tls/tls_strp.c:486 RIP: 0010:tls_strp_msg_load+0x72e/0xa80 net/tls/tls_strp.c:486 Call Trace: <TASK> tls_rx_rec_wait+0x280/0xa60 net/tls/tls_sw.c:1363 tls_sw_recvmsg+0x85c/0x1c30 net/tls/tls_sw.c:2043 inet6_recvmsg+0x2c9/0x730 net/ipv6/af_inet6.c:678 sock_recvmsg_nosec net/socket.c:1023 [inline] sock_recvmsg+0x109/0x280 net/socket.c:1045 __sys_recvfrom+0x202/0x380 net/socket.c:2237 Additional Analyst Notes: - CVE Program Container: References: - https://git
_sys_recvfrom+0x202/0x380 net/socket.c:2237 Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/7bdcf5bc35ae59fc4a0fa23276e84b4d1534a3cf - https://git.kernel.org/stable/c/ac91c6125468be720eafde9c973994cb45b61d44 - https://git.kernel.org/stable/c/f3ce4d3f874ab7919edca364c147ac735f9f1d04 - https://git.kernel.org/stable/c/2bcad8fefcecdd5f005d8c550b25d703c063c34a - https://git.kernel.org/stable/c/9fcbca0f801580cbb583e9cb274e2c7fbe766ca6 - https://git.kernel.org/stable/c/c665bef891e8972e1d3ce5bbc0d42a373346a2c3 - https://git.kernel.org/stable/c/8513411ec321942bd3cfed53d5bb700665c67d86 - https://git.kernel.org/stable/c/5071a1e606b30c0c11278d3c6620cd6a24
g/stable/c/8513411ec321942bd3cfed53d5bb700665c67d86 - https://git.kernel.org/stable/c/5071a1e606b30c0c11278d3c6620cd6a24724cf6
CVE ID: CVE-2025-37757 State: PUBLISHED Published: 2025-05-01T12:56:01.195Z Last Updated: 2025-11-03T19:54:31.835Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: tipc: fix memory leak in tipc_link_xmit In case the backlog transmit queue for system-importance messages is overloaded, tipc_link_xmit() returns -ENOBUFS but the skb list is not purged. This leads to memory leak and failure when a skb is allocated. This commit fixes this issue by purging the skb list before tipc_link_xmit() returns. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/84895f5ce3829d9fc030e5ec2d8729da4c0c9d08
t Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/84895f5ce3829d9fc030e5ec2d8729da4c0c9d08 - https://git.kernel.org/stable/c/d4d40e437adb376be16b3a12dd5c63f0fa768247 - https://git.kernel.org/stable/c/ed06675d3b8cd37120b447646d53f7cd3e6fcd63 - https://git.kernel.org/stable/c/24e6280cdd7f8d01fc6b9b365fb800c2fb7ea9bb - https://git.kernel.org/stable/c/09c2dcda2c551bba30710c33f6ac678ae7395389 - https://git.kernel.org/stable/c/7c5957f7905b4aede9d7a559d271438f3ca9e852 - https://git.kernel.org/stable/c/d0e02d3d27a0b4dcb13f954f537ca1dd8f282dcf - https://git.kernel.org/stable/c/a40cbfbb8f95c325430f017883da669b2aa927d4 - https://git.kernel.org/stable/c/69ae94725f4fc9e75219
/git.kernel.org/stable/c/a40cbfbb8f95c325430f017883da669b2aa927d4 - https://git.kernel.org/stable/c/69ae94725f4fc9e75219d2d69022029c5b24bc9a
CVE ID: CVE-2025-37758 State: PUBLISHED Published: 2025-05-01T12:56:02.520Z Last Updated: 2025-11-03T19:54:33.219Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ata: pata_pxa: Fix potential NULL pointer dereference in pxa_ata_probe() devm_ioremap() returns NULL on error. Currently, pxa_ata_probe() does not check for this case, which can result in a NULL pointer dereference. Add NULL check after devm_ioremap() to prevent this issue. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/a551f75401793ba8075d7f46ffc931ce5151f03f - https://git.kernel.org/stable/c/17d5e6e915fad5a261db3698c9
ernel.org/stable/c/a551f75401793ba8075d7f46ffc931ce5151f03f - https://git.kernel.org/stable/c/17d5e6e915fad5a261db3698c9c5bbe702102d7c - https://git.kernel.org/stable/c/d0d720f9282839b9db625a376c02a1426a16b0ae - https://git.kernel.org/stable/c/2dc53c7a0c1f57b082931facafa804a7ca32a9a6 - https://git.kernel.org/stable/c/5b09bf6243b0bc0ae58bd9efdf6f0de5546f8d06 - https://git.kernel.org/stable/c/ee2b0301d6bfe16b35d57947687c664ecb815775 - https://git.kernel.org/stable/c/c022287f6e599422511aa227dc6da37b58d9ceac - https://git.kernel.org/stable/c/2ba9e4c69207777bb0775c7c091800ecd69de144 - https://git.kernel.org/stable/c/ad320e408a8c95a282ab9c05cdf0c9b95e317985
CVE ID: CVE-2025-37759 State: PUBLISHED Published: 2025-05-01T12:56:03.462Z Last Updated: 2025-05-26T05:20:16.002Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ublk: fix handling recovery & reissue in ublk_abort_queue() Commit 8284066946e6 ("ublk: grab request reference when the request is handled by userspace") doesn't grab request reference in case of recovery reissue. Then the request can be requeued & re-dispatch & failed when canceling uring command. If it is one zc request, the request can be freed before io_uring returns the zc buffer back, then cause kernel panic: [ 126.773061] BUG: kernel NULL pointer dereference, ad
ore io_uring returns the zc buffer back, then cause kernel panic: [ 126.773061] BUG: kernel NULL pointer dereference, address: 00000000000000c8 [ 126.773657] #PF: supervisor read access in kernel mode [ 126.774052] #PF: error_code(0x0000) - not-present page [ 126.774455] PGD 0 P4D 0 [ 126.774698] Oops: Oops: 0000 [#1] SMP NOPTI [ 126.775034] CPU: 13 UID: 0 PID: 1612 Comm: kworker/u64:55 Not tainted 6.14.0_blk+ #182 PREEMPT(full) [ 126.775676] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-1.fc39 04/01/2014 [ 126.776275] Workqueue: iou_exit io_ring_exit_work [ 126.776651] RIP: 0010:ublk_io_release+0x14/0x130 [ublk_drv] Fixes it by always grabbing request reference for abortin
[ 126.776651] RIP: 0010:ublk_io_release+0x14/0x130 [ublk_drv] Fixes it by always grabbing request reference for aborting the request. References: - https://git.kernel.org/stable/c/caa5c8a2358604f38bf0a4afaa5eacda13763067 - https://git.kernel.org/stable/c/5d34a30efac9c9c93e150130caa940c0df6053c1 - https://git.kernel.org/stable/c/0a21d259ca4d6310fdfcc0284ebbc000e66cbf70 - https://git.kernel.org/stable/c/6ee6bd5d4fce502a5b5a2ea805e9ff16e6aa890f
CVE ID: CVE-2025-37760 State: PUBLISHED Published: 2025-05-01T13:07:02.617Z Last Updated: 2025-05-26T05:20:17.391Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: mm/vma: add give_up_on_oom option on modify/merge, use in uffd release Currently, if a VMA merge fails due to an OOM condition arising on commit merge or a failure to duplicate anon_vma's, we report this so the caller can handle it. However there are cases where the caller is only ostensibly trying a merge, and doesn't mind if it fails due to this condition. Since we do not want to introduce an implicit assumption that we only actually modify VMAs after OOM conditions
dition. Since we do not want to introduce an implicit assumption that we only actually modify VMAs after OOM conditions might arise, add a 'give up on oom' option and make an explicit contract that, should this flag be set, we absolutely will not modify any VMAs should OOM arise and just bail out. Since it'd be very unusual for a user to try to vma_modify() with this flag set but be specifying a range within a VMA which ends up being split (which can fail due to rlimit issues, not only OOM), we add a debug warning for this condition. The motivating reason for this is uffd release - syzkaller (and Pedro Falcato's VERY astute analysis) found a way in which an injected fault on allocation, trig
elease - syzkaller (and Pedro Falcato's VERY astute analysis) found a way in which an injected fault on allocation, triggering an OOM condition on commit merge, would result in uffd code becoming confused and treating an error value as if it were a VMA pointer. To avoid this, we make use of this new VMG flag to ensure that this never occurs, utilising the fact that, should we be clearing entire VMAs, we do not wish an OOM event to be reported to us. Many thanks to Pedro Falcato for his excellent analysis and Jann Horn for his insightful and intelligent analysis of the situation, both of whom were instrumental in this fix. References: - https://git.kernel.org/stable/c/b906c1ad25adce6ff35be19b
tion, both of whom were instrumental in this fix. References: - https://git.kernel.org/stable/c/b906c1ad25adce6ff35be19b65a1aa7d960fe1d7 - https://git.kernel.org/stable/c/c103a75c61648203d731e3b97a6fbeea4003cb15 - https://git.kernel.org/stable/c/41e6ddcaa0f18dda4c3fadf22533775a30d6f72f
CVE ID: CVE-2025-37761 State: PUBLISHED Published: 2025-05-01T13:07:03.389Z Last Updated: 2025-05-26T05:20:18.674Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: drm/xe: Fix an out-of-bounds shift when invalidating TLB When the size of the range invalidated is larger than rounddown_pow_of_two(ULONG_MAX), The function macro roundup_pow_of_two(length) will hit an out-of-bounds shift [1]. Use a full TLB invalidation for such cases. v2: - Use a define for the range size limit over which we use a full TLB invalidation. (Lucas) - Use a better calculation of the limit. [1]: [ 39.202421] ------------[ cut here ]------------ [ 39.202657
ion. (Lucas) - Use a better calculation of the limit. [1]: [ 39.202421] ------------[ cut here ]------------ [ 39.202657] UBSAN: shift-out-of-bounds in ./include/linux/log2.h:57:13 [ 39.202673] shift exponent 64 is too large for 64-bit type 'long unsigned int' [ 39.202688] CPU: 8 UID: 0 PID: 3129 Comm: xe_exec_system_ Tainted: G U 6.14.0+ #10 [ 39.202690] Tainted: [U]=USER [ 39.202690] Hardware name: ASUS System Product Name/PRIME B560M-A AC, BIOS 2001 02/01/2023 [ 39.202691] Call Trace: [ 39.202692] <TASK> [ 39.202695] dump_stack_lvl+0x6e/0xa0 [ 39.202699] ubsan_epilogue+0x5/0x30 [ 39.202701] __ubsan_handle_shift_out_of_bounds.cold+0x61/0xe6 [ 39.202705] xe_gt_tlb_invalidation_range.cold+0x
x5/0x30 [ 39.202701] __ubsan_handle_shift_out_of_bounds.cold+0x61/0xe6 [ 39.202705] xe_gt_tlb_invalidation_range.cold+0x1d/0x3a [xe] [ 39.202800] ? find_held_lock+0x2b/0x80 [ 39.202803] ? mark_held_locks+0x40/0x70 [ 39.202806] xe_svm_invalidate+0x459/0x700 [xe] [ 39.202897] drm_gpusvm_notifier_invalidate+0x4d/0x70 [drm_gpusvm] [ 39.202900] __mmu_notifier_release+0x1f5/0x270 [ 39.202905] exit_mmap+0x40e/0x450 [ 39.202912] __mmput+0x45/0x110 [ 39.202914] exit_mm+0xc5/0x130 [ 39.202916] do_exit+0x21c/0x500 [ 39.202918] ? lockdep_hardirqs_on_prepare+0xdb/0x190 [ 39.202920] do_group_exit+0x36/0xa0 [ 39.202922] get_signal+0x8f8/0x900 [ 39.202926] arch_do_signal_or_restart+0x35/0x100 [ 39.202930] s
roup_exit+0x36/0xa0 [ 39.202922] get_signal+0x8f8/0x900 [ 39.202926] arch_do_signal_or_restart+0x35/0x100 [ 39.202930] syscall_exit_to_user_mode+0x1fc/0x290 [ 39.202932] do_syscall_64+0xa1/0x180 [ 39.202934] ? do_user_addr_fault+0x59f/0x8a0 [ 39.202937] ? lock_release+0xd2/0x2a0 [ 39.202939] ? do_user_addr_fault+0x5a9/0x8a0 [ 39.202942] ? trace_hardirqs_off+0x4b/0xc0 [ 39.202944] ? clear_bhb_loop+0x25/0x80 [ 39.202946] ? clear_bhb_loop+0x25/0x80 [ 39.202947] ? clear_bhb_loop+0x25/0x80 [ 39.202950] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 39.202952] RIP: 0033:0x7fa945e543e1 [ 39.202961] Code: Unable to access opcode bytes at 0x7fa945e543b7. [ 39.202962] RSP: 002b:00007ffca8fb4170 EFLAGS: 00
1 [ 39.202961] Code: Unable to access opcode bytes at 0x7fa945e543b7. [ 39.202962] RSP: 002b:00007ffca8fb4170 EFLAGS: 00000293 [ 39.202963] RAX: 000000000000003d RBX: 0000000000000000 RCX: 00007fa945e543e3 [ 39.202964] RDX: 0000000000000000 RSI: 00007ffca8fb41ac RDI: 00000000ffffffff [ 39.202964] RBP: 00007ffca8fb4190 R08: 0000000000000000 R09: 00007fa945f600a0 [ 39.202965] R10: 0000000000000000 R11: 0000000000000293 R12: 0000000000000000 [ 39.202966] R13: 00007fa9460dd310 R14: 00007ffca8fb41ac R15: 0000000000000000 [ 39.202970] </TASK> [ 39.202970] ---[ end trace ]--- (cherry picked from commit b88f48f86500bc0b44b4f73ac66d500a40d320ad) References: - https://git.kernel.org/stable/c/28477f701
rry picked from commit b88f48f86500bc0b44b4f73ac66d500a40d320ad) References: - https://git.kernel.org/stable/c/28477f701b63922ff88e9fb13f5519c11cd48b86 - https://git.kernel.org/stable/c/e4715858f87b78ce58cfa03bbe140321edbbaf20 - https://git.kernel.org/stable/c/7bcfeddb36b77f9fe3b010bb0b282b7618420bba
CVE ID: CVE-2025-37762 State: PUBLISHED Published: 2025-05-01T13:07:04.385Z Last Updated: 2025-05-26T05:20:19.934Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: drm/virtio: Fix missed dmabuf unpinning in error path of prepare_fb() Correct error handling in prepare_fb() to fix leaking resources when error happens. References: - https://git.kernel.org/stable/c/fe983e925bf7062d7b975357afcbc77bb7f354d8 - https://git.kernel.org/stable/c/395cc80051f8da267b27496a4029dd931a198855
CVE ID: CVE-2025-37763 State: PUBLISHED Published: 2025-05-01T13:07:05.042Z Last Updated: 2025-05-26T05:20:21.219Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: drm/imagination: take paired job reference For paired jobs, have the fragment job take a reference on the geometry job, so that the geometry job cannot be freed until the fragment job has finished with it. The geometry job structure is accessed when the fragment job is being prepared by the GPU scheduler. Taking the reference prevents the geometry job being freed until the fragment job no longer requires it. Fixes a use after free bug detected by KASAN: [ 124.256386] B
being freed until the fragment job no longer requires it. Fixes a use after free bug detected by KASAN: [ 124.256386] BUG: KASAN: slab-use-after-free in pvr_queue_prepare_job+0x108/0x868 [powervr] [ 124.264893] Read of size 1 at addr ffff0000084cb960 by task kworker/u16:4/63 References: - https://git.kernel.org/stable/c/c90b95e12eb88d23740e5ea2c43d71675d17ac8d - https://git.kernel.org/stable/c/b5a6f97a78e2fc008fd6503b7040cb7e1120b873 - https://git.kernel.org/stable/c/4ba2abe154ef68f9612eee9d6fbfe53a1736b064
CVE ID: CVE-2025-37764 State: PUBLISHED Published: 2025-05-01T13:07:05.694Z Last Updated: 2025-05-26T05:20:22.513Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: drm/imagination: fix firmware memory leaks Free the memory used to hold the results of firmware image processing when the module is unloaded. Fix the related issue of the same memory being leaked if processing of the firmware image fails during module load. Ensure all firmware GEM objects are destroyed if firmware image processing fails. Fixes memory leaks on powervr module unload detected by Kmemleak: unreferenced object 0xffff000042e20000 (size 94208): comm "modprobe
leaks on powervr module unload detected by Kmemleak: unreferenced object 0xffff000042e20000 (size 94208): comm "modprobe", pid 470, jiffies 4295277154 hex dump (first 32 bytes): 02 ae 7f ed bf 45 84 00 3c 5b 1f ed 9f 45 45 05 .....E..<[...EE. d5 4f 5d 14 6c 00 3d 23 30 d0 3a 4a 66 0e 48 c8 .O].l.=#0.:Jf.H. backtrace (crc dd329dec): kmemleak_alloc+0x30/0x40 ___kmalloc_large_node+0x140/0x188 __kmalloc_large_node_noprof+0x2c/0x13c __kmalloc_noprof+0x48/0x4c0 pvr_fw_init+0xaa4/0x1f50 [powervr] unreferenced object 0xffff000042d20000 (size 20480): comm "modprobe", pid 470, jiffies 4295277154 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 09 00 00 00 0b 00 00 00 ................ 00 00 00 00 00
s 4295277154 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 09 00 00 00 0b 00 00 00 ................ 00 00 00 00 00 00 00 00 07 00 00 00 08 00 00 00 ................ backtrace (crc 395b02e3): kmemleak_alloc+0x30/0x40 ___kmalloc_large_node+0x140/0x188 __kmalloc_large_node_noprof+0x2c/0x13c __kmalloc_noprof+0x48/0x4c0 pvr_fw_init+0xb0c/0x1f50 [powervr] References: - https://git.kernel.org/stable/c/490c30fd554597e78f66650044877e7defb5f83c - https://git.kernel.org/stable/c/891c12ba855ccb34c06a2e5da75c644683087036 - https://git.kernel.org/stable/c/a5b230e7f3a55bd8bd8d012eec75a4b7baa671d5
CVE ID: CVE-2025-37765 State: PUBLISHED Published: 2025-05-01T13:07:06.498Z Last Updated: 2025-11-03T19:54:35.995Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: drm/nouveau: prime: fix ttm_bo_delayed_delete oops Fix an oops in ttm_bo_delayed_delete which results from dererencing a dangling pointer: Oops: general protection fault, probably for non-canonical address 0x6b6b6b6b6b6b6b7b: 0000 [#1] PREEMPT SMP CPU: 4 UID: 0 PID: 1082 Comm: kworker/u65:2 Not tainted 6.14.0-rc4-00267-g505460b44513-dirty #216 Hardware name: LENOVO 82N6/LNVNB161216, BIOS GKCN65WW 01/16/2024 Workqueue: ttm ttm_bo_delayed_delete [ttm] RIP: 0010:dma_resv_
e name: LENOVO 82N6/LNVNB161216, BIOS GKCN65WW 01/16/2024 Workqueue: ttm ttm_bo_delayed_delete [ttm] RIP: 0010:dma_resv_iter_first_unlocked+0x55/0x290 Code: 31 f6 48 c7 c7 00 2b fa aa e8 97 bd 52 ff e8 a2 c1 53 00 5a 85 c0 74 48 e9 88 01 00 00 4c 89 63 20 4d 85 e4 0f 84 30 01 00 00 <41> 8b 44 24 10 c6 43 2c 01 48 89 df 89 43 28 e8 97 fd ff ff 4c 8b RSP: 0018:ffffbf9383473d60 EFLAGS: 00010202 RAX: 0000000000000001 RBX: ffffbf9383473d88 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffffbf9383473d78 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: 6b6b6b6b6b6b6b6b R13: ffffa003bbf78580 R14: ffffa003a67280
000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: 6b6b6b6b6b6b6b6b R13: ffffa003bbf78580 R14: ffffa003a6728040 R15: 00000000000383cc FS: 0000000000000000(0000) GS:ffffa00991c00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000758348024dd0 CR3: 000000012c259000 CR4: 0000000000f50ef0 PKRU: 55555554 Call Trace: <TASK> ? __die_body.cold+0x19/0x26 ? die_addr+0x3d/0x70 ? exc_general_protection+0x159/0x460 ? asm_exc_general_protection+0x27/0x30 ? dma_resv_iter_first_unlocked+0x55/0x290 dma_resv_wait_timeout+0x56/0x100 ttm_bo_delayed_delete+0x69/0xb0 [ttm] process_one_work+0x217/0x5c0 worker_thread+0x1c8/0x3d0 ? apply_wqattrs_cleanup.part.0+0xc0/0
ayed_delete+0x69/0xb0 [ttm] process_one_work+0x217/0x5c0 worker_thread+0x1c8/0x3d0 ? apply_wqattrs_cleanup.part.0+0xc0/0xc0 kthread+0x10b/0x240 ? kthreads_online_cpu+0x140/0x140 ret_from_fork+0x40/0x70 ? kthreads_online_cpu+0x140/0x140 ret_from_fork_asm+0x11/0x20 </TASK> The cause of this is: - drm_prime_gem_destroy calls dma_buf_put(dma_buf) which releases the reference to the shared dma_buf. The reference count is 0, so the dma_buf is destroyed, which in turn decrements the corresponding amdgpu_bo reference count to 0, and the amdgpu_bo is destroyed - calling drm_gem_object_release then dma_resv_fini (which destroys the reservation object), then finally freeing the amdgpu_bo. - nouveau_bo
ct_release then dma_resv_fini (which destroys the reservation object), then finally freeing the amdgpu_bo. - nouveau_bo obj->bo.base.resv is now a dangling pointer to the memory formerly allocated to the amdgpu_bo. - nouveau_gem_object_del calls ttm_bo_put(&nvbo->bo) which calls ttm_bo_release, which schedules ttm_bo_delayed_delete. - ttm_bo_delayed_delete runs and dereferences the dangling resv pointer, resulting in a general protection fault. Fix this by moving the drm_prime_gem_destroy call from nouveau_gem_object_del to nouveau_bo_del_ttm. This ensures that it will be run after ttm_bo_delayed_delete. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/
un after ttm_bo_delayed_delete. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/706868a1a1072cffd8bd63f7e161d79141099849 - https://git.kernel.org/stable/c/47761deabb69a5df0c2c4ec400d80bb3e072bd2e - https://git.kernel.org/stable/c/ada78110b2d3ec88b398a49703bd336d4cee7a08 - https://git.kernel.org/stable/c/12b038d521c75e3521522503becf3bc162628469 - https://git.kernel.org/stable/c/31e94c7989572f96926673614a3b958915a13ca9 - https://git.kernel.org/stable/c/6e2c805996a49998d31ac522beb1534ca417e761 - https://git.kernel.org/stable/c/6b95947ee780f4e1fb26413a1437d05bcb99712b - https://git.kernel.org/stable/c/8ec0fbb28d049273bfd4f1e7a5ae4c74884beed3
CVE ID: CVE-2025-37766 State: PUBLISHED Published: 2025-05-01T13:07:07.168Z Last Updated: 2025-11-03T19:54:38.771Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: drm/amd/pm: Prevent division by zero The user can set any speed value. If speed is greater than UINT_MAX/8, division by zero is possible. Found by Linux Verification Center (linuxtesting.org) with SVACE. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/6b9f9b998b107c7539f148a013d789ddb860c3b9 - https://git.kernel.org/stable/c/ce773dd844ee19a605af27f11470887e0f2044a9 - https://git.kernel.org/stable/c/80814924260cea431a8fc6