Search

Search Results (325338 CVEs found)

CVE Vendors Products Updated CVSS v3.1
CVE-2022-50800 2025-12-31 7.5 High
H3C SSL VPN contains a user enumeration vulnerability that allows attackers to identify valid usernames through the 'txtUsrName' POST parameter. Attackers can submit different usernames to the login_submit.cgi endpoint and analyze response messages to distinguish between existing and non-existing accounts.
CVE-2022-50801 2025-12-31 4.3 Medium
JM-DATA ONU JF511-TV version 1.0.67 is vulnerable to authenticated stored cross-site scripting (XSS) attacks, allowing attackers with authenticated access to inject malicious scripts that will be executed in other users' browsers when they view the affected content.
CVE-2022-50802 2025-12-31 6.1 Medium
ETAP Safety Manager 1.0.0.32 contains a cross-site scripting vulnerability in the 'action' GET parameter that allows unauthenticated attackers to inject malicious HTML and JavaScript. Attackers can craft specially formed requests to execute arbitrary scripts in victim browser sessions, potentially stealing credentials or performing unauthorized actions.
CVE-2022-50803 2025-12-31 9.8 Critical
JM-DATA ONU JF511-TV version 1.0.67 uses default credentials that allow attackers to gain unauthorized access to the device with administrative privileges.
CVE-2022-50804 2025-12-31 6.5 Medium
JM-DATA ONU JF511-TV version 1.0.67 is vulnerable to cross-site request forgery (CSRF) attacks, allowing attackers to perform administrative actions on behalf of authenticated users without their knowledge or consent.
CVE-2023-54163 2025-12-31 8.2 High
NLB mKlik Macedonia 3.3.12 contains a SQL injection vulnerability in international transfer parameters that allows attackers to manipulate database queries. Attackers can inject arbitrary SQL code through unsanitized input to potentially disclose sensitive information from the mobile banking application.
CVE-2023-54215 1 Linux 1 Linux Kernel 2025-12-31 5.5 Medium
In the Linux kernel, the following vulnerability has been resolved: virtio-vdpa: Fix cpumask memory leak in virtio_vdpa_find_vqs() Free the cpumask allocated by create_affinity_masks() before returning from the function.
CVE-2023-54217 1 Linux 1 Linux Kernel 2025-12-31 N/A
In the Linux kernel, the following vulnerability has been resolved: Revert "drm/msm: Add missing check and destroy for alloc_ordered_workqueue" This reverts commit 643b7d0869cc7f1f7a5ac7ca6bd25d88f54e31d0. A recent patch that tried to fix up the msm_drm_init() paths with respect to the workqueue but only ended up making things worse: First, the newly added calls to msm_drm_uninit() on early errors would trigger NULL-pointer dereferences, for example, as the kms pointer would not have been initialised. (Note that these paths were also modified by a second broken error handling patch which in effect cancelled out this part when merged.) Second, the newly added allocation sanity check would still leak the previously allocated drm device. Instead of trying to salvage what was badly broken (and clearly not tested), let's revert the bad commit so that clean and backportable fixes can be added in its place. Patchwork: https://patchwork.freedesktop.org/patch/525107/
CVE-2023-54220 1 Linux 1 Linux Kernel 2025-12-31 5.5 Medium
In the Linux kernel, the following vulnerability has been resolved: serial: 8250: Fix oops for port->pm on uart_change_pm() Unloading a hardware specific 8250 driver can produce error "Unable to handle kernel paging request at virtual address" about ten seconds after unloading the driver. This happens on uart_hangup() calling uart_change_pm(). Turns out commit 04e82793f068 ("serial: 8250: Reinit port->pm on port specific driver unbind") was only a partial fix. If the hardware specific driver has initialized port->pm function, we need to clear port->pm too. Just reinitializing port->ops does not do this. Otherwise serial8250_pm() will call port->pm() instead of serial8250_do_pm().
CVE-2023-54222 1 Linux 1 Linux Kernel 2025-12-31 5.5 Medium
In the Linux kernel, the following vulnerability has been resolved: hte: tegra-194: Fix off by one in tegra_hte_map_to_line_id() The "map_sz" is the number of elements in the "m" array so the > comparison needs to be changed to >= to prevent an out of bounds read.
CVE-2023-54228 1 Linux 1 Linux Kernel 2025-12-31 N/A
In the Linux kernel, the following vulnerability has been resolved: regulator: raa215300: Fix resource leak in case of error The clk_register_clkdev() allocates memory by calling vclkdev_alloc() and this memory is not freed in the error path. Similarly, resources allocated by clk_register_fixed_rate() are not freed in the error path. Fix these issues by using devm_clk_hw_register_fixed_rate() and devm_clk_hw_register_clkdev(). After this, the static variable clk is not needed. Replace it with  local variable hw in probe() and drop calling clk_unregister_fixed_rate() from raa215300_rtc_unregister_device().
CVE-2023-54229 1 Linux 1 Linux Kernel 2025-12-31 7.0 High
In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: fix registration of 6Ghz-only phy without the full channel range Because of what seems to be a typo, a 6Ghz-only phy for which the BDF does not allow the 7115Mhz channel will fail to register: WARNING: CPU: 2 PID: 106 at net/wireless/core.c:907 wiphy_register+0x914/0x954 Modules linked in: ath11k_pci sbsa_gwdt CPU: 2 PID: 106 Comm: kworker/u8:5 Not tainted 6.3.0-rc7-next-20230418-00549-g1e096a17625a-dirty #9 Hardware name: Freebox V7R Board (DT) Workqueue: ath11k_qmi_driver_event ath11k_qmi_driver_event_work pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : wiphy_register+0x914/0x954 lr : ieee80211_register_hw+0x67c/0xc10 sp : ffffff800b123aa0 x29: ffffff800b123aa0 x28: 0000000000000000 x27: 0000000000000000 x26: 0000000000000000 x25: 0000000000000006 x24: ffffffc008d51418 x23: ffffffc008cb0838 x22: ffffff80176c2460 x21: 0000000000000168 x20: ffffff80176c0000 x19: ffffff80176c03e0 x18: 0000000000000014 x17: 00000000cbef338c x16: 00000000d2a26f21 x15: 00000000ad6bb85f x14: 0000000000000020 x13: 0000000000000020 x12: 00000000ffffffbd x11: 0000000000000208 x10: 00000000fffffdf7 x9 : ffffffc009394718 x8 : ffffff80176c0528 x7 : 000000007fffffff x6 : 0000000000000006 x5 : 0000000000000005 x4 : ffffff800b304284 x3 : ffffff800b304284 x2 : ffffff800b304d98 x1 : 0000000000000000 x0 : 0000000000000000 Call trace: wiphy_register+0x914/0x954 ieee80211_register_hw+0x67c/0xc10 ath11k_mac_register+0x7c4/0xe10 ath11k_core_qmi_firmware_ready+0x1f4/0x570 ath11k_qmi_driver_event_work+0x198/0x590 process_one_work+0x1b8/0x328 worker_thread+0x6c/0x414 kthread+0x100/0x104 ret_from_fork+0x10/0x20 ---[ end trace 0000000000000000 ]--- ath11k_pci 0002:01:00.0: ieee80211 registration failed: -22 ath11k_pci 0002:01:00.0: failed register the radio with mac80211: -22 ath11k_pci 0002:01:00.0: failed to create pdev core: -22
CVE-2023-54234 1 Linux 1 Linux Kernel 2025-12-31 5.5 Medium
In the Linux kernel, the following vulnerability has been resolved: scsi: mpi3mr: Fix missing mrioc->evtack_cmds initialization Commit c1af985d27da ("scsi: mpi3mr: Add Event acknowledgment logic") introduced an array mrioc->evtack_cmds but initialization of the array elements was missed. They are just zero cleared. The function mpi3mr_complete_evt_ack() refers host_tag field of the elements. Due to the zero value of the host_tag field, the function calls clear_bit() for mrico->evtack_cmds_bitmap with wrong bit index. This results in memory access to invalid address and "BUG: KASAN: use-after-free". This BUG was observed at eHBA-9600 firmware update to version 8.3.1.0. To fix it, add the missing initialization of mrioc->evtack_cmds.
CVE-2023-54235 1 Linux 1 Linux Kernel 2025-12-31 5.5 Medium
In the Linux kernel, the following vulnerability has been resolved: PCI/DOE: Fix destroy_work_on_stack() race The following debug object splat was observed in testing: ODEBUG: free active (active state 0) object: 0000000097d23782 object type: work_struct hint: doe_statemachine_work+0x0/0x510 WARNING: CPU: 1 PID: 71 at lib/debugobjects.c:514 debug_print_object+0x7d/0xb0 ... Workqueue: pci 0000:36:00.0 DOE [1 doe_statemachine_work RIP: 0010:debug_print_object+0x7d/0xb0 ... Call Trace: ? debug_print_object+0x7d/0xb0 ? __pfx_doe_statemachine_work+0x10/0x10 debug_object_free.part.0+0x11b/0x150 doe_statemachine_work+0x45e/0x510 process_one_work+0x1d4/0x3c0 This occurs because destroy_work_on_stack() was called after signaling the completion in the calling thread. This creates a race between destroy_work_on_stack() and the task->work struct going out of scope in pci_doe(). Signal the work complete after destroying the work struct. This is safe because signal_task_complete() is the final thing the work item does and the workqueue code is careful not to access the work struct after.
CVE-2023-54243 1 Linux 1 Linux Kernel 2025-12-31 7.0 High
In the Linux kernel, the following vulnerability has been resolved: netfilter: ebtables: fix table blob use-after-free We are not allowed to return an error at this point. Looking at the code it looks like ret is always 0 at this point, but its not. t = find_table_lock(net, repl->name, &ret, &ebt_mutex); ... this can return a valid table, with ret != 0. This bug causes update of table->private with the new blob, but then frees the blob right away in the caller. Syzbot report: BUG: KASAN: vmalloc-out-of-bounds in __ebt_unregister_table+0xc00/0xcd0 net/bridge/netfilter/ebtables.c:1168 Read of size 4 at addr ffffc90005425000 by task kworker/u4:4/74 Workqueue: netns cleanup_net Call Trace: kasan_report+0xbf/0x1f0 mm/kasan/report.c:517 __ebt_unregister_table+0xc00/0xcd0 net/bridge/netfilter/ebtables.c:1168 ebt_unregister_table+0x35/0x40 net/bridge/netfilter/ebtables.c:1372 ops_exit_list+0xb0/0x170 net/core/net_namespace.c:169 cleanup_net+0x4ee/0xb10 net/core/net_namespace.c:613 ... ip(6)tables appears to be ok (ret should be 0 at this point) but make this more obvious.
CVE-2023-54244 1 Linux 1 Linux Kernel 2025-12-31 5.5 Medium
In the Linux kernel, the following vulnerability has been resolved: ACPI: EC: Fix oops when removing custom query handlers When removing custom query handlers, the handler might still be used inside the EC query workqueue, causing a kernel oops if the module holding the callback function was already unloaded. Fix this by flushing the EC query workqueue when removing custom query handlers. Tested on a Acer Travelmate 4002WLMi
CVE-2023-54249 1 Linux 1 Linux Kernel 2025-12-31 N/A
In the Linux kernel, the following vulnerability has been resolved: bus: mhi: ep: Only send -ENOTCONN status if client driver is available For the STOP and RESET commands, only send the channel disconnect status -ENOTCONN if client driver is available. Otherwise, it will result in null pointer dereference.
CVE-2023-54250 1 Linux 1 Linux Kernel 2025-12-31 N/A
In the Linux kernel, the following vulnerability has been resolved: ksmbd: avoid out of bounds access in decode_preauth_ctxt() Confirm that the accessed pneg_ctxt->HashAlgorithms address sits within the SMB request boundary; deassemble_neg_contexts() only checks that the eight byte smb2_neg_context header + (client controlled) DataLength are within the packet boundary, which is insufficient. Checking for sizeof(struct smb2_preauth_neg_context) is overkill given that the type currently assumes SMB311_SALT_SIZE bytes of trailing Salt.
CVE-2023-54252 1 Linux 1 Linux Kernel 2025-12-31 5.5 Medium
In the Linux kernel, the following vulnerability has been resolved: platform/x86: think-lmi: Fix memory leaks when parsing ThinkStation WMI strings My previous commit introduced a memory leak where the item allocated from tlmi_setting was not freed. This commit also renames it to avoid confusion with the similarly name variable in the same function.
CVE-2023-54255 1 Linux 1 Linux Kernel 2025-12-31 N/A
In the Linux kernel, the following vulnerability has been resolved: sh: dma: Fix DMA channel offset calculation Various SoCs of the SH3, SH4 and SH4A family, which use this driver, feature a differing number of DMA channels, which can be distributed between up to two DMAC modules. The existing implementation fails to correctly accommodate for all those variations, resulting in wrong channel offset calculations and leading to kernel panics. Rewrite dma_base_addr() in order to properly calculate channel offsets in a DMAC module. Fix dmaor_read_reg() and dmaor_write_reg(), so that the correct DMAC module base is selected for the DMAOR register.