xamxte/cve-to-cwe huggingface dataset:
CVE-2025-71089: In the Linux kernel, the following vulnerability has been resolved:  iommu: disable SVA when CONFIG_X86 is set  Patch series "Fix stale IOTLB entries for kernel address space", v7.  This proposes a fix for a security vulnerability related to IOMMU Shared Virtual Addressing (SVA).  In an SVA context, an IOMMU can cache kernel page table entries.  When a kernel page table page is freed and reallocated for another purpose, the IOMMU might still hold stale, incorrect entries.  This can be exploited to cause a use-after-free or write-after-free condition, potentially leading to privilege escalation or data corruption.  This solution introduces a deferred freeing mechanism for kernel page table pages, which provides a safe window to notify the IOMMU to invalidate its caches before the page is reused.   This patch (of 8):  In the IOMMU Shared Virtual Addressing (SVA) context, the IOMMU hardware shares and walks the CPU's page tables.  The x86 architecture maps the kernel's virtual address space into the upper portion of every process's page table.  Consequently, in an SVA context, the IOMMU hardware can walk and cache kernel page table entries.  The Linux kernel currently lacks a notification mechanism for kernel page table changes, specifically when page table pages are freed and reused.  The IOMMU driver is only notified of changes to user virtual address mappings.  This can cause the IOMMU's internal caches to retain stale entries for kernel VA.  Use-After-Free (UAF) and Write-After-Free (WAF) conditions arise when kernel page table pages are freed and later reallocated.  The IOMMU could misinterpret the new data as valid page table entries.  The IOMMU might then walk into attacker-controlled memory, leading to arbitrary physical memory DMA access or privilege escalation.  This is also a Write-After-Free issue, as the IOMMU will potentially continue to write Accessed and Dirty bits to the freed memory while attempting to walk the stale page tables.  Currently, SVA contexts are unprivileged and cannot access kernel mappings.  However, the IOMMU will still walk kernel-only page tables all the way down to the leaf entries, where it realizes the mapping is for the kernel and errors out.  This means the IOMMU still caches these intermediate page table entries, making the described vulnerability a real concern.  Disable SVA on x86 architecture until the IOMMU can receive notification to flush the paging cache before freeing the CPU kernel page table pages.
CVE-2025-71090: In the Linux kernel, the following vulnerability has been resolved:  nfsd: fix nfsd_file reference leak in nfsd4_add_rdaccess_to_wrdeleg()  nfsd4_add_rdaccess_to_wrdeleg() unconditionally overwrites fp->fi_fds[O_RDONLY] with a newly acquired nfsd_file. However, if the client already has a SHARE_ACCESS_READ open from a previous OPEN operation, this action overwrites the existing pointer without releasing its reference, orphaning the previous reference.  Additionally, the function originally stored the same nfsd_file pointer in both fp->fi_fds[O_RDONLY] and fp->fi_rdeleg_file with only a single reference. When put_deleg_file() runs, it clears fi_rdeleg_file and calls nfs4_file_put_access() to release the file.  However, nfs4_file_put_access() only releases fi_fds[O_RDONLY] when the fi_access[O_RDONLY] counter drops to zero. If another READ open exists on the file, the counter remains elevated and the nfsd_file reference from the delegation is never released. This potentially causes open conflicts on that file.  Then, on server shutdown, these leaks cause __nfsd_file_cache_purge() to encounter files with an elevated reference count that cannot be cleaned up, ultimately triggering a BUG() in kmem_cache_destroy() because there are still nfsd_file objects allocated in that cache.
CVE-2025-71092: In the Linux kernel, the following vulnerability has been resolved:  RDMA/bnxt_re: Fix OOB write in bnxt_re_copy_err_stats()  Commit ef56081d1864 ("RDMA/bnxt_re: RoCE related hardware counters update") added three new counters and placed them after BNXT_RE_OUT_OF_SEQ_ERR.  BNXT_RE_OUT_OF_SEQ_ERR acts as a boundary marker for allocating hardware statistics with different num_counters values on chip_gen_p5_p7 devices.  As a result, BNXT_RE_NUM_STD_COUNTERS are used when allocating hw_stats, which leads to an out-of-bounds write in bnxt_re_copy_err_stats().  The counters BNXT_RE_REQ_CQE_ERROR, BNXT_RE_RESP_CQE_ERROR, and BNXT_RE_RESP_REMOTE_ACCESS_ERRS are applicable to generic hardware, not only p5/p7 devices.  Fix this by moving these counters before BNXT_RE_OUT_OF_SEQ_ERR so they are included in the generic counter set.
CVE-2025-71094: In the Linux kernel, the following vulnerability has been resolved:  net: usb: asix: validate PHY address before use  The ASIX driver reads the PHY address from the USB device via asix_read_phy_addr(). A malicious or faulty device can return an invalid address (>= PHY_MAX_ADDR), which causes a warning in mdiobus_get_phy():    addr 207 out of range   WARNING: drivers/net/phy/mdio_bus.c:76  Validate the PHY address in asix_read_phy_addr() and remove the now-redundant check in ax88172a.c.
CVE-2025-71096: In the Linux kernel, the following vulnerability has been resolved:  RDMA/core: Check for the presence of LS_NLA_TYPE_DGID correctly  The netlink response for RDMA_NL_LS_OP_IP_RESOLVE should always have a LS_NLA_TYPE_DGID attribute, it is invalid if it does not.  Use the nl parsing logic properly and call nla_parse_deprecated() to fill the nlattrs array and then directly index that array to get the data for the DGID. Just fail if it is NULL.  Remove the for loop searching for the nla, and squash the validation and parsing into one function.  Fixes an uninitialized read from the stack triggered by userspace if it does not provide the DGID to a kernel initiated RDMA_NL_LS_OP_IP_RESOLVE query.      BUG: KMSAN: uninit-value in hex_byte_pack include/linux/hex.h:13 [inline]     BUG: KMSAN: uninit-value in ip6_string+0xef4/0x13a0 lib/vsprintf.c:1490      hex_byte_pack include/linux/hex.h:13 [inline]      ip6_string+0xef4/0x13a0 lib/vsprintf.c:1490      ip6_addr_string+0x18a/0x3e0 lib/vsprintf.c:1509      ip_addr_string+0x245/0xee0 lib/vsprintf.c:1633      pointer+0xc09/0x1bd0 lib/vsprintf.c:2542      vsnprintf+0xf8a/0x1bd0 lib/vsprintf.c:2930      vprintk_store+0x3ae/0x1530 kernel/printk/printk.c:2279      vprintk_emit+0x307/0xcd0 kernel/printk/printk.c:2426      vprintk_default+0x3f/0x50 kernel/printk/printk.c:2465      vprintk+0x36/0x50 kernel/printk/printk_safe.c:82      _printk+0x17e/0x1b0 kernel/printk/printk.c:2475      ib_nl_process_good_ip_rsep drivers/infiniband/core/addr.c:128 [inline]      ib_nl_handle_ip_res_resp+0x963/0x9d0 drivers/infiniband/core/addr.c:141      rdma_nl_rcv_msg drivers/infiniband/core/netlink.c:-1 [inline]      rdma_nl_rcv_skb drivers/infiniband/core/netlink.c:239 [inline]      rdma_nl_rcv+0xefa/0x11c0 drivers/infiniband/core/netlink.c:259      netlink_unicast_kernel net/netlink/af_netlink.c:1320 [inline]      netlink_unicast+0xf04/0x12b0 net/netlink/af_netlink.c:1346      netlink_sendmsg+0x10b3/0x1250 net/netlink/af_netlink.c:1896      sock_sendmsg_nosec net/socket.c:714 [inline]      __sock_sendmsg+0x333/0x3d0 net/socket.c:729      ____sys_sendmsg+0x7e0/0xd80 net/socket.c:2617      ___sys_sendmsg+0x271/0x3b0 net/socket.c:2671      __sys_sendmsg+0x1aa/0x300 net/socket.c:2703      __compat_sys_sendmsg net/compat.c:346 [inline]      __do_compat_sys_sendmsg net/compat.c:353 [inline]      __se_compat_sys_sendmsg net/compat.c:350 [inline]      __ia32_compat_sys_sendmsg+0xa4/0x100 net/compat.c:350      ia32_sys_call+0x3f6c/0x4310 arch/x86/include/generated/asm/syscalls_32.h:371      do_syscall_32_irqs_on arch/x86/entry/syscall_32.c:83 [inline]      __do_fast_syscall_32+0xb0/0x150 arch/x86/entry/syscall_32.c:306      do_fast_syscall_32+0x38/0x80 arch/x86/entry/syscall_32.c:331      do_SYSENTER_32+0x1f/0x30 arch/x86/entry/syscall_32.c:3
CVE-2025-71097: In the Linux kernel, the following vulnerability has been resolved:  ipv4: Fix reference count leak when using error routes with nexthop objects  When a nexthop object is deleted, it is marked as dead and then fib_table_flush() is called to flush all the routes that are using the dead nexthop.  The current logic in fib_table_flush() is to only flush error routes (e.g., blackhole) when it is called as part of network namespace dismantle (i.e., with flush_all=true). Therefore, error routes are not flushed when their nexthop object is deleted:   # ip link add name dummy1 up type dummy  # ip nexthop add id 1 dev dummy1  # ip route add 198.51.100.1/32 nhid 1  # ip route add blackhole 198.51.100.2/32 nhid 1  # ip nexthop del id 1  # ip route show  blackhole 198.51.100.2 nhid 1 dev dummy1  As such, they keep holding a reference on the nexthop object which in turn holds a reference on the nexthop device, resulting in a reference count leak:   # ip link del dev dummy1  [   70.516258] unregister_netdevice: waiting for dummy1 to become free. Usage count = 2  Fix by flushing error routes when their nexthop is marked as dead.  IPv6 does not suffer from this problem.
CVE-2025-71098: In the Linux kernel, the following vulnerability has been resolved:  ip6_gre: make ip6gre_header() robust  Over the years, syzbot found many ways to crash the kernel in ip6gre_header() [1].  This involves team or bonding drivers ability to dynamically change their dev->needed_headroom and/or dev->hard_header_len  In this particular crash mld_newpack() allocated an skb with a too small reserve/headroom, and by the time mld_sendpack() was called, syzbot managed to attach an ip6gre device.  [1] skbuff: skb_under_panic: text:ffffffff8a1d69a8 len:136 put:40 head:ffff888059bc7000 data:ffff888059bc6fe8 tail:0x70 end:0x6c0 dev:team0 ------------[ cut here ]------------  kernel BUG at net/core/skbuff.c:213 !  <TASK>   skb_under_panic net/core/skbuff.c:223 [inline]   skb_push+0xc3/0xe0 net/core/skbuff.c:2641   ip6gre_header+0xc8/0x790 net/ipv6/ip6_gre.c:1371   dev_hard_header include/linux/netdevice.h:3436 [inline]   neigh_connected_output+0x286/0x460 net/core/neighbour.c:1618   neigh_output include/net/neighbour.h:556 [inline]   ip6_finish_output2+0xfb3/0x1480 net/ipv6/ip6_output.c:136  __ip6_finish_output net/ipv6/ip6_output.c:-1 [inline]   ip6_finish_output+0x234/0x7d0 net/ipv6/ip6_output.c:220   NF_HOOK_COND include/linux/netfilter.h:307 [inline]   ip6_output+0x340/0x550 net/ipv6/ip6_output.c:247   NF_HOOK+0x9e/0x380 include/linux/netfilter.h:318   mld_sendpack+0x8d4/0xe60 net/ipv6/mcast.c:1855   mld_send_cr net/ipv6/mcast.c:2154 [inline]   mld_ifc_work+0x83e/0xd60 net/ipv6/mcast.c:2693
CVE-2025-71099: In the Linux kernel, the following vulnerability has been resolved:  drm/xe/oa: Fix potential UAF in xe_oa_add_config_ioctl()  In xe_oa_add_config_ioctl(), we accessed oa_config->id after dropping metrics_lock. Since this lock protects the lifetime of oa_config, an attacker could guess the id and call xe_oa_remove_config_ioctl() with perfect timing, freeing oa_config before we dereference it, leading to a potential use-after-free.  Fix this by caching the id in a local variable while holding the lock.  v2: (Matt A) - Dropped mutex_unlock(&oa->metrics_lock) ordering change from   xe_oa_remove_config_ioctl()  (cherry picked from commit 28aeaed130e8e587fd1b73b6d66ca41ccc5a1a31)
CVE-2025-71100: In the Linux kernel, the following vulnerability has been resolved:  wifi: rtlwifi: 8192cu: fix tid out of range in rtl92cu_tx_fill_desc()  TID getting from ieee80211_get_tid() might be out of range of array size of sta_entry->tids[], so check TID is less than MAX_TID_COUNT. Othwerwise, UBSAN warn:   UBSAN: array-index-out-of-bounds in drivers/net/wireless/realtek/rtlwifi/rtl8192cu/trx.c:514:30  index 10 is out of range for type 'rtl_tid_data [9]'
CVE-2025-71101: In the Linux kernel, the following vulnerability has been resolved:  platform/x86: hp-bioscfg: Fix out-of-bounds array access in ACPI package parsing  The hp_populate_*_elements_from_package() functions in the hp-bioscfg driver contain out-of-bounds array access vulnerabilities.  These functions parse ACPI packages into internal data structures using a for loop with index variable 'elem' that iterates through enum_obj/integer_obj/order_obj/password_obj/string_obj arrays.  When processing multi-element fields like PREREQUISITES and ENUM_POSSIBLE_VALUES, these functions read multiple consecutive array elements using expressions like 'enum_obj[elem + reqs]' and 'enum_obj[elem + pos_values]' within nested loops.  The bug is that the bounds check only validated elem, but did not consider the additional offset when accessing elem + reqs or elem + pos_values.  The fix changes the bounds check to validate the actual accessed index.
CVE-2025-71103: In the Linux kernel, the following vulnerability has been resolved:  drm/msm: adreno: fix deferencing ifpc_reglist when not declared  On plaforms with an a7xx GPU not supporting IFPC, the ifpc_reglist if still deferenced in a7xx_patch_pwrup_reglist() which causes a kernel crash: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000008 ... pc : a6xx_hw_init+0x155c/0x1e4c [msm] lr : a6xx_hw_init+0x9a8/0x1e4c [msm] ... Call trace:   a6xx_hw_init+0x155c/0x1e4c [msm] (P)   msm_gpu_hw_init+0x58/0x88 [msm]   adreno_load_gpu+0x94/0x1fc [msm]   msm_open+0xe4/0xf4 [msm]   drm_file_alloc+0x1a0/0x2e4 [drm]   drm_client_init+0x7c/0x104 [drm]   drm_fbdev_client_setup+0x94/0xcf0 [drm_client_lib]   drm_client_setup+0xb4/0xd8 [drm_client_lib]   msm_drm_kms_post_init+0x2c/0x3c [msm]   msm_drm_init+0x1a4/0x228 [msm]   msm_drm_bind+0x30/0x3c [msm] ...  Check the validity of ifpc_reglist before deferencing the table to setup the register values.  Patchwork: https://patchwork.freedesktop.org/patch/688944/
CVE-2025-71109: In the Linux kernel, the following vulnerability has been resolved:  MIPS: ftrace: Fix memory corruption when kernel is located beyond 32 bits  Since commit e424054000878 ("MIPS: Tracing: Reduce the overhead of dynamic Function Tracer"), the macro UASM_i_LA_mostly has been used, and this macro can generate more than 2 instructions. At the same time, the code in ftrace assumes that no more than 2 instructions can be generated, which is why it stores them in an int[2] array. However, as previously noted, the macro UASM_i_LA_mostly (and now UASM_i_LA) causes a buffer overflow when _mcount is beyond 32 bits. This leads to corruption of the variables located in the __read_mostly section.  This corruption was observed because the variable __cpu_primary_thread_mask was corrupted, causing a hang very early during boot.  This fix prevents the corruption by avoiding the generation of instructions if they could exceed 2 instructions in length. Fortunately, insn_la_mcount is only used if the instrumented code is located outside the kernel code section, so dynamic ftrace can still be used, albeit in a more limited scope. This is still preferable to corrupting memory and/or crashing the kernel.
CVE-2025-71110: In the Linux kernel, the following vulnerability has been resolved:  mm/slub: reset KASAN tag in defer_free() before accessing freed memory  When CONFIG_SLUB_TINY is enabled, kfree_nolock() calls kasan_slab_free() before defer_free(). On ARM64 with MTE (Memory Tagging Extension), kasan_slab_free() poisons the memory and changes the tag from the original (e.g., 0xf3) to a poison tag (0xfe).  When defer_free() then tries to write to the freed object to build the deferred free list via llist_add(), the pointer still has the old tag, causing a tag mismatch and triggering a KASAN use-after-free report:    BUG: KASAN: slab-use-after-free in defer_free+0x3c/0xbc mm/slub.c:6537   Write at addr f3f000000854f020 by task kworker/u8:6/983   Pointer tag: [f3], memory tag: [fe]  Fix this by calling kasan_reset_tag() before accessing the freed memory. This is safe because defer_free() is part of the allocator itself and is expected to manipulate freed memory for bookkeeping purposes.
CVE-2025-71111: In the Linux kernel, the following vulnerability has been resolved:  hwmon: (w83791d) Convert macros to functions to avoid TOCTOU  The macro FAN_FROM_REG evaluates its arguments multiple times. When used in lockless contexts involving shared driver data, this leads to Time-of-Check to Time-of-Use (TOCTOU) race conditions, potentially causing divide-by-zero errors.  Convert the macro to a static function. This guarantees that arguments are evaluated only once (pass-by-value), preventing the race conditions.  Additionally, in store_fan_div, move the calculation of the minimum limit inside the update lock. This ensures that the read-modify-write sequence operates on consistent data.  Adhere to the principle of minimal changes by only converting macros that evaluate arguments multiple times and are used in lockless contexts.
CVE-2025-71112: In the Linux kernel, the following vulnerability has been resolved:  net: hns3: add VLAN id validation before using  Currently, the VLAN id may be used without validation when receive a VLAN configuration mailbox from VF. The length of vlan_del_fail_bmap is BITS_TO_LONGS(VLAN_N_VID). It may cause out-of-bounds memory access once the VLAN id is bigger than or equal to VLAN_N_VID.  Therefore, VLAN id needs to be checked to ensure it is within the range of VLAN_N_VID.
CVE-2025-71113: In the Linux kernel, the following vulnerability has been resolved:  crypto: af_alg - zero initialize memory allocated via sock_kmalloc  Several crypto user API contexts and requests allocated with sock_kmalloc() were left uninitialized, relying on callers to set fields explicitly. This resulted in the use of uninitialized data in certain error paths or when new fields are added in the future.  The ACVP patches also contain two user-space interface files: algif_kpp.c and algif_akcipher.c. These too rely on proper initialization of their context structures.  A particular issue has been observed with the newly added 'inflight' variable introduced in af_alg_ctx by commit:    67b164a871af ("crypto: af_alg - Disallow multiple in-flight AIO requests")  Because the context is not memset to zero after allocation, the inflight variable has contained garbage values. As a result, af_alg_alloc_areq() has incorrectly returned -EBUSY randomly when the garbage value was interpreted as true:    https://github.com/gregkh/linux/blame/master/crypto/af_alg.c#L1209  The check directly tests ctx->inflight without explicitly comparing against true/false. Since inflight is only ever set to true or false later, an uninitialized value has triggered -EBUSY failures. Zero-initializing memory allocated with sock_kmalloc() ensures inflight and other fields start in a known state, removing random issues caused by uninitialized data.
CVE-2025-71116: In the Linux kernel, the following vulnerability has been resolved:  libceph: make decode_pool() more resilient against corrupted osdmaps  If the osdmap is (maliciously) corrupted such that the encoded length of ceph_pg_pool envelope is less than what is expected for a particular encoding version, out-of-bounds reads may ensue because the only bounds check that is there is based on that length value.  This patch adds explicit bounds checks for each field that is decoded or skipped.
CVE-2025-71118: In the Linux kernel, the following vulnerability has been resolved:  ACPICA: Avoid walking the Namespace if start_node is NULL  Although commit 0c9992315e73 ("ACPICA: Avoid walking the ACPI Namespace if it is not there") fixed the situation when both start_node and acpi_gbl_root_node are NULL, the Linux kernel mainline now still crashed on Honor Magicbook 14 Pro [1].  That happens due to the access to the member of parent_node in acpi_ns_get_next_node().  The NULL pointer dereference will always happen, no matter whether or not the start_node is equal to ACPI_ROOT_OBJECT, so move the check of start_node being NULL out of the if block.  Unfortunately, all the attempts to contact Honor have failed, they refused to provide any technical support for Linux.  The bad DSDT table's dump could be found on GitHub [2].  DMI: HONOR FMB-P/FMB-P-PCB, BIOS 1.13 05/08/2025  [ rjw: Subject adjustment, changelog edits ]
CVE-2025-71120: In the Linux kernel, the following vulnerability has been resolved:  SUNRPC: svcauth_gss: avoid NULL deref on zero length gss_token in gss_read_proxy_verf  A zero length gss_token results in pages == 0 and in_token->pages[0] is NULL. The code unconditionally evaluates page_address(in_token->pages[0]) for the initial memcpy, which can dereference NULL even when the copy length is 0. Guard the first memcpy so it only runs when length > 0.
CVE-2025-71124: In the Linux kernel, the following vulnerability has been resolved:  drm/msm/a6xx: move preempt_prepare_postamble after error check  Move the call to preempt_prepare_postamble() after verifying that preempt_postamble_ptr is valid. If preempt_postamble_ptr is NULL, dereferencing it in preempt_prepare_postamble() would lead to a crash.  This change avoids calling the preparation function when the postamble allocation has failed, preventing potential NULL pointer dereference and ensuring proper error handling.  Patchwork: https://patchwork.freedesktop.org/patch/687659/
CVE-2025-71125: In the Linux kernel, the following vulnerability has been resolved:  tracing: Do not register unsupported perf events  Synthetic events currently do not have a function to register perf events. This leads to calling the tracepoint register functions with a NULL function pointer which triggers:   ------------[ cut here ]------------  WARNING: kernel/tracepoint.c:175 at tracepoint_add_func+0x357/0x370, CPU#2: perf/2272  Modules linked in: kvm_intel kvm irqbypass  CPU: 2 UID: 0 PID: 2272 Comm: perf Not tainted 6.18.0-ftest-11964-ge022764176fc-dirty #323 PREEMPTLAZY  Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.17.0-debian-1.17.0-1 04/01/2014  RIP: 0010:tracepoint_add_func+0x357/0x370  Code: 28 9c e8 4c 0b f5 ff eb 0f 4c 89 f7 48 c7 c6 80 4d 28 9c e8 ab 89 f4 ff 31 c0 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc cc <0f> 0b 49 c7 c6 ea ff ff ff e9 ee fe ff ff 0f 0b e9 f9 fe ff ff 0f  RSP: 0018:ffffabc0c44d3c40 EFLAGS: 00010246  RAX: 0000000000000001 RBX: ffff9380aa9e4060 RCX: 0000000000000000  RDX: 000000000000000a RSI: ffffffff9e1d4a98 RDI: ffff937fcf5fd6c8  RBP: 0000000000000001 R08: 0000000000000007 R09: ffff937fcf5fc780  R10: 0000000000000003 R11: ffffffff9c193910 R12: 000000000000000a  R13: ffffffff9e1e5888 R14: 0000000000000000 R15: ffffabc0c44d3c78  FS:  00007f6202f5f340(0000) GS:ffff93819f00f000(0000) knlGS:0000000000000000  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033  CR2: 000055d3162281a8 CR3: 0000000106a56003 CR4: 0000000000172ef0  Call Trace:   <TASK>   tracepoint_probe_register+0x5d/0x90   synth_event_reg+0x3c/0x60   perf_trace_event_init+0x204/0x340   perf_trace_init+0x85/0xd0   perf_tp_event_init+0x2e/0x50   perf_try_init_event+0x6f/0x230   ? perf_event_alloc+0x4bb/0xdc0   perf_event_alloc+0x65a/0xdc0   __se_sys_perf_event_open+0x290/0x9f0   do_syscall_64+0x93/0x7b0   ? entry_SYSCALL_64_after_hwframe+0x76/0x7e   ? trace_hardirqs_off+0x53/0xc0   entry_SYSCALL_64_after_hwframe+0x76/0x7e  Instead, have the code return -ENODEV, which doesn't warn and has perf error out with:   # perf record -e synthetic:futex_wait Error: The sys_perf_event_open() syscall returned with 19 (No such device) for event (synthetic:futex_wait). "dmesg | grep -i perf" may provide additional information.  Ideally perf should support synthetic events, but for now just fix the warning. The support can come later.