Total
276814 CVE
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2024-56720 | 1 Linux | 1 Linux Kernel | 2025-01-09 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: bpf, sockmap: Several fixes to bpf_msg_pop_data Several fixes to bpf_msg_pop_data, 1. In sk_msg_shift_left, we should put_page 2. if (len == 0), return early is better 3. pop the entire sk_msg (last == msg->sg.size) should be supported 4. Fix for the value of variable "a" 5. In sk_msg_shift_left, after shifting, i has already pointed to the next element. Addtional sk_msg_iter_var_next may result in BUG. | ||||
| CVE-2023-24010 | 2025-01-09 | 8.2 High | ||
| An attacker can arbitrarily craft malicious DDS Participants (or ROS 2 Nodes) with valid certificates to compromise and get full control of the attacked secure DDS databus system by exploiting vulnerable attributes in the configuration of PKCS#7 certificate’s validation. This is caused by a non-compliant implementation of permission document verification used by some DDS vendors. Specifically, an improper use of the OpenSSL PKCS7_verify function used to validate S/MIME signatures. | ||||
| CVE-2023-24011 | 2025-01-09 | 8.2 High | ||
| An attacker can arbitrarily craft malicious DDS Participants (or ROS 2 Nodes) with valid certificates to compromise and get full control of the attacked secure DDS databus system by exploiting vulnerable attributes in the configuration of PKCS#7 certificate’s validation. This is caused by a non-compliant implementation of permission document verification used by some DDS vendors. Specifically, an improper use of the OpenSSL PKCS7_verify function used to validate S/MIME signatures. | ||||
| CVE-2023-24012 | 2025-01-09 | 8.2 High | ||
| An attacker can arbitrarily craft malicious DDS Participants (or ROS 2 Nodes) with valid certificates to compromise and get full control of the attacked secure DDS databus system by exploiting vulnerable attributes in the configuration of PKCS#7 certificate’s validation. This is caused by a non-compliant implementation of permission document verification used by some DDS vendors. Specifically, an improper use of the OpenSSL PKCS7_verify function used to validate S/MIME signatures. | ||||
| CVE-2023-34220 | 1 Jetbrains | 1 Teamcity | 2025-01-09 | 4.6 Medium |
| In JetBrains TeamCity before 2023.05 stored XSS in the Commit Status Publisher window was possible | ||||
| CVE-2023-26277 | 1 Ibm | 1 Qradar Wincollect | 2025-01-09 | 7.8 High |
| IBM QRadar WinCollect Agent 10.0 though 10.1.3 could allow a local user to execute commands on the system due to execution with unnecessary privileges. IBM X-Force ID: 248156. | ||||
| CVE-2023-26278 | 1 Ibm | 1 Qradar Wincollect | 2025-01-09 | 8.2 High |
| IBM QRadar WinCollect Agent 10.0 through 10.1.3 could allow a local authenticated attacker to gain elevated privileges on the system. IBM X-Force ID: 248158. | ||||
| CVE-2018-5852 | 1 Qualcomm | 46 Mdm9206, Mdm9206 Firmware, Mdm9607 and 43 more | 2025-01-09 | 8.4 High |
| An unsigned integer underflow vulnerability in IPA driver result into a buffer over-read while reading NAT entry using debugfs command 'cat /sys/kernel/debug/ipa/ip4_nat' | ||||
| CVE-2021-47016 | 1 Linux | 1 Linux Kernel | 2025-01-09 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: m68k: mvme147,mvme16x: Don't wipe PCC timer config bits Don't clear the timer 1 configuration bits when clearing the interrupt flag and counter overflow. As Michael reported, "This results in no timer interrupts being delivered after the first. Initialization then hangs in calibrate_delay as the jiffies counter is not updated." On mvme16x, enable the timer after requesting the irq, consistent with mvme147. | ||||
| CVE-2023-33979 | 1 Gpt Academic Project | 1 Gpt Academic | 2025-01-09 | 6.5 Medium |
| gpt_academic provides a graphical interface for ChatGPT/GLM. A vulnerability was found in gpt_academic 3.37 and prior. This issue affects some unknown processing of the component Configuration File Handler. The manipulation of the argument file leads to information disclosure. Since no sensitive files are configured to be off-limits, sensitive information files in some working directories can be read through the `/file` route, leading to sensitive information leakage. This affects users that uses file configurations via `config.py`, `config_private.py`, `Dockerfile`. A patch is available at commit 1dcc2873d2168ad2d3d70afcb453ac1695fbdf02. As a workaround, one may use environment variables instead of `config*.py` files to configure this project, or use docker-compose installation to configure this project. | ||||
| CVE-2023-3008 | 1 Student Management System Project | 1 Student Management System | 2025-01-09 | 7.3 High |
| A vulnerability classified as critical has been found in ningzichun Student Management System 1.0. This affects an unknown part of the file login.php. The manipulation of the argument user/pass leads to sql injection. It is possible to initiate the attack remotely. The exploit has been disclosed to the public and may be used. The associated identifier of this vulnerability is VDB-230355. | ||||
| CVE-2023-34088 | 1 Collaboraoffice | 1 Collabora Online | 2025-01-09 | 8.7 High |
| Collabora Online is a collaborative online office suite. A stored cross-site scripting (XSS) vulnerability was found in Collabora Online prior to versions 22.05.13, 21.11.9.1, and 6.4.27. An attacker could create a document with an XSS payload as a document name. Later, if an administrator opened the admin console and navigated to the history page, the document name was injected as unescaped HTML and executed as a script inside the context of the admin console. The administrator JSON web token (JWT) used for the websocket connection could be leaked through this flaw. Users should upgrade to Collabora Online 22.05.13 or higher; Collabora Online 21.11.9.1 or higher; Collabora Online 6.4.27 or higher to receive a patch. | ||||
| CVE-2021-47037 | 1 Linux | 1 Linux Kernel | 2025-01-09 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: ASoC: q6afe-clocks: fix reprobing of the driver Q6afe-clocks driver can get reprobed. For example if the APR services are restarted after the firmware crash. However currently Q6afe-clocks driver will oops because hw.init will get cleared during first _probe call. Rewrite the driver to fill the clock data at runtime rather than using big static array of clocks. | ||||
| CVE-2021-47056 | 1 Linux | 1 Linux Kernel | 2025-01-09 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: crypto: qat - ADF_STATUS_PF_RUNNING should be set after adf_dev_init ADF_STATUS_PF_RUNNING is (only) used and checked by adf_vf2pf_shutdown() before calling adf_iov_putmsg()->mutex_lock(vf2pf_lock), however the vf2pf_lock is initialized in adf_dev_init(), which can fail and when it fail, the vf2pf_lock is either not initialized or destroyed, a subsequent use of vf2pf_lock will cause issue. To fix this issue, only set this flag if adf_dev_init() returns 0. [ 7.178404] BUG: KASAN: user-memory-access in __mutex_lock.isra.0+0x1ac/0x7c0 [ 7.180345] Call Trace: [ 7.182576] mutex_lock+0xc9/0xd0 [ 7.183257] adf_iov_putmsg+0x118/0x1a0 [intel_qat] [ 7.183541] adf_vf2pf_shutdown+0x4d/0x7b [intel_qat] [ 7.183834] adf_dev_shutdown+0x172/0x2b0 [intel_qat] [ 7.184127] adf_probe+0x5e9/0x600 [qat_dh895xccvf] | ||||
| CVE-2021-47066 | 1 Linux | 1 Linux Kernel | 2025-01-09 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: async_xor: increase src_offs when dropping destination page Now we support sharing one page if PAGE_SIZE is not equal stripe size. To support this, it needs to support calculating xor value with different offsets for each r5dev. One offset array is used to record those offsets. In RMW mode, parity page is used as a source page. It sets ASYNC_TX_XOR_DROP_DST before calculating xor value in ops_run_prexor5. So it needs to add src_list and src_offs at the same time. Now it only needs src_list. So the xor value which is calculated is wrong. It can cause data corruption problem. I can reproduce this problem 100% on a POWER8 machine. The steps are: mdadm -CR /dev/md0 -l5 -n3 /dev/sdb1 /dev/sdc1 /dev/sdd1 --size=3G mkfs.xfs /dev/md0 mount /dev/md0 /mnt/test mount: /mnt/test: mount(2) system call failed: Structure needs cleaning. | ||||
| CVE-2021-47072 | 1 Linux | 1 Linux Kernel | 2025-01-09 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: btrfs: fix removed dentries still existing after log is synced When we move one inode from one directory to another and both the inode and its previous parent directory were logged before, we are not supposed to have the dentry for the old parent if we have a power failure after the log is synced. Only the new dentry is supposed to exist. Generally this works correctly, however there is a scenario where this is not currently working, because the old parent of the file/directory that was moved is not authoritative for a range that includes the dir index and dir item keys of the old dentry. This case is better explained with the following example and reproducer: # The test requires a very specific layout of keys and items in the # fs/subvolume btree to trigger the bug. So we want to make sure that # on whatever platform we are, we have the same leaf/node size. # # Currently in btrfs the node/leaf size can not be smaller than the page # size (but it can be greater than the page size). So use the largest # supported node/leaf size (64K). $ mkfs.btrfs -f -n 65536 /dev/sdc $ mount /dev/sdc /mnt # "testdir" is inode 257. $ mkdir /mnt/testdir $ chmod 755 /mnt/testdir # Create several empty files to have the directory "testdir" with its # items spread over several leaves (7 in this case). $ for ((i = 1; i <= 1200; i++)); do echo -n > /mnt/testdir/file$i done # Create our test directory "dira", inode number 1458, which gets all # its items in leaf 7. # # The BTRFS_DIR_ITEM_KEY item for inode 257 ("testdir") that points to # the entry named "dira" is in leaf 2, while the BTRFS_DIR_INDEX_KEY # item that points to that entry is in leaf 3. # # For this particular filesystem node size (64K), file count and file # names, we endup with the directory entry items from inode 257 in # leaves 2 and 3, as previously mentioned - what matters for triggering # the bug exercised by this test case is that those items are not placed # in leaf 1, they must be placed in a leaf different from the one # containing the inode item for inode 257. # # The corresponding BTRFS_DIR_ITEM_KEY and BTRFS_DIR_INDEX_KEY items for # the parent inode (257) are the following: # # item 460 key (257 DIR_ITEM 3724298081) itemoff 48344 itemsize 34 # location key (1458 INODE_ITEM 0) type DIR # transid 6 data_len 0 name_len 4 # name: dira # # and: # # item 771 key (257 DIR_INDEX 1202) itemoff 36673 itemsize 34 # location key (1458 INODE_ITEM 0) type DIR # transid 6 data_len 0 name_len 4 # name: dira $ mkdir /mnt/testdir/dira # Make sure everything done so far is durably persisted. $ sync # Now do a change to inode 257 ("testdir") that does not result in # COWing leaves 2 and 3 - the leaves that contain the directory items # pointing to inode 1458 (directory "dira"). # # Changing permissions, the owner/group, updating or adding a xattr, # etc, will not change (COW) leaves 2 and 3. So for the sake of # simplicity change the permissions of inode 257, which results in # updating its inode item and therefore change (COW) only leaf 1. $ chmod 700 /mnt/testdir # Now fsync directory inode 257. # # Since only the first leaf was changed/COWed, we log the inode item of # inode 257 and only the dentries found in the first leaf, all have a # key type of BTRFS_DIR_ITEM_KEY, and no keys of type # BTRFS_DIR_INDEX_KEY, because they sort after the former type and none # exist in the first leaf. # # We also log 3 items that represent ranges for dir items and dir # indexes for which the log is authoritative: # # 1) a key of type BTRFS_DIR_LOG_ITEM_KEY, which indicates the log is # authoritative for all BTRFS_DIR_ITEM_KEY keys that have an offset # in the range [0, 2285968570] (the offset here is th ---truncated--- | ||||
| CVE-2023-3013 | 1 Gpac | 1 Gpac | 2025-01-09 | 7.1 High |
| Unchecked Return Value in GitHub repository gpac/gpac prior to 2.2.2. | ||||
| CVE-2024-49035 | 1 Microsoft | 1 Partner Center | 2025-01-09 | 8.7 High |
| An improper access control vulnerability in Partner.Microsoft.com allows an a unauthenticated attacker to elevate privileges over a network. | ||||
| CVE-2024-49038 | 1 Microsoft | 1 Copilot Studio | 2025-01-09 | 9.3 Critical |
| Improper neutralization of input during web page generation ('Cross-site Scripting') in Copilot Studio by an unauthorized attacker leads to elevation of privilege over a network. | ||||
| CVE-2024-12753 | 2025-01-09 | N/A | ||
| Foxit PDF Reader Link Following Local Privilege Escalation Vulnerability. This vulnerability allows local attackers to escalate privileges on affected installations of Foxit PDF Reader. An attacker must first obtain the ability to execute low-privileged code on the target system in order to exploit this vulnerability. The specific flaw exists within the product installer. By creating a junction, an attacker can abuse the installer process to create an arbitrary file. An attacker can leverage this vulnerability to escalate privileges and execute arbitrary code in the context of SYSTEM. Was ZDI-CAN-25408. | ||||