xamxte/cve-to-cwe huggingface dataset:
CVE-2025-40308: In the Linux kernel, the following vulnerability has been resolved:  Bluetooth: bcsp: receive data only if registered  Currently, bcsp_recv() can be called even when the BCSP protocol has not been registered. This leads to a NULL pointer dereference, as shown in the following stack trace:      KASAN: null-ptr-deref in range [0x0000000000000108-0x000000000000010f]     RIP: 0010:bcsp_recv+0x13d/0x1740 drivers/bluetooth/hci_bcsp.c:590     Call Trace:      <TASK>      hci_uart_tty_receive+0x194/0x220 drivers/bluetooth/hci_ldisc.c:627      tiocsti+0x23c/0x2c0 drivers/tty/tty_io.c:2290      tty_ioctl+0x626/0xde0 drivers/tty/tty_io.c:2706      vfs_ioctl fs/ioctl.c:51 [inline]      __do_sys_ioctl fs/ioctl.c:907 [inline]      __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:893      do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]      do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94      entry_SYSCALL_64_after_hwframe+0x77/0x7f  To prevent this, ensure that the HCI_UART_REGISTERED flag is set before processing received data. If the protocol is not registered, return -EUNATCH.
CVE-2025-40310: In the Linux kernel, the following vulnerability has been resolved:  amd/amdkfd: resolve a race in amdgpu_amdkfd_device_fini_sw  There is race in amdgpu_amdkfd_device_fini_sw and interrupt. if amdgpu_amdkfd_device_fini_sw run in b/w kfd_cleanup_nodes and   kfree(kfd), and KGD interrupt generated.  kernel panic log:  BUG: kernel NULL pointer dereference, address: 0000000000000098 amdgpu 0000:c8:00.0: amdgpu: Requesting 4 partitions through PSP  PGD d78c68067 P4D d78c68067  kfd kfd: amdgpu: Allocated 3969056 bytes on gart  PUD 1465b8067 PMD @  Oops: @002 [#1] SMP NOPTI  kfd kfd: amdgpu: Total number of KFD nodes to be created: 4 CPU: 115 PID: @ Comm: swapper/115 Kdump: loaded Tainted: G S W OE K  RIP: 0010:_raw_spin_lock_irqsave+0x12/0x40  Code: 89 e@ 41 5c c3 cc cc cc cc 66 66 2e Of 1f 84 00 00 00 00 00 OF 1f 40 00 Of 1f 44% 00 00 41 54 9c 41 5c fa 31 cO ba 01 00 00 00 <fO> OF b1 17 75 Ba 4c 89 e@ 41 Sc  89 c6 e8 07 38 5d  RSP: 0018: ffffc90@1a6b0e28 EFLAGS: 00010046  RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000018 0000000000000001 RSI: ffff8883bb623e00 RDI: 0000000000000098 ffff8883bb000000 RO8: ffff888100055020 ROO: ffff888100055020 0000000000000000 R11: 0000000000000000 R12: 0900000000000002 ffff888F2b97da0@ R14: @000000000000098 R15: ffff8883babdfo00  CS: 010 DS: 0000 ES: 0000 CRO: 0000000080050033  CR2: 0000000000000098 CR3: 0000000e7cae2006 CR4: 0000000002770ce0 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 0000000000000000 DR6: 00000000fffeO7FO DR7: 0000000000000400  PKRU: 55555554  Call Trace:  <IRQ>  kgd2kfd_interrupt+@x6b/0x1f@ [amdgpu]  ? amdgpu_fence_process+0xa4/0x150 [amdgpu]  kfd kfd: amdgpu: Node: 0, interrupt_bitmap: 3 YcpxFl Rant tErace  amdgpu_irq_dispatch+0x165/0x210 [amdgpu]  amdgpu_ih_process+0x80/0x100 [amdgpu]  amdgpu: Virtual CRAT table created for GPU  amdgpu_irq_handler+0x1f/@x60 [amdgpu]  __handle_irq_event_percpu+0x3d/0x170  amdgpu: Topology: Add dGPU node [0x74a2:0x1002]  handle_irq_event+0x5a/@xcO  handle_edge_irq+0x93/0x240  kfd kfd: amdgpu: KFD node 1 partition @ size 49148M  asm_call_irq_on_stack+0xf/@x20  </IRQ>  common_interrupt+0xb3/0x130  asm_common_interrupt+0x1le/0x40  5.10.134-010.a1i5000.a18.x86_64 #1
CVE-2025-40312: In the Linux kernel, the following vulnerability has been resolved:  jfs: Verify inode mode when loading from disk  The inode mode loaded from corrupted disk can be invalid. Do like what commit 0a9e74051313 ("isofs: Verify inode mode when loading from disk") does.
CVE-2025-40314: In the Linux kernel, the following vulnerability has been resolved:  usb: cdns3: gadget: Use-after-free during failed initialization and exit of cdnsp gadget  In the __cdnsp_gadget_init() and cdnsp_gadget_exit() functions, the gadget structure (pdev->gadget) was freed before its endpoints. The endpoints are linked via the ep_list in the gadget structure. Freeing the gadget first leaves dangling pointers in the endpoint list. When the endpoints are subsequently freed, this results in a use-after-free.  Fix: By separating the usb_del_gadget_udc() operation into distinct "del" and "put" steps, cdnsp_gadget_free_endpoints() can be executed prior to the final release of the gadget structure with usb_put_gadget().  A patch similar to bb9c74a5bd14("usb: dwc3: gadget: Free gadget structure  only after freeing endpoints").
CVE-2025-40315: In the Linux kernel, the following vulnerability has been resolved:  usb: gadget: f_fs: Fix epfile null pointer access after ep enable.  A race condition occurs when ffs_func_eps_enable() runs concurrently with ffs_data_reset(). The ffs_data_clear() called in ffs_data_reset() sets ffs->epfiles to NULL before resetting ffs->eps_count to 0, leading to a NULL pointer dereference when accessing epfile->ep in ffs_func_eps_enable() after successful usb_ep_enable().  The ffs->epfiles pointer is set to NULL in both ffs_data_clear() and ffs_data_close() functions, and its modification is protected by the spinlock ffs->eps_lock. And the whole ffs_func_eps_enable() function is also protected by ffs->eps_lock.  Thus, add NULL pointer handling for ffs->epfiles in the ffs_func_eps_enable() function to fix issues
CVE-2025-40316: In the Linux kernel, the following vulnerability has been resolved:  drm/mediatek: Fix device use-after-free on unbind  A recent change fixed device reference leaks when looking up drm platform device driver data during bind() but failed to remove a partial fix which had been added by commit 80805b62ea5b ("drm/mediatek: Fix kobject put for component sub-drivers").  This results in a reference imbalance on component bind() failures and on unbind() which could lead to a user-after-free.  Make sure to only drop the references after retrieving the driver data by effectively reverting the previous partial fix.  Note that holding a reference to a device does not prevent its driver data from going away so there is no point in keeping the reference.
CVE-2025-40318: In the Linux kernel, the following vulnerability has been resolved:  Bluetooth: hci_sync: fix race in hci_cmd_sync_dequeue_once  hci_cmd_sync_dequeue_once() does lookup and then cancel the entry under two separate lock sections. Meanwhile, hci_cmd_sync_work() can also delete the same entry, leading to double list_del() and "UAF".  Fix this by holding cmd_sync_work_lock across both lookup and cancel, so that the entry cannot be removed concurrently.
CVE-2025-40319: In the Linux kernel, the following vulnerability has been resolved:  bpf: Sync pending IRQ work before freeing ring buffer  Fix a race where irq_work can be queued in bpf_ringbuf_commit() but the ring buffer is freed before the work executes. In the syzbot reproducer, a BPF program attached to sched_switch triggers bpf_ringbuf_commit(), queuing an irq_work. If the ring buffer is freed before this work executes, the irq_work thread may accesses freed memory. Calling `irq_work_sync(&rb->work)` ensures that all pending irq_work complete before freeing the buffer.
CVE-2025-40320: In the Linux kernel, the following vulnerability has been resolved:  smb: client: fix potential cfid UAF in smb2_query_info_compound  When smb2_query_info_compound() retries, a previously allocated cfid may have been freed in the first attempt. Because cfid wasn't reset on replay, later cleanup could act on a stale pointer, leading to a potential use-after-free.  Reinitialize cfid to NULL under the replay label.  Example trace (trimmed):  refcount_t: underflow; use-after-free. WARNING: CPU: 1 PID: 11224 at ../lib/refcount.c:28 refcount_warn_saturate+0x9c/0x110 [...] RIP: 0010:refcount_warn_saturate+0x9c/0x110 [...] Call Trace:  <TASK>  smb2_query_info_compound+0x29c/0x5c0 [cifs f90b72658819bd21c94769b6a652029a07a7172f]  ? step_into+0x10d/0x690  ? __legitimize_path+0x28/0x60  smb2_queryfs+0x6a/0xf0 [cifs f90b72658819bd21c94769b6a652029a07a7172f]  smb311_queryfs+0x12d/0x140 [cifs f90b72658819bd21c94769b6a652029a07a7172f]  ? kmem_cache_alloc+0x18a/0x340  ? getname_flags+0x46/0x1e0  cifs_statfs+0x9f/0x2b0 [cifs f90b72658819bd21c94769b6a652029a07a7172f]  statfs_by_dentry+0x67/0x90  vfs_statfs+0x16/0xd0  user_statfs+0x54/0xa0  __do_sys_statfs+0x20/0x50  do_syscall_64+0x58/0x80
CVE-2025-40321: In the Linux kernel, the following vulnerability has been resolved:  wifi: brcmfmac: fix crash while sending Action Frames in standalone AP Mode  Currently, whenever there is a need to transmit an Action frame, the brcmfmac driver always uses the P2P vif to send the "actframe" IOVAR to firmware. The P2P interfaces were available when wpa_supplicant is managing the wlan interface.  However, the P2P interfaces are not created/initialized when only hostapd is managing the wlan interface. And if hostapd receives an ANQP Query REQ Action frame even from an un-associated STA, the brcmfmac driver tries to use an uninitialized P2P vif pointer for sending the IOVAR to firmware. This NULL pointer dereferencing triggers a driver crash.   [ 1417.074538] Unable to handle kernel NULL pointer dereference at virtual  address 0000000000000000  [...]  [ 1417.075188] Hardware name: Raspberry Pi 4 Model B Rev 1.5 (DT)  [...]  [ 1417.075653] Call trace:  [ 1417.075662]  brcmf_p2p_send_action_frame+0x23c/0xc58 [brcmfmac]  [ 1417.075738]  brcmf_cfg80211_mgmt_tx+0x304/0x5c0 [brcmfmac]  [ 1417.075810]  cfg80211_mlme_mgmt_tx+0x1b0/0x428 [cfg80211]  [ 1417.076067]  nl80211_tx_mgmt+0x238/0x388 [cfg80211]  [ 1417.076281]  genl_family_rcv_msg_doit+0xe0/0x158  [ 1417.076302]  genl_rcv_msg+0x220/0x2a0  [ 1417.076317]  netlink_rcv_skb+0x68/0x140  [ 1417.076330]  genl_rcv+0x40/0x60  [ 1417.076343]  netlink_unicast+0x330/0x3b8  [ 1417.076357]  netlink_sendmsg+0x19c/0x3f8  [ 1417.076370]  __sock_sendmsg+0x64/0xc0  [ 1417.076391]  ____sys_sendmsg+0x268/0x2a0  [ 1417.076408]  ___sys_sendmsg+0xb8/0x118  [ 1417.076427]  __sys_sendmsg+0x90/0xf8  [ 1417.076445]  __arm64_sys_sendmsg+0x2c/0x40  [ 1417.076465]  invoke_syscall+0x50/0x120  [ 1417.076486]  el0_svc_common.constprop.0+0x48/0xf0  [ 1417.076506]  do_el0_svc+0x24/0x38  [ 1417.076525]  el0_svc+0x30/0x100  [ 1417.076548]  el0t_64_sync_handler+0x100/0x130  [ 1417.076569]  el0t_64_sync+0x190/0x198  [ 1417.076589] Code: f9401e80 aa1603e2 f9403be1 5280e483 (f9400000)  Fix this, by always using the vif corresponding to the wdev on which the Action frame Transmission request was initiated by the userspace. This way, even if P2P vif is not available, the IOVAR is sent to firmware on AP vif and the ANQP Query RESP Action frame is transmitted without crashing the driver.  Move init_completion() for "send_af_done" from brcmf_p2p_create_p2pdev() to brcmf_p2p_attach(). Because the former function would not get executed when only hostapd is managing wlan interface, and it is not safe to do reinit_completion() later in brcmf_p2p_tx_action_frame(), without any prior init_completion().  And in the brcmf_p2p_tx_action_frame() function, the condition check for P2P Presence response frame is not needed, since the wpa_supplicant is properly sending the P2P Presense Response frame on the P2P-GO vif instead of the P2P-Device vif.  [Cc stable]
CVE-2025-40322: In the Linux kernel, the following vulnerability has been resolved:  fbdev: bitblit: bound-check glyph index in bit_putcs*  bit_putcs_aligned()/unaligned() derived the glyph pointer from the character value masked by 0xff/0x1ff, which may exceed the actual font's glyph count and read past the end of the built-in font array. Clamp the index to the actual glyph count before computing the address.  This fixes a global out-of-bounds read reported by syzbot.
CVE-2025-40323: In the Linux kernel, the following vulnerability has been resolved:  fbcon: Set fb_display[i]->mode to NULL when the mode is released  Recently, we discovered the following issue through syzkaller:  BUG: KASAN: slab-use-after-free in fb_mode_is_equal+0x285/0x2f0 Read of size 4 at addr ff11000001b3c69c by task syz.xxx ... Call Trace:  <TASK>  dump_stack_lvl+0xab/0xe0  print_address_description.constprop.0+0x2c/0x390  print_report+0xb9/0x280  kasan_report+0xb8/0xf0  fb_mode_is_equal+0x285/0x2f0  fbcon_mode_deleted+0x129/0x180  fb_set_var+0xe7f/0x11d0  do_fb_ioctl+0x6a0/0x750  fb_ioctl+0xe0/0x140  __x64_sys_ioctl+0x193/0x210  do_syscall_64+0x5f/0x9c0  entry_SYSCALL_64_after_hwframe+0x76/0x7e  Based on experimentation and analysis, during framebuffer unregistration, only the memory of fb_info->modelist is freed, without setting the corresponding fb_display[i]->mode to NULL for the freed modes. This leads to UAF issues during subsequent accesses. Here's an example of reproduction steps: 1. With /dev/fb0 already registered in the system, load a kernel module    to register a new device /dev/fb1; 2. Set fb1's mode to the global fb_display[] array (via FBIOPUT_CON2FBMAP); 3. Switch console from fb to VGA (to allow normal rmmod of the ko); 4. Unload the kernel module, at this point fb1's modelist is freed, leaving    a wild pointer in fb_display[]; 5. Trigger the bug via system calls through fb0 attempting to delete a mode    from fb0.  Add a check in do_unregister_framebuffer(): if the mode to be freed exists in fb_display[], set the corresponding mode pointer to NULL.
CVE-2022-50614: In the Linux kernel, the following vulnerability has been resolved:  misc: pci_endpoint_test: Fix pci_endpoint_test_{copy,write,read}() panic  The dma_map_single() doesn't permit zero length mapping. It causes a follow panic.  A panic was reported on arm64:  [   60.137988] ------------[ cut here ]------------ [   60.142630] kernel BUG at kernel/dma/swiotlb.c:624! [   60.147508] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP [   60.152992] Modules linked in: dw_hdmi_cec crct10dif_ce simple_bridge rcar_fdp1 vsp1 rcar_vin videobuf2_vmalloc rcar_csi2 v4l 2_mem2mem videobuf2_dma_contig videobuf2_memops pci_endpoint_test videobuf2_v4l2 videobuf2_common rcar_fcp v4l2_fwnode v4l2_asyn c videodev mc gpio_bd9571mwv max9611 pwm_rcar ccree at24 authenc libdes phy_rcar_gen3_usb3 usb_dmac display_connector pwm_bl [   60.186252] CPU: 0 PID: 508 Comm: pcitest Not tainted 6.0.0-rc1rpci-dev+ #237 [   60.193387] Hardware name: Renesas Salvator-X 2nd version board based on r8a77951 (DT) [   60.201302] pstate: 00000005 (nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [   60.208263] pc : swiotlb_tbl_map_single+0x2c0/0x590 [   60.213149] lr : swiotlb_map+0x88/0x1f0 [   60.216982] sp : ffff80000a883bc0 [   60.220292] x29: ffff80000a883bc0 x28: 0000000000000000 x27: 0000000000000000 [   60.227430] x26: 0000000000000000 x25: ffff0004c0da20d0 x24: ffff80000a1f77c0 [   60.234567] x23: 0000000000000002 x22: 0001000040000010 x21: 000000007a000000 [   60.241703] x20: 0000000000200000 x19: 0000000000000000 x18: 0000000000000000 [   60.248840] x17: 0000000000000000 x16: 0000000000000000 x15: ffff0006ff7b9180 [   60.255977] x14: ffff0006ff7b9180 x13: 0000000000000000 x12: 0000000000000000 [   60.263113] x11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000000 [   60.270249] x8 : 0001000000000010 x7 : ffff0004c6754b20 x6 : 0000000000000000 [   60.277385] x5 : ffff0004c0da2090 x4 : 0000000000000000 x3 : 0000000000000001 [   60.284521] x2 : 0000000040000000 x1 : 0000000000000000 x0 : 0000000040000010 [   60.291658] Call trace: [   60.294100]  swiotlb_tbl_map_single+0x2c0/0x590 [   60.298629]  swiotlb_map+0x88/0x1f0 [   60.302115]  dma_map_page_attrs+0x188/0x230 [   60.306299]  pci_endpoint_test_ioctl+0x5e4/0xd90 [pci_endpoint_test] [   60.312660]  __arm64_sys_ioctl+0xa8/0xf0 [   60.316583]  invoke_syscall+0x44/0x108 [   60.320334]  el0_svc_common.constprop.0+0xcc/0xf0 [   60.325038]  do_el0_svc+0x2c/0xb8 [   60.328351]  el0_svc+0x2c/0x88 [   60.331406]  el0t_64_sync_handler+0xb8/0xc0 [   60.335587]  el0t_64_sync+0x18c/0x190 [   60.339251] Code: 52800013 d2e00414 35fff45c d503201f (d4210000) [   60.345344] ---[ end trace 0000000000000000 ]---  To fix it, this patch adds a checking the payload length if it is zero.
CVE-2022-50615: In the Linux kernel, the following vulnerability has been resolved:  perf/x86/intel/uncore: Fix reference count leak in snr_uncore_mmio_map()  pci_get_device() will increase the reference count for the returned pci_dev, so snr_uncore_get_mc_dev() will return a pci_dev with its reference count increased. We need to call pci_dev_put() to decrease the reference count. Let's add the missing pci_dev_put().
CVE-2022-50616: In the Linux kernel, the following vulnerability has been resolved:  regulator: core: Use different devices for resource allocation and DT lookup  Following by the below discussion, there's the potential UAF issue between regulator and mfd. https://lore.kernel.org/all/20221128143601.1698148-1-yangyingliang@huawei.com/  From the analysis of Yingliang  CPU A    |CPU B mt6370_probe()   |   devm_mfd_add_devices() |     |mt6370_regulator_probe()     |  regulator_register()     |    //allocate init_data and add it to devres     |    regulator_of_get_init_data() i2c_unregister_device()  |   device_del()   |     devres_release_all() |       // init_data is freed |       release_nodes()  |     |  // using init_data causes UAF     |  regulator_register()  It's common to use mfd core to create child device for the regulator. In order to do the DT lookup for init data, the child that registered the regulator would pass its parent as the parameter. And this causes init data resource allocated to its parent, not itself. The issue happen when parent device is going to release and regulator core is still doing some operation of init data constraint for the regulator of child device.  To fix it, this patch expand 'regulator_register' API to use the different devices for init data allocation and DT lookup.
CVE-2022-50617: In the Linux kernel, the following vulnerability has been resolved:  drm/amdgpu/powerplay/psm: Fix memory leak in power state init  Commit 902bc65de0b3 ("drm/amdgpu/powerplay/psm: return an error in power state init") made the power state init function return early in case of failure to get an entry from the powerplay table, but it missed to clean up the allocated memory for the current power state before returning.
CVE-2022-50618: In the Linux kernel, the following vulnerability has been resolved:  mmc: meson-gx: fix return value check of mmc_add_host()  mmc_add_host() may return error, if we ignore its return value, it will lead two issues: 1. The memory that allocated in mmc_alloc_host() is leaked. 2. In the remove() path, mmc_remove_host() will be called to    delete device, but it's not added yet, it will lead a kernel    crash because of null-ptr-deref in device_del().  Fix this by checking the return value and goto error path which will call mmc_free_host().
CVE-2022-50619: In the Linux kernel, the following vulnerability has been resolved:  drm/amdkfd: Fix memory leak in kfd_mem_dmamap_userptr()  If the number of pages from the userptr BO differs from the SG BO then the allocated memory for the SG table doesn't get freed before returning -EINVAL, which may lead to a memory leak in some error paths. Fix this by checking the number of pages before allocating memory for the SG table.
CVE-2022-50620: In the Linux kernel, the following vulnerability has been resolved:  f2fs: fix to invalidate dcc->f2fs_issue_discard in error path  Syzbot reports a NULL pointer dereference issue as below:   __refcount_add include/linux/refcount.h:193 [inline]  __refcount_inc include/linux/refcount.h:250 [inline]  refcount_inc include/linux/refcount.h:267 [inline]  get_task_struct include/linux/sched/task.h:110 [inline]  kthread_stop+0x34/0x1c0 kernel/kthread.c:703  f2fs_stop_discard_thread+0x3c/0x5c fs/f2fs/segment.c:1638  kill_f2fs_super+0x5c/0x194 fs/f2fs/super.c:4522  deactivate_locked_super+0x70/0xe8 fs/super.c:332  deactivate_super+0xd0/0xd4 fs/super.c:363  cleanup_mnt+0x1f8/0x234 fs/namespace.c:1186  __cleanup_mnt+0x20/0x30 fs/namespace.c:1193  task_work_run+0xc4/0x14c kernel/task_work.c:177  exit_task_work include/linux/task_work.h:38 [inline]  do_exit+0x26c/0xbe0 kernel/exit.c:795  do_group_exit+0x60/0xe8 kernel/exit.c:925  __do_sys_exit_group kernel/exit.c:936 [inline]  __se_sys_exit_group kernel/exit.c:934 [inline]  __wake_up_parent+0x0/0x40 kernel/exit.c:934  __invoke_syscall arch/arm64/kernel/syscall.c:38 [inline]  invoke_syscall arch/arm64/kernel/syscall.c:52 [inline]  el0_svc_common+0x138/0x220 arch/arm64/kernel/syscall.c:142  do_el0_svc+0x48/0x164 arch/arm64/kernel/syscall.c:206  el0_svc+0x58/0x150 arch/arm64/kernel/entry-common.c:636  el0t_64_sync_handler+0x84/0xf0 arch/arm64/kernel/entry-common.c:654  el0t_64_sync+0x18c/0x190 arch/arm64/kernel/entry.S:581  The root cause of this issue is in error path of f2fs_start_discard_thread(), it missed to invalidate dcc->f2fs_issue_discard, later kthread_stop() may access invalid pointer.
CVE-2022-50622: In the Linux kernel, the following vulnerability has been resolved:  ext4: fix potential memory leak in ext4_fc_record_modified_inode()  As krealloc may return NULL, in this case 'state->fc_modified_inodes' may not be freed by krealloc, but 'state->fc_modified_inodes' already set NULL. Then will lead to 'state->fc_modified_inodes' memory leak.
CVE-2022-50623: In the Linux kernel, the following vulnerability has been resolved:  fpga: prevent integer overflow in dfl_feature_ioctl_set_irq()  The "hdr.count * sizeof(s32)" multiplication can overflow on 32 bit systems leading to memory corruption.  Use array_size() to fix that.
CVE-2022-50624: In the Linux kernel, the following vulnerability has been resolved:  net: netsec: fix error handling in netsec_register_mdio()  If phy_device_register() fails, phy_device_free() need be called to put refcount, so memory of phy device and device name can be freed in callback function.  If get_phy_device() fails, mdiobus_unregister() need be called, or it will cause warning in mdiobus_free() and kobject is leaked.