Total
271657 CVE
| CVE | Vendors | Products | Updated | CVSS v2 | CVSS v3 |
|---|---|---|---|---|---|
| CVE-2024-44571 | 2024-09-12 | N/A | 8.8 HIGH | ||
| RELY-PCIe v22.2.1 to v23.1.0 was discovered to contain incorrect access control in the mService function at phpinf.php. | |||||
| CVE-2024-44577 | 2024-09-12 | N/A | 8.8 HIGH | ||
| RELY-PCIe v22.2.1 to v23.1.0 was discovered to contain a command injection vulnerability via the time_date function. | |||||
| CVE-2024-44574 | 2024-09-12 | N/A | 8.8 HIGH | ||
| RELY-PCIe v22.2.1 to v23.1.0 was discovered to contain a command injection vulnerability via the sys_conf function. | |||||
| CVE-2024-44572 | 2024-09-12 | N/A | 8.8 HIGH | ||
| RELY-PCIe v22.2.1 to v23.1.0 was discovered to contain a command injection vulnerability via the sys_mgmt function. | |||||
| CVE-2024-44570 | 2024-09-12 | N/A | 8.8 HIGH | ||
| RELY-PCIe v22.2.1 to v23.1.0 was discovered to contain a code injection vulnerability via the getParams function in phpinf.php. | |||||
| CVE-2024-28981 | 2024-09-12 | N/A | 8.5 HIGH | ||
| Hitachi Vantara Pentaho Data Integration & Analytics versions before 10.1.0.0 and 9.3.0.8, including 8.3.x, discloses database passwords when searching metadata injectable fields. | |||||
| CVE-2024-8694 | 2024-09-12 | 4.7 MEDIUM | 3.8 LOW | ||
| A vulnerability, which was classified as problematic, was found in JFinalCMS up to 20240903. This affects the function update of the file /admin/template/update of the component com.cms.controller.admin.TemplateController. The manipulation of the argument fileName leads to path traversal. It is possible to initiate the attack remotely. The exploit has been disclosed to the public and may be used. | |||||
| CVE-2024-44541 | 2024-09-12 | N/A | 9.8 CRITICAL | ||
| evilnapsis Inventio Lite Versions v4 and before is vulnerable to SQL Injection via the "username" parameter in "/?action=processlogin." | |||||
| CVE-2024-8705 | 2024-09-12 | 6.5 MEDIUM | 6.3 MEDIUM | ||
| A vulnerability was found in Shandong Star Measurement and Control Equipment Heating Network Wireless Monitoring System 5.6.2 and classified as critical. Affected by this issue is the function GetDataKindByType of the file /DataSrvs/UCCGSrv.asmx. The manipulation leads to sql injection. The attack may be launched remotely. The exploit has been disclosed to the public and may be used. | |||||
| CVE-2024-8693 | 2024-09-12 | 3.3 LOW | 2.4 LOW | ||
| A vulnerability, which was classified as problematic, has been found in Kaon CG3000 1.01.43. Affected by this issue is some unknown functionality of the component dhcpcd Command Handler. The manipulation of the argument -h with the input <script>alert('XSS')</script> leads to cross site scripting. The attack may be launched remotely. The exploit has been disclosed to the public and may be used. The vendor was contacted early about this disclosure but did not respond in any way. | |||||
| CVE-2024-8706 | 2024-09-12 | 4.0 MEDIUM | 4.3 MEDIUM | ||
| A vulnerability was found in JFinalCMS up to 20240903. It has been classified as problematic. This affects the function update of the file /admin/template/update of the component com.cms.util.TemplateUtils. The manipulation of the argument fileName leads to path traversal. It is possible to initiate the attack remotely. The exploit has been disclosed to the public and may be used. | |||||
| CVE-2024-44974 | 1 Linux | 1 Linux Kernel | 2024-09-12 | N/A | 7.8 HIGH |
| In the Linux kernel, the following vulnerability has been resolved: mptcp: pm: avoid possible UaF when selecting endp select_local_address() and select_signal_address() both select an endpoint entry from the list inside an RCU protected section, but return a reference to it, to be read later on. If the entry is dereferenced after the RCU unlock, reading info could cause a Use-after-Free. A simple solution is to copy the required info while inside the RCU protected section to avoid any risk of UaF later. The address ID might need to be modified later to handle the ID0 case later, so a copy seems OK to deal with. | |||||
| CVE-2024-43905 | 1 Linux | 1 Linux Kernel | 2024-09-12 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: drm/amd/pm: Fix the null pointer dereference for vega10_hwmgr Check return value and conduct null pointer handling to avoid null pointer dereference. | |||||
| CVE-2024-43897 | 1 Linux | 1 Linux Kernel | 2024-09-12 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: net: drop bad gso csum_start and offset in virtio_net_hdr Tighten csum_start and csum_offset checks in virtio_net_hdr_to_skb for GSO packets. The function already checks that a checksum requested with VIRTIO_NET_HDR_F_NEEDS_CSUM is in skb linear. But for GSO packets this might not hold for segs after segmentation. Syzkaller demonstrated to reach this warning in skb_checksum_help offset = skb_checksum_start_offset(skb); ret = -EINVAL; if (WARN_ON_ONCE(offset >= skb_headlen(skb))) By injecting a TSO packet: WARNING: CPU: 1 PID: 3539 at net/core/dev.c:3284 skb_checksum_help+0x3d0/0x5b0 ip_do_fragment+0x209/0x1b20 net/ipv4/ip_output.c:774 ip_finish_output_gso net/ipv4/ip_output.c:279 [inline] __ip_finish_output+0x2bd/0x4b0 net/ipv4/ip_output.c:301 iptunnel_xmit+0x50c/0x930 net/ipv4/ip_tunnel_core.c:82 ip_tunnel_xmit+0x2296/0x2c70 net/ipv4/ip_tunnel.c:813 __gre_xmit net/ipv4/ip_gre.c:469 [inline] ipgre_xmit+0x759/0xa60 net/ipv4/ip_gre.c:661 __netdev_start_xmit include/linux/netdevice.h:4850 [inline] netdev_start_xmit include/linux/netdevice.h:4864 [inline] xmit_one net/core/dev.c:3595 [inline] dev_hard_start_xmit+0x261/0x8c0 net/core/dev.c:3611 __dev_queue_xmit+0x1b97/0x3c90 net/core/dev.c:4261 packet_snd net/packet/af_packet.c:3073 [inline] The geometry of the bad input packet at tcp_gso_segment: [ 52.003050][ T8403] skb len=12202 headroom=244 headlen=12093 tailroom=0 [ 52.003050][ T8403] mac=(168,24) mac_len=24 net=(192,52) trans=244 [ 52.003050][ T8403] shinfo(txflags=0 nr_frags=1 gso(size=1552 type=3 segs=0)) [ 52.003050][ T8403] csum(0x60000c7 start=199 offset=1536 ip_summed=3 complete_sw=0 valid=0 level=0) Mitigate with stricter input validation. csum_offset: for GSO packets, deduce the correct value from gso_type. This is already done for USO. Extend it to TSO. Let UFO be: udp[46]_ufo_fragment ignores these fields and always computes the checksum in software. csum_start: finding the real offset requires parsing to the transport header. Do not add a parser, use existing segmentation parsing. Thanks to SKB_GSO_DODGY, that also catches bad packets that are hw offloaded. Again test both TSO and USO. Do not test UFO for the above reason, and do not test UDP tunnel offload. GSO packet are almost always CHECKSUM_PARTIAL. USO packets may be CHECKSUM_NONE since commit 10154dbded6d6 ("udp: Allow GSO transmit from devices with no checksum offload"), but then still these fields are initialized correctly in udp4_hwcsum/udp6_hwcsum_outgoing. So no need to test for ip_summed == CHECKSUM_PARTIAL first. This revises an existing fix mentioned in the Fixes tag, which broke small packets with GSO offload, as detected by kselftests. | |||||
| CVE-2024-43892 | 1 Linux | 1 Linux Kernel | 2024-09-12 | N/A | 4.7 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: memcg: protect concurrent access to mem_cgroup_idr Commit 73f576c04b94 ("mm: memcontrol: fix cgroup creation failure after many small jobs") decoupled the memcg IDs from the CSS ID space to fix the cgroup creation failures. It introduced IDR to maintain the memcg ID space. The IDR depends on external synchronization mechanisms for modifications. For the mem_cgroup_idr, the idr_alloc() and idr_replace() happen within css callback and thus are protected through cgroup_mutex from concurrent modifications. However idr_remove() for mem_cgroup_idr was not protected against concurrency and can be run concurrently for different memcgs when they hit their refcnt to zero. Fix that. We have been seeing list_lru based kernel crashes at a low frequency in our fleet for a long time. These crashes were in different part of list_lru code including list_lru_add(), list_lru_del() and reparenting code. Upon further inspection, it looked like for a given object (dentry and inode), the super_block's list_lru didn't have list_lru_one for the memcg of that object. The initial suspicions were either the object is not allocated through kmem_cache_alloc_lru() or somehow memcg_list_lru_alloc() failed to allocate list_lru_one() for a memcg but returned success. No evidence were found for these cases. Looking more deeply, we started seeing situations where valid memcg's id is not present in mem_cgroup_idr and in some cases multiple valid memcgs have same id and mem_cgroup_idr is pointing to one of them. So, the most reasonable explanation is that these situations can happen due to race between multiple idr_remove() calls or race between idr_alloc()/idr_replace() and idr_remove(). These races are causing multiple memcgs to acquire the same ID and then offlining of one of them would cleanup list_lrus on the system for all of them. Later access from other memcgs to the list_lru cause crashes due to missing list_lru_one. | |||||
| CVE-2024-43854 | 1 Linux | 1 Linux Kernel | 2024-09-12 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: block: initialize integrity buffer to zero before writing it to media Metadata added by bio_integrity_prep is using plain kmalloc, which leads to random kernel memory being written media. For PI metadata this is limited to the app tag that isn't used by kernel generated metadata, but for non-PI metadata the entire buffer leaks kernel memory. Fix this by adding the __GFP_ZERO flag to allocations for writes. | |||||
| CVE-2024-42246 | 1 Linux | 1 Linux Kernel | 2024-09-12 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: net, sunrpc: Remap EPERM in case of connection failure in xs_tcp_setup_socket When using a BPF program on kernel_connect(), the call can return -EPERM. This causes xs_tcp_setup_socket() to loop forever, filling up the syslog and causing the kernel to potentially freeze up. Neil suggested: This will propagate -EPERM up into other layers which might not be ready to handle it. It might be safer to map EPERM to an error we would be more likely to expect from the network system - such as ECONNREFUSED or ENETDOWN. ECONNREFUSED as error seems reasonable. For programs setting a different error can be out of reach (see handling in 4fbac77d2d09) in particular on kernels which do not have f10d05966196 ("bpf: Make BPF_PROG_RUN_ARRAY return -err instead of allow boolean"), thus given that it is better to simply remap for consistent behavior. UDP does handle EPERM in xs_udp_send_request(). | |||||
| CVE-2024-38688 | 2024-09-12 | N/A | N/A | ||
| Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority. | |||||
| CVE-2024-38226 | 1 Microsoft | 2 Office, Publisher | 2024-09-12 | N/A | 7.3 HIGH |
| Microsoft Publisher Security Feature Bypass Vulnerability | |||||
| CVE-2024-40652 | 2024-09-11 | N/A | 7.3 HIGH | ||
| In onCreate of SettingsHomepageActivity.java, there is a possible way to access the Settings app while the device is provisioning due to a missing permission check. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is needed for exploitation. | |||||