Kushalkhemka/embedding-cve-nvd-dataset huggingface dataset:
2fs.h:3053 [inline] f2fs_data_blkaddr fs/f2fs/f2fs.h:3058 [inline] f2fs_get_dnode_of_data+0x1a09/0x1c40 fs/f2fs/node.c:855 f2fs_reserve_block+0x53/0x310 fs/f2fs/data.c:1195 prepare_write_begin fs/f2fs/data.c:3395 [inline] f2fs_write_begin+0xf39/0x2190 fs/f2fs/data.c:3594 generic_perform_write+0x2c7/0x910 mm/filemap.c:4112 f2fs_buffered_write_iter fs/f2fs/file.c:4988 [inline] f2fs_file_write_iter+0x1ec8/0x2410 fs/f2fs/file.c:5216 new_sync_write fs/read_write.c:593 [inline] vfs_write+0x546/0xa90 fs/read_write.c:686 ksys_write+0x149/0x250 fs/read_write.c:738 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xf3/0x3d0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwfr
h/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xf3/0x3d0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f The root cause is in the corrupted image, there is a dnode has the same node id w/ its inode, so during f2fs_get_dnode_of_data(), it tries to access block address in dnode at offset 934, however it parses the dnode as inode node, so that get_dnode_addr() returns 360, then it tries to access page address from 360 + 934 * 4 = 4096 w/ 4 bytes. To fix this issue, let's add sanity check for node id of all direct nodes during f2fs_get_dnode_of_data(). Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/ee4d13f5407cbdf1216
(). Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/ee4d13f5407cbdf1216cc258f45492075713889a - https://git.kernel.org/stable/c/a650654365c57407413e9b1f6ff4d539bf2e99ca - https://git.kernel.org/stable/c/6b7784ea07e6aa044f74b39d6b5af5e28746fc81 - https://git.kernel.org/stable/c/901f62efd6e855f93d8b1175540f29f4dc45ba55 - https://git.kernel.org/stable/c/92ef491b506a0f4dd971a3a76f86f2d8f5370180 - https://git.kernel.org/stable/c/888aa660144bcb6ec07839da756ee46bfcf7fc53 - https://git.kernel.org/stable/c/f1d5093d9fe9f3c74c123741c88666cc853b79c5 - https://git.kernel.org/stable/c/77de19b6867f2740cdcb6c9c7e50d522b47847a4
CVE ID: CVE-2025-38678 State: PUBLISHED Published: 2025-09-03T13:01:15.799Z Last Updated: 2025-11-24T09:49:52.799Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: reject duplicate device on updates A chain/flowtable update with duplicated devices in the same batch is possible. Unfortunately, netdev event path only removes the first device that is found, leaving unregistered the hook of the duplicated device. Check if a duplicated device exists in the transaction batch, bail out with EEXIST in such case. WARNING is hit when unregistering the hook: [49042.221275] WARNING: CPU: 4 PID: 8425 at net/netfilter/cor
in such case. WARNING is hit when unregistering the hook: [49042.221275] WARNING: CPU: 4 PID: 8425 at net/netfilter/core.c:340 nf_hook_entry_head+0xaa/0x150 [49042.221375] CPU: 4 UID: 0 PID: 8425 Comm: nft Tainted: G S 6.16.0+ #170 PREEMPT(full) [...] [49042.221382] RIP: 0010:nf_hook_entry_head+0xaa/0x150 References: - https://git.kernel.org/stable/c/3f358a66a04513311668ea4b40f5064e253d8386 - https://git.kernel.org/stable/c/cf23d531a9d496863aa4c5a0e2f71f0a23f3df3c - https://git.kernel.org/stable/c/d7615bde541f16517d6790412da6ec46fa8a4c1f - https://git.kernel.org/stable/c/cf5fb87fcdaaaafec55dcc0dc5a9e15ead343973
CVE ID: CVE-2025-38679 State: PUBLISHED Published: 2025-09-04T15:32:35.131Z Last Updated: 2025-11-03T17:41:03.792Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: media: venus: Fix OOB read due to missing payload bound check Currently, The event_seq_changed() handler processes a variable number of properties sent by the firmware. The number of properties is indicated by the firmware and used to iterate over the payload. However, the payload size is not being validated against the actual message length. This can lead to out-of-bounds memory access if the firmware provides a property count that exceeds the data available in the pa
lead to out-of-bounds memory access if the firmware provides a property count that exceeds the data available in the payload. Such a condition can result in kernel crashes or potential information leaks if memory beyond the buffer is accessed. Fix this by properly validating the remaining size of the payload before each property access and updating bounds accordingly as properties are parsed. This ensures that property parsing is safely bounded within the received message buffer and protects against malformed or malicious firmware behavior. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/a3eef5847603cd8a4110587907988c3f93c9605a - https://git.
Program Container: References: - https://git.kernel.org/stable/c/a3eef5847603cd8a4110587907988c3f93c9605a - https://git.kernel.org/stable/c/8f274e2b05fdae7a53cee83979202b5ecb49035c - https://git.kernel.org/stable/c/6f08bfb5805637419902f3d70069fe17a404545b - https://git.kernel.org/stable/c/c956c3758510b448b3d4d10d1da8230e8c9bf668 - https://git.kernel.org/stable/c/bed4921055dd7bb4d2eea2729852ae18cf97a2c6 - https://git.kernel.org/stable/c/06d6770ff0d8cc8dfd392329a8cc03e2a83e7289
CVE ID: CVE-2025-38680 State: PUBLISHED Published: 2025-09-04T15:32:35.963Z Last Updated: 2025-11-03T17:41:05.708Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: media: uvcvideo: Fix 1-byte out-of-bounds read in uvc_parse_format() The buffer length check before calling uvc_parse_format() only ensured that the buffer has at least 3 bytes (buflen > 2), buf the function accesses buffer[3], requiring at least 4 bytes. This can lead to an out-of-bounds read if the buffer has exactly 3 bytes. Fix it by checking that the buffer has at least 4 bytes in uvc_parse_format(). Additional Analyst Notes: - CVE Program Container: References: -
the buffer has at least 4 bytes in uvc_parse_format(). Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/9ad554217c9b945031c73df4e8176a475e2dea57 - https://git.kernel.org/stable/c/1e269581b3aa5962fdc52757ab40da286168c087 - https://git.kernel.org/stable/c/8343f3fe0b755925f83d60b05e92bf4396879758 - https://git.kernel.org/stable/c/ffdd82182953df643aa63d999b6f1653d0c93778 - https://git.kernel.org/stable/c/a97e062e4ff3dab84a2f1eb811e9eddc6699e2a9 - https://git.kernel.org/stable/c/cac702a439050df65272c49184aef7975fe3eff2 - https://git.kernel.org/stable/c/424980d33b3f816485513e538610168b03fab9f1 - https://git.kernel.org/stable/c/6d4a7c0b296162354b6fc7
it.kernel.org/stable/c/424980d33b3f816485513e538610168b03fab9f1 - https://git.kernel.org/stable/c/6d4a7c0b296162354b6fc759a1475b9d57ddfaa6 - https://git.kernel.org/stable/c/782b6a718651eda3478b1824b37a8b3185d2740c
CVE ID: CVE-2025-38681 State: PUBLISHED Published: 2025-09-04T15:32:36.681Z Last Updated: 2025-11-03T17:41:07.659Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: mm/ptdump: take the memory hotplug lock inside ptdump_walk_pgd() Memory hot remove unmaps and tears down various kernel page table regions as required. The ptdump code can race with concurrent modifications of the kernel page tables. When leaf entries are modified concurrently, the dump code may log stale or inconsistent information for a VA range, but this is otherwise not harmful. But when intermediate levels of kernel page table are freed, the dump code will continu
t this is otherwise not harmful. But when intermediate levels of kernel page table are freed, the dump code will continue to use memory that has been freed and potentially reallocated for another purpose. In such cases, the ptdump code may dereference bogus addresses, leading to a number of potential problems. To avoid the above mentioned race condition, platforms such as arm64, riscv and s390 take memory hotplug lock, while dumping kernel page table via the sysfs interface /sys/kernel/debug/kernel_page_tables. Similar race condition exists while checking for pages that might have been marked W+X via /sys/kernel/debug/kernel_page_tables/check_wx_pages which in turn calls ptdump_check_wx(). I
ht have been marked W+X via /sys/kernel/debug/kernel_page_tables/check_wx_pages which in turn calls ptdump_check_wx(). Instead of solving this race condition again, let's just move the memory hotplug lock inside generic ptdump_check_wx() which will benefit both the scenarios. Drop get_online_mems() and put_online_mems() combination from all existing platform ptdump code paths. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/3ee9a8c27bfd72c3f465004fa8455785d61be5e8 - https://git.kernel.org/stable/c/69bea84b06b5e779627e7afdbf4b60a7d231c76f - https://git.kernel.org/stable/c/ac25ec5fa2bf6e606dc7954488e4dded272fa9cd - https://git.kernel.org/stable/
60a7d231c76f - https://git.kernel.org/stable/c/ac25ec5fa2bf6e606dc7954488e4dded272fa9cd - https://git.kernel.org/stable/c/1636b5e9c3543b87d673e32a47e7c18698882425 - https://git.kernel.org/stable/c/ff40839e018b82c4d756d035f34a63aa2d93be83 - https://git.kernel.org/stable/c/67995d4244694928ce701928e530b5b4adeb17b4 - https://git.kernel.org/stable/c/ca8c414499f2e5337a95a76be0d21b728ee31c6b - https://git.kernel.org/stable/c/59305202c67fea50378dcad0cc199dbc13a0e99a
CVE ID: CVE-2025-38682 State: PUBLISHED Published: 2025-09-04T15:32:37.403Z Last Updated: 2025-09-29T05:55:53.675Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: i2c: core: Fix double-free of fwnode in i2c_unregister_device() Before commit df6d7277e552 ("i2c: core: Do not dereference fwnode in struct device"), i2c_unregister_device() only called fwnode_handle_put() on of_node-s in the form of calling of_node_put(client->dev.of_node). But after this commit the i2c_client's fwnode now unconditionally gets fwnode_handle_put() on it. When the i2c_client has no primary (ACPI / OF) fwnode but it does have a software fwnode, the softw
_handle_put() on it. When the i2c_client has no primary (ACPI / OF) fwnode but it does have a software fwnode, the software-node will be the primary node and fwnode_handle_put() will put() it. But for the software fwnode device_remove_software_node() will also put() it leading to a double free: [ 82.665598] ------------[ cut here ]------------ [ 82.665609] refcount_t: underflow; use-after-free. [ 82.665808] WARNING: CPU: 3 PID: 1502 at lib/refcount.c:28 refcount_warn_saturate+0xba/0x11 ... [ 82.666830] RIP: 0010:refcount_warn_saturate+0xba/0x110 ... [ 82.666962] <TASK> [ 82.666971] i2c_unregister_device+0x60/0x90 Fix this by not calling fwnode_handle_put() when the primary fwnode is a softwa
.666971] i2c_unregister_device+0x60/0x90 Fix this by not calling fwnode_handle_put() when the primary fwnode is a software-node. References: - https://git.kernel.org/stable/c/ffe02f7c4e36090154646612e67d331832f92037 - https://git.kernel.org/stable/c/1c24e5fc0c7096e00c202a6a3e0c342c1afb47c2
CVE ID: CVE-2025-38683 State: PUBLISHED Published: 2025-09-04T15:32:38.215Z Last Updated: 2025-11-03T17:41:09.549Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: hv_netvsc: Fix panic during namespace deletion with VF The existing code move the VF NIC to new namespace when NETDEV_REGISTER is received on netvsc NIC. During deletion of the namespace, default_device_exit_batch() >> default_device_exit_net() is called. When netvsc NIC is moved back and registered to the default namespace, it automatically brings VF NIC back to the default namespace. This will cause the default_device_exit_net() >> for_each_netdev_safe loop unable to
NIC back to the default namespace. This will cause the default_device_exit_net() >> for_each_netdev_safe loop unable to detect the list end, and hit NULL ptr: [ 231.449420] mana 7870:00:00.0 enP30832s1: Moved VF to namespace with: eth0 [ 231.449656] BUG: kernel NULL pointer dereference, address: 0000000000000010 [ 231.450246] #PF: supervisor read access in kernel mode [ 231.450579] #PF: error_code(0x0000) - not-present page [ 231.450916] PGD 17b8a8067 P4D 0 [ 231.451163] Oops: Oops: 0000 [#1] SMP NOPTI [ 231.451450] CPU: 82 UID: 0 PID: 1394 Comm: kworker/u768:1 Not tainted 6.16.0-rc4+ #3 VOLUNTARY [ 231.452042] Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper
6.16.0-rc4+ #3 VOLUNTARY [ 231.452042] Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 11/21/2024 [ 231.452692] Workqueue: netns cleanup_net [ 231.452947] RIP: 0010:default_device_exit_batch+0x16c/0x3f0 [ 231.453326] Code: c0 0c f5 b3 e8 d5 db fe ff 48 85 c0 74 15 48 c7 c2 f8 fd ca b2 be 10 00 00 00 48 8d 7d c0 e8 7b 77 25 00 49 8b 86 28 01 00 00 <48> 8b 50 10 4c 8b 2a 4c 8d 62 f0 49 83 ed 10 4c 39 e0 0f 84 d6 00 [ 231.454294] RSP: 0018:ff75fc7c9bf9fd00 EFLAGS: 00010246 [ 231.454610] RAX: 0000000000000000 RBX: 0000000000000002 RCX: 61c8864680b583eb [ 231.455094] RDX: ff1fa9f71462d800 RSI: ff75fc7c9bf9fd38 RDI: 0000000030766564 [ 231.45568
000002 RCX: 61c8864680b583eb [ 231.455094] RDX: ff1fa9f71462d800 RSI: ff75fc7c9bf9fd38 RDI: 0000000030766564 [ 231.455686] RBP: ff75fc7c9bf9fd78 R08: 0000000000000000 R09: 0000000000000000 [ 231.456126] R10: 0000000000000001 R11: 0000000000000004 R12: ff1fa9f70088e340 [ 231.456621] R13: ff1fa9f70088e340 R14: ffffffffb3f50c20 R15: ff1fa9f7103e6340 [ 231.457161] FS: 0000000000000000(0000) GS:ff1faa6783a08000(0000) knlGS:0000000000000000 [ 231.457707] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 231.458031] CR2: 0000000000000010 CR3: 0000000179ab2006 CR4: 0000000000b73ef0 [ 231.458434] Call Trace: [ 231.458600] <TASK> [ 231.458777] ops_undo_list+0x100/0x220 [ 231.459015] cleanup_net+0x1b8
0 [ 231.458434] Call Trace: [ 231.458600] <TASK> [ 231.458777] ops_undo_list+0x100/0x220 [ 231.459015] cleanup_net+0x1b8/0x300 [ 231.459285] process_one_work+0x184/0x340 To fix it, move the ns change to a workqueue, and take rtnl_lock to avoid changing the netdev list when default_device_exit_net() is using it. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/3ca41ab55d23a0aa71661a5a56a8f06c11db90dc - https://git.kernel.org/stable/c/3467c4ebb334658c6fcf3eabb64a6e8b2135e010 - https://git.kernel.org/stable/c/4eff1e57a8ef98d70451b94e8437e458b27dd234 - https://git.kernel.org/stable/c/2a70cbd1aef8b8be39992ab7b776ce1390091774 - https://git.kernel.org
b94e8437e458b27dd234 - https://git.kernel.org/stable/c/2a70cbd1aef8b8be39992ab7b776ce1390091774 - https://git.kernel.org/stable/c/d036104947176d030bec64792d54e1b4f4c7f318 - https://git.kernel.org/stable/c/5276896e6923ebe8c68573779d784aaf7d987cce - https://git.kernel.org/stable/c/4293f6c5ccf735b26afeb6825def14d830e0367b - https://git.kernel.org/stable/c/33caa208dba6fa639e8a92fd0c8320b652e5550c
CVE ID: CVE-2025-38684 State: PUBLISHED Published: 2025-09-04T15:32:38.927Z Last Updated: 2025-11-03T17:41:11.527Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: net/sched: ets: use old 'nbands' while purging unused classes Shuang reported sch_ets test-case [1] crashing in ets_class_qlen_notify() after recent changes from Lion [2]. The problem is: in ets_qdisc_change() we purge unused DWRR queues; the value of 'q->nbands' is the new one, and the cleanup should be done with the old one. The problem is here since my first attempts to fix ets_qdisc_change(), but it surfaced again after the recent qdisc len accounting fixes. Fix it
e my first attempts to fix ets_qdisc_change(), but it surfaced again after the recent qdisc len accounting fixes. Fix it purging idle DWRR queues before assigning a new value of 'q->nbands', so that all purge operations find a consistent configuration: - old 'q->nbands' because it's needed by ets_class_find() - old 'q->nstrict' because it's needed by ets_class_is_strict() BUG: kernel NULL pointer dereference, address: 0000000000000000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 62 UID: 0 PID: 39457 Comm: tc Kdump: loaded Not tainted 6.12.0-116.el10.x86_64 #1 PREEMPT(voluntary) Hardware name: Dell Inc.
: 0 PID: 39457 Comm: tc Kdump: loaded Not tainted 6.12.0-116.el10.x86_64 #1 PREEMPT(voluntary) Hardware name: Dell Inc. PowerEdge R640/06DKY5, BIOS 2.12.2 07/09/2021 RIP: 0010:__list_del_entry_valid_or_report+0x4/0x80 Code: ff 4c 39 c7 0f 84 39 19 8e ff b8 01 00 00 00 c3 cc cc cc cc 66 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa <48> 8b 17 48 8b 4f 08 48 85 d2 0f 84 56 19 8e ff 48 85 c9 0f 84 ab RSP: 0018:ffffba186009f400 EFLAGS: 00010202 RAX: 00000000000000d6 RBX: 0000000000000000 RCX: 0000000000000004 RDX: ffff9f0fa29b69c0 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffffffffc12c2400 R08: 0000000000000008 R09: 0000000000000004 R10: ffffffffffffffff R11: 0000000000000
0000000000000 RBP: ffffffffc12c2400 R08: 0000000000000008 R09: 0000000000000004 R10: ffffffffffffffff R11: 0000000000000004 R12: 0000000000000000 R13: ffff9f0f8cfe0000 R14: 0000000000100005 R15: 0000000000000000 FS: 00007f2154f37480(0000) GS:ffff9f269c1c0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 00000001530be001 CR4: 00000000007726f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: <TASK> ets_class_qlen_notify+0x65/0x90 [sch_ets] qdisc_tree_reduce_backlog+0x74/0x110 ets_qdisc_change+0x630/0xa40 [sch_ets] __tc_modify_q
len_notify+0x65/0x90 [sch_ets] qdisc_tree_reduce_backlog+0x74/0x110 ets_qdisc_change+0x630/0xa40 [sch_ets] __tc_modify_qdisc.constprop.0+0x216/0x7f0 tc_modify_qdisc+0x7c/0x120 rtnetlink_rcv_msg+0x145/0x3f0 netlink_rcv_skb+0x53/0x100 netlink_unicast+0x245/0x390 netlink_sendmsg+0x21b/0x470 ____sys_sendmsg+0x39d/0x3d0 ___sys_sendmsg+0x9a/0xe0 __sys_sendmsg+0x7a/0xd0 do_syscall_64+0x7d/0x160 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7f2155114084 Code: 89 02 b8 ff ff ff ff eb bb 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 f3 0f 1e fa 80 3d 25 f0 0c 00 00 74 13 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 54 c3 0f 1f 00 48 83 ec 28 89 54 24 1c 48 89 RSP: 002b:00007fff1fd7a988 EFLAGS: 00000202
00 0f 05 <48> 3d 00 f0 ff ff 77 54 c3 0f 1f 00 48 83 ec 28 89 54 24 1c 48 89 RSP: 002b:00007fff1fd7a988 EFLAGS: 00000202 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 0000560ec063e5e0 RCX: 00007f2155114084 RDX: 0000000000000000 RSI: 00007fff1fd7a9f0 RDI: 0000000000000003 RBP: 00007fff1fd7aa60 R08: 0000000000000010 R09: 000000000000003f R10: 0000560ee9b3a010 R11: 0000000000000202 R12: 00007fff1fd7aae0 R13: 000000006891ccde R14: 0000560ec063e5e0 R15: 00007fff1fd7aad0 </TASK> [1] https://lore.kernel.org/netdev/e08c7f4a6882f260011909a868311c6e9b54f3e4.1639153474.git.dcaratti@redhat.com/ [2] https://lore.kernel.org/netdev/d912cbd7-193b-4269-9857-525bee8bbb6a@gmail.com/ Additional Analyst
ratti@redhat.com/ [2] https://lore.kernel.org/netdev/d912cbd7-193b-4269-9857-525bee8bbb6a@gmail.com/ Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/bdfddcde86e8b9245d9c0c2efe2b6fe8dcf6bf41 - https://git.kernel.org/stable/c/be9692dafdfb36d9c43afd9d4e1d9d9ba8e7b51b - https://git.kernel.org/stable/c/97ec167cd2e8a81a2d87331a2ed92daf007542c8 - https://git.kernel.org/stable/c/84a24fb446ee07b22b64aae6f0e3f4a38266310a - https://git.kernel.org/stable/c/5b3b346bc4c2aa2c428735438a11989d251f32f1 - https://git.kernel.org/stable/c/d69f4a258cd91b3bcef7089eb0401005aae2aed5 - https://git.kernel.org/stable/c/970c1c731c4ede46d05f5b0355724d1e400cfbca - https://g
58cd91b3bcef7089eb0401005aae2aed5 - https://git.kernel.org/stable/c/970c1c731c4ede46d05f5b0355724d1e400cfbca - https://git.kernel.org/stable/c/87c6efc5ce9c126ae4a781bc04504b83780e3650
CVE ID: CVE-2025-38685 State: PUBLISHED Published: 2025-09-04T15:32:39.856Z Last Updated: 2025-11-03T17:41:12.573Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: fbdev: Fix vmalloc out-of-bounds write in fast_imageblit This issue triggers when a userspace program does an ioctl FBIOPUT_CON2FBMAP by passing console number and frame buffer number. Ideally this maps console to frame buffer and updates the screen if console is visible. As part of mapping it has to do resize of console according to frame buffer info. if this resize fails and returns from vc_do_resize() and continues further. At this point console and new frame buffer
. if this resize fails and returns from vc_do_resize() and continues further. At this point console and new frame buffer are mapped and sets display vars. Despite failure still it continue to proceed updating the screen at later stages where vc_data is related to previous frame buffer and frame buffer info and display vars are mapped to new frame buffer and eventully leading to out-of-bounds write in fast_imageblit(). This bheviour is excepted only when fg_console is equal to requested console which is a visible console and updates screen with invalid struct references in fbcon_putcs(). Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/078e62bff
bcon_putcs(). Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/078e62bffca4b7e72e8f3550eb063ab981c36c7a - https://git.kernel.org/stable/c/4c4d7ddaf1d43780b106bedc692679f965dc5a3a - https://git.kernel.org/stable/c/27b118aebdd84161c8ff5ce49d9d536f2af10754 - https://git.kernel.org/stable/c/ed9b8e5016230868c8d813d9179523f729fec8c6 - https://git.kernel.org/stable/c/56701bf9eeb63219e378cb7fcbd066ea4eaeeb50 - https://git.kernel.org/stable/c/cfec17721265e72e50cc69c6004fe3475cd38df2 - https://git.kernel.org/stable/c/af0db3c1f898144846d4c172531a199bb3ca375d
CVE ID: CVE-2025-38686 State: PUBLISHED Published: 2025-09-04T15:32:40.771Z Last Updated: 2025-09-29T05:55:58.953Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: userfaultfd: fix a crash in UFFDIO_MOVE when PMD is a migration entry When UFFDIO_MOVE encounters a migration PMD entry, it proceeds with obtaining a folio and accessing it even though the entry is swp_entry_t. Add the missing check and let split_huge_pmd() handle migration entries. While at it also remove unnecessary folio check. [surenb@google.com: remove extra folio check, per David] References: - https://git.kernel.org/stable/c/bb81c18dbd42650c844e160cafa7cbb20243a
remove extra folio check, per David] References: - https://git.kernel.org/stable/c/bb81c18dbd42650c844e160cafa7cbb20243a96a - https://git.kernel.org/stable/c/1202abad7a7ccd28c426d2844771a387b07629a4 - https://git.kernel.org/stable/c/7f1101a0a181243ad587ececdffc4845f035549f - https://git.kernel.org/stable/c/aba6faec0103ed8f169be8dce2ead41fcb689446
CVE ID: CVE-2025-38687 State: PUBLISHED Published: 2025-09-04T15:32:41.702Z Last Updated: 2025-11-03T17:41:14.570Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: comedi: fix race between polling and detaching syzbot reports a use-after-free in comedi in the below link, which is due to comedi gladly removing the allocated async area even though poll requests are still active on the wait_queue_head inside of it. This can cause a use-after-free when the poll entries are later triggered or removed, as the memory for the wait_queue_head has been freed. We need to check there are no tasks queued on any of the subdevices' wait queues