xamxte/cve-to-cwe huggingface dataset:
CVE-2025-40183: In the Linux kernel, the following vulnerability has been resolved:  bpf: Fix metadata_dst leak __bpf_redirect_neigh_v{4,6}  Cilium has a BPF egress gateway feature which forces outgoing K8s Pod traffic to pass through dedicated egress gateways which then SNAT the traffic in order to interact with stable IPs outside the cluster.  The traffic is directed to the gateway via vxlan tunnel in collect md mode. A recent BPF change utilized the bpf_redirect_neigh() helper to forward packets after the arrival and decap on vxlan, which turned out over time that the kmalloc-256 slab usage in kernel was ever-increasing.  The issue was that vxlan allocates the metadata_dst object and attaches it through a fake dst entry to the skb. The latter was never released though given bpf_redirect_neigh() was merely setting the new dst entry via skb_dst_set() without dropping an existing one first.
CVE-2025-40184: In the Linux kernel, the following vulnerability has been resolved:  KVM: arm64: Fix debug checking for np-guests using huge mappings  When running with transparent huge pages and CONFIG_NVHE_EL2_DEBUG then the debug checking in assert_host_shared_guest() fails on the launch of an np-guest. This WARN_ON() causes a panic and generates the stack below.  In __pkvm_host_relax_perms_guest() the debug checking assumes the mapping is a single page but it may be a block map. Update the checking so that the size is not checked and just assumes the correct size.  While we're here make the same fix in __pkvm_host_mkyoung_guest().    Info: # lkvm run -k /share/arch/arm64/boot/Image -m 704 -c 8 --name guest-128   Info: Removed ghost socket file "/.lkvm//guest-128.sock". [ 1406.521757] kvm [141]: nVHE hyp BUG at: arch/arm64/kvm/hyp/nvhe/mem_protect.c:1088! [ 1406.521804] kvm [141]: nVHE call trace: [ 1406.521828] kvm [141]:  [<ffff8000811676b4>] __kvm_nvhe_hyp_panic+0xb4/0xe8 [ 1406.521946] kvm [141]:  [<ffff80008116d12c>] __kvm_nvhe_assert_host_shared_guest+0xb0/0x10c [ 1406.522049] kvm [141]:  [<ffff80008116f068>] __kvm_nvhe___pkvm_host_relax_perms_guest+0x48/0x104 [ 1406.522157] kvm [141]:  [<ffff800081169df8>] __kvm_nvhe_handle___pkvm_host_relax_perms_guest+0x64/0x7c [ 1406.522250] kvm [141]:  [<ffff800081169f0c>] __kvm_nvhe_handle_trap+0x8c/0x1a8 [ 1406.522333] kvm [141]:  [<ffff8000811680fc>] __kvm_nvhe___skip_pauth_save+0x4/0x4 [ 1406.522454] kvm [141]: ---[ end nVHE call trace ]--- [ 1406.522477] kvm [141]: Hyp Offset: 0xfffece8013600000 [ 1406.522554] Kernel panic - not syncing: HYP panic: [ 1406.522554] PS:834003c9 PC:0000b1806db6d170 ESR:00000000f2000800 [ 1406.522554] FAR:ffff8000804be420 HPFAR:0000000000804be0 PAR:0000000000000000 [ 1406.522554] VCPU:0000000000000000 [ 1406.523337] CPU: 3 UID: 0 PID: 141 Comm: kvm-vcpu-0 Not tainted 6.16.0-rc7 #97 PREEMPT [ 1406.523485] Hardware name: FVP Base RevC (DT) [ 1406.523566] Call trace: [ 1406.523629]  show_stack+0x18/0x24 (C) [ 1406.523753]  dump_stack_lvl+0xd4/0x108 [ 1406.523899]  dump_stack+0x18/0x24 [ 1406.524040]  panic+0x3d8/0x448 [ 1406.524184]  nvhe_hyp_panic_handler+0x10c/0x23c [ 1406.524325]  kvm_handle_guest_abort+0x68c/0x109c [ 1406.524500]  handle_exit+0x60/0x17c [ 1406.524630]  kvm_arch_vcpu_ioctl_run+0x2e0/0x8c0 [ 1406.524794]  kvm_vcpu_ioctl+0x1a8/0x9cc [ 1406.524919]  __arm64_sys_ioctl+0xac/0x104 [ 1406.525067]  invoke_syscall+0x48/0x10c [ 1406.525189]  el0_svc_common.constprop.0+0x40/0xe0 [ 1406.525322]  do_el0_svc+0x1c/0x28 [ 1406.525441]  el0_svc+0x38/0x120 [ 1406.525588]  el0t_64_sync_handler+0x10c/0x138 [ 1406.525750]  el0t_64_sync+0x1ac/0x1b0 [ 1406.525876] SMP: stopping secondary CPUs [ 1406.525965] Kernel Offset: disabled [ 1406.526032] CPU features: 0x0000,00000080,8e134ca1,9446773f [ 1406.526130] Memory Limit: none [ 1406.959099] ---[ end Kernel panic - not syncing: HYP panic: [ 1406.959099] PS:834003c9 PC:0000b1806db6d170 ESR:00000000f2000800 [ 1406.959099] FAR:ffff8000804be420 HPFAR:0000000000804be0 PAR:0000000000000000 [ 1406.959099] VCPU:0000000000000000 ]
CVE-2025-40186: In the Linux kernel, the following vulnerability has been resolved:  tcp: Don't call reqsk_fastopen_remove() in tcp_conn_request().  syzbot reported the splat below in tcp_conn_request(). [0]  If a listener is close()d while a TFO socket is being processed in tcp_conn_request(), inet_csk_reqsk_queue_add() does not set reqsk->sk and calls inet_child_forget(), which calls tcp_disconnect() for the TFO socket.  After the cited commit, tcp_disconnect() calls reqsk_fastopen_remove(), where reqsk_put() is called due to !reqsk->sk.  Then, reqsk_fastopen_remove() in tcp_conn_request() decrements the last req->rsk_refcnt and frees reqsk, and __reqsk_free() at the drop_and_free label causes the refcount underflow for the listener and double-free of the reqsk.  Let's remove reqsk_fastopen_remove() in tcp_conn_request().  Note that other callers make sure tp->fastopen_rsk is not NULL.  [0]: refcount_t: underflow; use-after-free. WARNING: CPU: 12 PID: 5563 at lib/refcount.c:28 refcount_warn_saturate (lib/refcount.c:28) Modules linked in: CPU: 12 UID: 0 PID: 5563 Comm: syz-executor Not tainted syzkaller #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/12/2025 RIP: 0010:refcount_warn_saturate (lib/refcount.c:28) Code: ab e8 8e b4 98 ff 0f 0b c3 cc cc cc cc cc 80 3d a4 e4 d6 01 00 75 9c c6 05 9b e4 d6 01 01 48 c7 c7 e8 df fb ab e8 6a b4 98 ff <0f> 0b e9 03 5b 76 00 cc 80 3d 7d e4 d6 01 00 0f 85 74 ff ff ff c6 RSP: 0018:ffffa79fc0304a98 EFLAGS: 00010246 RAX: d83af4db1c6b3900 RBX: ffff9f65c7a69020 RCX: d83af4db1c6b3900 RDX: 0000000000000000 RSI: 00000000ffff7fff RDI: ffffffffac78a280 RBP: 000000009d781b60 R08: 0000000000007fff R09: ffffffffac6ca280 R10: 0000000000017ffd R11: 0000000000000004 R12: ffff9f65c7b4f100 R13: ffff9f65c7d23c00 R14: ffff9f65c7d26000 R15: ffff9f65c7a64ef8 FS:  00007f9f962176c0(0000) GS:ffff9f65fcf00000(0000) knlGS:0000000000000000 CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000200000000180 CR3: 000000000dbbe006 CR4: 0000000000372ef0 Call Trace:  <IRQ>  tcp_conn_request (./include/linux/refcount.h:400 ./include/linux/refcount.h:432 ./include/linux/refcount.h:450 ./include/net/sock.h:1965 ./include/net/request_sock.h:131 net/ipv4/tcp_input.c:7301)  tcp_rcv_state_process (net/ipv4/tcp_input.c:6708)  tcp_v6_do_rcv (net/ipv6/tcp_ipv6.c:1670)  tcp_v6_rcv (net/ipv6/tcp_ipv6.c:1906)  ip6_protocol_deliver_rcu (net/ipv6/ip6_input.c:438)  ip6_input (net/ipv6/ip6_input.c:500)  ipv6_rcv (net/ipv6/ip6_input.c:311)  __netif_receive_skb (net/core/dev.c:6104)  process_backlog (net/core/dev.c:6456)  __napi_poll (net/core/dev.c:7506)  net_rx_action (net/core/dev.c:7569 net/core/dev.c:7696)  handle_softirqs (kernel/softirq.c:579)  do_softirq (kernel/softirq.c:480)  </IRQ>
CVE-2025-40187: In the Linux kernel, the following vulnerability has been resolved:  net/sctp: fix a null dereference in sctp_disposition sctp_sf_do_5_1D_ce()  If new_asoc->peer.adaptation_ind=0 and sctp_ulpevent_make_authkey=0 and sctp_ulpevent_make_authkey() returns 0, then the variable ai_ev remains zero and the zero will be dereferenced in the sctp_ulpevent_free() function.
CVE-2025-40189: In the Linux kernel, the following vulnerability has been resolved:  net: usb: lan78xx: Fix lost EEPROM read timeout error(-ETIMEDOUT) in lan78xx_read_raw_eeprom  Syzbot reported read of uninitialized variable BUG with following call stack.  lan78xx 8-1:1.0 (unnamed net_device) (uninitialized): EEPROM read operation timeout ===================================================== BUG: KMSAN: uninit-value in lan78xx_read_eeprom drivers/net/usb/lan78xx.c:1095 [inline] BUG: KMSAN: uninit-value in lan78xx_init_mac_address drivers/net/usb/lan78xx.c:1937 [inline] BUG: KMSAN: uninit-value in lan78xx_reset+0x999/0x2cd0 drivers/net/usb/lan78xx.c:3241  lan78xx_read_eeprom drivers/net/usb/lan78xx.c:1095 [inline]  lan78xx_init_mac_address drivers/net/usb/lan78xx.c:1937 [inline]  lan78xx_reset+0x999/0x2cd0 drivers/net/usb/lan78xx.c:3241  lan78xx_bind+0x711/0x1690 drivers/net/usb/lan78xx.c:3766  lan78xx_probe+0x225c/0x3310 drivers/net/usb/lan78xx.c:4707  Local variable sig.i.i created at:  lan78xx_read_eeprom drivers/net/usb/lan78xx.c:1092 [inline]  lan78xx_init_mac_address drivers/net/usb/lan78xx.c:1937 [inline]  lan78xx_reset+0x77e/0x2cd0 drivers/net/usb/lan78xx.c:3241  lan78xx_bind+0x711/0x1690 drivers/net/usb/lan78xx.c:3766  The function lan78xx_read_raw_eeprom failed to properly propagate EEPROM read timeout errors (-ETIMEDOUT). In the fallthrough path, it first attempted to restore the pin configuration for LED outputs and then returned only the status of that restore operation, discarding the original timeout error.  As a result, callers could mistakenly treat the data buffer as valid even though the EEPROM read had actually timed out with no data or partial data.  To fix this, handle errors in restoring the LED pin configuration separately. If the restore succeeds, return any prior EEPROM timeout error correctly to the caller.
CVE-2025-40190: In the Linux kernel, the following vulnerability has been resolved:  ext4: guard against EA inode refcount underflow in xattr update  syzkaller found a path where ext4_xattr_inode_update_ref() reads an EA inode refcount that is already <= 0 and then applies ref_change (often -1). That lets the refcount underflow and we proceed with a bogus value, triggering errors like:    EXT4-fs error: EA inode <n> ref underflow: ref_count=-1 ref_change=-1   EXT4-fs warning: ea_inode dec ref err=-117  Make the invariant explicit: if the current refcount is non-positive, treat this as on-disk corruption, emit ext4_error_inode(), and fail the operation with -EFSCORRUPTED instead of updating the refcount. Delete the WARN_ONCE() as negative refcounts are now impossible; keep error reporting in ext4_error_inode().  This prevents the underflow and the follow-on orphan/cleanup churn.
CVE-2025-40191: In the Linux kernel, the following vulnerability has been resolved:  drm/amdkfd: Fix kfd process ref leaking when userptr unmapping  kfd_lookup_process_by_pid hold the kfd process reference to ensure it doesn't get destroyed while sending the segfault event to user space.  Calling kfd_lookup_process_by_pid as function parameter leaks the kfd process refcount and miss the NULL pointer check if app process is already destroyed.
CVE-2025-40193: In the Linux kernel, the following vulnerability has been resolved:  xtensa: simdisk: add input size check in proc_write_simdisk  A malicious user could pass an arbitrarily bad value to memdup_user_nul(), potentially causing kernel crash.  This follows the same pattern as commit ee76746387f6 ("netdevsim: prevent bad user input in nsim_dev_health_break_write()")
CVE-2025-40194: In the Linux kernel, the following vulnerability has been resolved:  cpufreq: intel_pstate: Fix object lifecycle issue in update_qos_request()  The cpufreq_cpu_put() call in update_qos_request() takes place too early because the latter subsequently calls freq_qos_update_request() that indirectly accesses the policy object in question through the QoS request object passed to it.  Fortunately, update_qos_request() is called under intel_pstate_driver_lock, so this issue does not matter for changing the intel_pstate operation mode, but it theoretically can cause a crash to occur on CPU device hot removal (which currently can only happen in virt, but it is formally supported nevertheless).  Address this issue by modifying update_qos_request() to drop the reference to the policy later.
CVE-2025-40195: In the Linux kernel, the following vulnerability has been resolved:  mount: handle NULL values in mnt_ns_release()  When calling in listmount() mnt_ns_release() may be passed a NULL pointer. Handle that case gracefully.
CVE-2025-40198: In the Linux kernel, the following vulnerability has been resolved:  ext4: avoid potential buffer over-read in parse_apply_sb_mount_options()  Unlike other strings in the ext4 superblock, we rely on tune2fs to make sure s_mount_opts is NUL terminated.  Harden parse_apply_sb_mount_options() by treating s_mount_opts as a potential __nonstring.
CVE-2025-40200: In the Linux kernel, the following vulnerability has been resolved:  Squashfs: reject negative file sizes in squashfs_read_inode()  Syskaller reports a "WARNING in ovl_copy_up_file" in overlayfs.  This warning is ultimately caused because the underlying Squashfs file system returns a file with a negative file size.  This commit checks for a negative file size and returns EINVAL.  [phillip@squashfs.org.uk: only need to check 64 bit quantity]
CVE-2025-40201: In the Linux kernel, the following vulnerability has been resolved:  kernel/sys.c: fix the racy usage of task_lock(tsk->group_leader) in sys_prlimit64() paths  The usage of task_lock(tsk->group_leader) in sys_prlimit64()->do_prlimit() path is very broken.  sys_prlimit64() does get_task_struct(tsk) but this only protects task_struct itself. If tsk != current and tsk is not a leader, this process can exit/exec and task_lock(tsk->group_leader) may use the already freed task_struct.  Another problem is that sys_prlimit64() can race with mt-exec which changes ->group_leader. In this case do_prlimit() may take the wrong lock, or (worse) ->group_leader may change between task_lock() and task_unlock().  Change sys_prlimit64() to take tasklist_lock when necessary. This is not nice, but I don't see a better fix for -stable.
CVE-2025-40202: In the Linux kernel, the following vulnerability has been resolved:  ipmi: Rework user message limit handling  The limit on the number of user messages had a number of issues, improper counting in some cases and a use after free.  Restructure how this is all done to handle more in the receive message allocation routine, so all refcouting and user message limit counts are done in that routine.  It's a lot cleaner and safer.
CVE-2025-40204: In the Linux kernel, the following vulnerability has been resolved:  sctp: Fix MAC comparison to be constant-time  To prevent timing attacks, MACs need to be compared in constant time. Use the appropriate helper function for this.
CVE-2025-40205: In the Linux kernel, the following vulnerability has been resolved:  btrfs: avoid potential out-of-bounds in btrfs_encode_fh()  The function btrfs_encode_fh() does not properly account for the three cases it handles.  Before writing to the file handle (fh), the function only returns to the user BTRFS_FID_SIZE_NON_CONNECTABLE (5 dwords, 20 bytes) or BTRFS_FID_SIZE_CONNECTABLE (8 dwords, 32 bytes).  However, when a parent exists and the root ID of the parent and the inode are different, the function writes BTRFS_FID_SIZE_CONNECTABLE_ROOT (10 dwords, 40 bytes).  If *max_len is not large enough, this write goes out of bounds because BTRFS_FID_SIZE_CONNECTABLE_ROOT is greater than BTRFS_FID_SIZE_CONNECTABLE originally returned.  This results in an 8-byte out-of-bounds write at fid->parent_root_objectid = parent_root_id.  A previous attempt to fix this issue was made but was lost.  https://lore.kernel.org/all/4CADAEEC020000780001B32C@vpn.id2.novell.com/  Although this issue does not seem to be easily triggerable, it is a potential memory corruption bug that should be fixed. This patch resolves the issue by ensuring the function returns the appropriate size for all three cases and validates that *max_len is large enough before writing any data.
CVE-2025-40206: In the Linux kernel, the following vulnerability has been resolved:  netfilter: nft_objref: validate objref and objrefmap expressions  Referencing a synproxy stateful object from OUTPUT hook causes kernel crash due to infinite recursive calls:  BUG: TASK stack guard page was hit at 000000008bda5b8c (stack is 000000003ab1c4a5..00000000494d8b12) [...] Call Trace:  __find_rr_leaf+0x99/0x230  fib6_table_lookup+0x13b/0x2d0  ip6_pol_route+0xa4/0x400  fib6_rule_lookup+0x156/0x240  ip6_route_output_flags+0xc6/0x150  __nf_ip6_route+0x23/0x50  synproxy_send_tcp_ipv6+0x106/0x200  synproxy_send_client_synack_ipv6+0x1aa/0x1f0  nft_synproxy_do_eval+0x263/0x310  nft_do_chain+0x5a8/0x5f0 [nf_tables  nft_do_chain_inet+0x98/0x110  nf_hook_slow+0x43/0xc0  __ip6_local_out+0xf0/0x170  ip6_local_out+0x17/0x70  synproxy_send_tcp_ipv6+0x1a2/0x200  synproxy_send_client_synack_ipv6+0x1aa/0x1f0 [...]  Implement objref and objrefmap expression validate functions.  Currently, only NFT_OBJECT_SYNPROXY object type requires validation. This will also handle a jump to a chain using a synproxy object from the OUTPUT hook.  Now when trying to reference a synproxy object in the OUTPUT hook, nft will produce the following error:  synproxy_crash.nft: Error: Could not process rule: Operation not supported   synproxy name mysynproxy   ^^^^^^^^^^^^^^^^^^^^^^^^
CVE-2025-40207: In the Linux kernel, the following vulnerability has been resolved:  media: v4l2-subdev: Fix alloc failure check in v4l2_subdev_call_state_try()  v4l2_subdev_call_state_try() macro allocates a subdev state with __v4l2_subdev_state_alloc(), but does not check the returned value. If __v4l2_subdev_state_alloc fails, it returns an ERR_PTR, and that would cause v4l2_subdev_call_state_try() to crash.  Add proper error handling to v4l2_subdev_call_state_try().
CVE-2025-10686: The Creta Testimonial Showcase WordPress plugin before 1.2.4 is vulnerable to Local File Inclusion. This makes it possible for authenticated attackers, with editor-level access and above, to include and execute arbitrary files on the server, allowing the execution of any PHP code in those files.
CVE-2025-9501: The W3 Total Cache WordPress plugin before 2.8.13 is vulnerable to command injection via the _parse_dynamic_mfunc function, allowing unauthenticated users to execute PHP commands by submitting a comment with a malicious payload to a post.
CVE-2025-55074: Mattermost versions 10.11.x <= 10.11.3, 10.5.x <= 10.5.11 fail to enforce access permissions on the Agents plugin which allows other users to determine when users had read channels via channel member objects
CVE-2025-12502: The attention-bar WordPress plugin through 0.7.2.1 does not sanitize and escape a parameter before using it in a SQL statement, allowing high privilege users such as administrator to perform SQL injection attacks
CVE-2025-40209: In the Linux kernel, the following vulnerability has been resolved:  btrfs: fix memory leak of qgroup_list in btrfs_add_qgroup_relation  When btrfs_add_qgroup_relation() is called with invalid qgroup levels (src >= dst), the function returns -EINVAL directly without freeing the preallocated qgroup_list structure passed by the caller. This causes a memory leak because the caller unconditionally sets the pointer to NULL after the call, preventing any cleanup.  The issue occurs because the level validation check happens before the mutex is acquired and before any error handling path that would free the prealloc pointer. On this early return, the cleanup code at the 'out' label (which includes kfree(prealloc)) is never reached.  In btrfs_ioctl_qgroup_assign(), the code pattern is:      prealloc = kzalloc(sizeof(*prealloc), GFP_KERNEL);     ret = btrfs_add_qgroup_relation(trans, sa->src, sa->dst, prealloc);     prealloc = NULL;  // Always set to NULL regardless of return value     ...     kfree(prealloc);  // This becomes kfree(NULL), does nothing  When the level check fails, 'prealloc' is never freed by either the callee or the caller, resulting in a 64-byte memory leak per failed operation. This can be triggered repeatedly by an unprivileged user with access to a writable btrfs mount, potentially exhausting kernel memory.  Fix this by freeing prealloc before the early return, ensuring prealloc is always freed on all error paths.
CVE-2025-40210: In the Linux kernel, the following vulnerability has been resolved:  Revert "NFSD: Remove the cap on number of operations per NFSv4 COMPOUND"  I've found that pynfs COMP6 now leaves the connection or lease in a strange state, which causes CLOSE9 to hang indefinitely. I've dug into it a little, but I haven't been able to root-cause it yet. However, I bisected to commit 48aab1606fa8 ("NFSD: Remove the cap on number of operations per NFSv4 COMPOUND").  Tianshuo Han also reports a potential vulnerability when decoding an NFSv4 COMPOUND. An attacker can place an arbitrarily large op count in the COMPOUND header, which results in:  [   51.410584] nfsd: vmalloc error: size 1209533382144, exceeds total pages, mode:0xdc0(GFP_KERNEL|__GFP_ZERO), nodemask=(null),cpuset=/,mems_allowed=0  when NFSD attempts to allocate the COMPOUND op array.  Let's restore the operation-per-COMPOUND limit, but increased to 200 for now.
CVE-2025-40211: In the Linux kernel, the following vulnerability has been resolved:  ACPI: video: Fix use-after-free in acpi_video_switch_brightness()  The switch_brightness_work delayed work accesses device->brightness and device->backlight, freed by acpi_video_dev_unregister_backlight() during device removal.  If the work executes after acpi_video_bus_unregister_backlight() frees these resources, it causes a use-after-free when acpi_video_switch_brightness() dereferences device->brightness or device->backlight.  Fix this by calling cancel_delayed_work_sync() for each device's switch_brightness_work in acpi_video_bus_remove_notify_handler() after removing the notify handler that queues the work. This ensures the work completes before the memory is freed.  [ rjw: Changelog edit ]
CVE-2025-11127: The Mstoreapp Mobile App WordPress plugin through 2.08 and Mstoreapp Mobile Multivendor through 9.0.1 do not properly verify users identify when using an AJAX action, allowing unauthenticated users to retrieve a valid session for arbitrary users by knowing their email address.
CVE-2024-14015: The WordPress eCommerce Plugin  WordPress plugin through 2.9.0 does not sanitise and escape a parameter before outputting it back in the page, leading to a Reflected Cross-Site Scripting which could be used against high privilege users such as admin
CVE-2025-12394: The Backup Migration WordPress plugin before 2.0.0 does not properly generate its backup path in certain server configurations, allowing unauthenticated users to fetch a log that discloses the backup filename. The backup archive is then downloadable without authentication.
CVE-2025-12569: The Guest posting / Frontend Posting / Front Editor  WordPress plugin before 5.0.0 does not validate a parameter before redirecting the user to its value, leading to an Open Redirect issue
CVE-2025-12629: The Broken Link Manager WordPress plugin through 0.6.5 does not sanitise and escape a parameter before outputting it back in the page, leading to a Reflected Cross-Site Scripting which could be used against high privilege users such as admin
CVE-2025-12628: The WP 2FA WordPress plugin does not generate backup codes with enough entropy, which could allow attackers to bypass the second factor by brute forcing them
CVE-2025-40212: In the Linux kernel, the following vulnerability has been resolved:  nfsd: fix refcount leak in nfsd_set_fh_dentry()  nfsd exports a "pseudo root filesystem" which is used by NFSv4 to find the various exported filesystems using LOOKUP requests from a known root filehandle.  NFSv3 uses the MOUNT protocol to find those exported filesystems and so is not given access to the pseudo root filesystem.  If a v3 (or v2) client uses a filehandle from that filesystem, nfsd_set_fh_dentry() will report an error, but still stores the export in "struct svc_fh" even though it also drops the reference (exp_put()). This means that when fh_put() is called an extra reference will be dropped which can lead to use-after-free and possible denial of service.  Normal NFS usage will not provide a pseudo-root filehandle to a v3 client.  This bug can only be triggered by the client synthesising an incorrect filehandle.  To fix this we move the assignments to the svc_fh later, after all possible error cases have been detected.