Kushalkhemka/embedding-cve-nvd-dataset huggingface dataset:
--- ___mark_inode_dirty inode_switch_wbs_work_fn spin_lock(&inode->i_lock); inode_attach_wb locked_inode_to_wb_and_lock_list get inode->i_wb spin_unlock(&inode->i_lock); spin_lock(&wb->list_lock) spin_lock(&inode->i_lock) inode_io_list_move_locked spin_unlock(&wb->list_lock) spin_unlock(&inode->i_lock) spin_lock(&old_wb->list_lock) inode_do_switch_wbs spin_lock(&inode->i_lock) inode->i_wb = new_wb spin_unlock(&inode->i_lock) spin_unlock(&old_wb->list_lock) wb_put_many(old_wb, nr_switched) cgwb_release old wb released wb_wakeup_delayed() accesses wb, then trigger the use-after-free issue Fix this race condition by holding inode spinlock until wb_wakeup_delayed() finished. Additional Analyst N
er-free issue Fix this race condition by holding inode spinlock until wb_wakeup_delayed() finished. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/b187c976111960e6e54a6b1fff724f6e3d39406c - https://git.kernel.org/stable/c/1edc2feb9c759a9883dfe81cb5ed231412d8b2e4 - https://git.kernel.org/stable/c/bf89b1f87c72df79cf76203f71fbf8349cd5c9de - https://git.kernel.org/stable/c/e63052921f1b25a836feb1500b841bff7a4a0456 - https://git.kernel.org/stable/c/c8c14adf80bd1a6e4a1d7ee9c2a816881c26d17a - https://git.kernel.org/stable/c/d02d2c98d25793902f65803ab853b592c7a96b29
CVE ID: CVE-2025-39867 State: REJECTED Published: 2025-09-23T06:00:42.707Z Last Updated: 2025-09-29T06:08:49.023Z Description: No description available.
CVE ID: CVE-2025-39868 State: PUBLISHED Published: 2025-09-23T06:00:43.308Z Last Updated: 2025-09-29T06:01:23.870Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: erofs: fix runtime warning on truncate_folio_batch_exceptionals() Commit 0e2f80afcfa6("fs/dax: ensure all pages are idle prior to filesystem unmount") introduced the WARN_ON_ONCE to capture whether the filesystem has removed all DAX entries or not and applied the fix to xfs and ext4. Apply the missed fix on erofs to fix the runtime warning: [ 5.266254] ------------[ cut here ]------------ [ 5.266274] WARNING: CPU: 6 PID: 3109 at mm/truncate.c:89 truncate_folio_batch_ex
] ------------[ cut here ]------------ [ 5.266274] WARNING: CPU: 6 PID: 3109 at mm/truncate.c:89 truncate_folio_batch_exceptionals+0xff/0x260 [ 5.266294] Modules linked in: [ 5.266999] CPU: 6 UID: 0 PID: 3109 Comm: umount Tainted: G S 6.16.0+ #6 PREEMPT(voluntary) [ 5.267012] Tainted: [S]=CPU_OUT_OF_SPEC [ 5.267017] Hardware name: Dell Inc. OptiPlex 5000/05WXFV, BIOS 1.5.1 08/24/2022 [ 5.267024] RIP: 0010:truncate_folio_batch_exceptionals+0xff/0x260 [ 5.267076] Code: 00 00 41 39 df 7f 11 eb 78 83 c3 01 49 83 c4 08 41 39 df 74 6c 48 63 f3 48 83 fe 1f 0f 83 3c 01 00 00 43 f6 44 26 08 01 74 df <0f> 0b 4a 8b 34 22 4c 89 ef 48 89 55 90 e8 ff 54 1f 00 48 8b 55 90 [ 5.267083] RSP: 0018:ffffc900013f
44 26 08 01 74 df <0f> 0b 4a 8b 34 22 4c 89 ef 48 89 55 90 e8 ff 54 1f 00 48 8b 55 90 [ 5.267083] RSP: 0018:ffffc900013f36c8 EFLAGS: 00010202 [ 5.267095] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000 [ 5.267101] RDX: ffffc900013f3790 RSI: 0000000000000000 RDI: ffff8882a1407898 [ 5.267108] RBP: ffffc900013f3740 R08: 0000000000000000 R09: 0000000000000000 [ 5.267113] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000 [ 5.267119] R13: ffff8882a1407ab8 R14: ffffc900013f3888 R15: 0000000000000001 [ 5.267125] FS: 00007aaa8b437800(0000) GS:ffff88850025b000(0000) knlGS:0000000000000000 [ 5.267132] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 5.267138] CR2: 00
850025b000(0000) knlGS:0000000000000000 [ 5.267132] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 5.267138] CR2: 00007aaa8b3aac10 CR3: 000000024f764000 CR4: 0000000000f52ef0 [ 5.267144] PKRU: 55555554 [ 5.267150] Call Trace: [ 5.267154] <TASK> [ 5.267181] truncate_inode_pages_range+0x118/0x5e0 [ 5.267193] ? save_trace+0x54/0x390 [ 5.267296] truncate_inode_pages_final+0x43/0x60 [ 5.267309] evict+0x2a4/0x2c0 [ 5.267339] dispose_list+0x39/0x80 [ 5.267352] evict_inodes+0x150/0x1b0 [ 5.267376] generic_shutdown_super+0x41/0x180 [ 5.267390] kill_block_super+0x1b/0x50 [ 5.267402] erofs_kill_sb+0x81/0x90 [erofs] [ 5.267436] deactivate_locked_super+0x32/0xb0 [ 5.267450] deactivate_super+0x46/0x60
02] erofs_kill_sb+0x81/0x90 [erofs] [ 5.267436] deactivate_locked_super+0x32/0xb0 [ 5.267450] deactivate_super+0x46/0x60 [ 5.267460] cleanup_mnt+0xc3/0x170 [ 5.267475] __cleanup_mnt+0x12/0x20 [ 5.267485] task_work_run+0x5d/0xb0 [ 5.267499] exit_to_user_mode_loop+0x144/0x170 [ 5.267512] do_syscall_64+0x2b9/0x7c0 [ 5.267523] ? __lock_acquire+0x665/0x2ce0 [ 5.267535] ? __lock_acquire+0x665/0x2ce0 [ 5.267560] ? lock_acquire+0xcd/0x300 [ 5.267573] ? find_held_lock+0x31/0x90 [ 5.267582] ? mntput_no_expire+0x97/0x4e0 [ 5.267606] ? mntput_no_expire+0xa1/0x4e0 [ 5.267625] ? mntput+0x24/0x50 [ 5.267634] ? path_put+0x1e/0x30 [ 5.267647] ? do_faccessat+0x120/0x2f0 [ 5.267677] ? do_syscall_64+0x1a2/0x7c0
x24/0x50 [ 5.267634] ? path_put+0x1e/0x30 [ 5.267647] ? do_faccessat+0x120/0x2f0 [ 5.267677] ? do_syscall_64+0x1a2/0x7c0 [ 5.267686] ? from_kgid_munged+0x17/0x30 [ 5.267703] ? from_kuid_munged+0x13/0x30 [ 5.267711] ? __do_sys_getuid+0x3d/0x50 [ 5.267724] ? do_syscall_64+0x1a2/0x7c0 [ 5.267732] ? irqentry_exit+0x77/0xb0 [ 5.267743] ? clear_bhb_loop+0x30/0x80 [ 5.267752] ? clear_bhb_loop+0x30/0x80 [ 5.267765] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 5.267772] RIP: 0033:0x7aaa8b32a9fb [ 5.267781] Code: c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 f3 0f 1e fa 31 f6 e9 05 00 00 00 0f 1f 44 00 00 f3 0f 1e fa b8 a6 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 05 c3 0f 1f 40 00 48 8b 15 e9 83 0d 00 f7 d8
0 00 0f 1f 44 00 00 f3 0f 1e fa b8 a6 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 05 c3 0f 1f 40 00 48 8b 15 e9 83 0d 00 f7 d8 [ 5.267787] RSP: 002b:00007ffd7c4c9468 EFLAGS: 00000246 ORIG_RAX: 00000000000000a6 [ 5.267796] RAX: 0000000000000000 RBX: 00005a61592a8b00 RCX: 00007aaa8b32a9fb [ 5.267802] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 00005a61592b2080 [ 5.267806] RBP: 00007ffd7c4c9540 R08: 00007aaa8b403b20 R09: 0000000000000020 [ 5.267812] R10: 0000000000000001 R11: 0000000000000246 R12: 00005a61592a8c00 [ 5.267817] R13: 00000000 ---truncated--- References: - https://git.kernel.org/stable/c/91c34cd6ca1bc67ccf2d104834956af56b5893de - https://git.kernel.org/stable/c/181993bb0d626cf88cc80
git.kernel.org/stable/c/91c34cd6ca1bc67ccf2d104834956af56b5893de - https://git.kernel.org/stable/c/181993bb0d626cf88cc803f4356ce5c5abe86278
CVE ID: CVE-2025-39869 State: PUBLISHED Published: 2025-09-23T06:00:43.852Z Last Updated: 2025-11-03T17:44:18.233Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: dmaengine: ti: edma: Fix memory allocation size for queue_priority_map Fix a critical memory allocation bug in edma_setup_from_hw() where queue_priority_map was allocated with insufficient memory. The code declared queue_priority_map as s8 (*)[2] (pointer to array of 2 s8), but allocated memory using sizeof(s8) instead of the correct size. This caused out-of-bounds memory writes when accessing: queue_priority_map[i][0] = i; queue_priority_map[i][1] = i; The bug manifes
out-of-bounds memory writes when accessing: queue_priority_map[i][0] = i; queue_priority_map[i][1] = i; The bug manifested as kernel crashes with "Oops - undefined instruction" on ARM platforms (BeagleBoard-X15) during EDMA driver probe, as the memory corruption triggered kernel hardening features on Clang. Change the allocation to use sizeof(*queue_priority_map) which automatically gets the correct size for the 2D array structure. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/7d4de60d6db02d9b01d5890d5156b04fad65d07a - https://git.kernel.org/stable/c/d722de80ce037dccf6931e778f4a46499d51bdf9 - https://git.kernel.org/stable/c/301a96cc4dc006c9
ps://git.kernel.org/stable/c/d722de80ce037dccf6931e778f4a46499d51bdf9 - https://git.kernel.org/stable/c/301a96cc4dc006c9a285913d301e681cfbf7edb6 - https://git.kernel.org/stable/c/5e462fa0dfdb52b3983cf41532d3d4c7d63e2f93 - https://git.kernel.org/stable/c/1baed10553fc8b388351d8fc803e3ae6f1a863bc - https://git.kernel.org/stable/c/069fd1688c57c0cc8a3de64d108579b31676f74b - https://git.kernel.org/stable/c/d5e82f3f2c918d446df46e8d65f8083fd97cdec5 - https://git.kernel.org/stable/c/e63419dbf2ceb083c1651852209c7f048089ac0f
CVE ID: CVE-2025-39870 State: PUBLISHED Published: 2025-09-23T06:00:44.369Z Last Updated: 2025-11-03T17:44:19.166Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: dmaengine: idxd: Fix double free in idxd_setup_wqs() The clean up in idxd_setup_wqs() has had a couple bugs because the error handling is a bit subtle. It's simpler to just re-write it in a cleaner way. The issues here are: 1) If "idxd->max_wqs" is <= 0 then we call put_device(conf_dev) when "conf_dev" hasn't been initialized. 2) If kzalloc_node() fails then again "conf_dev" is invalid. It's either uninitialized or it points to the "conf_dev" from the previous iteratio
ls then again "conf_dev" is invalid. It's either uninitialized or it points to the "conf_dev" from the previous iteration so it leads to a double free. It's better to free partial loop iterations within the loop and then the unwinding at the end can handle whole loop iterations. I also renamed the labels to describe what the goto does and not where the goto was located. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/25e6146c2812487a88f619d5ff6efbdcd5b2bc31 - https://git.kernel.org/stable/c/df82c7901513fd0fc738052a8e6a330d92cc8ec9 - https://git.kernel.org/stable/c/ec5430d090d0b6ace8fefa290fc37e88930017d2 - https://git.kernel.org/stable/c/9f0e2
c8ec9 - https://git.kernel.org/stable/c/ec5430d090d0b6ace8fefa290fc37e88930017d2 - https://git.kernel.org/stable/c/9f0e225635475b2285b966271d5e82cba74295b1 - https://git.kernel.org/stable/c/39aaa337449e71a41d4813be0226a722827ba606
CVE ID: CVE-2025-39871 State: PUBLISHED Published: 2025-09-23T06:00:44.882Z Last Updated: 2025-09-29T06:01:27.766Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: dmaengine: idxd: Remove improper idxd_free The call to idxd_free() introduces a duplicate put_device() leading to a reference count underflow: refcount_t: underflow; use-after-free. WARNING: CPU: 15 PID: 4428 at lib/refcount.c:28 refcount_warn_saturate+0xbe/0x110 ... Call Trace: <TASK> idxd_remove+0xe4/0x120 [idxd] pci_device_remove+0x3f/0xb0 device_release_driver_internal+0x197/0x200 driver_detach+0x48/0x90 bus_remove_driver+0x74/0xf0 pci_unregister_driver+0x2e/0xb0 i
elease_driver_internal+0x197/0x200 driver_detach+0x48/0x90 bus_remove_driver+0x74/0xf0 pci_unregister_driver+0x2e/0xb0 idxd_exit_module+0x34/0x7a0 [idxd] __do_sys_delete_module.constprop.0+0x183/0x280 do_syscall_64+0x54/0xd70 entry_SYSCALL_64_after_hwframe+0x76/0x7e The idxd_unregister_devices() which is invoked at the very beginning of idxd_remove(), already takes care of the necessary put_device() through the following call path: idxd_unregister_devices() -> device_unregister() -> put_device() In addition, when CONFIG_DEBUG_KOBJECT_RELEASE is enabled, put_device() may trigger asynchronous cleanup via schedule_delayed_work(). If idxd_free() is called immediately after, it can result in a us
gger asynchronous cleanup via schedule_delayed_work(). If idxd_free() is called immediately after, it can result in a use-after-free. Remove the improper idxd_free() to avoid both the refcount underflow and potential memory corruption during module unload. References: - https://git.kernel.org/stable/c/0e95ee7f532b21206fe3f1c4054002b0d21e3b9c - https://git.kernel.org/stable/c/dd7a7e43269711d757fc260b0bbdf7138f75de11 - https://git.kernel.org/stable/c/da4fbc1488a4cec6748da685181ee4449a878dac - https://git.kernel.org/stable/c/f41c538881eec4dcf5961a242097d447f848cda6
CVE ID: CVE-2025-39872 State: PUBLISHED Published: 2025-09-23T06:00:45.528Z Last Updated: 2025-09-29T06:01:29.027Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: hsr: hold rcu and dev lock for hsr_get_port_ndev hsr_get_port_ndev calls hsr_for_each_port, which need to hold rcu lock. On the other hand, before return the port device, we need to hold the device reference to avoid UaF in the caller function. References: - https://git.kernel.org/stable/c/68a6729afd3e8e9a2a32538642ce92b96ccf9b1d - https://git.kernel.org/stable/c/847748fc66d08a89135a74e29362a66ba4e3ab15
CVE ID: CVE-2025-39873 State: PUBLISHED Published: 2025-09-23T06:00:46.157Z Last Updated: 2025-11-03T17:44:20.103Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: can: xilinx_can: xcan_write_frame(): fix use-after-free of transmitted SKB can_put_echo_skb() takes ownership of the SKB and it may be freed during or after the call. However, xilinx_can xcan_write_frame() keeps using SKB after the call. Fix that by only calling can_put_echo_skb() after the code is done touching the SKB. The tx_lock is held for the entire xcan_write_frame() execution and also on the can_get_echo_skb() side so the order of operations does not matter. An
tire xcan_write_frame() execution and also on the can_get_echo_skb() side so the order of operations does not matter. An earlier fix commit 3d3c817c3a40 ("can: xilinx_can: Fix usage of skb memory") did not move the can_put_echo_skb() call far enough. [mkl: add "commit" in front of sha1 in patch description] [mkl: fix indention] Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/e202ffd9e54538ef67ec301ebd6d9da4823466c9 - https://git.kernel.org/stable/c/1139321161a3ba5e45e61e0738b37f42f20bc57a - https://git.kernel.org/stable/c/94b050726288a56a6b8ff55aa641f2fedbd3b44c - https://git.kernel.org/stable/c/725b33deebd6e4c96fe7893f384510a54258f28f - https
050726288a56a6b8ff55aa641f2fedbd3b44c - https://git.kernel.org/stable/c/725b33deebd6e4c96fe7893f384510a54258f28f - https://git.kernel.org/stable/c/668cc1e3bb21101d074e430de1b7ba8fd10189e7 - https://git.kernel.org/stable/c/ef79f00be72bd81d2e1e6f060d83cf7e425deee4
CVE ID: CVE-2025-39874 State: PUBLISHED Published: 2025-09-23T06:00:46.690Z Last Updated: 2025-09-29T06:01:31.845Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: macsec: sync features on RTM_NEWLINK Syzkaller managed to lock the lower device via ETHTOOL_SFEATURES: netdev_lock include/linux/netdevice.h:2761 [inline] netdev_lock_ops include/net/netdev_lock.h:42 [inline] netdev_sync_lower_features net/core/dev.c:10649 [inline] __netdev_update_features+0xcb1/0x1be0 net/core/dev.c:10819 netdev_update_features+0x6d/0xe0 net/core/dev.c:10876 macsec_notify+0x2f5/0x660 drivers/net/macsec.c:4533 notifier_call_chain+0x1b3/0x3e0 kernel/not
0xe0 net/core/dev.c:10876 macsec_notify+0x2f5/0x660 drivers/net/macsec.c:4533 notifier_call_chain+0x1b3/0x3e0 kernel/notifier.c:85 call_netdevice_notifiers_extack net/core/dev.c:2267 [inline] call_netdevice_notifiers net/core/dev.c:2281 [inline] netdev_features_change+0x85/0xc0 net/core/dev.c:1570 __dev_ethtool net/ethtool/ioctl.c:3469 [inline] dev_ethtool+0x1536/0x19b0 net/ethtool/ioctl.c:3502 dev_ioctl+0x392/0x1150 net/core/dev_ioctl.c:759 It happens because lower features are out of sync with the upper: __dev_ethtool (real_dev) netdev_lock_ops(real_dev) ETHTOOL_SFEATURES __netdev_features_change netdev_sync_upper_features disable LRO on the lower if (old_features != dev->features) netdev_
__netdev_features_change netdev_sync_upper_features disable LRO on the lower if (old_features != dev->features) netdev_features_change fires NETDEV_FEAT_CHANGE macsec_notify NETDEV_FEAT_CHANGE netdev_update_features (for each macsec dev) netdev_sync_lower_features if (upper_features != lower_features) netdev_lock_ops(lower) # lower == real_dev stuck ... netdev_unlock_ops(real_dev) Per commit af5f54b0ef9e ("net: Lock lower level devices when updating features"), we elide the lock/unlock when the upper and lower features are synced. Makes sure the lower (real_dev) has proper features after the macsec link has been created. This makes sure we never hit the situation where we need to sync upper
features after the macsec link has been created. This makes sure we never hit the situation where we need to sync upper flags to the lower. References: - https://git.kernel.org/stable/c/d7624629ccf47135c65fef0701fa0d9a115b87f3 - https://git.kernel.org/stable/c/0f82c3ba66c6b2e3cde0f255156a753b108ee9dc
CVE ID: CVE-2025-39875 State: PUBLISHED Published: 2025-09-23T06:00:47.198Z Last Updated: 2025-09-29T06:01:33.315Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: igb: Fix NULL pointer dereference in ethtool loopback test The igb driver currently causes a NULL pointer dereference when executing the ethtool loopback test. This occurs because there is no associated q_vector for the test ring when it is set up, as interrupts are typically not added to the test rings. Since commit 5ef44b3cb43b removed the napi_id assignment in __xdp_rxq_info_reg(), there is no longer a need to pass a napi_id to it. Therefore, simply use 0 as the las
ssignment in __xdp_rxq_info_reg(), there is no longer a need to pass a napi_id to it. Therefore, simply use 0 as the last parameter. References: - https://git.kernel.org/stable/c/473be7d39efd3be383e9c0c8e44b53508b4ffeb5 - https://git.kernel.org/stable/c/75871a525a596ff4d16c4aebc0018f8d0923c9b1
CVE ID: CVE-2025-39876 State: PUBLISHED Published: 2025-09-23T06:00:47.731Z Last Updated: 2025-11-03T17:44:21.070Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: net: fec: Fix possible NPD in fec_enet_phy_reset_after_clk_enable() The function of_phy_find_device may return NULL, so we need to take care before dereferencing phy_dev. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/8c60d12bba14dc655d2d948b1dbf390b3ae39cb8 - https://git.kernel.org/stable/c/20a3433d31c2d2bf70ab0abec75f3136b42ae66c - https://git.kernel.org/stable/c/93a699d6e92cfdfa9eb9dbb8c653b5322542ca4f - https://git.
c2d2bf70ab0abec75f3136b42ae66c - https://git.kernel.org/stable/c/93a699d6e92cfdfa9eb9dbb8c653b5322542ca4f - https://git.kernel.org/stable/c/5f1bb554a131e59b28482abad21f691390651752 - https://git.kernel.org/stable/c/fe78891f296ac05bf4e5295c9829ef822f3c32e7 - https://git.kernel.org/stable/c/4fe53aaa4271a72fe5fe3e88a45ce01646b68dc5 - https://git.kernel.org/stable/c/eb148d85e126c47d65be34f2a465d69432ca5541 - https://git.kernel.org/stable/c/03e79de4608bdd48ad6eec272e196124cefaf798
CVE ID: CVE-2025-39877 State: PUBLISHED Published: 2025-09-23T06:00:48.317Z Last Updated: 2025-11-03T17:44:22.015Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: mm/damon/sysfs: fix use-after-free in state_show() state_show() reads kdamond->damon_ctx without holding damon_sysfs_lock. This allows a use-after-free race: CPU 0 CPU 1 ----- ----- state_show() damon_sysfs_turn_damon_on() ctx = kdamond->damon_ctx; mutex_lock(&damon_sysfs_lock); damon_destroy_ctx(kdamond->damon_ctx); kdamond->damon_ctx = NULL; mutex_unlock(&damon_sysfs_lock); damon_is_running(ctx); /* ctx is freed */ mutex_lock(&ctx->kdamond_lock); /* UAF */ (The race
nlock(&damon_sysfs_lock); damon_is_running(ctx); /* ctx is freed */ mutex_lock(&ctx->kdamond_lock); /* UAF */ (The race can also occur with damon_sysfs_kdamonds_rm_dirs() and damon_sysfs_kdamond_release(), which free or replace the context under damon_sysfs_lock.) Fix by taking damon_sysfs_lock before dereferencing the context, mirroring the locking used in pid_show(). The bug has existed since state_show() first accessed kdamond->damon_ctx. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/3858c44341ad49dc7544b19cc9f9ecffaa7cc50e - https://git.kernel.org/stable/c/60d7a3d2b985a395318faa1d88da6915fad11c19 - https://git.kernel.org/stable/c/26d29b2
50e - https://git.kernel.org/stable/c/60d7a3d2b985a395318faa1d88da6915fad11c19 - https://git.kernel.org/stable/c/26d29b2ac87a2989071755f9828ebf839b560d4c - https://git.kernel.org/stable/c/4e87f461d61959647464a94d11ae15c011be58ce - https://git.kernel.org/stable/c/3260a3f0828e06f5f13fac69fb1999a6d60d9cff
CVE ID: CVE-2025-39878 State: PUBLISHED Published: 2025-09-23T06:00:48.850Z Last Updated: 2025-09-29T06:01:37.095Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ceph: fix crash after fscrypt_encrypt_pagecache_blocks() error The function move_dirty_folio_in_page_array() was created by commit ce80b76dd327 ("ceph: introduce ceph_process_folio_batch() method") by moving code from ceph_writepages_start() to this function. This new function is supposed to return an error code which is checked by the caller (now ceph_process_folio_batch()), and on error, the caller invokes redirty_page_for_writepage() and then breaks from the loop. H
h_process_folio_batch()), and on error, the caller invokes redirty_page_for_writepage() and then breaks from the loop. However, the refactoring commit has gone wrong, and it by accident, it always returns 0 (= success) because it first NULLs the pointer and then returns PTR_ERR(NULL) which is always 0. This means errors are silently ignored, leaving NULL entries in the page array, which may later crash the kernel. The simple solution is to call PTR_ERR() before clearing the pointer. References: - https://git.kernel.org/stable/c/dd1616ecbea920d228c56729461ed223cc501425 - https://git.kernel.org/stable/c/249e0a47cdb46bb9eae65511c569044bd8698d7d
CVE ID: CVE-2025-39879 State: PUBLISHED Published: 2025-09-23T06:00:49.377Z Last Updated: 2025-09-29T06:01:38.349Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ceph: always call ceph_shift_unused_folios_left() The function ceph_process_folio_batch() sets folio_batch entries to NULL, which is an illegal state. Before folio_batch_release() crashes due to this API violation, the function ceph_shift_unused_folios_left() is supposed to remove those NULLs from the array. However, since commit ce80b76dd327 ("ceph: introduce ceph_process_folio_batch() method"), this shifting doesn't happen anymore because the "for" loop got moved to
introduce ceph_process_folio_batch() method"), this shifting doesn't happen anymore because the "for" loop got moved to ceph_process_folio_batch(), and now the `i` variable that remains in ceph_writepages_start() doesn't get incremented anymore, making the shifting effectively unreachable much of the time. Later, commit 1551ec61dc55 ("ceph: introduce ceph_submit_write() method") added more preconditions for doing the shift, replacing the `i` check (with something that is still just as broken): - if ceph_process_folio_batch() fails, shifting never happens - if ceph_move_dirty_page_in_page_array() was never called (because ceph_process_folio_batch() has returned early for some of various reaso
y_page_in_page_array() was never called (because ceph_process_folio_batch() has returned early for some of various reasons), shifting never happens - if `processed_in_fbatch` is zero (because ceph_process_folio_batch() has returned early for some of the reasons mentioned above or because ceph_move_dirty_page_in_page_array() has failed), shifting never happens Since those two commits, any problem in ceph_process_folio_batch() could crash the kernel, e.g. this way: BUG: kernel NULL pointer dereference, address: 0000000000000034 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page PGD 0 P4D 0 Oops: Oops: 0002 [#1] SMP NOPTI CPU: 172 UID: 0 PID: 2342707 Comm: kw