xamxte/cve-to-cwe huggingface dataset:
CVE-2025-39758: In the Linux kernel, the following vulnerability has been resolved:  RDMA/siw: Fix the sendmsg byte count in siw_tcp_sendpages  Ever since commit c2ff29e99a76 ("siw: Inline do_tcp_sendpages()"), we have been doing this:  static int siw_tcp_sendpages(struct socket *s, struct page **page, int offset,                              size_t size) [...]         /* Calculate the number of bytes we need to push, for this page          * specifically */         size_t bytes = min_t(size_t, PAGE_SIZE - offset, size);         /* If we can't splice it, then copy it in, as normal */         if (!sendpage_ok(page[i]))                 msg.msg_flags &= ~MSG_SPLICE_PAGES;         /* Set the bvec pointing to the page, with len $bytes */         bvec_set_page(&bvec, page[i], bytes, offset);         /* Set the iter to $size, aka the size of the whole sendpages (!!!) */         iov_iter_bvec(&msg.msg_iter, ITER_SOURCE, &bvec, 1, size); try_page_again:         lock_sock(sk);         /* Sendmsg with $size size (!!!) */         rv = tcp_sendmsg_locked(sk, &msg, size);  This means we've been sending oversized iov_iters and tcp_sendmsg calls for a while. This has a been a benign bug because sendpage_ok() always returned true. With the recent slab allocator changes being slowly introduced into next (that disallow sendpage on large kmalloc allocations), we have recently hit out-of-bounds crashes, due to slight differences in iov_iter behavior between the MSG_SPLICE_PAGES and "regular" copy paths:  (MSG_SPLICE_PAGES) skb_splice_from_iter   iov_iter_extract_pages     iov_iter_extract_bvec_pages       uses i->nr_segs to correctly stop in its tracks before OoB'ing everywhere   skb_splice_from_iter gets a "short" read  (!MSG_SPLICE_PAGES) skb_copy_to_page_nocache copy=iov_iter_count  [...]    copy_from_iter         /* this doesn't help */         if (unlikely(iter->count < len))                 len = iter->count;           iterate_bvec             ... and we run off the bvecs  Fix this by properly setting the iov_iter's byte count, plus sending the correct byte count to tcp_sendmsg_locked.
CVE-2025-39774: In the Linux kernel, the following vulnerability has been resolved:  iio: adc: rzg2l_adc: Set driver data before enabling runtime PM  When stress-testing the system by repeatedly unbinding and binding the ADC device in a loop, and the ADC is a supplier for another device (e.g., a thermal hardware block that reads temperature through the ADC), it may happen that the ADC device is runtime-resumed immediately after runtime PM is enabled, triggered by its consumer. At this point, since drvdata is not yet set and the driver's runtime PM callbacks rely on it, a crash can occur. To avoid this, set drvdata just after it was allocated.
CVE-2025-39775: In the Linux kernel, the following vulnerability has been resolved:  mm/mremap: fix WARN with uffd that has remap events disabled  Registering userfaultd on a VMA that spans at least one PMD and then mremap()'ing that VMA can trigger a WARN when recovering from a failed page table move due to a page table allocation error.  The code ends up doing the right thing (recurse, avoiding moving actual page tables), but triggering that WARN is unpleasant:  WARNING: CPU: 2 PID: 6133 at mm/mremap.c:357 move_normal_pmd mm/mremap.c:357 [inline] WARNING: CPU: 2 PID: 6133 at mm/mremap.c:357 move_pgt_entry mm/mremap.c:595 [inline] WARNING: CPU: 2 PID: 6133 at mm/mremap.c:357 move_page_tables+0x3832/0x44a0 mm/mremap.c:852 Modules linked in: CPU: 2 UID: 0 PID: 6133 Comm: syz.0.19 Not tainted 6.17.0-rc1-syzkaller-00004-g53e760d89498 #0 PREEMPT(full) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 RIP: 0010:move_normal_pmd mm/mremap.c:357 [inline] RIP: 0010:move_pgt_entry mm/mremap.c:595 [inline] RIP: 0010:move_page_tables+0x3832/0x44a0 mm/mremap.c:852 Code: ... RSP: 0018:ffffc900037a76d8 EFLAGS: 00010293 RAX: 0000000000000000 RBX: 0000000032930007 RCX: ffffffff820c6645 RDX: ffff88802e56a440 RSI: ffffffff820c7201 RDI: 0000000000000007 RBP: ffff888037728fc0 R08: 0000000000000007 R09: 0000000000000000 R10: 0000000032930007 R11: 0000000000000000 R12: 0000000000000000 R13: ffffc900037a79a8 R14: 0000000000000001 R15: dffffc0000000000 FS:  000055556316a500(0000) GS:ffff8880d68bc000(0000) knlGS:0000000000000000 CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000001b30863fff CR3: 0000000050171000 CR4: 0000000000352ef0 Call Trace:  <TASK>  copy_vma_and_data+0x468/0x790 mm/mremap.c:1215  move_vma+0x548/0x1780 mm/mremap.c:1282  mremap_to+0x1b7/0x450 mm/mremap.c:1406  do_mremap+0xfad/0x1f80 mm/mremap.c:1921  __do_sys_mremap+0x119/0x170 mm/mremap.c:1977  do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]  do_syscall_64+0xcd/0x4c0 arch/x86/entry/syscall_64.c:94  entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f00d0b8ebe9 Code: ... RSP: 002b:00007ffe5ea5ee98 EFLAGS: 00000246 ORIG_RAX: 0000000000000019 RAX: ffffffffffffffda RBX: 00007f00d0db5fa0 RCX: 00007f00d0b8ebe9 RDX: 0000000000400000 RSI: 0000000000c00000 RDI: 0000200000000000 RBP: 00007ffe5ea5eef0 R08: 0000200000c00000 R09: 0000000000000000 R10: 0000000000000003 R11: 0000000000000246 R12: 0000000000000002 R13: 00007f00d0db5fa0 R14: 00007f00d0db5fa0 R15: 0000000000000005  </TASK>  The underlying issue is that we recurse during the original page table move, but not during the recovery move.  Fix it by checking for both VMAs and performing the check before the pmd_none() sanity check.  Add a new helper where we perform+document that check for the PMD and PUD level.  Thanks to Harry for bisecting.
CVE-2025-39787: In the Linux kernel, the following vulnerability has been resolved:  soc: qcom: mdt_loader: Ensure we don't read past the ELF header  When the MDT loader is used in remoteproc, the ELF header is sanitized beforehand, but that's not necessary the case for other clients.  Validate the size of the firmware buffer to ensure that we don't read past the end as we iterate over the header. e_phentsize and e_shentsize are validated as well, to ensure that the assumptions about step size in the traversal are valid.
CVE-2025-10148: curl's websocket code did not update the 32 bit mask pattern for each new  outgoing frame as the specification says. Instead it used a fixed mask that persisted and was used throughout the entire connection.  A predictable mask pattern allows for a malicious server to induce traffic between the two communicating parties that could be interpreted by an involved proxy (configured or transparent) as genuine, real, HTTP traffic with content and thereby poison its cache. That cached poisoned content could then be served to all users of that proxy.
CVE-2025-3650: The jQuery Colorbox WordPress plugin through 4.6.3 uses the colorbox library, which does not sanitize title attributes on links before using them, allowing users with at least the contributor role to conduct XSS attacks against administrators.
CVE-2025-9556: Langchaingo supports the use of jinja2 syntax when parsing prompts, which is in turn parsed using the gonja library v1.5.3. Gonja supports include and extends syntax to read files, which leads to a server side template injection vulnerability within langchaingo, allowing an attacker to insert a statement into a prompt to read the "etc/passwd" file.
CVE-2025-39793: In the Linux kernel, the following vulnerability has been resolved:  io_uring/memmap: cast nr_pages to size_t before shifting  If the allocated size exceeds UINT_MAX, then it's necessary to cast the mr->nr_pages value to size_t to prevent it from overflowing. In practice this isn't much of a concern as the required memory size will have been validated upfront, and accounted to the user. And > 4GB sizes will be necessary to make the lack of a cast a problem, which greatly exceeds normal user locked_vm settings that are generally in the kb to mb range. However, if root is used, then accounting isn't done, and then it's possible to hit this issue.
CVE-2022-50246: In the Linux kernel, the following vulnerability has been resolved:  usb: typec: tcpci: fix of node refcount leak in tcpci_register_port()  I got the following report while doing device(mt6370-tcpc) load test with CONFIG_OF_UNITTEST and CONFIG_OF_DYNAMIC enabled:    OF: ERROR: memory leak, expected refcount 1 instead of 2,   of_node_get()/of_node_put() unbalanced - destroy cset entry:   attach overlay node /i2c/pmic@34/tcpc/connector  The 'fwnode' set in tcpci_parse_config() which is called in tcpci_register_port(), its node refcount is increased in device_get_named_child_node(). It needs be put while exiting, so call fwnode_handle_put() in the error path of tcpci_register_port() and in tcpci_unregister_port() to avoid leak.
CVE-2022-50249: In the Linux kernel, the following vulnerability has been resolved:  memory: of: Fix refcount leak bug in of_get_ddr_timings()  We should add the of_node_put() when breaking out of for_each_child_of_node() as it will automatically increase and decrease the refcount.
CVE-2022-50261: In the Linux kernel, the following vulnerability has been resolved:  drm/sti: Fix return type of sti_{dvo,hda,hdmi}_connector_mode_valid()  With clang's kernel control flow integrity (kCFI, CONFIG_CFI_CLANG), indirect call targets are validated against the expected function pointer prototype to make sure the call target is valid to help mitigate ROP attacks. If they are not identical, there is a failure at run time, which manifests as either a kernel panic or thread getting killed. A proposed warning in clang aims to catch these at compile time, which reveals:    drivers/gpu/drm/sti/sti_hda.c:637:16: error: incompatible function pointer types initializing 'enum drm_mode_status (*)(struct drm_connector *, struct drm_display_mode *)' with an expression of type 'int (struct drm_connector *, struct drm_display_mode *)' [-Werror,-Wincompatible-function-pointer-types-strict]           .mode_valid = sti_hda_connector_mode_valid,                         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~   drivers/gpu/drm/sti/sti_dvo.c:376:16: error: incompatible function pointer types initializing 'enum drm_mode_status (*)(struct drm_connector *, struct drm_display_mode *)' with an expression of type 'int (struct drm_connector *, struct drm_display_mode *)' [-Werror,-Wincompatible-function-pointer-types-strict]           .mode_valid = sti_dvo_connector_mode_valid,                         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~   drivers/gpu/drm/sti/sti_hdmi.c:1035:16: error: incompatible function pointer types initializing 'enum drm_mode_status (*)(struct drm_connector *, struct drm_display_mode *)' with an expression of type 'int (struct drm_connector *, struct drm_display_mode *)' [-Werror,-Wincompatible-function-pointer-types-strict]           .mode_valid = sti_hdmi_connector_mode_valid,                         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~  ->mode_valid() in 'struct drm_connector_helper_funcs' expects a return type of 'enum drm_mode_status', not 'int'. Adjust the return type of sti_{dvo,hda,hdmi}_connector_mode_valid() to match the prototype's to resolve the warning and CFI failure.
CVE-2023-53163: In the Linux kernel, the following vulnerability has been resolved:  fs/ntfs3: don't hold ni_lock when calling truncate_setsize()  syzbot is reporting hung task at do_user_addr_fault() [1], for there is a silent deadlock between PG_locked bit and ni_lock lock.  Since filemap_update_page() calls filemap_read_folio() after calling folio_trylock() which will set PG_locked bit, ntfs_truncate() must not call truncate_setsize() which will wait for PG_locked bit to be cleared when holding ni_lock lock.
CVE-2023-53164: In the Linux kernel, the following vulnerability has been resolved:  irqchip/ti-sci: Fix refcount leak in ti_sci_intr_irq_domain_probe  of_irq_find_parent() returns a node pointer with refcount incremented, We should use of_node_put() on it when not needed anymore. Add missing of_node_put() to avoid refcount leak.
CVE-2023-53175: In the Linux kernel, the following vulnerability has been resolved:  PCI: hv: Fix a crash in hv_pci_restore_msi_msg() during hibernation  When a Linux VM with an assigned PCI device runs on Hyper-V, if the PCI device driver is not loaded yet (i.e. MSI-X/MSI is not enabled on the device yet), doing a VM hibernation triggers a panic in hv_pci_restore_msi_msg() -> msi_lock_descs(&pdev->dev), because pdev->dev.msi.data is still NULL.  Avoid the panic by checking if MSI-X/MSI is enabled.
CVE-2023-53176: In the Linux kernel, the following vulnerability has been resolved:  serial: 8250: Reinit port->pm on port specific driver unbind  When we unbind a serial port hardware specific 8250 driver, the generic serial8250 driver takes over the port. After that we see an oops about 10 seconds later. This can produce the following at least on some TI SoCs:  Unhandled fault: imprecise external abort (0x1406) Internal error: : 1406 [#1] SMP ARM  Turns out that we may still have the serial port hardware specific driver port->pm in use, and serial8250_pm() tries to call it after the port specific driver is gone:  serial8250_pm [8250_base] from uart_change_pm+0x54/0x8c [serial_base] uart_change_pm [serial_base] from uart_hangup+0x154/0x198 [serial_base] uart_hangup [serial_base] from __tty_hangup.part.0+0x328/0x37c __tty_hangup.part.0 from disassociate_ctty+0x154/0x20c disassociate_ctty from do_exit+0x744/0xaac do_exit from do_group_exit+0x40/0x8c do_group_exit from __wake_up_parent+0x0/0x1c  Let's fix the issue by calling serial8250_set_defaults() in serial8250_unregister_port(). This will set the port back to using the serial8250 default functions, and sets the port->pm to point to serial8250_pm.
CVE-2023-53181: In the Linux kernel, the following vulnerability has been resolved:  dma-buf/dma-resv: Stop leaking on krealloc() failure  Currently dma_resv_get_fences() will leak the previously allocated array if the fence iteration got restarted and the krealloc_array() fails.  Free the old array by hand, and make sure we still clear the returned *fences so the caller won't end up accessing freed memory. Some (but not all) of the callers of dma_resv_get_fences() seem to still trawl through the array even when dma_resv_get_fences() failed. And let's zero out *num_fences as well for good measure.
CVE-2023-53191: In the Linux kernel, the following vulnerability has been resolved:  irqchip/alpine-msi: Fix refcount leak in alpine_msix_init_domains  of_irq_find_parent() returns a node pointer with refcount incremented, We should use of_node_put() on it when not needed anymore. Add missing of_node_put() to avoid refcount leak.
CVE-2022-50265: In the Linux kernel, the following vulnerability has been resolved:  kcm: annotate data-races around kcm->rx_wait  kcm->rx_psock can be read locklessly in kcm_rfree(). Annotate the read and writes accordingly.  syzbot reported:  BUG: KCSAN: data-race in kcm_rcv_strparser / kcm_rfree  write to 0xffff88810784e3d0 of 1 bytes by task 1823 on cpu 1: reserve_rx_kcm net/kcm/kcmsock.c:283 [inline] kcm_rcv_strparser+0x250/0x3a0 net/kcm/kcmsock.c:363 __strp_recv+0x64c/0xd20 net/strparser/strparser.c:301 strp_recv+0x6d/0x80 net/strparser/strparser.c:335 tcp_read_sock+0x13e/0x5a0 net/ipv4/tcp.c:1703 strp_read_sock net/strparser/strparser.c:358 [inline] do_strp_work net/strparser/strparser.c:406 [inline] strp_work+0xe8/0x180 net/strparser/strparser.c:415 process_one_work+0x3d3/0x720 kernel/workqueue.c:2289 worker_thread+0x618/0xa70 kernel/workqueue.c:2436 kthread+0x1a9/0x1e0 kernel/kthread.c:376 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:306  read to 0xffff88810784e3d0 of 1 bytes by task 17869 on cpu 0: kcm_rfree+0x121/0x220 net/kcm/kcmsock.c:181 skb_release_head_state+0x8e/0x160 net/core/skbuff.c:841 skb_release_all net/core/skbuff.c:852 [inline] __kfree_skb net/core/skbuff.c:868 [inline] kfree_skb_reason+0x5c/0x260 net/core/skbuff.c:891 kfree_skb include/linux/skbuff.h:1216 [inline] kcm_recvmsg+0x226/0x2b0 net/kcm/kcmsock.c:1161 ____sys_recvmsg+0x16c/0x2e0 ___sys_recvmsg net/socket.c:2743 [inline] do_recvmmsg+0x2f1/0x710 net/socket.c:2837 __sys_recvmmsg net/socket.c:2916 [inline] __do_sys_recvmmsg net/socket.c:2939 [inline] __se_sys_recvmmsg net/socket.c:2932 [inline] __x64_sys_recvmmsg+0xde/0x160 net/socket.c:2932 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x2b/0x70 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd  value changed: 0x01 -> 0x00  Reported by Kernel Concurrency Sanitizer on: CPU: 0 PID: 17869 Comm: syz-executor.2 Not tainted 6.1.0-rc1-syzkaller-00010-gbb1a1146467a-dirty #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/22/2022
CVE-2022-50285: In the Linux kernel, the following vulnerability has been resolved:  mm,hugetlb: take hugetlb_lock before decrementing h->resv_huge_pages  The h->*_huge_pages counters are protected by the hugetlb_lock, but alloc_huge_page has a corner case where it can decrement the counter outside of the lock.  This could lead to a corrupted value of h->resv_huge_pages, which we have observed on our systems.  Take the hugetlb_lock before decrementing h->resv_huge_pages to avoid a potential race.
CVE-2022-50291: In the Linux kernel, the following vulnerability has been resolved:  kcm: annotate data-races around kcm->rx_psock  kcm->rx_psock can be read locklessly in kcm_rfree(). Annotate the read and writes accordingly.  We do the same for kcm->rx_wait in the following patch.  syzbot reported: BUG: KCSAN: data-race in kcm_rfree / unreserve_rx_kcm  write to 0xffff888123d827b8 of 8 bytes by task 2758 on cpu 1: unreserve_rx_kcm+0x72/0x1f0 net/kcm/kcmsock.c:313 kcm_rcv_strparser+0x2b5/0x3a0 net/kcm/kcmsock.c:373 __strp_recv+0x64c/0xd20 net/strparser/strparser.c:301 strp_recv+0x6d/0x80 net/strparser/strparser.c:335 tcp_read_sock+0x13e/0x5a0 net/ipv4/tcp.c:1703 strp_read_sock net/strparser/strparser.c:358 [inline] do_strp_work net/strparser/strparser.c:406 [inline] strp_work+0xe8/0x180 net/strparser/strparser.c:415 process_one_work+0x3d3/0x720 kernel/workqueue.c:2289 worker_thread+0x618/0xa70 kernel/workqueue.c:2436 kthread+0x1a9/0x1e0 kernel/kthread.c:376 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:306  read to 0xffff888123d827b8 of 8 bytes by task 5859 on cpu 0: kcm_rfree+0x14c/0x220 net/kcm/kcmsock.c:181 skb_release_head_state+0x8e/0x160 net/core/skbuff.c:841 skb_release_all net/core/skbuff.c:852 [inline] __kfree_skb net/core/skbuff.c:868 [inline] kfree_skb_reason+0x5c/0x260 net/core/skbuff.c:891 kfree_skb include/linux/skbuff.h:1216 [inline] kcm_recvmsg+0x226/0x2b0 net/kcm/kcmsock.c:1161 ____sys_recvmsg+0x16c/0x2e0 ___sys_recvmsg net/socket.c:2743 [inline] do_recvmmsg+0x2f1/0x710 net/socket.c:2837 __sys_recvmmsg net/socket.c:2916 [inline] __do_sys_recvmmsg net/socket.c:2939 [inline] __se_sys_recvmmsg net/socket.c:2932 [inline] __x64_sys_recvmmsg+0xde/0x160 net/socket.c:2932 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x2b/0x70 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd  value changed: 0xffff88812971ce00 -> 0x0000000000000000  Reported by Kernel Concurrency Sanitizer on: CPU: 0 PID: 5859 Comm: syz-executor.3 Not tainted 6.0.0-syzkaller-12189-g19d17ab7c68b-dirty #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/22/2022
CVE-2022-50297: In the Linux kernel, the following vulnerability has been resolved:  wifi: ath9k: verify the expected usb_endpoints are present  The bug arises when a USB device claims to be an ATH9K but doesn't have the expected endpoints. (In this case there was an interrupt endpoint where the driver expected a bulk endpoint.) The kernel needs to be able to handle such devices without getting an internal error.  usb 1-1: BOGUS urb xfer, pipe 3 != type 1 WARNING: CPU: 3 PID: 500 at drivers/usb/core/urb.c:493 usb_submit_urb+0xce2/0x1430 drivers/usb/core/urb.c:493 Modules linked in: CPU: 3 PID: 500 Comm: kworker/3:2 Not tainted 5.10.135-syzkaller #0 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014 Workqueue: events request_firmware_work_func RIP: 0010:usb_submit_urb+0xce2/0x1430 drivers/usb/core/urb.c:493 Call Trace:  ath9k_hif_usb_alloc_rx_urbs drivers/net/wireless/ath/ath9k/hif_usb.c:908 [inline]  ath9k_hif_usb_alloc_urbs+0x75e/0x1010 drivers/net/wireless/ath/ath9k/hif_usb.c:1019  ath9k_hif_usb_dev_init drivers/net/wireless/ath/ath9k/hif_usb.c:1109 [inline]  ath9k_hif_usb_firmware_cb+0x142/0x530 drivers/net/wireless/ath/ath9k/hif_usb.c:1242  request_firmware_work_func+0x12e/0x240 drivers/base/firmware_loader/main.c:1097  process_one_work+0x9af/0x1600 kernel/workqueue.c:2279  worker_thread+0x61d/0x12f0 kernel/workqueue.c:2425  kthread+0x3b4/0x4a0 kernel/kthread.c:313  ret_from_fork+0x22/0x30 arch/x86/entry/entry_64.S:299  Found by Linux Verification Center (linuxtesting.org) with Syzkaller.
CVE-2022-50309: In the Linux kernel, the following vulnerability has been resolved:  media: xilinx: vipp: Fix refcount leak in xvip_graph_dma_init  of_get_child_by_name() returns a node pointer with refcount incremented, we should use of_node_put() on it when not need anymore. Add missing of_node_put() to avoid refcount leak.
CVE-2022-50311: In the Linux kernel, the following vulnerability has been resolved:  cxl: Fix refcount leak in cxl_calc_capp_routing  of_get_next_parent() returns a node pointer with refcount incremented, we should use of_node_put() on it when not need anymore. This function only calls of_node_put() in normal path, missing it in the error path. Add missing of_node_put() to avoid refcount leak.
CVE-2022-50318: In the Linux kernel, the following vulnerability has been resolved:  perf/x86/intel/uncore: Fix reference count leak in hswep_has_limit_sbox()  pci_get_device() will increase the reference count for the returned 'dev'. We need to call pci_dev_put() to decrease the reference count. Since 'dev' is only used in pci_read_config_dword(), let's add pci_dev_put() right after it.
CVE-2022-50337: In the Linux kernel, the following vulnerability has been resolved:  ocxl: fix pci device refcount leak when calling get_function_0()  get_function_0() calls pci_get_domain_bus_and_slot(), as comment says, it returns a pci device with refcount increment, so after using it, pci_dev_put() needs be called.  Get the device reference when get_function_0() is not called, so pci_dev_put() can be called in the error path and callers unconditionally. And add comment above get_dvsec_vendor0() to tell callers to call pci_dev_put().