Kushalkhemka/embedding-cve-nvd-dataset huggingface dataset:
madvise_vma_behavior(). As observed in syzkaller reports, it is ultimately madvise_update_vma() that is invoked, calling vma_modify_flags_name() and vma_modify() in turn. Then, in vma_modify(), we attempt the merge: merged = vma_merge_existing_range(vmg); if (merged) return merged; We invoke this with vmg->start, end set to start, tmp as such: start tmp |<--->| |----------|------| | vma | next | |----------|------| We find ourselves in the merge right scenario, but the one in which we cannot remove the middle (we are offset into vma). Here we have a special case where vmg->start, end get set to perhaps unintuitive values - we intended to shrink the middle VMA and expand the next. This means
start, end get set to perhaps unintuitive values - we intended to shrink the middle VMA and expand the next. This means vmg->start, end are set to... vma->vm_start, start. Now the commit_merge() fails, and vmg->start, end are left like this. This means we return to the rest of vma_modify() with vmg->start, end (here denoted as start', end') set as: start' end' |<-->| |----------|------| | vma | next | |----------|------| So we now erroneously try to split accordingly. This is where the unfortunate ---truncated--- References: - https://git.kernel.org/stable/c/79636d2981b066acd945117387a9533f56411f6f - https://git.kernel.org/stable/c/53fd215f7886a1e8dea5a9ca1391dbb697fff601 - https://git.kerne
cd945117387a9533f56411f6f - https://git.kernel.org/stable/c/53fd215f7886a1e8dea5a9ca1391dbb697fff601 - https://git.kernel.org/stable/c/47b16d0462a460000b8f05dfb1292377ac48f3ca
CVE ID: CVE-2025-21933 State: PUBLISHED Published: 2025-04-01T15:41:02.300Z Last Updated: 2025-10-01T19:26:33.367Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: arm: pgtable: fix NULL pointer dereference issue When update_mmu_cache_range() is called by update_mmu_cache(), the vmf parameter is NULL, which will cause a NULL pointer dereference issue in adjust_pte(): Unable to handle kernel NULL pointer dereference at virtual address 00000030 when read Hardware name: Atmel AT91SAM9 PC is at update_mmu_cache_range+0x1e0/0x278 LR is at pte_offset_map_rw_nolock+0x18/0x2c Call trace: update_mmu_cache_range from remove_migration_pte+0
e+0x1e0/0x278 LR is at pte_offset_map_rw_nolock+0x18/0x2c Call trace: update_mmu_cache_range from remove_migration_pte+0x29c/0x2ec remove_migration_pte from rmap_walk_file+0xcc/0x130 rmap_walk_file from remove_migration_ptes+0x90/0xa4 remove_migration_ptes from migrate_pages_batch+0x6d4/0x858 migrate_pages_batch from migrate_pages+0x188/0x488 migrate_pages from compact_zone+0x56c/0x954 compact_zone from compact_node+0x90/0xf0 compact_node from kcompactd+0x1d4/0x204 kcompactd from kthread+0x120/0x12c kthread from ret_from_fork+0x14/0x38 Exception stack(0xc0d8bfb0 to 0xc0d8bff8) To fix it, do not rely on whether 'ptl' is equal to decide whether to hold the pte lock, but decide it by whether CO
f8) To fix it, do not rely on whether 'ptl' is equal to decide whether to hold the pte lock, but decide it by whether CONFIG_SPLIT_PTE_PTLOCKS is enabled. In addition, if two vmas map to the same PTE page, there is no need to hold the pte lock again, otherwise a deadlock will occur. Just add the need_lock parameter to let adjust_pte() know this information. Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/91d011efe30aedde067ce6d218d521cf99b162e5 - https://git.kernel.org/stable/c/a564ccfe300fa6a065beda06ab7f3c140d6b4d63
CVE ID: CVE-2025-21934 State: PUBLISHED Published: 2025-04-01T15:41:02.804Z Last Updated: 2025-11-03T19:39:30.684Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: rapidio: fix an API misues when rio_add_net() fails rio_add_net() calls device_register() and fails when device_register() fails. Thus, put_device() should be used rather than kfree(). Add "mport->net = NULL;" to avoid a use after free issue. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/d4ec862ce80f64db923a1d942b5d11cf6fc87d36 - https://git.kernel.org/stable/c/88ddad53e4cfb6de861c6d4fb7b25427f
rg/stable/c/d4ec862ce80f64db923a1d942b5d11cf6fc87d36 - https://git.kernel.org/stable/c/88ddad53e4cfb6de861c6d4fb7b25427f46baed5 - https://git.kernel.org/stable/c/cdd9f58f7fe41a55fae4305ea51fc234769fd466 - https://git.kernel.org/stable/c/a5f5e520e8fbc6294020ff8afa36f684d92c6e6a - https://git.kernel.org/stable/c/2537f01d57f08c527e40bbb5862aa6ff43344898 - https://git.kernel.org/stable/c/22e4977141dfc6d109bf29b495bf2187b4250990 - https://git.kernel.org/stable/c/f0aa4ee1cbbf7789907e5a3f6810de01c146c211 - https://git.kernel.org/stable/c/b2ef51c74b0171fde7eb69b6152d3d2f743ef269
CVE ID: CVE-2025-21935 State: PUBLISHED Published: 2025-04-01T15:41:03.335Z Last Updated: 2025-11-03T19:39:33.438Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: rapidio: add check for rio_add_net() in rio_scan_alloc_net() The return value of rio_add_net() should be checked. If it fails, put_device() should be called to free the memory and give up the reference initialized in rio_add_net(). Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/6d22953c4a183d0b7fdf34d68c5debd16da6edc5 - https://git.kernel.org/stable/c/4f3509cfcc02e9d757f2714bb7dbbeec35de6fa7 - https://git.kernel.org/sta
8c5debd16da6edc5 - https://git.kernel.org/stable/c/4f3509cfcc02e9d757f2714bb7dbbeec35de6fa7 - https://git.kernel.org/stable/c/181d4daaefb3bceeb2f2635ba9f3781eeda9e550 - https://git.kernel.org/stable/c/ad82be4298a89a9ae46f07128bdf3d8614bce745 - https://git.kernel.org/stable/c/e6411c3b9512dba09af7d014d474516828c89706 - https://git.kernel.org/stable/c/c332f3e2df0fcae5a45fd55cc18902fb1e4825ca - https://git.kernel.org/stable/c/a0d069ccc475abaaa79c6368ee27fc0b5912bea8 - https://git.kernel.org/stable/c/e842f9a1edf306bf36fe2a4d847a0b0d458770de
CVE ID: CVE-2025-21936 State: PUBLISHED Published: 2025-04-01T15:41:03.845Z Last Updated: 2025-11-03T19:39:34.824Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: Bluetooth: Add check for mgmt_alloc_skb() in mgmt_device_connected() Add check for the return value of mgmt_alloc_skb() in mgmt_device_connected() to prevent null pointer dereference. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/dc516e66fb28c61b248b393e2ddd63bd7f104969 - https://git.kernel.org/stable/c/bdb1805c248e9694dbb3ffa8867cef2e52cf7261 - https://git.kernel.org/stable/c/7841180342c9a0fd9
s://git.kernel.org/stable/c/bdb1805c248e9694dbb3ffa8867cef2e52cf7261 - https://git.kernel.org/stable/c/7841180342c9a0fd97d54f3e62c7369309b5cd84 - https://git.kernel.org/stable/c/7d39387886ffe220323cbed5c155233c3276926b - https://git.kernel.org/stable/c/d8df010f72b8a32aaea393e36121738bb53ed905
CVE ID: CVE-2025-21937 State: PUBLISHED Published: 2025-04-01T15:41:04.378Z Last Updated: 2025-11-03T19:39:36.194Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: Bluetooth: Add check for mgmt_alloc_skb() in mgmt_remote_name() Add check for the return value of mgmt_alloc_skb() in mgmt_remote_name() to prevent null pointer dereference. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/37785a01040cb5d11ed0ddbcbf78491fcd073161 - https://git.kernel.org/stable/c/c5845c73cbacf5704169283ef29ca02031a36564 - https://git.kernel.org/stable/c/88310caff68ae69d0574859f792
rnel.org/stable/c/c5845c73cbacf5704169283ef29ca02031a36564 - https://git.kernel.org/stable/c/88310caff68ae69d0574859f7926a59c1da2d60b - https://git.kernel.org/stable/c/69fb168b88e4d62cb31cdd725b67ccc5216cfcaf - https://git.kernel.org/stable/c/f2176a07e7b19f73e05c805cf3d130a2999154cb
CVE ID: CVE-2025-21938 State: PUBLISHED Published: 2025-04-01T15:41:04.886Z Last Updated: 2025-11-03T19:39:37.579Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: mptcp: fix 'scheduling while atomic' in mptcp_pm_nl_append_new_local_addr If multiple connection requests attempt to create an implicit mptcp endpoint in parallel, more than one caller may end up in mptcp_pm_nl_append_new_local_addr because none found the address in local_addr_list during their call to mptcp_pm_nl_get_local_id. In this case, the concurrent new_local_addr calls may delete the address entry created by the previous caller. These deletes use synchronize_rc
rrent new_local_addr calls may delete the address entry created by the previous caller. These deletes use synchronize_rcu, but this is not permitted in some of the contexts where this function may be called. During packet recv, the caller may be in a rcu read critical section and have preemption disabled. An example stack: BUG: scheduling while atomic: swapper/2/0/0x00000302 Call Trace: <IRQ> dump_stack_lvl (lib/dump_stack.c:117 (discriminator 1)) dump_stack (lib/dump_stack.c:124) __schedule_bug (kernel/sched/core.c:5943) schedule_debug.constprop.0 (arch/x86/include/asm/preempt.h:33 kernel/sched/core.c:5970) __schedule (arch/x86/include/asm/jump_label.h:27 include/linux/jump_label.h:207 kern
empt.h:33 kernel/sched/core.c:5970) __schedule (arch/x86/include/asm/jump_label.h:27 include/linux/jump_label.h:207 kernel/sched/features.h:29 kernel/sched/core.c:6621) schedule (arch/x86/include/asm/preempt.h:84 kernel/sched/core.c:6804 kernel/sched/core.c:6818) schedule_timeout (kernel/time/timer.c:2160) wait_for_completion (kernel/sched/completion.c:96 kernel/sched/completion.c:116 kernel/sched/completion.c:127 kernel/sched/completion.c:148) __wait_rcu_gp (include/linux/rcupdate.h:311 kernel/rcu/update.c:444) synchronize_rcu (kernel/rcu/tree.c:3609) mptcp_pm_nl_append_new_local_addr (net/mptcp/pm_netlink.c:966 net/mptcp/pm_netlink.c:1061) mptcp_pm_nl_get_local_id (net/mptcp/pm_netlink.c:1
w_local_addr (net/mptcp/pm_netlink.c:966 net/mptcp/pm_netlink.c:1061) mptcp_pm_nl_get_local_id (net/mptcp/pm_netlink.c:1164) mptcp_pm_get_local_id (net/mptcp/pm.c:420) subflow_check_req (net/mptcp/subflow.c:98 net/mptcp/subflow.c:213) subflow_v4_route_req (net/mptcp/subflow.c:305) tcp_conn_request (net/ipv4/tcp_input.c:7216) subflow_v4_conn_request (net/mptcp/subflow.c:651) tcp_rcv_state_process (net/ipv4/tcp_input.c:6709) tcp_v4_do_rcv (net/ipv4/tcp_ipv4.c:1934) tcp_v4_rcv (net/ipv4/tcp_ipv4.c:2334) ip_protocol_deliver_rcu (net/ipv4/ip_input.c:205 (discriminator 1)) ip_local_deliver_finish (include/linux/rcupdate.h:813 net/ipv4/ip_input.c:234) ip_local_deliver (include/linux/netfilter.h:314
al_deliver_finish (include/linux/rcupdate.h:813 net/ipv4/ip_input.c:234) ip_local_deliver (include/linux/netfilter.h:314 include/linux/netfilter.h:308 net/ipv4/ip_input.c:254) ip_sublist_rcv_finish (include/net/dst.h:461 net/ipv4/ip_input.c:580) ip_sublist_rcv (net/ipv4/ip_input.c:640) ip_list_rcv (net/ipv4/ip_input.c:675) __netif_receive_skb_list_core (net/core/dev.c:5583 net/core/dev.c:5631) netif_receive_skb_list_internal (net/core/dev.c:5685 net/core/dev.c:5774) napi_complete_done (include/linux/list.h:37 include/net/gro.h:449 include/net/gro.h:444 net/core/dev.c:6114) igb_poll (drivers/net/ethernet/intel/igb/igb_main.c:8244) igb __napi_poll (net/core/dev.c:6582) net_rx_action (net/core/
igb_poll (drivers/net/ethernet/intel/igb/igb_main.c:8244) igb __napi_poll (net/core/dev.c:6582) net_rx_action (net/core/dev.c:6653 net/core/dev.c:6787) handle_softirqs (kernel/softirq.c:553) __irq_exit_rcu (kernel/softirq.c:588 kernel/softirq.c:427 kernel/softirq.c:636) irq_exit_rcu (kernel/softirq.c:651) common_interrupt (arch/x86/kernel/irq.c:247 (discriminator 14)) </IRQ> This problem seems particularly prevalent if the user advertises an endpoint that has a different external vs internal address. In the case where the external address is advertised and multiple connections already exist, multiple subflow SYNs arrive in parallel which tends to trigger the race during creation of the first
ons already exist, multiple subflow SYNs arrive in parallel which tends to trigger the race during creation of the first local_addr_list entries which have the internal address instead. Fix by skipping the replacement of an existing implicit local address if called via mptcp_pm_nl_get_local_id. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/f1404f368c40fc6a068dad72e4ee0824ee6a78ee - https://git.kernel.org/stable/c/f3fcdb2de9fdbed9d8c6a8eb2c5fbd7d6f54a4d8 - https://git.kernel.org/stable/c/4b228dae3d2cc6d9dce167449cd8fa9f028e9376 - https://git.kernel.org/stable/c/125ccafe6dd062901b5a0c31ee9038740fc8859e - https://git.kernel.org/stable/c/022bfe2
376 - https://git.kernel.org/stable/c/125ccafe6dd062901b5a0c31ee9038740fc8859e - https://git.kernel.org/stable/c/022bfe24aad8937705704ff2e414b100cf0f2e1a
CVE ID: CVE-2025-21939 State: PUBLISHED Published: 2025-04-01T15:41:05.393Z Last Updated: 2025-05-04T07:25:05.653Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: drm/xe/hmm: Don't dereference struct page pointers without notifier lock The pnfs that we obtain from hmm_range_fault() point to pages that we don't have a reference on, and the guarantee that they are still in the cpu page-tables is that the notifier lock must be held and the notifier seqno is still valid. So while building the sg table and marking the pages accesses / dirty we need to hold this lock with a validated seqno. However, the lock is reclaim tainted which m
he pages accesses / dirty we need to hold this lock with a validated seqno. However, the lock is reclaim tainted which makes sg_alloc_table_from_pages_segment() unusable, since it internally allocates memory. Instead build the sg-table manually. For the non-iommu case this might lead to fewer coalesces, but if that's a problem it can be fixed up later in the resource cursor code. For the iommu case, the whole sg-table may still be coalesced to a single contigous device va region. This avoids marking pages that we don't own dirty and accessed, and it also avoid dereferencing struct pages that we don't own. v2: - Use assert to check whether hmm pfns are valid (Matthew Auld) - Take into account
struct pages that we don't own. v2: - Use assert to check whether hmm pfns are valid (Matthew Auld) - Take into account that large pages may cross range boundaries (Matthew Auld) v3: - Don't unnecessarily check for a non-freed sg-table. (Matthew Auld) - Add a missing up_read() in an error path. (Matthew Auld) (cherry picked from commit ea3e66d280ce2576664a862693d1da8fd324c317) References: - https://git.kernel.org/stable/c/2a24c98f0e4cc994334598d4f3a851972064809d - https://git.kernel.org/stable/c/f9326f529da7298a95643c3267f1c0fdb0db55eb - https://git.kernel.org/stable/c/0a98219bcc961edd3388960576e4353e123b4a51
CVE ID: CVE-2025-21940 State: PUBLISHED Published: 2025-04-01T15:41:05.977Z Last Updated: 2025-10-01T19:26:32.688Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: Fix NULL Pointer Dereference in KFD queue Through KFD IOCTL Fuzzing we encountered a NULL pointer derefrence when calling kfd_queue_acquire_buffers. (cherry picked from commit 049e5bf3c8406f87c3d8e1958e0a16804fa1d530) Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/c3cbeafb4e0001d9146df50b470885e02664f3c7 - https://git.kernel.org/stable/c/33eb8041c5d6c19d46e7bfd23a031844336afd80 - https://git.kernel.org/stabl
0885e02664f3c7 - https://git.kernel.org/stable/c/33eb8041c5d6c19d46e7bfd23a031844336afd80 - https://git.kernel.org/stable/c/fd617ea3b79d2116d53f76cdb5a3601c0ba6e42f
CVE ID: CVE-2025-21941 State: PUBLISHED Published: 2025-04-01T15:41:06.489Z Last Updated: 2025-11-03T19:39:40.415Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix null check for pipe_ctx->plane_state in resource_build_scaling_params Null pointer dereference issue could occur when pipe_ctx->plane_state is null. The fix adds a check to ensure 'pipe_ctx->plane_state' is not null before accessing. This prevents a null pointer dereference. Found by code review. (cherry picked from commit 63e6a77ccf239337baa9b1e7787cde9fa0462092) Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: Reference
ccf239337baa9b1e7787cde9fa0462092) Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/265422915416468ba91bffa56addbff45e18342a - https://git.kernel.org/stable/c/f435192e00bc4d5d4134356b93212670ec47fa8d - https://git.kernel.org/stable/c/c1e54752dc12e90305eb0475ca908f42f5b369ca - https://git.kernel.org/stable/c/3b3c2be58d5275aa59d8b4810a59f173f2f5bac1 - https://git.kernel.org/stable/c/e0345c3478f185ca840daac7f08a1fcd4ebec3e9 - https://git.kernel.org/stable/c/3748fad09d89e9a5290e1738fd6872a79f794743 - https://git.kernel.org/stable/c/374c9faac5a763a05bc3f68ad9f73dab3c6aec90
CVE ID: CVE-2025-21942 State: PUBLISHED Published: 2025-04-01T15:41:06.977Z Last Updated: 2025-07-06T09:08:50.894Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: btrfs: zoned: fix extent range end unlock in cow_file_range() Running generic/751 on the for-next branch often results in a hang like below. They are both stack by locking an extent. This suggests someone forget to unlock an extent. INFO: task kworker/u128:1:12 blocked for more than 323 seconds. Not tainted 6.13.0-BTRFS-ZNS+ #503 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:kworker/u128:1 state:D stack:0 pid:12 tgid:12 ppid:2 flags:0x0
ernel/hung_task_timeout_secs" disables this message. task:kworker/u128:1 state:D stack:0 pid:12 tgid:12 ppid:2 flags:0x00004000 Workqueue: btrfs-fixup btrfs_work_helper [btrfs] Call Trace: <TASK> __schedule+0x534/0xdd0 schedule+0x39/0x140 __lock_extent+0x31b/0x380 [btrfs] ? __pfx_autoremove_wake_function+0x10/0x10 btrfs_writepage_fixup_worker+0xf1/0x3a0 [btrfs] btrfs_work_helper+0xff/0x480 [btrfs] ? lock_release+0x178/0x2c0 process_one_work+0x1ee/0x570 ? srso_return_thunk+0x5/0x5f worker_thread+0x1d1/0x3b0 ? __pfx_worker_thread+0x10/0x10 kthread+0x10b/0x230 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x30/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 </TASK> INFO: task kworker/u134:
0x10/0x10 ret_from_fork+0x30/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 </TASK> INFO: task kworker/u134:0:184 blocked for more than 323 seconds. Not tainted 6.13.0-BTRFS-ZNS+ #503 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:kworker/u134:0 state:D stack:0 pid:184 tgid:184 ppid:2 flags:0x00004000 Workqueue: writeback wb_workfn (flush-btrfs-4) Call Trace: <TASK> __schedule+0x534/0xdd0 schedule+0x39/0x140 __lock_extent+0x31b/0x380 [btrfs] ? __pfx_autoremove_wake_function+0x10/0x10 find_lock_delalloc_range+0xdb/0x260 [btrfs] writepage_delalloc+0x12f/0x500 [btrfs] ? srso_return_thunk+0x5/0x5f extent_write_cache_pages+0x232/0x840 [btrfs] btrfs_writ
tepage_delalloc+0x12f/0x500 [btrfs] ? srso_return_thunk+0x5/0x5f extent_write_cache_pages+0x232/0x840 [btrfs] btrfs_writepages+0x72/0x130 [btrfs] do_writepages+0xe7/0x260 ? srso_return_thunk+0x5/0x5f ? lock_acquire+0xd2/0x300 ? srso_return_thunk+0x5/0x5f ? find_held_lock+0x2b/0x80 ? wbc_attach_and_unlock_inode.part.0+0x102/0x250 ? wbc_attach_and_unlock_inode.part.0+0x102/0x250 __writeback_single_inode+0x5c/0x4b0 writeback_sb_inodes+0x22d/0x550 __writeback_inodes_wb+0x4c/0xe0 wb_writeback+0x2f6/0x3f0 wb_workfn+0x32a/0x510 process_one_work+0x1ee/0x570 ? srso_return_thunk+0x5/0x5f worker_thread+0x1d1/0x3b0 ? __pfx_worker_thread+0x10/0x10 kthread+0x10b/0x230 ? __pfx_kthread+0x10/0x10 ret_from_fo
0x5f worker_thread+0x1d1/0x3b0 ? __pfx_worker_thread+0x10/0x10 kthread+0x10b/0x230 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x30/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 </TASK> This happens because we have another success path for the zoned mode. When there is no active zone available, btrfs_reserve_extent() returns -EAGAIN. In this case, we have two reactions. (1) If the given range is never allocated, we can only wait for someone to finish a zone, so wait on BTRFS_FS_NEED_ZONE_FINISH bit and retry afterward. (2) Or, if some allocations are already done, we must bail out and let the caller to send IOs for the allocation. This is because these IOs may be necessary to finish
we must bail out and let the caller to send IOs for the allocation. This is because these IOs may be necessary to finish a zone. The commit 06f364284794 ("btrfs: do proper folio cleanup when cow_file_range() failed") moved the unlock code from the inside of the loop to the outside. So, previously, the allocated extents are unlocked just after the allocation and so before returning from the function. However, they are no longer unlocked on the case (2) above. That caused the hang issue. Fix the issue by modifying the 'end' to the end of the allocated range. Then, we can exit the loop and the same unlock code can properly handle the case. References: - https://git.kernel.org/stable/c/5f4863cfb
the loop and the same unlock code can properly handle the case. References: - https://git.kernel.org/stable/c/5f4863cfb29a7b4fe7625ce148d0b9000b75b802 - https://git.kernel.org/stable/c/3fcff2f55389306482ab049b4321bda49495e546 - https://git.kernel.org/stable/c/5a4041f2c47247575a6c2e53ce14f7b0ac946c33
CVE ID: CVE-2025-21943 State: PUBLISHED Published: 2025-04-01T15:41:07.463Z Last Updated: 2025-11-03T19:39:43.188Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: gpio: aggregator: protect driver attr handlers against module unload Both new_device_store and delete_device_store touch module global resources (e.g. gpio_aggregator_lock). To prevent race conditions with module unload, a reference needs to be held. Add try_module_get() in these handlers. For new_device_store, this eliminates what appears to be the most dangerous scenario: if an id is allocated from gpio_aggregator_idr but platform_device_register has not yet been cal
ost dangerous scenario: if an id is allocated from gpio_aggregator_idr but platform_device_register has not yet been called or completed, a concurrent module unload could fail to unregister/delete the device, leaving behind a dangling platform device/GPIO forwarder. This can result in various issues. The following simple reproducer demonstrates these problems: #!/bin/bash while :; do # note: whether 'gpiochip0 0' exists or not does not matter. echo 'gpiochip0 0' > /sys/bus/platform/drivers/gpio-aggregator/new_device done & while :; do modprobe gpio-aggregator modprobe -r gpio-aggregator done & wait Starting with the following warning, several kinds of warnings will appear and the system may
io-aggregator done & wait Starting with the following warning, several kinds of warnings will appear and the system may become unstable: ------------[ cut here ]------------ list_del corruption, ffff888103e2e980->next is LIST_POISON1 (dead000000000100) WARNING: CPU: 1 PID: 1327 at lib/list_debug.c:56 __list_del_entry_valid_or_report+0xa3/0x120 [...] RIP: 0010:__list_del_entry_valid_or_report+0xa3/0x120 [...] Call Trace: <TASK> ? __list_del_entry_valid_or_report+0xa3/0x120 ? __warn.cold+0x93/0xf2 ? __list_del_entry_valid_or_report+0xa3/0x120 ? report_bug+0xe6/0x170 ? __irq_work_queue_local+0x39/0xe0 ? handle_bug+0x58/0x90 ? exc_invalid_op+0x13/0x60 ? asm_exc_invalid_op+0x16/0x20 ? __list_del_