Kushalkhemka/embedding-cve-nvd-dataset huggingface dataset:
it.kernel.org/stable/c/ce773dd844ee19a605af27f11470887e0f2044a9 - https://git.kernel.org/stable/c/80814924260cea431a8fc6137d11cc8cb331a10c - https://git.kernel.org/stable/c/ffd688804425579a472fbd2525bedb58b1d28bd9 - https://git.kernel.org/stable/c/068091b796480819bf70b159f17e222ad8bea900 - https://git.kernel.org/stable/c/42f7b5d12c28b2a601a98d10a80c6db1fe1a2900 - https://git.kernel.org/stable/c/affd2241927a1e74c0aecd50c2d920dc4213c56d - https://git.kernel.org/stable/c/4e3d9508c056d7e0a56b58d5c81253e2a0d22b6c
CVE ID: CVE-2025-37767 State: PUBLISHED Published: 2025-05-01T13:07:07.861Z Last Updated: 2025-11-03T19:54:40.168Z 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/f2904fa2b9da943db6bef7c0f8b3fb4fc14acbc4 - https://git.kernel.org/stable/c/8f7b5987e21e003cafac28f0e4d323e6496f83ba - https://git.kernel.org/stable/c/c3ff73e3bddf1a6c30d7ef
it.kernel.org/stable/c/8f7b5987e21e003cafac28f0e4d323e6496f83ba - https://git.kernel.org/stable/c/c3ff73e3bddf1a6c30d7effe4018d12ba0cadd2e - https://git.kernel.org/stable/c/fb803d4bb9ea0a61c21c4987505e4d4ae18f9fdc - https://git.kernel.org/stable/c/327107bd7f052f4ee2d0c966c7ae879822f1814f - https://git.kernel.org/stable/c/f23e9116ebb71b63fe9cec0dcac792aa9af30b0c
CVE ID: CVE-2025-37768 State: PUBLISHED Published: 2025-05-01T13:07:08.680Z Last Updated: 2025-11-03T19:54:42.962Z 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/3cdd02cb70682d7d205ca6dc02a4d1eb76758d24 - https://git.kernel.org/stable/c/be0fffc4152aac4f0291ed2d793f3cfee788449d - https://git.kernel.org/stable/c/5fc4fb54f6f064c25bfbbf
it.kernel.org/stable/c/be0fffc4152aac4f0291ed2d793f3cfee788449d - https://git.kernel.org/stable/c/5fc4fb54f6f064c25bfbbfd443aa861d3422dd4c - https://git.kernel.org/stable/c/b0742a709be7979c7a480772046a1f36d09dab00 - https://git.kernel.org/stable/c/8e9c4f8d197d5709c75effa5d58e80b4fa01981a - https://git.kernel.org/stable/c/9e4f1e21fe7b93a8ef57db433071266c2590e260 - https://git.kernel.org/stable/c/7c246a05df51c52fe0852ce56ba10c41e6ed1f39
CVE ID: CVE-2025-37769 State: PUBLISHED Published: 2025-05-01T13:07:09.417Z Last Updated: 2025-11-03T19:54:44.373Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: drm/amd/pm/smu11: 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. (cherry picked from commit da7dc714a8f8e1c9fc33c57cd63583779a3bef71) Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/de6f8e0534cfabc528c969d453150ca90b24fb01 - https://git.kernel.org/stable/c/de2cba068c9c648503973b
it.kernel.org/stable/c/de6f8e0534cfabc528c969d453150ca90b24fb01 - https://git.kernel.org/stable/c/de2cba068c9c648503973b57696d035cfe58a9f6 - https://git.kernel.org/stable/c/63a150400194592206817124268ff6f43947e8c9 - https://git.kernel.org/stable/c/fc9d55377353321e78f9e108d15f72a17e8c6ee2 - https://git.kernel.org/stable/c/7ba88b5cccc1a99c1afb96e31e7eedac9907704c
CVE ID: CVE-2025-37770 State: PUBLISHED Published: 2025-05-01T13:07:10.353Z Last Updated: 2025-11-03T19:54:47.176Z 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/e109528bbf460e50074c156253d9080d223ee37f - https://git.kernel.org/stable/c/0c02fcbe4a1393a3c02da6ae35e72493cfdb2155 - https://git.kernel.org/stable/c/836a189fb422e7efb81c51
it.kernel.org/stable/c/0c02fcbe4a1393a3c02da6ae35e72493cfdb2155 - https://git.kernel.org/stable/c/836a189fb422e7efb81c51d5160e47ec7bc11500 - https://git.kernel.org/stable/c/587de3ca7875c06fe3c3aa4073a85c4eff46591f - https://git.kernel.org/stable/c/bd4d90adbca1862d03e581e10e74ab73ec75e61b - https://git.kernel.org/stable/c/05de66de280ea1bd0459c994bfd2dd332cfbc2a9 - https://git.kernel.org/stable/c/4b8c3c0d17c07f301011e2908fecd2ebdcfe3d1c
CVE ID: CVE-2025-37771 State: PUBLISHED Published: 2025-05-01T13:07:11.517Z Last Updated: 2025-11-03T19:54:48.572Z 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/b7c41df4913789ebfe73cc1e17c6401d4c5eab69 - https://git.kernel.org/stable/c/402964994e8ece29702383b234fabcf04791ff95 - https://git.kernel.org/stable/c/5096174074114f83c700a2
it.kernel.org/stable/c/402964994e8ece29702383b234fabcf04791ff95 - https://git.kernel.org/stable/c/5096174074114f83c700a27869c54362cbb10f3e - https://git.kernel.org/stable/c/6413fed016208171592c88b5df002af8a1387e24 - https://git.kernel.org/stable/c/baa54adb5e0599299b8f088efb5544d876a3eb62 - https://git.kernel.org/stable/c/7d641c2b83275d3b0424127b2e0d2d0f7dd82aef
CVE ID: CVE-2025-37772 State: PUBLISHED Published: 2025-05-01T13:07:12.168Z Last Updated: 2025-11-03T19:54:49.961Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: RDMA/cma: Fix workqueue crash in cma_netevent_work_handler struct rdma_cm_id has member "struct work_struct net_work" that is reused for enqueuing cma_netevent_work_handler()s onto cma_wq. Below crash[1] can occur if more than one call to cma_netevent_callback() occurs in quick succession, which further enqueues cma_netevent_work_handler()s for the same rdma_cm_id, overwriting any previously queued work-item(s) that was just scheduled to run i.e. there is no guarantee
me rdma_cm_id, overwriting any previously queued work-item(s) that was just scheduled to run i.e. there is no guarantee the queued work item may run between two successive calls to cma_netevent_callback() and the 2nd INIT_WORK would overwrite the 1st work item (for the same rdma_cm_id), despite grabbing id_table_lock during enqueue. Also drgn analysis [2] indicates the work item was likely overwritten. Fix this by moving the INIT_WORK() to __rdma_create_id(), so that it doesn't race with any existing queue_work() or its worker thread. [1] Trimmed crash stack: ============================================= BUG: kernel NULL pointer dereference, address: 0000000000000008 kworker/u256:6 ... 6.12.
=============================== BUG: kernel NULL pointer dereference, address: 0000000000000008 kworker/u256:6 ... 6.12.0-0... Workqueue: cma_netevent_work_handler [rdma_cm] (rdma_cm) RIP: 0010:process_one_work+0xba/0x31a Call Trace: worker_thread+0x266/0x3a0 kthread+0xcf/0x100 ret_from_fork+0x31/0x50 ret_from_fork_asm+0x1a/0x30 ============================================= [2] drgn crash analysis: >>> trace = prog.crashed_thread().stack_trace() >>> trace (0) crash_setup_regs (./arch/x86/include/asm/kexec.h:111:15) (1) __crash_kexec (kernel/crash_core.c:122:4) (2) panic (kernel/panic.c:399:3) (3) oops_end (arch/x86/kernel/dumpstack.c:382:3) ... (8) process_one_work (kernel/workqueue.c:3168:2
rnel/panic.c:399:3) (3) oops_end (arch/x86/kernel/dumpstack.c:382:3) ... (8) process_one_work (kernel/workqueue.c:3168:2) (9) process_scheduled_works (kernel/workqueue.c:3310:3) (10) worker_thread (kernel/workqueue.c:3391:4) (11) kthread (kernel/kthread.c:389:9) Line workqueue.c:3168 for this kernel version is in process_one_work(): 3168 strscpy(worker->desc, pwq->wq->name, WORKER_DESC_LEN); >>> trace[8]["work"] *(struct work_struct *)0xffff92577d0a21d8 = { .data = (atomic_long_t){ .counter = (s64)536870912, <=== Note }, .entry = (struct list_head){ .next = (struct list_head *)0xffff924d075924c0, .prev = (struct list_head *)0xffff924d075924c0, }, .func = (work_func_t)cma_netevent_work_handle
d *)0xffff924d075924c0, .prev = (struct list_head *)0xffff924d075924c0, }, .func = (work_func_t)cma_netevent_work_handler+0x0 = 0xffffffffc2cec280, } Suspicion is that pwq is NULL: >>> trace[8]["pwq"] (struct pool_workqueue *)<absent> In process_one_work(), pwq is assigned from: struct pool_workqueue *pwq = get_work_pwq(work); and get_work_pwq() is: static struct pool_workqueue *get_work_pwq(struct work_struct *work) { unsigned long data = atomic_long_read(&work->data); if (data & WORK_STRUCT_PWQ) return work_struct_pwq(data); else return NULL; } WORK_STRUCT_PWQ is 0x4: >>> print(repr(prog['WORK_STRUCT_PWQ'])) Object(prog, 'enum work_flags', value=4) But work->data is 536870912 which is 0x20
print(repr(prog['WORK_STRUCT_PWQ'])) Object(prog, 'enum work_flags', value=4) But work->data is 536870912 which is 0x20000000. So, get_work_pwq() returns NULL and we crash in process_one_work(): 3168 strscpy(worker->desc, pwq->wq->name, WORKER_DESC_LEN); ============================================= Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/51003b2c872c63d28bcf5fbcc52cf7b05615f7b7 - https://git.kernel.org/stable/c/c2b169fc7a12665d8a675c1ff14bca1b9c63fb9a - https://git.kernel.org/stable/c/d23fd7a539ac078df119707110686a5b226ee3bb - https://git.kernel.org/stable/c/b172a4a0de254f1fcce7591833a9a63547c2f447 - https://git.kernel.org/stable/c/4
b226ee3bb - https://git.kernel.org/stable/c/b172a4a0de254f1fcce7591833a9a63547c2f447 - https://git.kernel.org/stable/c/45f5dcdd049719fb999393b30679605f16ebce14
CVE ID: CVE-2025-37773 State: PUBLISHED Published: 2025-05-01T13:07:12.944Z Last Updated: 2025-11-03T19:54:52.701Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: virtiofs: add filesystem context source name check In certain scenarios, for example, during fuzz testing, the source name may be NULL, which could lead to a kernel panic. Therefore, an extra check for the source name should be added. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/b84f13fdad10a543e2e65bab7e81b3f0bceabd67 - https://git.kernel.org/stable/c/9d6dcf18a1b49990295ac8a05fd9bdfd27ccbf88 - https://git.kernel.org/
bab7e81b3f0bceabd67 - https://git.kernel.org/stable/c/9d6dcf18a1b49990295ac8a05fd9bdfd27ccbf88 - https://git.kernel.org/stable/c/5ee09cdaf3414f6c92960714af46d3d90eede2f3 - https://git.kernel.org/stable/c/599d1e2a6aecc44acf22fe7ea6f5e84a7e526abe - https://git.kernel.org/stable/c/f6ec52710dc5e156b774cbef5d0f5c99b1c53a80 - https://git.kernel.org/stable/c/c3e31d613951c299487844c4d1686a933e8ee291 - https://git.kernel.org/stable/c/a648d80f8d9b208beee03a2d9aa690cfacf1d41e - https://git.kernel.org/stable/c/a94fd938df2b1628da66b498aa0eeb89593bc7a2
CVE ID: CVE-2025-37774 State: PUBLISHED Published: 2025-05-01T13:07:13.593Z Last Updated: 2025-05-26T05:20:36.102Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: slab: ensure slab->obj_exts is clear in a newly allocated slab page ktest recently reported crashes while running several buffered io tests with __alloc_tagging_slab_alloc_hook() at the top of the crash call stack. The signature indicates an invalid address dereference with low bits of slab->obj_exts being set. The bits were outside of the range used by page_memcg_data_flags and objext_flags and hence were not masked out by slab_obj_exts() when obtaining the pointer st
by page_memcg_data_flags and objext_flags and hence were not masked out by slab_obj_exts() when obtaining the pointer stored in slab->obj_exts. The typical crash log looks like this: 00510 Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010 00510 Mem abort info: 00510 ESR = 0x0000000096000045 00510 EC = 0x25: DABT (current EL), IL = 32 bits 00510 SET = 0, FnV = 0 00510 EA = 0, S1PTW = 0 00510 FSC = 0x05: level 1 translation fault 00510 Data abort info: 00510 ISV = 0, ISS = 0x00000045, ISS2 = 0x00000000 00510 CM = 0, WnR = 1, TnD = 0, TagAccess = 0 00510 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 00510 user pgtable: 4k pages, 39-bit VAs, pgdp=0000000104175000
ss = 0 00510 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 00510 user pgtable: 4k pages, 39-bit VAs, pgdp=0000000104175000 00510 [0000000000000010] pgd=0000000000000000, p4d=0000000000000000, pud=0000000000000000 00510 Internal error: Oops: 0000000096000045 [#1] SMP 00510 Modules linked in: 00510 CPU: 10 UID: 0 PID: 7692 Comm: cat Not tainted 6.15.0-rc1-ktest-g189e17946605 #19327 NONE 00510 Hardware name: linux,dummy-virt (DT) 00510 pstate: 20001005 (nzCv daif -PAN -UAO -TCO -DIT +SSBS BTYPE=--) 00510 pc : __alloc_tagging_slab_alloc_hook+0xe0/0x190 00510 lr : __kmalloc_noprof+0x150/0x310 00510 sp : ffffff80c87df6c0 00510 x29: ffffff80c87df6c0 x28: 000000000013d1ff x27: 000000000013d200 00510 x2
0x150/0x310 00510 sp : ffffff80c87df6c0 00510 x29: ffffff80c87df6c0 x28: 000000000013d1ff x27: 000000000013d200 00510 x26: ffffff80c87df9e0 x25: 0000000000000000 x24: 0000000000000001 00510 x23: ffffffc08041953c x22: 000000000000004c x21: ffffff80c0002180 00510 x20: fffffffec3120840 x19: ffffff80c4821000 x18: 0000000000000000 00510 x17: fffffffec3d02f00 x16: fffffffec3d02e00 x15: fffffffec3d00700 00510 x14: fffffffec3d00600 x13: 0000000000000200 x12: 0000000000000006 00510 x11: ffffffc080bb86c0 x10: 0000000000000000 x9 : ffffffc080201e58 00510 x8 : ffffff80c4821060 x7 : 0000000000000000 x6 : 0000000055555556 00510 x5 : 0000000000000001 x4 : 0000000000000010 x3 : 0000000000000060 00510 x2 : 0
0000000000000 x6 : 0000000055555556 00510 x5 : 0000000000000001 x4 : 0000000000000010 x3 : 0000000000000060 00510 x2 : 0000000000000000 x1 : ffffffc080f50cf8 x0 : ffffff80d801d000 00510 Call trace: 00510 __alloc_tagging_slab_alloc_hook+0xe0/0x190 (P) 00510 __kmalloc_noprof+0x150/0x310 00510 __bch2_folio_create+0x5c/0xf8 00510 bch2_folio_create+0x2c/0x40 00510 bch2_readahead+0xc0/0x460 00510 read_pages+0x7c/0x230 00510 page_cache_ra_order+0x244/0x3a8 00510 page_cache_async_ra+0x124/0x170 00510 filemap_readahead.isra.0+0x58/0xa0 00510 filemap_get_pages+0x454/0x7b0 00510 filemap_read+0xdc/0x418 00510 bch2_read_iter+0x100/0x1b0 00510 vfs_read+0x214/0x300 00510 ksys_read+0x6c/0x108 00510 __arm64_
ap_read+0xdc/0x418 00510 bch2_read_iter+0x100/0x1b0 00510 vfs_read+0x214/0x300 00510 ksys_read+0x6c/0x108 00510 __arm64_sys_read+0x20/0x30 00510 invoke_syscall.constprop.0+0x54/0xe8 00510 do_el0_svc+0x44/0xc8 00510 el0_svc+0x18/0x58 00510 el0t_64_sync_handler+0x104/0x130 00510 el0t_64_sync+0x154/0x158 00510 Code: d5384100 f9401c01 b9401aa3 b40002e1 (f8227881) 00510 ---[ end trace 0000000000000000 ]--- 00510 Kernel panic - not syncing: Oops: Fatal exception 00510 SMP: stopping secondary CPUs 00510 Kernel Offset: disabled 00510 CPU features: 0x0000,000000e0,00000410,8240500b 00510 Memory Limit: none Investigation indicates that these bits are already set when we allocate slab page and are not
00510 Memory Limit: none Investigation indicates that these bits are already set when we allocate slab page and are not zeroed out after allocation. We are not yet sure why these crashes start happening only recently but regardless of the reason, not initializing a field that gets used later is wrong. Fix it by initializing slab->obj_exts during slab page allocation. References: - https://git.kernel.org/stable/c/8baa747193591410a853bac9c3710142dfa4937b - https://git.kernel.org/stable/c/28bef6622a1a874fe63aceeb0c684fab75afb3ae - https://git.kernel.org/stable/c/d2f5819b6ed357c0c350c0616b6b9f38be59adf6
CVE ID: CVE-2025-37775 State: PUBLISHED Published: 2025-05-01T13:07:14.356Z Last Updated: 2025-11-03T19:54:54.085Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix the warning from __kernel_write_iter [ 2110.972290] ------------[ cut here ]------------ [ 2110.972301] WARNING: CPU: 3 PID: 735 at fs/read_write.c:599 __kernel_write_iter+0x21b/0x280 This patch doesn't allow writing to directory. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/44079e544c9f6e3e9fb43a16ddf8b08cf686d657 - https://git.kernel.org/stable/c/b7ce8db490286c2e009758fa1416d66aeb333614 - https://git.kern
3e9fb43a16ddf8b08cf686d657 - https://git.kernel.org/stable/c/b7ce8db490286c2e009758fa1416d66aeb333614 - https://git.kernel.org/stable/c/2a879da5c34a1e5d971e815d5b30f27eb6d69efc - https://git.kernel.org/stable/c/1ed343481ba6911178bc5ca7a51be319eafcc747 - https://git.kernel.org/stable/c/b37f2f332b40ad1c27f18682a495850f2f04db0a
CVE ID: CVE-2025-37776 State: PUBLISHED Published: 2025-05-01T13:07:14.998Z Last Updated: 2025-05-26T05:20:38.759Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix use-after-free in smb_break_all_levII_oplock() There is a room in smb_break_all_levII_oplock that can cause racy issues when unlocking in the middle of the loop. This patch use read lock to protect whole loop. References: - https://git.kernel.org/stable/c/296cb5457cc6f4a754c4ae29855f8a253d52bcc6 - https://git.kernel.org/stable/c/d54ab1520d43e95f9b2e22d7a05fc9614192e5a5 - https://git.kernel.org/stable/c/d73686367ad68534257cd88a36ca3c52cb8b81d8 - https://git.k
3e95f9b2e22d7a05fc9614192e5a5 - https://git.kernel.org/stable/c/d73686367ad68534257cd88a36ca3c52cb8b81d8 - https://git.kernel.org/stable/c/18b4fac5ef17f77fed9417d22210ceafd6525fc7
CVE ID: CVE-2025-37777 State: PUBLISHED Published: 2025-05-01T13:07:15.741Z Last Updated: 2025-08-09T14:20:09.676Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix use-after-free in __smb2_lease_break_noti() Move tcp_transport free to ksmbd_conn_free. If ksmbd connection is referenced when ksmbd server thread terminates, It will not be freed, but conn->tcp_transport is freed. __smb2_lease_break_noti can be performed asynchronously when the connection is disconnected. __smb2_lease_break_noti calls ksmbd_conn_write, which can cause use-after-free when conn->ksmbd_transport is already freed. References: - https://git.kern
d_conn_write, which can cause use-after-free when conn->ksmbd_transport is already freed. References: - https://git.kernel.org/stable/c/1da8bd9a10ecd718692732294d15fd801c0eabb5 - https://git.kernel.org/stable/c/1aec4d14cf81b7b3e7b69eb1cfa94144eed7138e - https://git.kernel.org/stable/c/e59796fc80603bcd8569d4d2e10b213c1918edb4 - https://git.kernel.org/stable/c/21a4e47578d44c6b37c4fc4aba8ed7cc8dbb13de
CVE ID: CVE-2025-37778 State: PUBLISHED Published: 2025-05-01T13:07:16.472Z Last Updated: 2025-11-03T19:54:55.466Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ksmbd: Fix dangling pointer in krb_authenticate krb_authenticate frees sess->user and does not set the pointer to NULL. It calls ksmbd_krb5_authenticate to reinitialise sess->user but that function may return without doing so. If that happens then smb2_sess_setup, which calls krb_authenticate, will be accessing free'd memory when it later uses sess->user. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/d5b554bc8d554ed6dd
ser. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/d5b554bc8d554ed6ddf443d3db2fad9f665cec10 - https://git.kernel.org/stable/c/1db2451de23e98bc864c6a6e52aa0d82c91cb325 - https://git.kernel.org/stable/c/6e30c0e10210c714f3d4453dc258d4abcc70364e - https://git.kernel.org/stable/c/e83e39a5f6a01a81411a4558a59a10f87aa88dd6 - https://git.kernel.org/stable/c/1e440d5b25b7efccb3defe542a73c51005799a5f
CVE ID: CVE-2025-37779 State: PUBLISHED Published: 2025-05-01T13:07:17.106Z Last Updated: 2025-05-26T05:20:42.641Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: lib/iov_iter: fix to increase non slab folio refcount When testing EROFS file-backed mount over v9fs on qemu, I encountered a folio UAF issue. The page sanity check reports the following call trace. The root cause is that pages in bvec are coalesced across a folio bounary. The refcount of all non-slab folios should be increased to ensure p9_releas_pages can put them correctly. BUG: Bad page state in process md5sum pfn:18300 page: refcount:0 mapcount:0 mapping:00000000d
es can put them correctly. BUG: Bad page state in process md5sum pfn:18300 page: refcount:0 mapcount:0 mapping:00000000d5ad8e4e index:0x60 pfn:0x18300 head: order:0 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0 aops:z_erofs_aops ino:30b0f dentry name(?):"GoogleExtServicesCn.apk" flags: 0x100000000000041(locked|head|node=0|zone=1) raw: 0100000000000041 dead000000000100 dead000000000122 ffff888014b13bd0 raw: 0000000000000060 0000000000000020 00000000ffffffff 0000000000000000 head: 0100000000000041 dead000000000100 dead000000000122 ffff888014b13bd0 head: 0000000000000060 0000000000000020 00000000ffffffff 0000000000000000 head: 0100000000000000 0000000000000000 ffffffffffffffff 00000
000060 0000000000000020 00000000ffffffff 0000000000000000 head: 0100000000000000 0000000000000000 ffffffffffffffff 0000000000000000 head: 0000000000000010 0000000000000000 00000000ffffffff 0000000000000000 page dumped because: PAGE_FLAGS_CHECK_AT_FREE flag(s) set Call Trace: dump_stack_lvl+0x53/0x70 bad_page+0xd4/0x220 __free_pages_ok+0x76d/0xf30 __folio_put+0x230/0x320 p9_release_pages+0x179/0x1f0 p9_virtio_zc_request+0xa2a/0x1230 p9_client_zc_rpc.constprop.0+0x247/0x700 p9_client_read_once+0x34d/0x810 p9_client_read+0xf3/0x150 v9fs_issue_read+0x111/0x360 netfs_unbuffered_read_iter_locked+0x927/0x1390 netfs_unbuffered_read_iter+0xa2/0xe0 vfs_iocb_iter_read+0x2c7/0x460 erofs_fileio_rq_submit
read_iter_locked+0x927/0x1390 netfs_unbuffered_read_iter+0xa2/0xe0 vfs_iocb_iter_read+0x2c7/0x460 erofs_fileio_rq_submit+0x46b/0x5b0 z_erofs_runqueue+0x1203/0x21e0 z_erofs_readahead+0x579/0x8b0 read_pages+0x19f/0xa70 page_cache_ra_order+0x4ad/0xb80 filemap_readahead.isra.0+0xe7/0x150 filemap_get_pages+0x7aa/0x1890 filemap_read+0x320/0xc80 vfs_read+0x6c6/0xa30 ksys_read+0xf9/0x1c0 do_syscall_64+0x9e/0x1a0 entry_SYSCALL_64_after_hwframe+0x71/0x79 References: - https://git.kernel.org/stable/c/d833f21162c4d536d729628f8cf1ee8d4110f2b7 - https://git.kernel.org/stable/c/770c8d55c42868239c748a3ebc57c9e37755f842
CVE ID: CVE-2025-37780 State: PUBLISHED Published: 2025-05-01T13:07:17.748Z Last Updated: 2025-11-03T19:54:58.221Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: isofs: Prevent the use of too small fid syzbot reported a slab-out-of-bounds Read in isofs_fh_to_parent. [1] The handle_bytes value passed in by the reproducing program is equal to 12. In handle_to_path(), only 12 bytes of memory are allocated for the structure file_handle->f_handle member, which causes an out-of-bounds access when accessing the member parent_block of the structure isofs_fid in isofs, because accessing parent_block requires at least 16 bytes of f_handl