Vulnerabilities (CVE)

Total 271657 CVE
CVE Vendors Products Updated CVSS v2 CVSS v3
CVE-2020-36830 1 Nescalante 1 Urlregex 2024-09-05 4.0 MEDIUM 7.5 HIGH
A vulnerability was found in nescalante urlregex up to 0.5.0 and classified as problematic. This issue affects some unknown processing of the file index.js of the component Backtracking. The manipulation leads to inefficient regular expression complexity. The attack may be initiated remotely. The exploit has been disclosed to the public and may be used. Upgrading to version 0.5.1 is able to address this issue. The identifier of the patch is e5a085afe6abfaea1d1a78f54c45af9ef43ca1f9. It is recommended to upgrade the affected component.
CVE-2024-38402 1 Qualcomm 336 Ar8035, Ar8035 Firmware, Csra6620 and 333 more 2024-09-05 N/A 7.8 HIGH
Memory corruption while processing IOCTL call for getting group info.
CVE-2024-45692 2 Virtualmin, Webmin 2 Virtualmin, Webmin 2024-09-05 N/A 7.5 HIGH
Webmin before 2.202 and Virtualmin before 7.20.2 allow a network traffic loop via spoofed UDP packets on port 10000.
CVE-2024-42416 1 Freebsd 1 Freebsd 2024-09-05 N/A 8.8 HIGH
The ctl_report_supported_opcodes function did not sufficiently validate a field provided by userspace, allowing an arbitrary write to a limited amount of kernel help memory. Malicious software running in a guest VM that exposes virtio_scsi can exploit the vulnerabilities to achieve code execution on the host in the bhyve userspace process, which typically runs as root. Note that bhyve runs in a Capsicum sandbox, so malicious code is constrained by the capabilities available to the bhyve process. A malicious iSCSI initiator could achieve remote code execution on the iSCSI target host.
CVE-2024-43110 1 Freebsd 1 Freebsd 2024-09-05 N/A 8.8 HIGH
The ctl_request_sense function could expose up to three bytes of the kernel heap to userspace. Malicious software running in a guest VM that exposes virtio_scsi can exploit the vulnerabilities to achieve code execution on the host in the bhyve userspace process, which typically runs as root. Note that bhyve runs in a Capsicum sandbox, so malicious code is constrained by the capabilities available to the bhyve process. A malicious iSCSI initiator could achieve remote code execution on the iSCSI target host.
CVE-2024-36068 1 Rubrik 1 Cloud Data Management 2024-09-05 N/A 9.8 CRITICAL
An incorrect access control vulnerability in Rubrik CDM versions prior to 9.1.2-p1, 9.0.3-p6 and 8.1.3-p12, allows an attacker with network access to execute arbitrary code.
CVE-2024-41879 2 Adobe, Microsoft 2 Acrobat Reader, Edge 2024-09-05 N/A 7.8 HIGH
Acrobat Reader versions 127.0.2651.105 and earlier are affected by an out-of-bounds write vulnerability that could result in arbitrary code execution in the context of the current user. Exploitation of this issue requires user interaction in that a victim must open a malicious file.
CVE-2024-43887 1 Linux 1 Linux Kernel 2024-09-05 N/A 4.7 MEDIUM
In the Linux kernel, the following vulnerability has been resolved: net/tcp: Disable TCP-AO static key after RCU grace period The lifetime of TCP-AO static_key is the same as the last tcp_ao_info. On the socket destruction tcp_ao_info ceases to be with RCU grace period, while tcp-ao static branch is currently deferred destructed. The static key definition is : DEFINE_STATIC_KEY_DEFERRED_FALSE(tcp_ao_needed, HZ); which means that if RCU grace period is delayed by more than a second and tcp_ao_needed is in the process of disablement, other CPUs may yet see tcp_ao_info which atent dead, but soon-to-be. And that breaks the assumption of static_key_fast_inc_not_disabled(). See the comment near the definition: > * The caller must make sure that the static key can't get disabled while > * in this function. It doesn't patch jump labels, only adds a user to > * an already enabled static key. Originally it was introduced in commit eb8c507296f6 ("jump_label: Prevent key->enabled int overflow"), which is needed for the atomic contexts, one of which would be the creation of a full socket from a request socket. In that atomic context, it's known by the presence of the key (md5/ao) that the static branch is already enabled. So, the ref counter for that static branch is just incremented instead of holding the proper mutex. static_key_fast_inc_not_disabled() is just a helper for such usage case. But it must not be used if the static branch could get disabled in parallel as it's not protected by jump_label_mutex and as a result, races with jump_label_update() implementation details. Happened on netdev test-bot[1], so not a theoretical issue: [] jump_label: Fatal kernel bug, unexpected op at tcp_inbound_hash+0x1a7/0x870 [ffffffffa8c4e9b7] (eb 50 0f 1f 44 != 66 90 0f 1f 00)) size:2 type:1 [] ------------[ cut here ]------------ [] kernel BUG at arch/x86/kernel/jump_label.c:73! [] Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN NOPTI [] CPU: 3 PID: 243 Comm: kworker/3:3 Not tainted 6.10.0-virtme #1 [] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 [] Workqueue: events jump_label_update_timeout [] RIP: 0010:__jump_label_patch+0x2f6/0x350 ... [] Call Trace: [] <TASK> [] arch_jump_label_transform_queue+0x6c/0x110 [] __jump_label_update+0xef/0x350 [] __static_key_slow_dec_cpuslocked.part.0+0x3c/0x60 [] jump_label_update_timeout+0x2c/0x40 [] process_one_work+0xe3b/0x1670 [] worker_thread+0x587/0xce0 [] kthread+0x28a/0x350 [] ret_from_fork+0x31/0x70 [] ret_from_fork_asm+0x1a/0x30 [] </TASK> [] Modules linked in: veth [] ---[ end trace 0000000000000000 ]--- [] RIP: 0010:__jump_label_patch+0x2f6/0x350 [1]: https://netdev-3.bots.linux.dev/vmksft-tcp-ao-dbg/results/696681/5-connect-deny-ipv6/stderr
CVE-2024-37136 1 Dell 1 Path To Powerprotect 2024-09-05 N/A 4.9 MEDIUM
Dell Path to PowerProtect, versions 1.1, 1.2, contains an Exposure of Private Personal Information to an Unauthorized Actor vulnerability. A remote high privileged attacker could potentially exploit this vulnerability, leading to information exposure.
CVE-2024-43890 1 Linux 1 Linux Kernel 2024-09-05 N/A 5.5 MEDIUM
In the Linux kernel, the following vulnerability has been resolved: tracing: Fix overflow in get_free_elt() "tracing_map->next_elt" in get_free_elt() is at risk of overflowing. Once it overflows, new elements can still be inserted into the tracing_map even though the maximum number of elements (`max_elts`) has been reached. Continuing to insert elements after the overflow could result in the tracing_map containing "tracing_map->max_size" elements, leaving no empty entries. If any attempt is made to insert an element into a full tracing_map using `__tracing_map_insert()`, it will cause an infinite loop with preemption disabled, leading to a CPU hang problem. Fix this by preventing any further increments to "tracing_map->next_elt" once it reaches "tracing_map->max_elt".
CVE-2024-43891 1 Linux 1 Linux Kernel 2024-09-05 N/A 4.7 MEDIUM
In the Linux kernel, the following vulnerability has been resolved: tracing: Have format file honor EVENT_FILE_FL_FREED When eventfs was introduced, special care had to be done to coordinate the freeing of the file meta data with the files that are exposed to user space. The file meta data would have a ref count that is set when the file is created and would be decremented and freed after the last user that opened the file closed it. When the file meta data was to be freed, it would set a flag (EVENT_FILE_FL_FREED) to denote that the file is freed, and any new references made (like new opens or reads) would fail as it is marked freed. This allowed other meta data to be freed after this flag was set (under the event_mutex). All the files that were dynamically created in the events directory had a pointer to the file meta data and would call event_release() when the last reference to the user space file was closed. This would be the time that it is safe to free the file meta data. A shortcut was made for the "format" file. It's i_private would point to the "call" entry directly and not point to the file's meta data. This is because all format files are the same for the same "call", so it was thought there was no reason to differentiate them. The other files maintain state (like the "enable", "trigger", etc). But this meant if the file were to disappear, the "format" file would be unaware of it. This caused a race that could be trigger via the user_events test (that would create dynamic events and free them), and running a loop that would read the user_events format files: In one console run: # cd tools/testing/selftests/user_events # while true; do ./ftrace_test; done And in another console run: # cd /sys/kernel/tracing/ # while true; do cat events/user_events/__test_event/format; done 2>/dev/null With KASAN memory checking, it would trigger a use-after-free bug report (which was a real bug). This was because the format file was not checking the file's meta data flag "EVENT_FILE_FL_FREED", so it would access the event that the file meta data pointed to after the event was freed. After inspection, there are other locations that were found to not check the EVENT_FILE_FL_FREED flag when accessing the trace_event_file. Add a new helper function: event_file_file() that will make sure that the event_mutex is held, and will return NULL if the trace_event_file has the EVENT_FILE_FL_FREED flag set. Have the first reference of the struct file pointer use event_file_file() and check for NULL. Later uses can still use the event_file_data() helper function if the event_mutex is still held and was not released since the event_file_file() call.
CVE-2024-8173 1 Blood Bank System Project 1 Blood Bank System 2024-09-05 7.5 HIGH 7.5 HIGH
A vulnerability, which was classified as critical, was found in code-projects Blood Bank System 1.0. Affected is an unknown function of the file /login.php of the component Login Page. The manipulation of the argument user leads to sql injection. It is possible to launch the attack remotely. The exploit has been disclosed to the public and may be used.
CVE-2024-43896 1 Linux 1 Linux Kernel 2024-09-05 N/A 5.5 MEDIUM
In the Linux kernel, the following vulnerability has been resolved: ASoC: cs-amp-lib: Fix NULL pointer crash if efi.get_variable is NULL Call efi_rt_services_supported() to check that efi.get_variable exists before calling it.
CVE-2024-41444 1 Seacms 1 Seacms 2024-09-05 N/A 9.8 CRITICAL
SeaCMS v12.9 has a SQL injection vulnerability in the key parameter of /js/player/dmplayer/dmku/index.php?ac=so.
CVE-2024-42790 1 Lopalopa 1 Music Management System 2024-09-05 N/A 5.4 MEDIUM
A Reflected Cross Site Scripting (XSS) vulnerability was found in "/music/index.php?page=test" in Kashipara Music Management System v1.0. This vulnerability allows remote attackers to execute arbitrary code via the "page" parameter.
CVE-2024-42792 1 Lopalopa 1 Music Management System 2024-09-05 N/A 3.5 LOW
A Cross-Site Request Forgery (CSRF) vulnerability was found in Kashipara Music Management System v1.0 via /music/ajax.php?action=delete_playlist page.
CVE-2024-42885 2024-09-05 N/A 9.1 CRITICAL
SQL Injection vulnerability in ESAFENET CDG 5.6 and before allows an attacker to execute arbitrary code via the id parameter of the data.jsp page.
CVE-2024-7401 1 Netskope 1 Netskope 2024-09-05 N/A 7.5 HIGH
Netskope was notified about a security gap in Netskope Client enrollment process where NSClient is using a static token “Orgkey” as authentication parameter. Since this is a static token, if leaked, cannot be rotated or revoked. A malicious actor can use this token to enroll NSClient from a customer’s tenant and impersonate a user.
CVE-2024-42913 1 Ruoyi 1 Ruoyi 2024-09-05 N/A 9.8 CRITICAL
RuoYi CMS v4.7.9 was discovered to contain a SQL injection vulnerability via the job_id parameter at /sasfs1.
CVE-2024-45265 1 Skyss 1 Arfa-cms 2024-09-05 N/A 9.8 CRITICAL
A SQL injection vulnerability in the poll component in SkySystem Arfa-CMS before 5.1.3124 allows remote attackers to execute arbitrary SQL commands via the psid parameter.