xamxte/cve-to-cwe huggingface dataset:
CVE-2023-53347: In the Linux kernel, the following vulnerability has been resolved:  net/mlx5: Handle pairing of E-switch via uplink un/load APIs  In case user switch a device from switchdev mode to legacy mode, mlx5 first unpair the E-switch and afterwards unload the uplink vport. From the other hand, in case user remove or reload a device, mlx5 first unload the uplink vport and afterwards unpair the E-switch.  The latter is causing a bug[1], hence, handle pairing of E-switch as part of uplink un/load APIs.  [1] In case VF_LAG is used, every tc fdb flow is duplicated to the peer esw. However, the original esw keeps a pointer to this duplicated flow, not the peer esw. e.g.: if user create tc fdb flow over esw0, the flow is duplicated over esw1, in FW/HW, but in SW, esw0 keeps a pointer to the duplicated flow. During module unload while a peer tc fdb flow is still offloaded, in case the first device to be removed is the peer device (esw1 in the example above), the peer net-dev is destroyed, and so the mlx5e_priv is memset to 0. Afterwards, the peer device is trying to unpair himself from the original device (esw0 in the example above). Unpair API invoke the original device to clear peer flow from its eswitch (esw0), but the peer flow, which is stored over the original eswitch (esw0), is trying to use the peer mlx5e_priv, which is memset to 0 and result in bellow kernel-oops.  [  157.964081 ] BUG: unable to handle page fault for address: 000000000002ce60 [  157.964662 ] #PF: supervisor read access in kernel mode [  157.965123 ] #PF: error_code(0x0000) - not-present page [  157.965582 ] PGD 0 P4D 0 [  157.965866 ] Oops: 0000 [#1] SMP [  157.967670 ] RIP: 0010:mlx5e_tc_del_fdb_flow+0x48/0x460 [mlx5_core] [  157.976164 ] Call Trace: [  157.976437 ]  <TASK> [  157.976690 ]  __mlx5e_tc_del_fdb_peer_flow+0xe6/0x100 [mlx5_core] [  157.977230 ]  mlx5e_tc_clean_fdb_peer_flows+0x67/0x90 [mlx5_core] [  157.977767 ]  mlx5_esw_offloads_unpair+0x2d/0x1e0 [mlx5_core] [  157.984653 ]  mlx5_esw_offloads_devcom_event+0xbf/0x130 [mlx5_core] [  157.985212 ]  mlx5_devcom_send_event+0xa3/0xb0 [mlx5_core] [  157.985714 ]  esw_offloads_disable+0x5a/0x110 [mlx5_core] [  157.986209 ]  mlx5_eswitch_disable_locked+0x152/0x170 [mlx5_core] [  157.986757 ]  mlx5_eswitch_disable+0x51/0x80 [mlx5_core] [  157.987248 ]  mlx5_unload+0x2a/0xb0 [mlx5_core] [  157.987678 ]  mlx5_uninit_one+0x5f/0xd0 [mlx5_core] [  157.988127 ]  remove_one+0x64/0xe0 [mlx5_core] [  157.988549 ]  pci_device_remove+0x31/0xa0 [  157.988933 ]  device_release_driver_internal+0x18f/0x1f0 [  157.989402 ]  driver_detach+0x3f/0x80 [  157.989754 ]  bus_remove_driver+0x70/0xf0 [  157.990129 ]  pci_unregister_driver+0x34/0x90 [  157.990537 ]  mlx5_cleanup+0xc/0x1c [mlx5_core] [  157.990972 ]  __x64_sys_delete_module+0x15a/0x250 [  157.991398 ]  ? exit_to_user_mode_prepare+0xea/0x110 [  157.991840 ]  do_syscall_64+0x3d/0x90 [  157.992198 ]  entry_SYSCALL_64_after_hwframe+0x46/0xb0
CVE-2023-53362: In the Linux kernel, the following vulnerability has been resolved:  bus: fsl-mc: don't assume child devices are all fsl-mc devices  Changes in VFIO caused a pseudo-device to be created as child of fsl-mc devices causing a crash [1] when trying to bind a fsl-mc device to VFIO. Fix this by checking the device type when enumerating fsl-mc child devices.  [1] Modules linked in: Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP CPU: 6 PID: 1289 Comm: sh Not tainted 6.2.0-rc5-00047-g7c46948a6e9c #2 Hardware name: NXP Layerscape LX2160ARDB (DT) pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : mc_send_command+0x24/0x1f0 lr : dprc_get_obj_region+0xfc/0x1c0 sp : ffff80000a88b900 x29: ffff80000a88b900 x28: ffff48a9429e1400 x27: 00000000000002b2 x26: ffff48a9429e1718 x25: 0000000000000000 x24: 0000000000000000 x23: ffffd59331ba3918 x22: ffffd59331ba3000 x21: 0000000000000000 x20: ffff80000a88b9b8 x19: 0000000000000000 x18: 0000000000000001 x17: 7270642f636d2d6c x16: 73662e3030303030 x15: ffffffffffffffff x14: ffffd59330f1d668 x13: ffff48a8727dc389 x12: ffff48a8727dc386 x11: 0000000000000002 x10: 00008ceaf02f35d4 x9 : 0000000000000012 x8 : 0000000000000000 x7 : 0000000000000006 x6 : ffff80000a88bab0 x5 : 0000000000000000 x4 : 0000000000000000 x3 : ffff80000a88b9e8 x2 : ffff80000a88b9e8 x1 : 0000000000000000 x0 : ffff48a945142b80 Call trace:  mc_send_command+0x24/0x1f0  dprc_get_obj_region+0xfc/0x1c0  fsl_mc_device_add+0x340/0x590  fsl_mc_obj_device_add+0xd0/0xf8  dprc_scan_objects+0x1c4/0x340  dprc_scan_container+0x38/0x60  vfio_fsl_mc_probe+0x9c/0xf8  fsl_mc_driver_probe+0x24/0x70  really_probe+0xbc/0x2a8  __driver_probe_device+0x78/0xe0  device_driver_attach+0x30/0x68  bind_store+0xa8/0x130  drv_attr_store+0x24/0x38  sysfs_kf_write+0x44/0x60  kernfs_fop_write_iter+0x128/0x1b8  vfs_write+0x334/0x448  ksys_write+0x68/0xf0  __arm64_sys_write+0x1c/0x28  invoke_syscall+0x44/0x108  el0_svc_common.constprop.1+0x94/0xf8  do_el0_svc+0x38/0xb0  el0_svc+0x20/0x50  el0t_64_sync_handler+0x98/0xc0  el0t_64_sync+0x174/0x178 Code: aa0103f4 a9025bf5 d5384100 b9400801 (79401260) ---[ end trace 0000000000000000 ]---
CVE-2023-53365: In the Linux kernel, the following vulnerability has been resolved:  ip6mr: Fix skb_under_panic in ip6mr_cache_report()  skbuff: skb_under_panic: text:ffffffff88771f69 len:56 put:-4  head:ffff88805f86a800 data:ffff887f5f86a850 tail:0x88 end:0x2c0 dev:pim6reg  ------------[ cut here ]------------  kernel BUG at net/core/skbuff.c:192!  invalid opcode: 0000 [#1] PREEMPT SMP KASAN  CPU: 2 PID: 22968 Comm: kworker/2:11 Not tainted 6.5.0-rc3-00044-g0a8db05b571a #236  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014  Workqueue: ipv6_addrconf addrconf_dad_work  RIP: 0010:skb_panic+0x152/0x1d0  Call Trace:   <TASK>   skb_push+0xc4/0xe0   ip6mr_cache_report+0xd69/0x19b0   reg_vif_xmit+0x406/0x690   dev_hard_start_xmit+0x17e/0x6e0   __dev_queue_xmit+0x2d6a/0x3d20   vlan_dev_hard_start_xmit+0x3ab/0x5c0   dev_hard_start_xmit+0x17e/0x6e0   __dev_queue_xmit+0x2d6a/0x3d20   neigh_connected_output+0x3ed/0x570   ip6_finish_output2+0x5b5/0x1950   ip6_finish_output+0x693/0x11c0   ip6_output+0x24b/0x880   NF_HOOK.constprop.0+0xfd/0x530   ndisc_send_skb+0x9db/0x1400   ndisc_send_rs+0x12a/0x6c0   addrconf_dad_completed+0x3c9/0xea0   addrconf_dad_work+0x849/0x1420   process_one_work+0xa22/0x16e0   worker_thread+0x679/0x10c0   ret_from_fork+0x28/0x60   ret_from_fork_asm+0x11/0x20  When setup a vlan device on dev pim6reg, DAD ns packet may sent on reg_vif_xmit(). reg_vif_xmit()     ip6mr_cache_report()         skb_push(skb, -skb_network_offset(pkt));//skb_network_offset(pkt) is 4 And skb_push declared as:  void *skb_push(struct sk_buff *skb, unsigned int len);   skb->data -= len;   //0xffff88805f86a84c - 0xfffffffc = 0xffff887f5f86a850 skb->data is set to 0xffff887f5f86a850, which is invalid mem addr, lead to skb_push() fails.
CVE-2025-5305: The Password Reset with Code for WordPress REST API WordPress plugin before 0.0.17 does not use cryptographically sound algorithms to generate OTP codes, potentially leading to account takeovers.
CVE-2025-8942: The WP Hotel Booking WordPress plugin before 2.2.3 lacks proper server-side validation for review ratings, allowing an attacker to manipulate the rating value (e.g., sending negative or out-of-range values) by intercepting and modifying requests.
CVE-2024-13151: CWE - 89 - Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection') vulnerability in ESBI Information and Telecommunication Industry and Trade Limited Company Auto Service Software allows SQL Injection.This issue affects Auto Service Software: before v.2025.10.01.
CVE-2022-50385: In the Linux kernel, the following vulnerability has been resolved:  NFS: Fix an Oops in nfs_d_automount()  When mounting from a NFSv4 referral, path->dentry can end up being a negative dentry, so derive the struct nfs_server from the dentry itself instead.
CVE-2022-50390: In the Linux kernel, the following vulnerability has been resolved:  drm/ttm: fix undefined behavior in bit shift for TTM_TT_FLAG_PRIV_POPULATED  Shifting signed 32-bit value by 31 bits is undefined, so changing significant bit to unsigned. The UBSAN warning calltrace like below:  UBSAN: shift-out-of-bounds in ./include/drm/ttm/ttm_tt.h:122:26 left shift of 1 by 31 places cannot be represented in type 'int' Call Trace:  <TASK>  dump_stack_lvl+0x7d/0xa5  dump_stack+0x15/0x1b  ubsan_epilogue+0xe/0x4e  __ubsan_handle_shift_out_of_bounds+0x1e7/0x20c  ttm_bo_move_memcpy+0x3b4/0x460 [ttm]  bo_driver_move+0x32/0x40 [drm_vram_helper]  ttm_bo_handle_move_mem+0x118/0x200 [ttm]  ttm_bo_validate+0xfa/0x220 [ttm]  drm_gem_vram_pin_locked+0x70/0x1b0 [drm_vram_helper]  drm_gem_vram_pin+0x48/0xb0 [drm_vram_helper]  drm_gem_vram_plane_helper_prepare_fb+0x53/0xe0 [drm_vram_helper]  drm_gem_vram_simple_display_pipe_prepare_fb+0x26/0x30 [drm_vram_helper]  drm_simple_kms_plane_prepare_fb+0x4d/0xe0 [drm_kms_helper]  drm_atomic_helper_prepare_planes+0xda/0x210 [drm_kms_helper]  drm_atomic_helper_commit+0xc3/0x1e0 [drm_kms_helper]  drm_atomic_commit+0x9c/0x160 [drm]  drm_client_modeset_commit_atomic+0x33a/0x380 [drm]  drm_client_modeset_commit_locked+0x77/0x220 [drm]  drm_client_modeset_commit+0x31/0x60 [drm]  __drm_fb_helper_restore_fbdev_mode_unlocked+0xa7/0x170 [drm_kms_helper]  drm_fb_helper_set_par+0x51/0x90 [drm_kms_helper]  fbcon_init+0x316/0x790  visual_init+0x113/0x1d0  do_bind_con_driver+0x2a3/0x5c0  do_take_over_console+0xa9/0x270  do_fbcon_takeover+0xa1/0x170  do_fb_registered+0x2a8/0x340  fbcon_fb_registered+0x47/0xe0  register_framebuffer+0x294/0x4a0  __drm_fb_helper_initial_config_and_unlock+0x43c/0x880 [drm_kms_helper]  drm_fb_helper_initial_config+0x52/0x80 [drm_kms_helper]  drm_fbdev_client_hotplug+0x156/0x1b0 [drm_kms_helper]  drm_fbdev_generic_setup+0xfc/0x290 [drm_kms_helper]  bochs_pci_probe+0x6ca/0x772 [bochs]  local_pci_probe+0x4d/0xb0  pci_device_probe+0x119/0x320  really_probe+0x181/0x550  __driver_probe_device+0xc6/0x220  driver_probe_device+0x32/0x100  __driver_attach+0x195/0x200  bus_for_each_dev+0xbb/0x120  driver_attach+0x27/0x30  bus_add_driver+0x22e/0x2f0  driver_register+0xa9/0x190  __pci_register_driver+0x90/0xa0  bochs_pci_driver_init+0x52/0x1000 [bochs]  do_one_initcall+0x76/0x430  do_init_module+0x61/0x28a  load_module+0x1f82/0x2e50  __do_sys_finit_module+0xf8/0x190  __x64_sys_finit_module+0x23/0x30  do_syscall_64+0x58/0x80  entry_SYSCALL_64_after_hwframe+0x63/0xcd  </TASK>
CVE-2022-50392: In the Linux kernel, the following vulnerability has been resolved:  ASoC: mediatek: mt8183: fix refcount leak in mt8183_mt6358_ts3a227_max98357_dev_probe()  The node returned by of_parse_phandle() with refcount incremented, of_node_put() needs be called when finish using it. So add it in the error path in mt8183_mt6358_ts3a227_max98357_dev_probe().
CVE-2023-53381: In the Linux kernel, the following vulnerability has been resolved:  NFSD: fix leaked reference count of nfsd4_ssc_umount_item  The reference count of nfsd4_ssc_umount_item is not decremented on error conditions. This prevents the laundromat from unmounting the vfsmount of the source file.  This patch decrements the reference count of nfsd4_ssc_umount_item on error.
CVE-2023-53387: In the Linux kernel, the following vulnerability has been resolved:  scsi: ufs: core: Fix device management cmd timeout flow  In the UFS error handling flow, the host will send a device management cmd (NOP OUT) to the device for link recovery. If this cmd times out and clearing the doorbell fails, ufshcd_wait_for_dev_cmd() will do nothing and return. hba->dev_cmd.complete struct is not set to NULL.  When this happens, if cmd has been completed by device, then we will call complete() in __ufshcd_transfer_req_compl(). Because the complete struct is allocated on the stack, the following crash will occur:    ipanic_die+0x24/0x38 [mrdump]   die+0x344/0x748   arm64_notify_die+0x44/0x104   do_debug_exception+0x104/0x1e0   el1_dbg+0x38/0x54   el1_sync_handler+0x40/0x88   el1_sync+0x8c/0x140   queued_spin_lock_slowpath+0x2e4/0x3c0   __ufshcd_transfer_req_compl+0x3b0/0x1164   ufshcd_trc_handler+0x15c/0x308   ufshcd_host_reset_and_restore+0x54/0x260   ufshcd_reset_and_restore+0x28c/0x57c   ufshcd_err_handler+0xeb8/0x1b6c   process_one_work+0x288/0x964   worker_thread+0x4bc/0xc7c   kthread+0x15c/0x264   ret_from_fork+0x10/0x30
CVE-2023-53391: In the Linux kernel, the following vulnerability has been resolved:  shmem: use ramfs_kill_sb() for kill_sb method of ramfs-based tmpfs  As the ramfs-based tmpfs uses ramfs_init_fs_context() for the init_fs_context method, which allocates fc->s_fs_info, use ramfs_kill_sb() to free it and avoid a memory leak.
CVE-2023-53394: In the Linux kernel, the following vulnerability has been resolved:  net/mlx5e: xsk: Fix crash on regular rq reactivation  When the regular rq is reactivated after the XSK socket is closed it could be reading stale cqes which eventually corrupts the rq. This leads to no more traffic being received on the regular rq and a crash on the next close or deactivation of the rq.  Kal Cuttler Conely reported this issue as a crash on the release path when the xdpsock sample program is stopped (killed) and restarted in sequence while traffic is running.  This patch flushes all cqes when during the rq flush. The cqe flushing is done in the reset state of the rq. mlx5e_rq_to_ready code is moved into the flush function to allow for this.
CVE-2023-53400: In the Linux kernel, the following vulnerability has been resolved:  ALSA: hda: Fix Oops by 9.1 surround channel names  get_line_out_pfx() may trigger an Oops by overflowing the static array with more than 8 channels.  This was reported for MacBookPro 12,1 with Cirrus codec.  As a workaround, extend for the 9.1 channels and also fix the potential Oops by unifying the code paths accessing the same array with the proper size check.
CVE-2022-50412: In the Linux kernel, the following vulnerability has been resolved:  drm: bridge: adv7511: unregister cec i2c device after cec adapter  cec_unregister_adapter() assumes that the underlying adapter ops are callable. For example, if the CEC adapter currently has a valid physical address, then the unregistration procedure will invalidate the physical address by setting it to f.f.f.f. Whence the following kernel oops observed after removing the adv7511 module:      Unable to handle kernel execution of user memory at virtual address 0000000000000000     Internal error: Oops: 86000004 [#1] PREEMPT_RT SMP     Call trace:      0x0      adv7511_cec_adap_log_addr+0x1ac/0x1c8 [adv7511]      cec_adap_unconfigure+0x44/0x90 [cec]      __cec_s_phys_addr.part.0+0x68/0x230 [cec]      __cec_s_phys_addr+0x40/0x50 [cec]      cec_unregister_adapter+0xb4/0x118 [cec]      adv7511_remove+0x60/0x90 [adv7511]      i2c_device_remove+0x34/0xe0      device_release_driver_internal+0x114/0x1f0      driver_detach+0x54/0xe0      bus_remove_driver+0x60/0xd8      driver_unregister+0x34/0x60      i2c_del_driver+0x2c/0x68      adv7511_exit+0x1c/0x67c [adv7511]      __arm64_sys_delete_module+0x154/0x288      invoke_syscall+0x48/0x100      el0_svc_common.constprop.0+0x48/0xe8      do_el0_svc+0x28/0x88      el0_svc+0x1c/0x50      el0t_64_sync_handler+0xa8/0xb0      el0t_64_sync+0x15c/0x160     Code: bad PC value     ---[ end trace 0000000000000000 ]---  Protect against this scenario by unregistering i2c_cec after unregistering the CEC adapter. Duly disable the CEC clock afterwards too.
CVE-2022-50414: In the Linux kernel, the following vulnerability has been resolved:  scsi: fcoe: Fix transport not deattached when fcoe_if_init() fails  fcoe_init() calls fcoe_transport_attach(&fcoe_sw_transport), but when fcoe_if_init() fails, &fcoe_sw_transport is not detached and leaves freed &fcoe_sw_transport on fcoe_transports list. This causes panic when reinserting module.   BUG: unable to handle page fault for address: fffffbfff82e2213  RIP: 0010:fcoe_transport_attach+0xe1/0x230 [libfcoe]  Call Trace:   <TASK>   do_one_initcall+0xd0/0x4e0   load_module+0x5eee/0x7210   ...
CVE-2023-53431: In the Linux kernel, the following vulnerability has been resolved:  scsi: ses: Handle enclosure with just a primary component gracefully  This reverts commit 3fe97ff3d949 ("scsi: ses: Don't attach if enclosure has no components") and introduces proper handling of case where there are no detected secondary components, but primary component (enumerated in num_enclosures) does exist. That fix was originally proposed by Ding Hui <dinghui@sangfor.com.cn>.  Completely ignoring devices that have one primary enclosure and no secondary one results in ses_intf_add() bailing completely   scsi 2:0:0:254: enclosure has no enumerated components         scsi 2:0:0:254: Failed to bind enclosure -12ven in valid configurations such  even on valid configurations with 1 primary and 0 secondary enclosures as below:   # sg_ses /dev/sg0    3PARdata  SES               3321  Supported diagnostic pages:    Supported Diagnostic Pages [sdp] [0x0]    Configuration (SES) [cf] [0x1]    Short Enclosure Status (SES) [ses] [0x8]  # sg_ses -p cf /dev/sg0    3PARdata  SES               3321  Configuration diagnostic page:    number of secondary subenclosures: 0    generation code: 0x0    enclosure descriptor list      Subenclosure identifier: 0 [primary]        relative ES process id: 0, number of ES processes: 1        number of type descriptor headers: 1        enclosure logical identifier (hex): 20000002ac02068d        enclosure vendor: 3PARdata  product: VV                rev: 3321    type descriptor header and text list      Element type: Unspecified, subenclosure id: 0        number of possible elements: 1  The changelog for the original fix follows  ===== We can get a crash when disconnecting the iSCSI session, the call trace like this:    [ffff00002a00fb70] kfree at ffff00000830e224   [ffff00002a00fba0] ses_intf_remove at ffff000001f200e4   [ffff00002a00fbd0] device_del at ffff0000086b6a98   [ffff00002a00fc50] device_unregister at ffff0000086b6d58   [ffff00002a00fc70] __scsi_remove_device at ffff00000870608c   [ffff00002a00fca0] scsi_remove_device at ffff000008706134   [ffff00002a00fcc0] __scsi_remove_target at ffff0000087062e4   [ffff00002a00fd10] scsi_remove_target at ffff0000087064c0   [ffff00002a00fd70] __iscsi_unbind_session at ffff000001c872c4   [ffff00002a00fdb0] process_one_work at ffff00000810f35c   [ffff00002a00fe00] worker_thread at ffff00000810f648   [ffff00002a00fe70] kthread at ffff000008116e98  In ses_intf_add, components count could be 0, and kcalloc 0 size scomp, but not saved in edev->component[i].scratch  In this situation, edev->component[0].scratch is an invalid pointer, when kfree it in ses_intf_remove_enclosure, a crash like above would happen The call trace also could be other random cases when kfree cannot catch the invalid pointer  We should not use edev->component[] array when the components count is 0 We also need check index when use edev->component[] array in ses_enclosure_data_process =====
CVE-2023-53445: In the Linux kernel, the following vulnerability has been resolved:  net: qrtr: Fix a refcount bug in qrtr_recvmsg()  Syzbot reported a bug as following:  refcount_t: addition on 0; use-after-free. ... RIP: 0010:refcount_warn_saturate+0x17c/0x1f0 lib/refcount.c:25 ... Call Trace:  <TASK>  __refcount_add include/linux/refcount.h:199 [inline]  __refcount_inc include/linux/refcount.h:250 [inline]  refcount_inc include/linux/refcount.h:267 [inline]  kref_get include/linux/kref.h:45 [inline]  qrtr_node_acquire net/qrtr/af_qrtr.c:202 [inline]  qrtr_node_lookup net/qrtr/af_qrtr.c:398 [inline]  qrtr_send_resume_tx net/qrtr/af_qrtr.c:1003 [inline]  qrtr_recvmsg+0x85f/0x990 net/qrtr/af_qrtr.c:1070  sock_recvmsg_nosec net/socket.c:1017 [inline]  sock_recvmsg+0xe2/0x160 net/socket.c:1038  qrtr_ns_worker+0x170/0x1700 net/qrtr/ns.c:688  process_one_work+0x991/0x15c0 kernel/workqueue.c:2390  worker_thread+0x669/0x1090 kernel/workqueue.c:2537  It occurs in the concurrent scenario of qrtr_recvmsg() and qrtr_endpoint_unregister() as following:   cpu0     cpu1 qrtr_recvmsg    qrtr_endpoint_unregister qrtr_send_resume_tx   qrtr_node_release qrtr_node_lookup   mutex_lock(&qrtr_node_lock) spin_lock_irqsave(&qrtr_nodes_lock, ) refcount_dec_and_test(&node->ref) [node->ref == 0] radix_tree_lookup [node != NULL] __qrtr_node_release qrtr_node_acquire   spin_lock_irqsave(&qrtr_nodes_lock, ) kref_get(&node->ref) [WARNING]  ...      mutex_unlock(&qrtr_node_lock)  Use qrtr_node_lock to protect qrtr_node_lookup() implementation, this is actually improving the protection of node reference.
CVE-2025-39842: In the Linux kernel, the following vulnerability has been resolved:  ocfs2: prevent release journal inode after journal shutdown  Before calling ocfs2_delete_osb(), ocfs2_journal_shutdown() has already been executed in ocfs2_dismount_volume(), so osb->journal must be NULL.  Therefore, the following calltrace will inevitably fail when it reaches jbd2_journal_release_jbd_inode().  ocfs2_dismount_volume()->   ocfs2_delete_osb()->     ocfs2_free_slot_info()->       __ocfs2_free_slot_info()->         evict()->           ocfs2_evict_inode()->             ocfs2_clear_inode()->        jbd2_journal_release_jbd_inode(osb->journal->j_journal,  Adding osb->journal checks will prevent null-ptr-deref during the above execution path.
CVE-2025-9115: The Etsy Shop WordPress plugin before 3.0.7 does not escape the $_SERVER['REQUEST_URI'] parameter before outputting it back in an attribute, which could lead to Reflected Cross-Site Scripting in old web browsers.
CVE-2025-9487: The Admin and Site Enhancements (ASE) WordPress plugin before 7.9.8 does not sanitise SVG files when uploaded via xmlrpc.php when such uploads are enabled, which could allow users to upload a malicious SVG containing XSS payloads
CVE-2025-9540: The Markup Markdown WordPress plugin before 3.20.10 allows links to contain JavaScript which could allow users with the contributor role and above to perform Stored Cross-Site Scripting attacks.
CVE-2025-9541: The Markup Markdown WordPress plugin before 3.20.10 allows links to contain JavaScript which could allow users with the contributor role and above to perform Stored Cross-Site Scripting attacks.
CVE-2025-39872: In the Linux kernel, the following vulnerability has been resolved:  hsr: hold rcu and dev lock for hsr_get_port_ndev  hsr_get_port_ndev calls hsr_for_each_port, which need to hold rcu lock. On the other hand, before return the port device, we need to hold the device reference to avoid UaF in the caller function.