xamxte/cve-to-cwe huggingface dataset:
CVE-2025-38564: In the Linux kernel, the following vulnerability has been resolved:  perf/core: Handle buffer mapping fail correctly in perf_mmap()  After successful allocation of a buffer or a successful attachment to an existing buffer perf_mmap() tries to map the buffer read only into the page table. If that fails, the already set up page table entries are zapped, but the other perf specific side effects of that failure are not handled.  The calling code just cleans up the VMA and does not invoke perf_mmap_close().  This leaks reference counts, corrupts user->vm accounting and also results in an unbalanced invocation of event::event_mapped().  Cure this by moving the event::event_mapped() invocation before the map_range() call so that on map_range() failure perf_mmap_close() can be invoked without causing an unbalanced event::event_unmapped() call.  perf_mmap_close() undoes the reference counts and eventually frees buffers.
CVE-2025-38565: In the Linux kernel, the following vulnerability has been resolved:  perf/core: Exit early on perf_mmap() fail  When perf_mmap() fails to allocate a buffer, it still invokes the event_mapped() callback of the related event. On X86 this might increase the perf_rdpmc_allowed reference counter. But nothing undoes this as perf_mmap_close() is never called in this case, which causes another reference count leak.  Return early on failure to prevent that.
CVE-2025-38572: In the Linux kernel, the following vulnerability has been resolved:  ipv6: reject malicious packets in ipv6_gso_segment()  syzbot was able to craft a packet with very long IPv6 extension headers leading to an overflow of skb->transport_header.  This 16bit field has a limited range.  Add skb_reset_transport_header_careful() helper and use it from ipv6_gso_segment()  WARNING: CPU: 0 PID: 5871 at ./include/linux/skbuff.h:3032 skb_reset_transport_header include/linux/skbuff.h:3032 [inline] WARNING: CPU: 0 PID: 5871 at ./include/linux/skbuff.h:3032 ipv6_gso_segment+0x15e2/0x21e0 net/ipv6/ip6_offload.c:151 Modules linked in: CPU: 0 UID: 0 PID: 5871 Comm: syz-executor211 Not tainted 6.16.0-rc6-syzkaller-g7abc678e3084 #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/12/2025  RIP: 0010:skb_reset_transport_header include/linux/skbuff.h:3032 [inline]  RIP: 0010:ipv6_gso_segment+0x15e2/0x21e0 net/ipv6/ip6_offload.c:151 Call Trace:  <TASK>   skb_mac_gso_segment+0x31c/0x640 net/core/gso.c:53   nsh_gso_segment+0x54a/0xe10 net/nsh/nsh.c:110   skb_mac_gso_segment+0x31c/0x640 net/core/gso.c:53   __skb_gso_segment+0x342/0x510 net/core/gso.c:124   skb_gso_segment include/net/gso.h:83 [inline]   validate_xmit_skb+0x857/0x11b0 net/core/dev.c:3950   validate_xmit_skb_list+0x84/0x120 net/core/dev.c:4000   sch_direct_xmit+0xd3/0x4b0 net/sched/sch_generic.c:329   __dev_xmit_skb net/core/dev.c:4102 [inline]   __dev_queue_xmit+0x17b6/0x3a70 net/core/dev.c:4679
CVE-2025-38576: In the Linux kernel, the following vulnerability has been resolved:  powerpc/eeh: Make EEH driver device hotplug safe  Multiple race conditions existed between the PCIe hotplug driver and the EEH driver, leading to a variety of kernel oopses of the same general nature:  <pcie device unplug> <eeh driver trigger> <hotplug removal trigger> <pcie tree reconfiguration> <eeh recovery next step> <oops in EEH driver bus iteration loop>  A second class of oops is also seen when the underlying bus disappears during device recovery.  Refactor the EEH module to be PCI rescan and remove safe.  Also clean up a few minor formatting / readability issues.
CVE-2025-38622: In the Linux kernel, the following vulnerability has been resolved:  net: drop UFO packets in udp_rcv_segment()  When sending a packet with virtio_net_hdr to tun device, if the gso_type in virtio_net_hdr is SKB_GSO_UDP and the gso_size is less than udphdr size, below crash may happen.    ------------[ cut here ]------------   kernel BUG at net/core/skbuff.c:4572!   Oops: invalid opcode: 0000 [#1] SMP NOPTI   CPU: 0 UID: 0 PID: 62 Comm: mytest Not tainted 6.16.0-rc7 #203 PREEMPT(voluntary)   Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014   RIP: 0010:skb_pull_rcsum+0x8e/0xa0   Code: 00 00 5b c3 cc cc cc cc 8b 93 88 00 00 00 f7 da e8 37 44 38 00 f7 d8 89 83 88 00 00 00 48 8b 83 c8 00 00 00 5b c3 cc cc cc cc <0f> 0b 0f 0b 66 66 2e 0f 1f 84 00 000   RSP: 0018:ffffc900001fba38 EFLAGS: 00000297   RAX: 0000000000000004 RBX: ffff8880040c1000 RCX: ffffc900001fb948   RDX: ffff888003e6d700 RSI: 0000000000000008 RDI: ffff88800411a062   RBP: ffff8880040c1000 R08: 0000000000000000 R09: 0000000000000001   R10: ffff888003606c00 R11: 0000000000000001 R12: 0000000000000000   R13: ffff888004060900 R14: ffff888004050000 R15: ffff888004060900   FS:  000000002406d3c0(0000) GS:ffff888084a19000(0000) knlGS:0000000000000000   CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033   CR2: 0000000020000040 CR3: 0000000004007000 CR4: 00000000000006f0   Call Trace:    <TASK>    udp_queue_rcv_one_skb+0x176/0x4b0 net/ipv4/udp.c:2445    udp_queue_rcv_skb+0x155/0x1f0 net/ipv4/udp.c:2475    udp_unicast_rcv_skb+0x71/0x90 net/ipv4/udp.c:2626    __udp4_lib_rcv+0x433/0xb00 net/ipv4/udp.c:2690    ip_protocol_deliver_rcu+0xa6/0x160 net/ipv4/ip_input.c:205    ip_local_deliver_finish+0x72/0x90 net/ipv4/ip_input.c:233    ip_sublist_rcv_finish+0x5f/0x70 net/ipv4/ip_input.c:579    ip_sublist_rcv+0x122/0x1b0 net/ipv4/ip_input.c:636    ip_list_rcv+0xf7/0x130 net/ipv4/ip_input.c:670    __netif_receive_skb_list_core+0x21d/0x240 net/core/dev.c:6067    netif_receive_skb_list_internal+0x186/0x2b0 net/core/dev.c:6210    napi_complete_done+0x78/0x180 net/core/dev.c:6580    tun_get_user+0xa63/0x1120 drivers/net/tun.c:1909    tun_chr_write_iter+0x65/0xb0 drivers/net/tun.c:1984    vfs_write+0x300/0x420 fs/read_write.c:593    ksys_write+0x60/0xd0 fs/read_write.c:686    do_syscall_64+0x50/0x1c0 arch/x86/entry/syscall_64.c:63    </TASK>  To trigger gso segment in udp_queue_rcv_skb(), we should also set option UDP_ENCAP_ESPINUDP to enable udp_sk(sk)->encap_rcv. When the encap_rcv hook return 1 in udp_queue_rcv_one_skb(), udp_csum_pull_header() will try to pull udphdr, but the skb size has been segmented to gso size, which leads to this crash.  Previous commit cf329aa42b66 ("udp: cope with UDP GRO packet misdirection") introduces segmentation in UDP receive path only for GRO, which was never intended to be used for UFO, so drop UFO packets in udp_rcv_segment().
CVE-2025-38624: In the Linux kernel, the following vulnerability has been resolved:  PCI: pnv_php: Clean up allocated IRQs on unplug  When the root of a nested PCIe bridge configuration is unplugged, the pnv_php driver leaked the allocated IRQ resources for the child bridges' hotplug event notifications, resulting in a panic.  Fix this by walking all child buses and deallocating all its IRQ resources before calling pci_hp_remove_devices().  Also modify the lifetime of the workqueue at struct pnv_php_slot::wq so that it is only destroyed in pnv_php_free_slot(), instead of pnv_php_disable_irq(). This is required since pnv_php_disable_irq() will now be called by workers triggered by hot unplug interrupts, so the workqueue needs to stay allocated.  The abridged kernel panic that occurs without this patch is as follows:    WARNING: CPU: 0 PID: 687 at kernel/irq/msi.c:292 msi_device_data_release+0x6c/0x9c   CPU: 0 UID: 0 PID: 687 Comm: bash Not tainted 6.14.0-rc5+ #2   Call Trace:    msi_device_data_release+0x34/0x9c (unreliable)    release_nodes+0x64/0x13c    devres_release_all+0xc0/0x140    device_del+0x2d4/0x46c    pci_destroy_dev+0x5c/0x194    pci_hp_remove_devices+0x90/0x128    pci_hp_remove_devices+0x44/0x128    pnv_php_disable_slot+0x54/0xd4    power_write_file+0xf8/0x18c    pci_slot_attr_store+0x40/0x5c    sysfs_kf_write+0x64/0x78    kernfs_fop_write_iter+0x1b0/0x290    vfs_write+0x3bc/0x50c    ksys_write+0x84/0x140    system_call_exception+0x124/0x230    system_call_vectored_common+0x15c/0x2ec  [bhelgaas: tidy comments]
CVE-2025-38639: In the Linux kernel, the following vulnerability has been resolved:  netfilter: xt_nfacct: don't assume acct name is null-terminated  BUG: KASAN: slab-out-of-bounds in .. lib/vsprintf.c:721 Read of size 1 at addr ffff88801eac95c8 by task syz-executor183/5851 [..]  string+0x231/0x2b0 lib/vsprintf.c:721  vsnprintf+0x739/0xf00 lib/vsprintf.c:2874  [..]  nfacct_mt_checkentry+0xd2/0xe0 net/netfilter/xt_nfacct.c:41  xt_check_match+0x3d1/0xab0 net/netfilter/x_tables.c:523  nfnl_acct_find_get() handles non-null input, but the error printk relied on its presence.
CVE-2025-38663: In the Linux kernel, the following vulnerability has been resolved:  nilfs2: reject invalid file types when reading inodes  To prevent inodes with invalid file types from tripping through the vfs and causing malfunctions or assertion failures, add a missing sanity check when reading an inode from a block device.  If the file type is not valid, treat it as a filesystem error.
CVE-2025-38671: In the Linux kernel, the following vulnerability has been resolved:  i2c: qup: jump out of the loop in case of timeout  Original logic only sets the return value but doesn't jump out of the loop if the bus is kept active by a client. This is not expected. A malicious or buggy i2c client can hang the kernel in this case and should be avoided. This is observed during a long time test with a PCA953x GPIO extender.  Fix it by changing the logic to not only sets the return value, but also jumps out of the loop and return to the caller with -ETIMEDOUT.
CVE-2023-21468: Improper access control vulnerability in Telephony prior to SMR Apr-2023 Release 1 allows attackers to access files with escalated permission.
CVE-2023-21469: Improper access control vulnerability in SLocation prior to SMR Apr-2022 Release 1 allows local attackers to get device location information using com.samsung.android.wifi.GEOFENCE action.
CVE-2023-21470: Improper access control vulnerability in SLocation prior to SMR Apr-2022 Release 1 allows local attackers to get device location information using com.samsung.android.wifi.NETWORK_LOCATION action.
CVE-2023-21479: Improper authorization in Smart suggestions prior to SMR Apr-2023 Release 1 in Android 13 and 4.1.01.0 in Android 12 allows remote attackers to register a schedule.
CVE-2023-21482: Missing authorization vulnerability in Camera prior to versions 11.1.02.18 in Android 11, 12.1.03.8 in Android 12 and 13.1.01.4 in Android 13  allows physical attackers to install package through Galaxy store before completion of Setup wizard.
CVE-2023-21483: Improper Access Control vulnerability in Galaxy Store prior to version 4.5.53.6 allows local attacker to access protected data using exported service.
CVE-2025-21025: Improper access control in MARsExemptionManager prior to SMR Sep-2025 Release 1 allows local attackers to be excluded from background execution management.
CVE-2025-21028: Improper privilege management in ThemeManager prior to SMR Sep-2025 Release 1 allows local privileged attackers to reuse trial items.
CVE-2025-21032: Improper access control in One UI Home prior to SMR Sep-2025 Release 1 allows physical attackers to bypass Kiosk mode under limited conditions.
CVE-2025-21033: Improper access control in ContactProvider prior to SMR Sep-2025 Release 1 allows local attackers to access sensitive information.
CVE-2025-21035: Improper access control in Samsung Calendar prior to version 12.5.06.5 in Android 14 and 12.6.01.12 in Android 15 allows physical attackers to access data across multiple user profiles.
CVE-2025-21036: Improper access control in Samsung Notes prior to version 4.4.30.63 allows local privileged attackers to access exported note files. User interaction is required for triggering this vulnerability.
CVE-2025-21037: Improper access control in Samsung Notes prior to version 4.4.30.63 allows physical attackers to access data across multiple user profiles. User interaction is required for triggering this vulnerability.
CVE-2025-21039: Improper verification of intent by SystemExceptionalBroadcastReceiver in S Assistant prior to version 9.3.2 allows local attackers to modify itinerary information.
CVE-2022-39888: Improper access control vulnerability in retrieveExternalProxy in MiscPolicy prior to SMR Nov-2022 Release 1 allows local attacker to access to Proxy information.
CVE-2024-34598: Improper export of component in GoodLock prior to version 2.2.04.95 allows local attackers to install arbitrary applications from Galaxy Store.
CVE-2025-38686: 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]
CVE-2025-38707: In the Linux kernel, the following vulnerability has been resolved:  fs/ntfs3: Add sanity check for file name  The length of the file name should be smaller than the directory entry size.
CVE-2025-38710: In the Linux kernel, the following vulnerability has been resolved:  gfs2: Validate i_depth for exhash directories  A fuzzer test introduced corruption that ends up with a depth of 0 in dir_e_read(), causing an undefined shift by 32 at:    index = hash >> (32 - dip->i_depth);  As calculated in an open-coded way in dir_make_exhash(), the minimum depth for an exhash directory is ilog2(sdp->sd_hash_ptrs) and 0 is invalid as sdp->sd_hash_ptrs is fixed as sdp->bsize / 16 at mount time.  So we can avoid the undefined behaviour by checking for depth values lower than the minimum in gfs2_dinode_in(). Values greater than the maximum are already being checked for there.  Also switch the calculation in dir_make_exhash() to use ilog2() to clarify how the depth is calculated.  Tested with the syzkaller repro.c and xfstests '-g quick'.
CVE-2025-38721: In the Linux kernel, the following vulnerability has been resolved:  netfilter: ctnetlink: fix refcount leak on table dump  There is a reference count leak in ctnetlink_dump_table():       if (res < 0) {                 nf_conntrack_get(&ct->ct_general); // HERE                 cb->args[1] = (unsigned long)ct;                 ...  While its very unlikely, its possible that ct == last. If this happens, then the refcount of ct was already incremented. This 2nd increment is never undone.  This prevents the conntrack object from being released, which in turn keeps prevents cnet->count from dropping back to 0.  This will then block the netns dismantle (or conntrack rmmod) as nf_conntrack_cleanup_net_list() will wait forever.  This can be reproduced by running conntrack_resize.sh selftest in a loop. It takes ~20 minutes for me on a preemptible kernel on average before I see a runaway kworker spinning in nf_conntrack_cleanup_net_list.  One fix would to change this to:         if (res < 0) {   if (ct != last)                  nf_conntrack_get(&ct->ct_general);  But this reference counting isn't needed in the first place. We can just store a cookie value instead.  A followup patch will do the same for ctnetlink_exp_dump_table, it looks to me as if this has the same problem and like ctnetlink_dump_table, we only need a 'skip hint', not the actual object so we can apply the same cookie strategy there as well.
CVE-2025-38723: In the Linux kernel, the following vulnerability has been resolved:  LoongArch: BPF: Fix jump offset calculation in tailcall  The extra pass of bpf_int_jit_compile() skips JIT context initialization which essentially skips offset calculation leaving out_offset = -1, so the jmp_offset in emit_bpf_tail_call is calculated by  "#define jmp_offset (out_offset - (cur_offset))"  is a negative number, which is wrong. The final generated assembly are as follow.  54: bgeu         $a2, $t1, -8     # 0x0000004c 58: addi.d       $a6, $s5, -1 5c: bltz         $a6, -16     # 0x0000004c 60: alsl.d       $t2, $a2, $a1, 0x3 64: ld.d         $t2, $t2, 264 68: beq          $t2, $zero, -28     # 0x0000004c  Before apply this patch, the follow test case will reveal soft lock issues.  cd tools/testing/selftests/bpf/ ./test_progs --allow=tailcalls/tailcall_bpf2bpf_1  dmesg: watchdog: BUG: soft lockup - CPU#2 stuck for 26s! [test_progs:25056]
CVE-2025-39681: In the Linux kernel, the following vulnerability has been resolved:  x86/cpu/hygon: Add missing resctrl_cpu_detect() in bsp_init helper  Since    923f3a2b48bd ("x86/resctrl: Query LLC monitoring properties once during boot")  resctrl_cpu_detect() has been moved from common CPU initialization code to the vendor-specific BSP init helper, while Hygon didn't put that call in their code.  This triggers a division by zero fault during early booting stage on our machines with X86_FEATURE_CQM* supported, where get_rdt_mon_resources() tries to calculate mon_l3_config with uninitialized boot_cpu_data.x86_cache_occ_scale.  Add the missing resctrl_cpu_detect() in the Hygon BSP init helper.    [ bp: Massage commit message. ]
CVE-2025-39687: In the Linux kernel, the following vulnerability has been resolved:  iio: light: as73211: Ensure buffer holes are zeroed  Given that the buffer is copied to a kfifo that ultimately user space can read, ensure we zero it.
CVE-2025-39695: In the Linux kernel, the following vulnerability has been resolved:  RDMA/rxe: Flush delayed SKBs while releasing RXE resources  When skb packets are sent out, these skb packets still depends on the rxe resources, for example, QP, sk, when these packets are destroyed.  If these rxe resources are released when the skb packets are destroyed, the call traces will appear.  To avoid skb packets hang too long time in some network devices, a timestamp is added when these skb packets are created. If these skb packets hang too long time in network devices, these network devices can free these skb packets to release rxe resources.
CVE-2025-39696: In the Linux kernel, the following vulnerability has been resolved:  ALSA: hda: tas2781: Fix wrong reference of tasdevice_priv  During the conversion to unify the calibration data management, the reference to tasdevice_priv was wrongly set to h->hda_priv instead of h->priv.  This resulted in memory corruption and crashes eventually. Unfortunately it's a void pointer, hence the compiler couldn't know that it's wrong.
CVE-2025-39714: In the Linux kernel, the following vulnerability has been resolved:  media: usbtv: Lock resolution while streaming  When an program is streaming (ffplay) and another program (qv4l2) changes the TV standard from NTSC to PAL, the kernel crashes due to trying to copy to unmapped memory.  Changing from NTSC to PAL increases the resolution in the usbtv struct, but the video plane buffer isn't adjusted, so it overflows.  [hverkuil: call vb2_is_busy instead of vb2_is_streaming]
CVE-2025-39720: In the Linux kernel, the following vulnerability has been resolved:  ksmbd: fix refcount leak causing resource not released  When ksmbd_conn_releasing(opinfo->conn) returns true,the refcount was not decremented properly, causing a refcount leak that prevents the count from reaching zero and the memory from being released.
CVE-2025-39732: In the Linux kernel, the following vulnerability has been resolved:  wifi: ath11k: fix sleeping-in-atomic in ath11k_mac_op_set_bitrate_mask()  ath11k_mac_disable_peer_fixed_rate() is passed as the iterator to ieee80211_iterate_stations_atomic(). Note in this case the iterator is required to be atomic, however ath11k_mac_disable_peer_fixed_rate() does not follow it as it might sleep. Consequently below warning is seen:  BUG: sleeping function called from invalid context at wmi.c:304 Call Trace:  <TASK>  dump_stack_lvl  __might_resched.cold  ath11k_wmi_cmd_send  ath11k_wmi_set_peer_param  ath11k_mac_disable_peer_fixed_rate  ieee80211_iterate_stations_atomic  ath11k_mac_op_set_bitrate_mask.cold  Change to ieee80211_iterate_stations_mtx() to fix this issue.  Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.30
CVE-2025-39734: In the Linux kernel, the following vulnerability has been resolved:  Revert "fs/ntfs3: Replace inode_trylock with inode_lock"  This reverts commit 69505fe98f198ee813898cbcaf6770949636430b.  Initially, conditional lock acquisition was removed to fix an xfstest bug that was observed during internal testing. The deadlock reported by syzbot is resolved by reintroducing conditional acquisition. The xfstest bug no longer occurs on kernel version 6.16-rc1 during internal testing. I assume that changes in other modules may have contributed to this.
CVE-2025-9034: The Wp Edit Password Protected  WordPress plugin before 1.3.5 does not validate a parameter before redirecting the user to its value, leading to an Open Redirect issue
CVE-2025-39741: In the Linux kernel, the following vulnerability has been resolved:  drm/xe/migrate: don't overflow max copy size  With non-page aligned copy, we need to use 4 byte aligned pitch, however the size itself might still be close to our maximum of ~8M, and so the dimensions of the copy can easily exceed the S16_MAX limit of the copy command leading to the following assert:  xe 0000:03:00.0: [drm] Assertion `size / pitch <= ((s16)(((u16)~0U) >> 1))` failed! platform: BATTLEMAGE subplatform: 1 graphics: Xe2_HPG 20.01 step A0 media: Xe2_HPM 13.01 step A1 tile: 0 VRAM 10.0 GiB GT: 0 type 1  WARNING: CPU: 23 PID: 10605 at drivers/gpu/drm/xe/xe_migrate.c:673 emit_copy+0x4b5/0x4e0 [xe]  To fix this account for the pitch when calculating the number of current bytes to copy.  (cherry picked from commit 8c2d61e0e916e077fda7e7b8e67f25ffe0f361fc)
CVE-2025-39749: In the Linux kernel, the following vulnerability has been resolved:  rcu: Protect ->defer_qs_iw_pending from data race  On kernels built with CONFIG_IRQ_WORK=y, when rcu_read_unlock() is invoked within an interrupts-disabled region of code [1], it will invoke rcu_read_unlock_special(), which uses an irq-work handler to force the system to notice when the RCU read-side critical section actually ends. That end won't happen until interrupts are enabled at the soonest.  In some kernels, such as those booted with rcutree.use_softirq=y, the irq-work handler is used unconditionally.  The per-CPU rcu_data structure's ->defer_qs_iw_pending field is updated by the irq-work handler and is both read and updated by rcu_read_unlock_special().  This resulted in the following KCSAN splat:  ------------------------------------------------------------------------  BUG: KCSAN: data-race in rcu_preempt_deferred_qs_handler / rcu_read_unlock_special  read to 0xffff96b95f42d8d8 of 1 bytes by task 90 on cpu 8:  rcu_read_unlock_special+0x175/0x260  __rcu_read_unlock+0x92/0xa0  rt_spin_unlock+0x9b/0xc0  __local_bh_enable+0x10d/0x170  __local_bh_enable_ip+0xfb/0x150  rcu_do_batch+0x595/0xc40  rcu_cpu_kthread+0x4e9/0x830  smpboot_thread_fn+0x24d/0x3b0  kthread+0x3bd/0x410  ret_from_fork+0x35/0x40  ret_from_fork_asm+0x1a/0x30  write to 0xffff96b95f42d8d8 of 1 bytes by task 88 on cpu 8:  rcu_preempt_deferred_qs_handler+0x1e/0x30  irq_work_single+0xaf/0x160  run_irq_workd+0x91/0xc0  smpboot_thread_fn+0x24d/0x3b0  kthread+0x3bd/0x410  ret_from_fork+0x35/0x40  ret_from_fork_asm+0x1a/0x30  no locks held by irq_work/8/88. irq event stamp: 200272 hardirqs last  enabled at (200272): [<ffffffffb0f56121>] finish_task_switch+0x131/0x320 hardirqs last disabled at (200271): [<ffffffffb25c7859>] __schedule+0x129/0xd70 softirqs last  enabled at (0): [<ffffffffb0ee093f>] copy_process+0x4df/0x1cc0 softirqs last disabled at (0): [<0000000000000000>] 0x0  ------------------------------------------------------------------------  The problem is that irq-work handlers run with interrupts enabled, which means that rcu_preempt_deferred_qs_handler() could be interrupted, and that interrupt handler might contain an RCU read-side critical section, which might invoke rcu_read_unlock_special().  In the strict KCSAN mode of operation used by RCU, this constitutes a data race on the ->defer_qs_iw_pending field.  This commit therefore disables interrupts across the portion of the rcu_preempt_deferred_qs_handler() that updates the ->defer_qs_iw_pending field.  This suffices because this handler is not a fast path.