xamxte/cve-to-cwe huggingface dataset:
CVE-2022-48961: In the Linux kernel, the following vulnerability has been resolved:  net: mdio: fix unbalanced fwnode reference count in mdio_device_release()  There is warning report about of_node refcount leak while probing mdio device:  OF: ERROR: memory leak, expected refcount 1 instead of 2, of_node_get()/of_node_put() unbalanced - destroy cset entry: attach overlay node /spi/soc@0/mdio@710700c0/ethernet@4  In of_mdiobus_register_device(), we increase fwnode refcount by fwnode_handle_get() before associating the of_node with mdio device, but it has never been decreased in normal path. Since that, in mdio_device_release(), it needs to call fwnode_handle_put() in addition instead of calling kfree() directly.  After above, just calling mdio_device_free() in the error handle path of of_mdiobus_register_device() is enough to keep the refcount balanced.
CVE-2022-48965: In the Linux kernel, the following vulnerability has been resolved:  gpio/rockchip: fix refcount leak in rockchip_gpiolib_register()  The node returned by of_get_parent() with refcount incremented, of_node_put() needs be called when finish using it. So add it in the end of of_pinctrl_get().
CVE-2022-48971: In the Linux kernel, the following vulnerability has been resolved:  Bluetooth: Fix not cleanup led when bt_init fails  bt_init() calls bt_leds_init() to register led, but if it fails later, bt_leds_cleanup() is not called to unregister it.  This can cause panic if the argument "bluetooth-power" in text is freed and then another led_trigger_register() tries to access it:  BUG: unable to handle page fault for address: ffffffffc06d3bc0 RIP: 0010:strcmp+0xc/0x30   Call Trace:     <TASK>     led_trigger_register+0x10d/0x4f0     led_trigger_register_simple+0x7d/0x100     bt_init+0x39/0xf7 [bluetooth]     do_one_initcall+0xd0/0x4e0
CVE-2022-48973: In the Linux kernel, the following vulnerability has been resolved:  gpio: amd8111: Fix PCI device reference count leak  for_each_pci_dev() is implemented by pci_get_device(). The comment of pci_get_device() says that it will increase the reference count for the returned pci_dev and also decrease the reference count for the input pci_dev @from if it is not NULL.  If we break for_each_pci_dev() loop with pdev not NULL, we need to call pci_dev_put() to decrease the reference count. Add the missing pci_dev_put() after the 'out' label. Since pci_dev_put() can handle NULL input parameter, there is no problem for the 'Device not found' branch. For the normal path, add pci_dev_put() in amd_gpio_exit().
CVE-2022-48985: In the Linux kernel, the following vulnerability has been resolved:  net: mana: Fix race on per-CQ variable napi work_done  After calling napi_complete_done(), the NAPIF_STATE_SCHED bit may be cleared, and another CPU can start napi thread and access per-CQ variable, cq->work_done. If the other thread (for example, from busy_poll) sets it to a value >= budget, this thread will continue to run when it should stop, and cause memory corruption and panic.  To fix this issue, save the per-CQ work_done variable in a local variable before napi_complete_done(), so it won't be corrupted by a possible concurrent thread after napi_complete_done().  Also, add a flag bit to advertise to the NIC firmware: the NAPI work_done variable race is fixed, so the driver is able to reliably support features like busy_poll.
CVE-2022-48997: In the Linux kernel, the following vulnerability has been resolved:  char: tpm: Protect tpm_pm_suspend with locks  Currently tpm transactions are executed unconditionally in tpm_pm_suspend() function, which may lead to races with other tpm accessors in the system.  Specifically, the hw_random tpm driver makes use of tpm_get_random(), and this function is called in a loop from a kthread, which means it's not frozen alongside userspace, and so can race with the work done during system suspend:    tpm tpm0: tpm_transmit: tpm_recv: error -52   tpm tpm0: invalid TPM_STS.x 0xff, dumping stack for forensics   CPU: 0 PID: 1 Comm: init Not tainted 6.1.0-rc5+ #135   Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.0-20220807_005459-localhost 04/01/2014   Call Trace:    tpm_tis_status.cold+0x19/0x20    tpm_transmit+0x13b/0x390    tpm_transmit_cmd+0x20/0x80    tpm1_pm_suspend+0xa6/0x110    tpm_pm_suspend+0x53/0x80    __pnp_bus_suspend+0x35/0xe0    __device_suspend+0x10f/0x350  Fix this by calling tpm_try_get_ops(), which itself is a wrapper around tpm_chip_start(), but takes the appropriate mutex.  [Jason: reworked commit message, added metadata]
CVE-2022-49000: In the Linux kernel, the following vulnerability has been resolved:  iommu/vt-d: Fix PCI device refcount leak in has_external_pci()  for_each_pci_dev() is implemented by pci_get_device(). The comment of pci_get_device() says that it will increase the reference count for the returned pci_dev and also decrease the reference count for the input pci_dev @from if it is not NULL.  If we break for_each_pci_dev() loop with pdev not NULL, we need to call pci_dev_put() to decrease the reference count. Add the missing pci_dev_put() before 'return true' to avoid reference count leak.
CVE-2022-49002: In the Linux kernel, the following vulnerability has been resolved:  iommu/vt-d: Fix PCI device refcount leak in dmar_dev_scope_init()  for_each_pci_dev() is implemented by pci_get_device(). The comment of pci_get_device() says that it will increase the reference count for the returned pci_dev and also decrease the reference count for the input pci_dev @from if it is not NULL.  If we break for_each_pci_dev() loop with pdev not NULL, we need to call pci_dev_put() to decrease the reference count. Add the missing pci_dev_put() for the error path to avoid reference count leak.
CVE-2022-49027: In the Linux kernel, the following vulnerability has been resolved:  iavf: Fix error handling in iavf_init_module()  The iavf_init_module() won't destroy workqueue when pci_register_driver() failed. Call destroy_workqueue() when pci_register_driver() failed to prevent the resource leak.  Similar to the handling of u132_hcd_init in commit f276e002793c ("usb: u132-hcd: fix resource leak")
CVE-2024-50020: In the Linux kernel, the following vulnerability has been resolved:  ice: Fix improper handling of refcount in ice_sriov_set_msix_vec_count()  This patch addresses an issue with improper reference count handling in the ice_sriov_set_msix_vec_count() function.  First, the function calls ice_get_vf_by_id(), which increments the reference count of the vf pointer. If the subsequent call to ice_get_vf_vsi() fails, the function currently returns an error without decrementing the reference count of the vf pointer, leading to a reference count leak. The correct behavior, as implemented in this patch, is to decrement the reference count using ice_put_vf(vf) before returning an error when vsi is NULL.  Second, the function calls ice_sriov_get_irqs(), which sets vf->first_vector_idx. If this call returns a negative value, indicating an error, the function returns an error without decrementing the reference count of the vf pointer, resulting in another reference count leak. The patch addresses this by adding a call to ice_put_vf(vf) before returning an error when vf->first_vector_idx < 0.  This bug was identified by an experimental static analysis tool developed by our team. The tool specializes in analyzing reference count operations and identifying potential mismanagement of reference counts. In this case, the tool flagged the missing decrement operation as a potential issue, leading to this patch.
CVE-2024-50021: In the Linux kernel, the following vulnerability has been resolved:  ice: Fix improper handling of refcount in ice_dpll_init_rclk_pins()  This patch addresses a reference count handling issue in the ice_dpll_init_rclk_pins() function. The function calls ice_dpll_get_pins(), which increments the reference count of the relevant resources. However, if the condition WARN_ON((!vsi || !vsi->netdev)) is met, the function currently returns an error without properly releasing the resources acquired by ice_dpll_get_pins(), leading to a reference count leak.  To resolve this, the check has been moved to the top of the function. This ensures that the function verifies the state before any resources are acquired, avoiding the need for additional resource management in the error path.  This bug was identified by an experimental static analysis tool developed by our team. The tool specializes in analyzing reference count operations and detecting potential issues where resources are not properly managed. In this case, the tool flagged the missing release operation as a potential problem, which led to the development of this patch.
CVE-2024-50023: In the Linux kernel, the following vulnerability has been resolved:  net: phy: Remove LED entry from LEDs list on unregister  Commit c938ab4da0eb ("net: phy: Manual remove LEDs to ensure correct ordering") correctly fixed a problem with using devm_ but missed removing the LED entry from the LEDs list.  This cause kernel panic on specific scenario where the port for the PHY is torn down and up and the kmod for the PHY is removed.  On setting the port down the first time, the assosiacted LEDs are correctly unregistered. The associated kmod for the PHY is now removed. The kmod is now added again and the port is now put up, the associated LED are registered again. On putting the port down again for the second time after these step, the LED list now have 4 elements. With the first 2 already unregistered previously and the 2 new one registered again.  This cause a kernel panic as the first 2 element should have been removed.  Fix this by correctly removing the element when LED is unregistered.
CVE-2024-50028: In the Linux kernel, the following vulnerability has been resolved:  thermal: core: Reference count the zone in thermal_zone_get_by_id()  There are places in the thermal netlink code where nothing prevents the thermal zone object from going away while being accessed after it has been returned by thermal_zone_get_by_id().  To address this, make thermal_zone_get_by_id() get a reference on the thermal zone device object to be returned with the help of get_device(), under thermal_list_lock, and adjust all of its callers to this change with the help of the cleanup.h infrastructure.
CVE-2024-50036: In the Linux kernel, the following vulnerability has been resolved:  net: do not delay dst_entries_add() in dst_release()  dst_entries_add() uses per-cpu data that might be freed at netns dismantle from ip6_route_net_exit() calling dst_entries_destroy()  Before ip6_route_net_exit() can be called, we release all the dsts associated with this netns, via calls to dst_release(), which waits an rcu grace period before calling dst_destroy()  dst_entries_add() use in dst_destroy() is racy, because dst_entries_destroy() could have been called already.  Decrementing the number of dsts must happen sooner.  Notes:  1) in CONFIG_XFRM case, dst_destroy() can call    dst_release_immediate(child), this might also cause UAF    if the child does not have DST_NOCOUNT set.    IPSEC maintainers might take a look and see how to address this.  2) There is also discussion about removing this count of dst,    which might happen in future kernels.
CVE-2024-50063: In the Linux kernel, the following vulnerability has been resolved:  bpf: Prevent tail call between progs attached to different hooks  bpf progs can be attached to kernel functions, and the attached functions can take different parameters or return different return values. If prog attached to one kernel function tail calls prog attached to another kernel function, the ctx access or return value verification could be bypassed.  For example, if prog1 is attached to func1 which takes only 1 parameter and prog2 is attached to func2 which takes two parameters. Since verifier assumes the bpf ctx passed to prog2 is constructed based on func2's prototype, verifier allows prog2 to access the second parameter from the bpf ctx passed to it. The problem is that verifier does not prevent prog1 from passing its bpf ctx to prog2 via tail call. In this case, the bpf ctx passed to prog2 is constructed from func1 instead of func2, that is, the assumption for ctx access verification is bypassed.  Another example, if BPF LSM prog1 is attached to hook file_alloc_security, and BPF LSM prog2 is attached to hook bpf_lsm_audit_rule_known. Verifier knows the return value rules for these two hooks, e.g. it is legal for bpf_lsm_audit_rule_known to return positive number 1, and it is illegal for file_alloc_security to return positive number. So verifier allows prog2 to return positive number 1, but does not allow prog1 to return positive number. The problem is that verifier does not prevent prog1 from calling prog2 via tail call. In this case, prog2's return value 1 will be used as the return value for prog1's hook file_alloc_security. That is, the return value rule is bypassed.  This patch adds restriction for tail call to prevent such bypasses.
CVE-2024-50050: Llama Stack prior to revision 7a8aa775e5a267cf8660d83140011a0b7f91e005 used pickle as a serialization format for socket communication, potentially allowing for remote code execution. Socket communication has been changed to use JSON instead.
CVE-2024-40431: A lack of input validation in Realtek SD card reader driver before 10.0.26100.21374 through the implementation of the IOCTL_SCSI_PASS_THROUGH control of the SD card reader driver allows an attacker to write to predictable kernel memory locations, even as a low-privileged user.
CVE-2024-40432: A lack of input validation in Realtek SD card reader driver before 10.0.26100.21374 through the implementation of the IOCTL_SFFDISK_DEVICE_COMMAND control of the SD card reader driver allows a privileged attacker to crash the OS.
CVE-2024-48225: Funadmin v5.0.2 has an arbitrary file deletion vulnerability in /curd/index/delfile.
CVE-2024-50616: Ironman PowerShell Universal 5.x before 5.0.12 allows an authenticated attacker to elevate their privileges and view job information.
CVE-2024-44155: A custom URL scheme handling issue was addressed with improved input validation. This issue is fixed in Safari 18, iOS 17.7.1 and iPadOS 17.7.1, macOS Sequoia 15, watchOS 11, iOS 18 and iPadOS 18. Maliciously crafted web content may violate iframe sandboxing policy.
CVE-2024-44194: This issue was addressed with improved redaction of sensitive information. This issue is fixed in watchOS 11.1, visionOS 2.1, iOS 18.1 and iPadOS 18.1. An app may be able to access sensitive user data.
CVE-2024-44215: This issue was addressed with improved checks. This issue is fixed in tvOS 18.1, iOS 18.1 and iPadOS 18.1, iOS 17.7.1 and iPadOS 17.7.1, macOS Ventura 13.7.1, macOS Sonoma 14.7.1, watchOS 11.1, visionOS 2.1. Processing an image may result in disclosure of process memory.
CVE-2024-44229: An information leakage was addressed with additional validation. This issue is fixed in visionOS 2.1, iOS 18.1 and iPadOS 18.1, macOS Sequoia 15.1, Safari 18.1. Private browsing may leak some browsing history.
CVE-2024-44254: This issue was addressed with improved redaction of sensitive information. This issue is fixed in watchOS 11.1, macOS Ventura 13.7.1, macOS Sonoma 14.7.1, iOS 18.1 and iPadOS 18.1. An app may be able to access sensitive user data.
CVE-2024-44274: The issue was addressed with improved authentication. This issue is fixed in iOS 17.7.1 and iPadOS 17.7.1, watchOS 11.1, iOS 18.1 and iPadOS 18.1. An attacker with physical access to a locked device may be able to view sensitive user information.
CVE-2024-44278: An information disclosure issue was addressed with improved private data redaction for log entries. This issue is fixed in iOS 18.1 and iPadOS 18.1, iOS 17.7.1 and iPadOS 17.7.1, macOS Ventura 13.7.1, macOS Sonoma 14.7.1, watchOS 11.1, visionOS 2.1. A sandboxed app may be able to access sensitive user data in system logs.
CVE-2024-44302: The issue was addressed with improved checks. This issue is fixed in tvOS 18.1, iOS 18.1 and iPadOS 18.1, iOS 17.7.1 and iPadOS 17.7.1, macOS Ventura 13.7.1, macOS Sonoma 14.7.1, watchOS 11.1, visionOS 2.1. Processing a maliciously crafted font may result in the disclosure of process memory.
CVE-2024-44240: The issue was addressed with improved checks. This issue is fixed in tvOS 18.1, iOS 18.1 and iPadOS 18.1, iOS 17.7.1 and iPadOS 17.7.1, macOS Ventura 13.7.1, macOS Sonoma 14.7.1, watchOS 11.1, visionOS 2.1. Processing a maliciously crafted font may result in the disclosure of process memory.
CVE-2024-50075: In the Linux kernel, the following vulnerability has been resolved:  xhci: tegra: fix checked USB2 port number  If USB virtualizatoin is enabled, USB2 ports are shared between all Virtual Functions. The USB2 port number owned by an USB2 root hub in a Virtual Function may be less than total USB2 phy number supported by the Tegra XUSB controller.  Using total USB2 phy number as port number to check all PORTSC values would cause invalid memory access.  [  116.923438] Unable to handle kernel paging request at virtual address 006c622f7665642f ... [  117.213640] Call trace: [  117.216783]  tegra_xusb_enter_elpg+0x23c/0x658 [  117.222021]  tegra_xusb_runtime_suspend+0x40/0x68 [  117.227260]  pm_generic_runtime_suspend+0x30/0x50 [  117.232847]  __rpm_callback+0x84/0x3c0 [  117.237038]  rpm_suspend+0x2dc/0x740 [  117.241229] pm_runtime_work+0xa0/0xb8 [  117.245769]  process_scheduled_works+0x24c/0x478 [  117.251007]  worker_thread+0x23c/0x328 [  117.255547]  kthread+0x104/0x1b0 [  117.259389]  ret_from_fork+0x10/0x20 [  117.263582] Code: 54000222 f9461ae8 f8747908 b4ffff48 (f9400100)
CVE-2024-50077: In the Linux kernel, the following vulnerability has been resolved:  Bluetooth: ISO: Fix multiple init when debugfs is disabled  If bt_debugfs is not created successfully, which happens if either CONFIG_DEBUG_FS or CONFIG_DEBUG_FS_ALLOW_ALL is unset, then iso_init() returns early and does not set iso_inited to true. This means that a subsequent call to iso_init() will result in duplicate calls to proto_register(), bt_sock_register(), etc.  With CONFIG_LIST_HARDENED and CONFIG_BUG_ON_DATA_CORRUPTION enabled, the duplicate call to proto_register() triggers this BUG():    list_add double add: new=ffffffffc0b280d0, prev=ffffffffbab56250,     next=ffffffffc0b280d0.   ------------[ cut here ]------------   kernel BUG at lib/list_debug.c:35!   Oops: invalid opcode: 0000 [#1] PREEMPT SMP PTI   CPU: 2 PID: 887 Comm: bluetoothd Not tainted 6.10.11-1-ao-desktop #1   RIP: 0010:__list_add_valid_or_report+0x9a/0xa0   ...     __list_add_valid_or_report+0x9a/0xa0     proto_register+0x2b5/0x340     iso_init+0x23/0x150 [bluetooth]     set_iso_socket_func+0x68/0x1b0 [bluetooth]     kmem_cache_free+0x308/0x330     hci_sock_sendmsg+0x990/0x9e0 [bluetooth]     __sock_sendmsg+0x7b/0x80     sock_write_iter+0x9a/0x110     do_iter_readv_writev+0x11d/0x220     vfs_writev+0x180/0x3e0     do_writev+0xca/0x100   ...  This change removes the early return. The check for iso_debugfs being NULL was unnecessary, it is always NULL when iso_inited is false.
CVE-2024-50078: In the Linux kernel, the following vulnerability has been resolved:  Bluetooth: Call iso_exit() on module unload  If iso_init() has been called, iso_exit() must be called on module unload. Without that, the struct proto that iso_init() registered with proto_register() becomes invalid, which could cause unpredictable problems later. In my case, with CONFIG_LIST_HARDENED and CONFIG_BUG_ON_DATA_CORRUPTION enabled, loading the module again usually triggers this BUG():    list_add corruption. next->prev should be prev (ffffffffb5355fd0),     but was 0000000000000068. (next=ffffffffc0a010d0).   ------------[ cut here ]------------   kernel BUG at lib/list_debug.c:29!   Oops: invalid opcode: 0000 [#1] PREEMPT SMP PTI   CPU: 1 PID: 4159 Comm: modprobe Not tainted 6.10.11-4+bt2-ao-desktop #1   RIP: 0010:__list_add_valid_or_report+0x61/0xa0   ...     __list_add_valid_or_report+0x61/0xa0     proto_register+0x299/0x320     hci_sock_init+0x16/0xc0 [bluetooth]     bt_init+0x68/0xd0 [bluetooth]     __pfx_bt_init+0x10/0x10 [bluetooth]     do_one_initcall+0x80/0x2f0     do_init_module+0x8b/0x230     __do_sys_init_module+0x15f/0x190     do_syscall_64+0x68/0x110   ...
CVE-2024-50081: In the Linux kernel, the following vulnerability has been resolved:  blk-mq: setup queue ->tag_set before initializing hctx  Commit 7b815817aa58 ("blk-mq: add helper for checking if one CPU is mapped to specified hctx") needs to check queue mapping via tag set in hctx's cpuhp handler.  However, q->tag_set may not be setup yet when the cpuhp handler is enabled, then kernel oops is triggered.  Fix the issue by setup queue tag_set before initializing hctx.
CVE-2024-37573: The Talkatone com.talkatone.android application 8.4.6 for Android enables any installed application (with no permissions) to place phone calls without user interaction by sending a crafted intent via the com.talkatone.vedroid.ui.launcher.OutgoingCallInterceptor component.
CVE-2023-52066: http.zig commit 76cf5 was discovered to contain a CRLF injection vulnerability via the url parameter.
CVE-2024-42835: langflow v1.0.12 was discovered to contain a remote code execution (RCE) vulnerability via the PythonCodeTool component.
CVE-2024-30619: Chamilo LMS Version 1.11.26 is vulnerable to Incorrect Access Control. A non-authenticated attacker can request the number of messages and the number of online users via "/main/inc/ajax/message.ajax.php?a=get_count_message" AND "/main/inc/ajax/online.ajax.php?a=get_users_online."
CVE-2024-50091: In the Linux kernel, the following vulnerability has been resolved:  dm vdo: don't refer to dedupe_context after releasing it  Clear the dedupe_context pointer in a data_vio whenever ownership of the context is lost, so that vdo can't examine it accidentally.
CVE-2024-50093: In the Linux kernel, the following vulnerability has been resolved:  thermal: intel: int340x: processor: Fix warning during module unload  The processor_thermal driver uses pcim_device_enable() to enable a PCI device, which means the device will be automatically disabled on driver detach.  Thus there is no need to call pci_disable_device() again on it.  With recent PCI device resource management improvements, e.g. commit f748a07a0b64 ("PCI: Remove legacy pcim_release()"), this problem is exposed and triggers the warining below.   [  224.010735] proc_thermal_pci 0000:00:04.0: disabling already-disabled device  [  224.010747] WARNING: CPU: 8 PID: 4442 at drivers/pci/pci.c:2250 pci_disable_device+0xe5/0x100  ...  [  224.010844] Call Trace:  [  224.010845]  <TASK>  [  224.010847]  ? show_regs+0x6d/0x80  [  224.010851]  ? __warn+0x8c/0x140  [  224.010854]  ? pci_disable_device+0xe5/0x100  [  224.010856]  ? report_bug+0x1c9/0x1e0  [  224.010859]  ? handle_bug+0x46/0x80  [  224.010862]  ? exc_invalid_op+0x1d/0x80  [  224.010863]  ? asm_exc_invalid_op+0x1f/0x30  [  224.010867]  ? pci_disable_device+0xe5/0x100  [  224.010869]  ? pci_disable_device+0xe5/0x100  [  224.010871]  ? kfree+0x21a/0x2b0  [  224.010873]  pcim_disable_device+0x20/0x30  [  224.010875]  devm_action_release+0x16/0x20  [  224.010878]  release_nodes+0x47/0xc0  [  224.010880]  devres_release_all+0x9f/0xe0  [  224.010883]  device_unbind_cleanup+0x12/0x80  [  224.010885]  device_release_driver_internal+0x1ca/0x210  [  224.010887]  driver_detach+0x4e/0xa0  [  224.010889]  bus_remove_driver+0x6f/0xf0  [  224.010890]  driver_unregister+0x35/0x60  [  224.010892]  pci_unregister_driver+0x44/0x90  [  224.010894]  proc_thermal_pci_driver_exit+0x14/0x5f0 [processor_thermal_device_pci]  ...  [  224.010921] ---[ end trace 0000000000000000 ]---  Remove the excess pci_disable_device() calls.  [ rjw: Subject and changelog edits ]