xamxte/cve-to-cwe huggingface dataset:
CVE-2025-71126: In the Linux kernel, the following vulnerability has been resolved:  mptcp: avoid deadlock on fallback while reinjecting  Jakub reported an MPTCP deadlock at fallback time:   WARNING: possible recursive locking detected  6.18.0-rc7-virtme #1 Not tainted  --------------------------------------------  mptcp_connect/20858 is trying to acquire lock:  ff1100001da18b60 (&msk->fallback_lock){+.-.}-{3:3}, at: __mptcp_try_fallback+0xd8/0x280   but task is already holding lock:  ff1100001da18b60 (&msk->fallback_lock){+.-.}-{3:3}, at: __mptcp_retrans+0x352/0xaa0   other info that might help us debug this:   Possible unsafe locking scenario:          CPU0         ----    lock(&msk->fallback_lock);    lock(&msk->fallback_lock);    *** DEADLOCK ***    May be due to missing lock nesting notation   3 locks held by mptcp_connect/20858:   #0: ff1100001da18290 (sk_lock-AF_INET){+.+.}-{0:0}, at: mptcp_sendmsg+0x114/0x1bc0   #1: ff1100001db40fd0 (k-sk_lock-AF_INET#2){+.+.}-{0:0}, at: __mptcp_retrans+0x2cb/0xaa0   #2: ff1100001da18b60 (&msk->fallback_lock){+.-.}-{3:3}, at: __mptcp_retrans+0x352/0xaa0   stack backtrace:  CPU: 0 UID: 0 PID: 20858 Comm: mptcp_connect Not tainted 6.18.0-rc7-virtme #1 PREEMPT(full)  Hardware name: Bochs, BIOS Bochs 01/01/2011  Call Trace:   <TASK>   dump_stack_lvl+0x6f/0xa0   print_deadlock_bug.cold+0xc0/0xcd   validate_chain+0x2ff/0x5f0   __lock_acquire+0x34c/0x740   lock_acquire.part.0+0xbc/0x260   _raw_spin_lock_bh+0x38/0x50   __mptcp_try_fallback+0xd8/0x280   mptcp_sendmsg_frag+0x16c2/0x3050   __mptcp_retrans+0x421/0xaa0   mptcp_release_cb+0x5aa/0xa70   release_sock+0xab/0x1d0   mptcp_sendmsg+0xd5b/0x1bc0   sock_write_iter+0x281/0x4d0   new_sync_write+0x3c5/0x6f0   vfs_write+0x65e/0xbb0   ksys_write+0x17e/0x200   do_syscall_64+0xbb/0xfd0   entry_SYSCALL_64_after_hwframe+0x4b/0x53  RIP: 0033:0x7fa5627cbc5e  Code: 4d 89 d8 e8 14 bd 00 00 4c 8b 5d f8 41 8b 93 08 03 00 00 59 5e 48 83 f8 fc 74 11 c9 c3 0f 1f 80 00 00 00 00 48 8b 45 10 0f 05 <c9> c3 83 e2 39 83 fa 08 75 e7 e8 13 ff ff ff 0f 1f 00 f3 0f 1e fa  RSP: 002b:00007fff1fe14700 EFLAGS: 00000202 ORIG_RAX: 0000000000000001  RAX: ffffffffffffffda RBX: 0000000000000005 RCX: 00007fa5627cbc5e  RDX: 0000000000001f9c RSI: 00007fff1fe16984 RDI: 0000000000000005  RBP: 00007fff1fe14710 R08: 0000000000000000 R09: 0000000000000000  R10: 0000000000000000 R11: 0000000000000202 R12: 00007fff1fe16920  R13: 0000000000002000 R14: 0000000000001f9c R15: 0000000000001f9c  The packet scheduler could attempt a reinjection after receiving an MP_FAIL and before the infinite map has been transmitted, causing a deadlock since MPTCP needs to do the reinjection atomically from WRT fallback.  Address the issue explicitly avoiding the reinjection in the critical scenario. Note that this is the only fallback critical section that could potentially send packets and hit the double-lock.
CVE-2025-71127: In the Linux kernel, the following vulnerability has been resolved:  wifi: mac80211: Discard Beacon frames to non-broadcast address  Beacon frames are required to be sent to the broadcast address, see IEEE Std 802.11-2020, 11.1.3.1 ("The Address 1 field of the Beacon .. frame shall be set to the broadcast address"). A unicast Beacon frame might be used as a targeted attack to get one of the associated STAs to do something (e.g., using CSA to move it to another channel). As such, it is better have strict filtering for this on the received side and discard all Beacon frames that are sent to an unexpected address.  This is even more important for cases where beacon protection is used. The current implementation in mac80211 is correctly discarding unicast Beacon frames if the Protected Frame bit in the Frame Control field is set to 0. However, if that bit is set to 1, the logic used for checking for configured BIGTK(s) does not actually work. If the driver does not have logic for dropping unicast Beacon frames with Protected Frame bit 1, these frames would be accepted in mac80211 processing as valid Beacon frames even though they are not protected. This would allow beacon protection to be bypassed. While the logic for checking beacon protection could be extended to cover this corner case, a more generic check for discard all Beacon frames based on A1=unicast address covers this without needing additional changes.  Address all these issues by dropping received Beacon frames if they are sent to a non-broadcast address.
CVE-2025-71128: In the Linux kernel, the following vulnerability has been resolved:  erspan: Initialize options_len before referencing options.  The struct ip_tunnel_info has a flexible array member named options that is protected by a counted_by(options_len) attribute.  The compiler will use this information to enforce runtime bounds checking deployed by FORTIFY_SOURCE string helpers.  As laid out in the GCC documentation, the counter must be initialized before the first reference to the flexible array member.  After scanning through the files that use struct ip_tunnel_info and also refer to options or options_len, it appears the normal case is to use the ip_tunnel_info_opts_set() helper.  Said helper would initialize options_len properly before copying data into options, however in the GRE ERSPAN code a partial update is done, preventing the use of the helper function.  Before this change the handling of ERSPAN traffic in GRE tunnels would cause a kernel panic when the kernel is compiled with GCC 15+ and having FORTIFY_SOURCE configured:  memcpy: detected buffer overflow: 4 byte write of buffer size 0  Call Trace:  <IRQ>  __fortify_panic+0xd/0xf  erspan_rcv.cold+0x68/0x83  ? ip_route_input_slow+0x816/0x9d0  gre_rcv+0x1b2/0x1c0  gre_rcv+0x8e/0x100  ? raw_v4_input+0x2a0/0x2b0  ip_protocol_deliver_rcu+0x1ea/0x210  ip_local_deliver_finish+0x86/0x110  ip_local_deliver+0x65/0x110  ? ip_rcv_finish_core+0xd6/0x360  ip_rcv+0x186/0x1a0  Reported-at: https://launchpad.net/bugs/2129580
CVE-2025-71130: In the Linux kernel, the following vulnerability has been resolved:  drm/i915/gem: Zero-initialize the eb.vma array in i915_gem_do_execbuffer  Initialize the eb.vma array with values of 0 when the eb structure is first set up. In particular, this sets the eb->vma[i].vma pointers to NULL, simplifying cleanup and getting rid of the bug described below.  During the execution of eb_lookup_vmas(), the eb->vma array is successively filled up with struct eb_vma objects. This process includes calling eb_add_vma(), which might fail; however, even in the event of failure, eb->vma[i].vma is set for the currently processed buffer.  If eb_add_vma() fails, eb_lookup_vmas() returns with an error, which prompts a call to eb_release_vmas() to clean up the mess. Since eb_lookup_vmas() might fail during processing any (possibly not first) buffer, eb_release_vmas() checks whether a buffer's vma is NULL to know at what point did the lookup function fail.  In eb_lookup_vmas(), eb->vma[i].vma is set to NULL if either the helper function eb_lookup_vma() or eb_validate_vma() fails. eb->vma[i+1].vma is set to NULL in case i915_gem_object_userptr_submit_init() fails; the current one needs to be cleaned up by eb_release_vmas() at this point, so the next one is set. If eb_add_vma() fails, neither the current nor the next vma is set to NULL, which is a source of a NULL deref bug described in the issue linked in the Closes tag.  When entering eb_lookup_vmas(), the vma pointers are set to the slab poison value, instead of NULL. This doesn't matter for the actual lookup, since it gets overwritten anyway, however the eb_release_vmas() function only recognizes NULL as the stopping value, hence the pointers are being set to NULL as they go in case of intermediate failure. This patch changes the approach to filling them all with NULL at the start instead, rather than handling that manually during failure.  (cherry picked from commit 08889b706d4f0b8d2352b7ca29c2d8df4d0787cd)
CVE-2025-71133: In the Linux kernel, the following vulnerability has been resolved:  RDMA/irdma: avoid invalid read in irdma_net_event  irdma_net_event() should not dereference anything from "neigh" (alias "ptr") until it has checked that the event is NETEVENT_NEIGH_UPDATE. Other events come with different structures pointed to by "ptr" and they may be smaller than struct neighbour.  Move the read of neigh->dev under the NETEVENT_NEIGH_UPDATE case.  The bug is mostly harmless, but it triggers KASAN on debug kernels:   BUG: KASAN: stack-out-of-bounds in irdma_net_event+0x32e/0x3b0 [irdma]  Read of size 8 at addr ffffc900075e07f0 by task kworker/27:2/542554   CPU: 27 PID: 542554 Comm: kworker/27:2 Kdump: loaded Not tainted 5.14.0-630.el9.x86_64+debug #1  Hardware name: [...]  Workqueue: events rt6_probe_deferred  Call Trace:   <IRQ>   dump_stack_lvl+0x60/0xb0   print_address_description.constprop.0+0x2c/0x3f0   print_report+0xb4/0x270   kasan_report+0x92/0xc0   irdma_net_event+0x32e/0x3b0 [irdma]   notifier_call_chain+0x9e/0x180   atomic_notifier_call_chain+0x5c/0x110   rt6_do_redirect+0xb91/0x1080   tcp_v6_err+0xe9b/0x13e0   icmpv6_notify+0x2b2/0x630   ndisc_redirect_rcv+0x328/0x530   icmpv6_rcv+0xc16/0x1360   ip6_protocol_deliver_rcu+0xb84/0x12e0   ip6_input_finish+0x117/0x240   ip6_input+0xc4/0x370   ipv6_rcv+0x420/0x7d0   __netif_receive_skb_one_core+0x118/0x1b0   process_backlog+0xd1/0x5d0   __napi_poll.constprop.0+0xa3/0x440   net_rx_action+0x78a/0xba0   handle_softirqs+0x2d4/0x9c0   do_softirq+0xad/0xe0   </IRQ>
CVE-2025-71135: In the Linux kernel, the following vulnerability has been resolved:  md/raid5: fix possible null-pointer dereferences in raid5_store_group_thread_cnt()  The variable mddev->private is first assigned to conf and then checked:    conf = mddev->private;   if (!conf) ...  If conf is NULL, then mddev->private is also NULL. In this case, null-pointer dereferences can occur when calling raid5_quiesce():    raid5_quiesce(mddev, true);   raid5_quiesce(mddev, false);  since mddev->private is assigned to conf again in raid5_quiesce(), and conf is dereferenced in several places, for example:    conf->quiesce = 0;   wake_up(&conf->wait_for_quiescent);  To fix this issue, the function should unlock mddev and return before invoking raid5_quiesce() when conf is NULL, following the existing pattern in raid5_change_consistency_policy().
CVE-2025-71136: In the Linux kernel, the following vulnerability has been resolved:  media: adv7842: Avoid possible out-of-bounds array accesses in adv7842_cp_log_status()  It's possible for cp_read() and hdmi_read() to return -EIO. Those values are further used as indexes for accessing arrays.  Fix that by checking return values where it's needed.  Found by Linux Verification Center (linuxtesting.org) with SVACE.
CVE-2025-71138: In the Linux kernel, the following vulnerability has been resolved:  drm/msm/dpu: Add missing NULL pointer check for pingpong interface  It is checked almost always in dpu_encoder_phys_wb_setup_ctl(), but in a single place the check is missing. Also use convenient locals instead of phys_enc->* where available.  Patchwork: https://patchwork.freedesktop.org/patch/693860/
CVE-2025-71140: In the Linux kernel, the following vulnerability has been resolved:  media: mediatek: vcodec: Use spinlock for context list protection lock  Previously a mutex was added to protect the encoder and decoder context lists from unexpected changes originating from the SCP IP block, causing the context pointer to go invalid, resulting in a NULL pointer dereference in the IPI handler.  Turns out on the MT8173, the VPU IPI handler is called from hard IRQ context. This causes a big warning from the scheduler. This was first reported downstream on the ChromeOS kernels, but is also reproducible on mainline using Fluster with the FFmpeg v4l2m2m decoders. Even though the actual capture format is not supported, the affected code paths are triggered.  Since this lock just protects the context list and operations on it are very fast, it should be OK to switch to a spinlock.
CVE-2026-0612: The Librarian contains a information leakage vulnerability through the `web_fetch` tool, which can be used to retrieve arbitrary external content provided by an attacker, which can be used to proxy requests through The Librarian infrastructure. The vendor has fixed the vulnerability in all versions of TheLibrarian.
CVE-2026-0616: TheLibrarians web_fetch tool can be used to retrieve the Adminer interface content, which can then be used to log into the internal TheLibrarian backend system. The vendor has fixed the vulnerability in all affected versions.
CVE-2025-12573: The Bookingor  WordPress plugin through 1.0.12 exposes authenticated AJAX actions without capability or nonce checks, allowing low-privileged users to delete Bookingor  WordPress plugin through 1.0.12 data.
CVE-2025-14369: dr_flac, an audio decoder within the dr_libs toolset, contains an integer overflow vulnerability flaw due to trusting the totalPCMFrameCount field from FLAC metadata before calculating buffer size, allowing an attacker with a specially crafted file to perform DoS against programs using the tool.
CVE-2026-21924: Vulnerability in the Oracle Utilities Application Framework product of Oracle Utilities Applications (component: General).  Supported versions that are affected are 4.4.0.3.0, 4.5.0.0.0, 4.5.0.1.1, 4.5.0.1.3, 4.5.0.2.0, 25.4 and  25.10. Easily exploitable vulnerability allows low privileged attacker with network access via HTTP to compromise Oracle Utilities Application Framework.  Successful attacks require human interaction from a person other than the attacker and while the vulnerability is in Oracle Utilities Application Framework, attacks may significantly impact additional products (scope change). Successful attacks of this vulnerability can result in  unauthorized update, insert or delete access to some of Oracle Utilities Application Framework accessible data as well as  unauthorized read access to a subset of Oracle Utilities Application Framework accessible data. CVSS 3.1 Base Score 5.4 (Confidentiality and Integrity impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:N).
CVE-2026-21931: Vulnerability in the Oracle APEX Sample Applications product of Oracle APEX (component: Brookstrut Sample App).  Supported versions that are affected are 23.2.0, 23.2.1, 24.1.0, 24.2.0 and  24.2.1. Easily exploitable vulnerability allows low privileged attacker with network access via HTTP to compromise Oracle APEX Sample Applications.  Successful attacks require human interaction from a person other than the attacker and while the vulnerability is in Oracle APEX Sample Applications, attacks may significantly impact additional products (scope change). Successful attacks of this vulnerability can result in  unauthorized update, insert or delete access to some of Oracle APEX Sample Applications accessible data as well as  unauthorized read access to a subset of Oracle APEX Sample Applications accessible data. CVSS 3.1 Base Score 5.4 (Confidentiality and Integrity impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:N).
CVE-2026-21936: Vulnerability in the MySQL Server product of Oracle MySQL (component: InnoDB).  Supported versions that are affected are 8.0.0-8.0.44, 8.4.0-8.4.7 and  9.0.0-9.5.0. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).
CVE-2026-21938: Vulnerability in the PeopleSoft Enterprise PeopleTools product of Oracle PeopleSoft (component: Portal).  Supported versions that are affected are 8.60, 8.61 and  8.62. Easily exploitable vulnerability allows unauthenticated attacker with network access via HTTP to compromise PeopleSoft Enterprise PeopleTools.  Successful attacks require human interaction from a person other than the attacker and while the vulnerability is in PeopleSoft Enterprise PeopleTools, attacks may significantly impact additional products (scope change). Successful attacks of this vulnerability can result in  unauthorized update, insert or delete access to some of PeopleSoft Enterprise PeopleTools accessible data as well as  unauthorized read access to a subset of PeopleSoft Enterprise PeopleTools accessible data. CVSS 3.1 Base Score 6.1 (Confidentiality and Integrity impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N).
CVE-2026-21966: Vulnerability in the Oracle Hospitality OPERA 5 Property Services product of Oracle Hospitality Applications (component: Opera).  Supported versions that are affected are 5.6.19.23, 5.6.25.17, 5.6.26.10 and  5.6.27.4. Easily exploitable vulnerability allows unauthenticated attacker with network access via HTTP to compromise Oracle Hospitality OPERA 5 Property Services.  Successful attacks require human interaction from a person other than the attacker and while the vulnerability is in Oracle Hospitality OPERA 5 Property Services, attacks may significantly impact additional products (scope change). Successful attacks of this vulnerability can result in  unauthorized update, insert or delete access to some of Oracle Hospitality OPERA 5 Property Services accessible data as well as  unauthorized read access to a subset of Oracle Hospitality OPERA 5 Property Services accessible data. CVSS 3.1 Base Score 6.1 (Confidentiality and Integrity impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N).
CVE-2026-21968: Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Optimizer).  Supported versions that are affected are 8.0.0-8.0.44, 8.4.0-8.4.7 and  9.0.0-9.5.0. Easily exploitable vulnerability allows low privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 6.5 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H).
CVE-2025-71145: In the Linux kernel, the following vulnerability has been resolved:  usb: phy: isp1301: fix non-OF device reference imbalance  A recent change fixing a device reference leak in a UDC driver introduced a potential use-after-free in the non-OF case as the isp1301_get_client() helper only increases the reference count for the returned I2C device in the OF case.  Increment the reference count also for non-OF so that the caller can decrement it unconditionally.  Note that this is inherently racy just as using the returned I2C device is since nothing is preventing the PHY driver from being unbound while in use.
CVE-2025-71148: In the Linux kernel, the following vulnerability has been resolved:  net/handshake: restore destructor on submit failure  handshake_req_submit() replaces sk->sk_destruct but never restores it when submission fails before the request is hashed. handshake_sk_destruct() then returns early and the original destructor never runs, leaking the socket. Restore sk_destruct on the error path.
CVE-2025-71150: In the Linux kernel, the following vulnerability has been resolved:  ksmbd: Fix refcount leak when invalid session is found on session lookup  When a session is found but its state is not SMB2_SESSION_VALID, It indicates that no valid session was found, but it is missing to decrement the reference count acquired by the session lookup, which results in a reference count leak. This patch fixes the issue by explicitly calling ksmbd_user_session_put to release the reference to the session.
CVE-2025-71160: In the Linux kernel, the following vulnerability has been resolved:  netfilter: nf_tables: avoid chain re-validation if possible  Hamza Mahfooz reports cpu soft lock-ups in nft_chain_validate():   watchdog: BUG: soft lockup - CPU#1 stuck for 27s! [iptables-nft-re:37547] [..]  RIP: 0010:nft_chain_validate+0xcb/0x110 [nf_tables] [..]   nft_immediate_validate+0x36/0x50 [nf_tables]   nft_chain_validate+0xc9/0x110 [nf_tables]   nft_immediate_validate+0x36/0x50 [nf_tables]   nft_chain_validate+0xc9/0x110 [nf_tables]   nft_immediate_validate+0x36/0x50 [nf_tables]   nft_chain_validate+0xc9/0x110 [nf_tables]   nft_immediate_validate+0x36/0x50 [nf_tables]   nft_chain_validate+0xc9/0x110 [nf_tables]   nft_immediate_validate+0x36/0x50 [nf_tables]   nft_chain_validate+0xc9/0x110 [nf_tables]   nft_immediate_validate+0x36/0x50 [nf_tables]   nft_chain_validate+0xc9/0x110 [nf_tables]   nft_table_validate+0x6b/0xb0 [nf_tables]   nf_tables_validate+0x8b/0xa0 [nf_tables]   nf_tables_commit+0x1df/0x1eb0 [nf_tables] [..]  Currently nf_tables will traverse the entire table (chain graph), starting from the entry points (base chains), exploring all possible paths (chain jumps).  But there are cases where we could avoid revalidation.  Consider: 1  input -> j2 -> j3 2  input -> j2 -> j3 3  input -> j1 -> j2 -> j3  Then the second rule does not need to revalidate j2, and, by extension j3, because this was already checked during validation of the first rule. We need to validate it only for rule 3.  This is needed because chain loop detection also ensures we do not exceed the jump stack: Just because we know that j2 is cycle free, its last jump might now exceed the allowed stack size.  We also need to update all reachable chains with the new largest observed call depth.  Care has to be taken to revalidate even if the chain depth won't be an issue: chain validation also ensures that expressions are not called from invalid base chains.  For example, the masquerade expression can only be called from NAT postrouting base chains.  Therefore we also need to keep record of the base chain context (type, hooknum) and revalidate if the chain becomes reachable from a different hook location.
CVE-2026-22978: In the Linux kernel, the following vulnerability has been resolved:  wifi: avoid kernel-infoleak from struct iw_point  struct iw_point has a 32bit hole on 64bit arches.  struct iw_point {   void __user   *pointer;       /* Pointer to the data  (in user space) */   __u16         length;         /* number of fields or size in bytes */   __u16         flags;          /* Optional params */ };  Make sure to zero the structure to avoid disclosing 32bits of kernel data to user space.
CVE-2026-22989: In the Linux kernel, the following vulnerability has been resolved:  nfsd: check that server is running in unlock_filesystem  If we are trying to unlock the filesystem via an administrative interface and nfsd isn't running, it crashes the server. This happens currently because nfsd4_revoke_states() access state structures (eg., conf_id_hashtbl) that has been freed as a part of the server shutdown.  [   59.465072] Call trace: [   59.465308]  nfsd4_revoke_states+0x1b4/0x898 [nfsd] (P) [   59.465830]  write_unlock_fs+0x258/0x440 [nfsd] [   59.466278]  nfsctl_transaction_write+0xb0/0x120 [nfsd] [   59.466780]  vfs_write+0x1f0/0x938 [   59.467088]  ksys_write+0xfc/0x1f8 [   59.467395]  __arm64_sys_write+0x74/0xb8 [   59.467746]  invoke_syscall.constprop.0+0xdc/0x1e8 [   59.468177]  do_el0_svc+0x154/0x1d8 [   59.468489]  el0_svc+0x40/0xe0 [   59.468767]  el0t_64_sync_handler+0xa0/0xe8 [   59.469138]  el0t_64_sync+0x1ac/0x1b0  Ensure this can't happen by taking the nfsd_mutex and checking that the server is still up, and then holding the mutex across the call to nfsd4_revoke_states().
CVE-2026-22994: In the Linux kernel, the following vulnerability has been resolved:  bpf: Fix reference count leak in bpf_prog_test_run_xdp()  syzbot is reporting    unregister_netdevice: waiting for sit0 to become free. Usage count = 2  problem. A debug printk() patch found that a refcount is obtained at xdp_convert_md_to_buff() from bpf_prog_test_run_xdp().  According to commit ec94670fcb3b ("bpf: Support specifying ingress via xdp_md context in BPF_PROG_TEST_RUN"), the refcount obtained by xdp_convert_md_to_buff() will be released by xdp_convert_buff_to_md().  Therefore, we can consider that the error handling path introduced by commit 1c1949982524 ("bpf: introduce frags support to bpf_prog_test_run_xdp()") forgot to call xdp_convert_buff_to_md().