Total
319973 CVE
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2025-66382 | 1 Libexpat Project | 1 Libexpat | 2025-12-02 | 2.9 Low |
| In libexpat through 2.7.3, a crafted file with an approximate size of 2 MiB can lead to dozens of seconds of processing time. | ||||
| CVE-2025-13576 | 2 Code-projects, Fabian | 2 Eblog Site, Blog Site | 2025-12-02 | 6.3 Medium |
| A vulnerability was detected in code-projects Blog Site 1.0. The affected element is an unknown function of the file /admin.php. Performing manipulation results in improper authorization. It is possible to initiate the attack remotely. The exploit is now public and may be used. Multiple endpoints are affected. | ||||
| CVE-2025-13579 | 1 Code-projects | 1 Library System | 2025-12-02 | 6.3 Medium |
| A vulnerability was found in code-projects Library System 1.0. This impacts an unknown function of the file /return.php. The manipulation of the argument ID results in sql injection. The attack can be launched remotely. The exploit has been made public and could be used. | ||||
| CVE-2025-13580 | 1 Code-projects | 1 Library System | 2025-12-02 | 6.3 Medium |
| A vulnerability was determined in code-projects Library System 1.0. Affected is an unknown function of the file /mail.php. This manipulation of the argument ID causes sql injection. The attack may be initiated remotely. The exploit has been publicly disclosed and may be utilized. | ||||
| CVE-2025-13582 | 2 Anisha, Code-projects | 2 Jonnys Liquor, Jonnys Liquor | 2025-12-02 | 7.3 High |
| A security flaw has been discovered in code-projects Jonnys Liquor 1.0. Affected by this issue is some unknown functionality of the file /detail.php of the component GET Parameter Handler. Performing manipulation of the argument Product results in sql injection. Remote exploitation of the attack is possible. The exploit has been released to the public and may be exploited. | ||||
| CVE-2025-13583 | 2 Carmelo, Code-projects | 2 Question Paper Generator, Question Paper Generator | 2025-12-02 | 7.3 High |
| A weakness has been identified in code-projects Question Paper Generator 1.0. This affects an unknown part of the file /signupscript.php of the component POST Parameter Handler. Executing manipulation of the argument Fname can lead to sql injection. The attack can be executed remotely. The exploit has been made available to the public and could be exploited. | ||||
| CVE-2025-13586 | 2 Senior-walter, Sourcecodester | 2 Online Student Clearance System, Online Student Clearance System | 2025-12-02 | 4.7 Medium |
| A flaw has been found in SourceCodester Online Student Clearance System 1.0. Impacted is an unknown function of the file /Admin/changepassword.php. This manipulation of the argument txtconfirm_password causes sql injection. It is possible to initiate the attack remotely. The exploit has been published and may be used. | ||||
| CVE-2025-64047 | 1 Openrapid | 1 Rapidcms | 2025-12-02 | 6.1 Medium |
| OpenRapid RapidCMS 1.3.1 is vulnerable to Cross Site Scripting (XSS) in /user/user-move.php. | ||||
| CVE-2025-63522 | 1 Feehi | 2 Feehi Cms, Feehicms | 2025-12-02 | 4.6 Medium |
| Reverse Tabnabbing vulnerability in FeehiCMS 2.1.1 in the Comments Management function | ||||
| CVE-2025-63523 | 1 Feehi | 2 Feehi Cms, Feehicms | 2025-12-02 | 6.5 Medium |
| FeehiCMS version 2.1.1 fails to enforce server-side immutability for parameters that are presented to clients as "read-only." An authenticated attacker can intercept and modify the parameter in transit and the backend accepts the changes. This can lead to unintended username changes. | ||||
| CVE-2023-53171 | 1 Linux | 1 Linux Kernel | 2025-12-02 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: vfio/type1: prevent underflow of locked_vm via exec() When a vfio container is preserved across exec, the task does not change, but it gets a new mm with locked_vm=0, and loses the count from existing dma mappings. If the user later unmaps a dma mapping, locked_vm underflows to a large unsigned value, and a subsequent dma map request fails with ENOMEM in __account_locked_vm. To avoid underflow, grab and save the mm at the time a dma is mapped. Use that mm when adjusting locked_vm, rather than re-acquiring the saved task's mm, which may have changed. If the saved mm is dead, do nothing. locked_vm is incremented for existing mappings in a subsequent patch. | ||||
| CVE-2023-53173 | 1 Linux | 1 Linux Kernel | 2025-12-02 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: tty: pcn_uart: fix memory leak with using debugfs_lookup() When calling debugfs_lookup() the result must have dput() called on it, otherwise the memory will leak over time. To make things simpler, just call debugfs_lookup_and_remove() instead which handles all of the logic at once. | ||||
| CVE-2023-53174 | 1 Linux | 1 Linux Kernel | 2025-12-02 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: scsi: core: Fix possible memory leak if device_add() fails If device_add() returns error, the name allocated by dev_set_name() needs be freed. As the comment of device_add() says, put_device() should be used to decrease the reference count in the error path. So fix this by calling put_device(), then the name can be freed in kobject_cleanp(). | ||||
| CVE-2023-53177 | 1 Linux | 1 Linux Kernel | 2025-12-02 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: media: hi846: fix usage of pm_runtime_get_if_in_use() pm_runtime_get_if_in_use() does not only return nonzero values when the device is in use, it can return a negative errno too. And especially during resuming from system suspend, when runtime pm is not yet up again, -EAGAIN is being returned, so the subsequent pm_runtime_put() call results in a refcount underflow. Fix system-resume by handling -EAGAIN of pm_runtime_get_if_in_use(). | ||||
| CVE-2023-53175 | 1 Linux | 1 Linux Kernel | 2025-12-02 | 5.5 Medium |
| 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 | 1 Linux | 1 Linux Kernel | 2025-12-02 | 5.5 Medium |
| 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-53180 | 1 Linux | 1 Linux Kernel | 2025-12-02 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: wifi: ath12k: Avoid NULL pointer access during management transmit cleanup Currently 'ar' reference is not added in skb_cb. Though this is generally not used during transmit completion callbacks, on interface removal the remaining idr cleanup callback uses the ar pointer from skb_cb from management txmgmt_idr. Hence fill them during transmit call for proper usage to avoid NULL pointer dereference. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.0.1-00029-QCAHKSWPL_SILICONZ-1 | ||||
| CVE-2023-53178 | 1 Linux | 1 Linux Kernel | 2025-12-02 | 4.7 Medium |
| In the Linux kernel, the following vulnerability has been resolved: mm: fix zswap writeback race condition The zswap writeback mechanism can cause a race condition resulting in memory corruption, where a swapped out page gets swapped in with data that was written to a different page. The race unfolds like this: 1. a page with data A and swap offset X is stored in zswap 2. page A is removed off the LRU by zpool driver for writeback in zswap-shrink work, data for A is mapped by zpool driver 3. user space program faults and invalidates page entry A, offset X is considered free 4. kswapd stores page B at offset X in zswap (zswap could also be full, if so, page B would then be IOed to X, then skip step 5.) 5. entry A is replaced by B in tree->rbroot, this doesn't affect the local reference held by zswap-shrink work 6. zswap-shrink work writes back A at X, and frees zswap entry A 7. swapin of slot X brings A in memory instead of B The fix: Once the swap page cache has been allocated (case ZSWAP_SWAPCACHE_NEW), zswap-shrink work just checks that the local zswap_entry reference is still the same as the one in the tree. If it's not the same it means that it's either been invalidated or replaced, in both cases the writeback is aborted because the local entry contains stale data. Reproducer: I originally found this by running `stress` overnight to validate my work on the zswap writeback mechanism, it manifested after hours on my test machine. The key to make it happen is having zswap writebacks, so whatever setup pumps /sys/kernel/debug/zswap/written_back_pages should do the trick. In order to reproduce this faster on a vm, I setup a system with ~100M of available memory and a 500M swap file, then running `stress --vm 1 --vm-bytes 300000000 --vm-stride 4000` makes it happen in matter of tens of minutes. One can speed things up even more by swinging /sys/module/zswap/parameters/max_pool_percent up and down between, say, 20 and 1; this makes it reproduce in tens of seconds. It's crucial to set `--vm-stride` to something other than 4096 otherwise `stress` won't realize that memory has been corrupted because all pages would have the same data. | ||||
| CVE-2023-53179 | 1 Linux | 1 Linux Kernel | 2025-12-02 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: netfilter: ipset: add the missing IP_SET_HASH_WITH_NET0 macro for ip_set_hash_netportnet.c The missing IP_SET_HASH_WITH_NET0 macro in ip_set_hash_netportnet can lead to the use of wrong `CIDR_POS(c)` for calculating array offsets, which can lead to integer underflow. As a result, it leads to slab out-of-bound access. This patch adds back the IP_SET_HASH_WITH_NET0 macro to ip_set_hash_netportnet to address the issue. | ||||
| CVE-2023-53181 | 1 Linux | 1 Linux Kernel | 2025-12-02 | 5.5 Medium |
| 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. | ||||