Filtered by vendor Redhat
Subscriptions
Total
20653 CVE
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2023-0119 | 1 Redhat | 5 Enterprise Linux, Satellite, Satellite Capsule and 2 more | 2024-08-02 | 5.4 Medium |
| A stored Cross-site scripting vulnerability was found in foreman. The Comment section in the Hosts tab has incorrect filtering of user input data. As a result of the attack, an attacker with an existing account on the system can steal another user's session, make requests on behalf of the user, and obtain user credentials. | ||||
| CVE-2023-0105 | 1 Redhat | 4 Keycloak, Red Hat Single Sign On, Rhosemc and 1 more | 2024-08-02 | 6.5 Medium |
| A flaw was found in Keycloak. This flaw allows impersonation and lockout due to the email trust not being handled correctly in Keycloak. An attacker can shadow other users with the same email and lockout or impersonate them. | ||||
| CVE-2023-0091 | 1 Redhat | 4 Keycloak, Red Hat Single Sign On, Rhosemc and 1 more | 2024-08-02 | 3.8 Low |
| A flaw was found in Keycloak, where it did not properly check client tokens for possible revocation in its client credential flow. This flaw allows an attacker to access or modify potentially sensitive information. | ||||
| CVE-2023-0056 | 3 Fedoraproject, Haproxy, Redhat | 12 Extra Packages For Enterprise Linux, Fedora, Haproxy and 9 more | 2024-08-02 | 6.5 Medium |
| An uncontrolled resource consumption vulnerability was discovered in HAProxy which could crash the service. This issue could allow an authenticated remote attacker to run a specially crafted malicious server in an OpenShift cluster. The biggest impact is to availability. | ||||
| CVE-2023-0044 | 2 Quarkus, Redhat | 3 Quarkus, Build Of Quarkus, Quarkus | 2024-08-02 | 6.1 Medium |
| If the Quarkus Form Authentication session cookie Path attribute is set to `/` then a cross-site attack may be initiated which might lead to the Information Disclosure. This attack can be prevented with the Quarkus CSRF Prevention feature. | ||||
| CVE-2024-40767 | 2 Openstack, Redhat | 2 Nova, Openstack | 2024-08-02 | 6.5 Medium |
| In OpenStack Nova before 27.4.1, 28 before 28.2.1, and 29 before 29.1.1, by supplying a raw format image that is actually a crafted QCOW2 image with a backing file path or VMDK flat image with a descriptor file path, an authenticated user may convince systems to return a copy of the referenced file's contents from the server, resulting in unauthorized access to potentially sensitive data. All Nova deployments are affected. NOTE: this issue exists because of an incomplete fix for CVE-2022-47951 and CVE-2024-32498. | ||||
| CVE-2024-40634 | 2 Argoproj, Redhat | 2 Argo-cd, Openshift Gitops | 2024-08-02 | 7.5 High |
| Argo CD is a declarative, GitOps continuous delivery tool for Kubernetes. This report details a security vulnerability in Argo CD, where an unauthenticated attacker can send a specially crafted large JSON payload to the /api/webhook endpoint, causing excessive memory allocation that leads to service disruption by triggering an Out Of Memory (OOM) kill. The issue poses a high risk to the availability of Argo CD deployments. This vulnerability is fixed in 2.11.6, 2.10.15, and 2.9.20. | ||||
| CVE-2024-39908 | 2 Redhat, Ruby-lang | 2 Enterprise Linux, Rexml | 2024-08-02 | 4.3 Medium |
| REXML is an XML toolkit for Ruby. The REXML gem before 3.3.1 has some DoS vulnerabilities when it parses an XML that has many specific characters such as `<`, `0` and `%>`. If you need to parse untrusted XMLs, you many be impacted to these vulnerabilities. The REXML gem 3.3.2 or later include the patches to fix these vulnerabilities. Users are advised to upgrade. Users unable to upgrade should avoid parsing untrusted XML strings. | ||||
| CVE-2024-39936 | 2 Qt, Redhat | 7 Qt, Enterprise Linux, Rhel Aus and 4 more | 2024-08-02 | 8.6 High |
| An issue was discovered in HTTP2 in Qt before 5.15.18, 6.x before 6.2.13, 6.3.x through 6.5.x before 6.5.7, and 6.6.x through 6.7.x before 6.7.3. Code to make security-relevant decisions about an established connection may execute too early, because the encrypted() signal has not yet been emitted and processed.. | ||||
| CVE-2024-39614 | 2 Djangoproject, Redhat | 2 Django, Ansible Automation Platform | 2024-08-02 | 7.5 High |
| An issue was discovered in Django 5.0 before 5.0.7 and 4.2 before 4.2.14. get_supported_language_variant() was subject to a potential denial-of-service attack when used with very long strings containing specific characters. | ||||
| CVE-2024-39476 | 2 Linux, Redhat | 2 Linux Kernel, Enterprise Linux | 2024-08-02 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: md/raid5: fix deadlock that raid5d() wait for itself to clear MD_SB_CHANGE_PENDING Xiao reported that lvm2 test lvconvert-raid-takeover.sh can hang with small possibility, the root cause is exactly the same as commit bed9e27baf52 ("Revert "md/raid5: Wait for MD_SB_CHANGE_PENDING in raid5d"") However, Dan reported another hang after that, and junxiao investigated the problem and found out that this is caused by plugged bio can't issue from raid5d(). Current implementation in raid5d() has a weird dependence: 1) md_check_recovery() from raid5d() must hold 'reconfig_mutex' to clear MD_SB_CHANGE_PENDING; 2) raid5d() handles IO in a deadloop, until all IO are issued; 3) IO from raid5d() must wait for MD_SB_CHANGE_PENDING to be cleared; This behaviour is introduce before v2.6, and for consequence, if other context hold 'reconfig_mutex', and md_check_recovery() can't update super_block, then raid5d() will waste one cpu 100% by the deadloop, until 'reconfig_mutex' is released. Refer to the implementation from raid1 and raid10, fix this problem by skipping issue IO if MD_SB_CHANGE_PENDING is still set after md_check_recovery(), daemon thread will be woken up when 'reconfig_mutex' is released. Meanwhile, the hang problem will be fixed as well. | ||||
| CVE-2024-39330 | 1 Redhat | 1 Ansible Automation Platform | 2024-08-02 | 4.3 Medium |
| An issue was discovered in Django 5.0 before 5.0.7 and 4.2 before 4.2.14. Derived classes of the django.core.files.storage.Storage base class, when they override generate_filename() without replicating the file-path validations from the parent class, potentially allow directory traversal via certain inputs during a save() call. (Built-in Storage sub-classes are unaffected.) | ||||
| CVE-2024-39329 | 2 Djangoproject, Redhat | 2 Django, Ansible Automation Platform | 2024-08-02 | 5.3 Medium |
| An issue was discovered in Django 5.0 before 5.0.7 and 4.2 before 4.2.14. The django.contrib.auth.backends.ModelBackend.authenticate() method allows remote attackers to enumerate users via a timing attack involving login requests for users with an unusable password. | ||||
| CVE-2024-39276 | 1 Redhat | 1 Enterprise Linux | 2024-08-02 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: ext4: fix mb_cache_entry's e_refcnt leak in ext4_xattr_block_cache_find() Syzbot reports a warning as follows: ============================================ WARNING: CPU: 0 PID: 5075 at fs/mbcache.c:419 mb_cache_destroy+0x224/0x290 Modules linked in: CPU: 0 PID: 5075 Comm: syz-executor199 Not tainted 6.9.0-rc6-gb947cc5bf6d7 RIP: 0010:mb_cache_destroy+0x224/0x290 fs/mbcache.c:419 Call Trace: <TASK> ext4_put_super+0x6d4/0xcd0 fs/ext4/super.c:1375 generic_shutdown_super+0x136/0x2d0 fs/super.c:641 kill_block_super+0x44/0x90 fs/super.c:1675 ext4_kill_sb+0x68/0xa0 fs/ext4/super.c:7327 [...] ============================================ This is because when finding an entry in ext4_xattr_block_cache_find(), if ext4_sb_bread() returns -ENOMEM, the ce's e_refcnt, which has already grown in the __entry_find(), won't be put away, and eventually trigger the above issue in mb_cache_destroy() due to reference count leakage. So call mb_cache_entry_put() on the -ENOMEM error branch as a quick fix. | ||||
| CVE-2024-38875 | 1 Redhat | 1 Ansible Automation Platform | 2024-08-02 | 7.5 High |
| An issue was discovered in Django 4.2 before 4.2.14 and 5.0 before 5.0.7. urlize and urlizetrunc were subject to a potential denial of service attack via certain inputs with a very large number of brackets. | ||||
| CVE-2024-38615 | 1 Redhat | 2 Enterprise Linux, Rhel Eus | 2024-08-02 | 4.4 Medium |
| In the Linux kernel, the following vulnerability has been resolved: cpufreq: exit() callback is optional The exit() callback is optional and shouldn't be called without checking a valid pointer first. Also, we must clear freq_table pointer even if the exit() callback isn't present. | ||||
| CVE-2024-38573 | 2 Linux, Redhat | 4 Acrn, Linux Kernel, Enterprise Linux and 1 more | 2024-08-02 | 7.5 High |
| In the Linux kernel, the following vulnerability has been resolved: cppc_cpufreq: Fix possible null pointer dereference cppc_cpufreq_get_rate() and hisi_cppc_cpufreq_get_rate() can be called from different places with various parameters. So cpufreq_cpu_get() can return null as 'policy' in some circumstances. Fix this bug by adding null return check. Found by Linux Verification Center (linuxtesting.org) with SVACE. | ||||
| CVE-2024-38663 | 1 Redhat | 2 Enterprise Linux, Rhel Eus | 2024-08-02 | 4.4 Medium |
| In the Linux kernel, the following vulnerability has been resolved: blk-cgroup: fix list corruption from resetting io stat Since commit 3b8cc6298724 ("blk-cgroup: Optimize blkcg_rstat_flush()"), each iostat instance is added to blkcg percpu list, so blkcg_reset_stats() can't reset the stat instance by memset(), otherwise the llist may be corrupted. Fix the issue by only resetting the counter part. | ||||
| CVE-2024-38575 | 1 Redhat | 1 Enterprise Linux | 2024-08-02 | 4.4 Medium |
| In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: pcie: handle randbuf allocation failure The kzalloc() in brcmf_pcie_download_fw_nvram() will return null if the physical memory has run out. As a result, if we use get_random_bytes() to generate random bytes in the randbuf, the null pointer dereference bug will happen. In order to prevent allocation failure, this patch adds a separate function using buffer on kernel stack to generate random bytes in the randbuf, which could prevent the kernel stack from overflow. | ||||
| CVE-2024-38564 | 1 Redhat | 3 Rhel Aus, Rhel E4s, Rhel Tus | 2024-08-02 | 4.4 Medium |
| In the Linux kernel, the following vulnerability has been resolved: bpf: Add BPF_PROG_TYPE_CGROUP_SKB attach type enforcement in BPF_LINK_CREATE bpf_prog_attach uses attach_type_to_prog_type to enforce proper attach type for BPF_PROG_TYPE_CGROUP_SKB. link_create uses bpf_prog_get and relies on bpf_prog_attach_check_attach_type to properly verify prog_type <> attach_type association. Add missing attach_type enforcement for the link_create case. Otherwise, it's currently possible to attach cgroup_skb prog types to other cgroup hooks. | ||||