CVE-2024-50198 | In the Linux kernel, the following vulnerability has been resolved: iio: light: veml6030: fix IIO device retrieval from embedded device The dev pointer that is received as an argument in the in_illuminance_period_available_show function references the device embedded in the IIO device, not in the i2c client. dev_to_iio_dev() must be used to accessthe right data. The current implementation leads to a segmentation fault on every attempt to read the attribute because indio_dev gets a NULL assignment. This bug has been present since the first appearance of the driver, apparently since the last version (V6) before getting applied. A constant attribute was used until then, and the last modifications might have not been tested again. | medium |
CVE-2024-50197 | In the Linux kernel, the following vulnerability has been resolved: pinctrl: intel: platform: fix error path in device_for_each_child_node() The device_for_each_child_node() loop requires calls to fwnode_handle_put() upon early returns to decrement the refcount of the child node and avoid leaking memory if that error path is triggered. There is one early returns within that loop in intel_platform_pinctrl_prepare_community(), but fwnode_handle_put() is missing. Instead of adding the missing call, the scoped version of the loop can be used to simplify the code and avoid mistakes in the future if new early returns are added, as the child node is only used for parsing, and it is never assigned. | medium |
CVE-2024-50196 | In the Linux kernel, the following vulnerability has been resolved: pinctrl: ocelot: fix system hang on level based interrupts The current implementation only calls chained_irq_enter() and chained_irq_exit() if it detects pending interrupts. ``` for (i = 0; i < info->stride; i++) { uregmap_read(info->map, id_reg + 4 * i, ®); if (!reg) continue; chained_irq_enter(parent_chip, desc); ``` However, in case of GPIO pin configured in level mode and the parent controller configured in edge mode, GPIO interrupt might be lowered by the hardware. In the result, if the interrupt is short enough, the parent interrupt is still pending while the GPIO interrupt is cleared; chained_irq_enter() never gets called and the system hangs trying to service the parent interrupt. Moving chained_irq_enter() and chained_irq_exit() outside the for loop ensures that they are called even when GPIO interrupt is lowered by the hardware. The similar code with chained_irq_enter() / chained_irq_exit() functions wrapping interrupt checking loop may be found in many other drivers: ``` grep -r -A 10 chained_irq_enter drivers/pinctrl ``` | medium |
CVE-2024-50195 | In the Linux kernel, the following vulnerability has been resolved: posix-clock: Fix missing timespec64 check in pc_clock_settime() As Andrew pointed out, it will make sense that the PTP core checked timespec64 struct's tv_sec and tv_nsec range before calling ptp->info->settime64(). As the man manual of clock_settime() said, if tp.tv_sec is negative or tp.tv_nsec is outside the range [0..999,999,999], it should return EINVAL, which include dynamic clocks which handles PTP clock, and the condition is consistent with timespec64_valid(). As Thomas suggested, timespec64_valid() only check the timespec is valid, but not ensure that the time is in a valid range, so check it ahead using timespec64_valid_strict() in pc_clock_settime() and return -EINVAL if not valid. There are some drivers that use tp->tv_sec and tp->tv_nsec directly to write registers without validity checks and assume that the higher layer has checked it, which is dangerous and will benefit from this, such as hclge_ptp_settime(), igb_ptp_settime_i210(), _rcar_gen4_ptp_settime(), and some drivers can remove the checks of itself. | medium |
CVE-2024-50194 | In the Linux kernel, the following vulnerability has been resolved: arm64: probes: Fix uprobes for big-endian kernels The arm64 uprobes code is broken for big-endian kernels as it doesn't convert the in-memory instruction encoding (which is always little-endian) into the kernel's native endianness before analyzing and simulating instructions. This may result in a few distinct problems: * The kernel may may erroneously reject probing an instruction which can safely be probed. * The kernel may erroneously erroneously permit stepping an instruction out-of-line when that instruction cannot be stepped out-of-line safely. * The kernel may erroneously simulate instruction incorrectly dur to interpretting the byte-swapped encoding. The endianness mismatch isn't caught by the compiler or sparse because: * The arch_uprobe::{insn,ixol} fields are encoded as arrays of u8, so the compiler and sparse have no idea these contain a little-endian 32-bit value. The core uprobes code populates these with a memcpy() which similarly does not handle endianness. * While the uprobe_opcode_t type is an alias for __le32, both arch_uprobe_analyze_insn() and arch_uprobe_skip_sstep() cast from u8[] to the similarly-named probe_opcode_t, which is an alias for u32. Hence there is no endianness conversion warning. Fix this by changing the arch_uprobe::{insn,ixol} fields to __le32 and adding the appropriate __le32_to_cpu() conversions prior to consuming the instruction encoding. The core uprobes copies these fields as opaque ranges of bytes, and so is unaffected by this change. At the same time, remove MAX_UINSN_BYTES and consistently use AARCH64_INSN_SIZE for clarity. Tested with the following: | #include <stdio.h> | #include <stdbool.h> | | #define noinline __attribute__((noinline)) | | static noinline void *adrp_self(void) | { | void *addr; | | asm volatile( | " adrp %x0, adrp_self\n" | " add %x0, %x0, :lo12:adrp_self\n" | : "=r" (addr)); | } | | | int main(int argc, char *argv) | { | void *ptr = adrp_self(); | bool equal = (ptr == adrp_self); | | printf("adrp_self => %p\n" | "adrp_self() => %p\n" | "%s\n", | adrp_self, ptr, equal ? "EQUAL" : "NOT EQUAL"); | | return 0; | } .... where the adrp_self() function was compiled to: | 00000000004007e0 <adrp_self>: | 4007e0: 90000000 adrp x0, 400000 <__ehdr_start> | 4007e4: 911f8000 add x0, x0, #0x7e0 | 4007e8: d65f03c0 ret Before this patch, the ADRP is not recognized, and is assumed to be steppable, resulting in corruption of the result: | # ./adrp-self | adrp_self => 0x4007e0 | adrp_self() => 0x4007e0 | EQUAL | # echo 'p /root/adrp-self:0x007e0' > /sys/kernel/tracing/uprobe_events | # echo 1 > /sys/kernel/tracing/events/uprobes/enable | # ./adrp-self | adrp_self => 0x4007e0 | adrp_self() => 0xffffffffff7e0 | NOT EQUAL After this patch, the ADRP is correctly recognized and simulated: | # ./adrp-self | adrp_self => 0x4007e0 | adrp_self() => 0x4007e0 | EQUAL | # | # echo 'p /root/adrp-self:0x007e0' > /sys/kernel/tracing/uprobe_events | # echo 1 > /sys/kernel/tracing/events/uprobes/enable | # ./adrp-self | adrp_self => 0x4007e0 | adrp_self() => 0x4007e0 | EQUAL | medium |
CVE-2024-50193 | In the Linux kernel, the following vulnerability has been resolved: x86/entry_32: Clear CPU buffers after register restore in NMI return CPU buffers are currently cleared after call to exc_nmi, but before register state is restored. This may be okay for MDS mitigation but not for RDFS. Because RDFS mitigation requires CPU buffers to be cleared when registers don't have any sensitive data. Move CLEAR_CPU_BUFFERS after RESTORE_ALL_NMI. | high |
CVE-2024-50192 | In the Linux kernel, the following vulnerability has been resolved: irqchip/gic-v4: Don't allow a VMOVP on a dying VPE Kunkun Jiang reported that there is a small window of opportunity for userspace to force a change of affinity for a VPE while the VPE has already been unmapped, but the corresponding doorbell interrupt still visible in /proc/irq/. Plug the race by checking the value of vmapp_count, which tracks whether the VPE is mapped ot not, and returning an error in this case. This involves making vmapp_count common to both GICv4.1 and its v4.0 ancestor. | medium |
CVE-2024-50182 | In the Linux kernel, the following vulnerability has been resolved: secretmem: disable memfd_secret() if arch cannot set direct map Return -ENOSYS from memfd_secret() syscall if !can_set_direct_map(). This is the case for example on some arm64 configurations, where marking 4k PTEs in the direct map not present can only be done if the direct map is set up at 4k granularity in the first place (as ARM's break-before-make semantics do not easily allow breaking apart large/gigantic pages). More precisely, on arm64 systems with !can_set_direct_map(), set_direct_map_invalid_noflush() is a no-op, however it returns success (0) instead of an error. This means that memfd_secret will seemingly "work" (e.g. syscall succeeds, you can mmap the fd and fault in pages), but it does not actually achieve its goal of removing its memory from the direct map. Note that with this patch, memfd_secret() will start erroring on systems where can_set_direct_map() returns false (arm64 with CONFIG_RODATA_FULL_DEFAULT_ENABLED=n, CONFIG_DEBUG_PAGEALLOC=n and CONFIG_KFENCE=n), but that still seems better than the current silent failure. Since CONFIG_RODATA_FULL_DEFAULT_ENABLED defaults to 'y', most arm64 systems actually have a working memfd_secret() and aren't be affected. From going through the iterations of the original memfd_secret patch series, it seems that disabling the syscall in these scenarios was the intended behavior [1] (preferred over having set_direct_map_invalid_noflush return an error as that would result in SIGBUSes at page-fault time), however the check for it got dropped between v16 [2] and v17 [3], when secretmem moved away from CMA allocations. [1]: https://lore.kernel.org/lkml/[email protected]/ [2]: https://lore.kernel.org/lkml/[email protected]/#t [3]: https://lore.kernel.org/lkml/[email protected]/ | medium |
CVE-2024-50181 | In the Linux kernel, the following vulnerability has been resolved: clk: imx: Remove CLK_SET_PARENT_GATE for DRAM mux for i.MX7D For i.MX7D DRAM related mux clock, the clock source change should ONLY be done done in low level asm code without accessing DRAM, and then calling clk API to sync the HW clock status with clk tree, it should never touch real clock source switch via clk API, so CLK_SET_PARENT_GATE flag should NOT be added, otherwise, DRAM's clock parent will be disabled when DRAM is active, and system will hang. | medium |
CVE-2024-50180 | In the Linux kernel, the following vulnerability has been resolved: fbdev: sisfb: Fix strbuf array overflow The values of the variables xres and yres are placed in strbuf. These variables are obtained from strbuf1. The strbuf1 array contains digit characters and a space if the array contains non-digit characters. Then, when executing sprintf(strbuf, "%ux%ux8", xres, yres); more than 16 bytes will be written to strbuf. It is suggested to increase the size of the strbuf array to 24. Found by Linux Verification Center (linuxtesting.org) with SVACE. | high |
CVE-2024-50179 | In the Linux kernel, the following vulnerability has been resolved: ceph: remove the incorrect Fw reference check when dirtying pages When doing the direct-io reads it will also try to mark pages dirty, but for the read path it won't hold the Fw caps and there is case will it get the Fw reference. | medium |
CVE-2024-49806 | IBM Security Verify Access Appliance 10.0.0 through 10.0.8 contains hard-coded credentials, such as a password or cryptographic key, which it uses for its own inbound authentication, outbound communication to external components, or encryption of internal data. | critical |
CVE-2024-49805 | IBM Security Verify Access Appliance 10.0.0 through 10.0.8 contains hard-coded credentials, such as a password or cryptographic key, which it uses for its own inbound authentication, outbound communication to external components, or encryption of internal data. | critical |
CVE-2024-49804 | IBM Security Verify Access Appliance 10.0.0 through 10.0.8 could allow a locally authenticated non-administrative user to escalate their privileges due to unnecessary permissions used to perform certain tasks. | high |
CVE-2024-49803 | IBM Security Verify Access Appliance 10.0.0 through 10.0.8 could allow a remote authenticated attacker to execute arbitrary commands on the system by sending a specially crafted request. | critical |
CVE-2024-49360 | Sandboxie is a sandbox-based isolation software for 32-bit and 64-bit Windows NT-based operating systems. An authenticated user (**UserA**) with no privileges is authorized to read all files created in sandbox belonging to other users in the sandbox folders `C:\Sandbox\UserB\xxx`. An authenticated attacker who can use `explorer.exe` or `cmd.exe` outside any sandbox can read other users' files in `C:\Sandbox\xxx`. By default in Windows 7+, the `C:\Users\UserA` folder is not readable by **UserB**. All files edited or created during the sandbox processing are affected by the vulnerability. All files in C:\Users are safe. If `UserB` runs a cmd in a sandbox, he will be able to access `C:\Sandox\UserA`. In addition, if **UserB** create a folder `C:\Sandbox\UserA` with malicious ACLs, when **UserA** will user the sandbox, Sandboxie doesn't reset ACLs ! This issue has not yet been fixed. Users are advised to limit access to their systems using Sandboxie. | critical |
CVE-2024-48651 | In ProFTPD through 1.3.8b before cec01cc, supplemental group inheritance grants unintended access to GID 0 because of the lack of supplemental groups from mod_sql. | high |
CVE-2024-48406 | Buffer Overflow vulnerability in SunBK201 umicat through v.0.3.2 and fixed in v.0.3.3 allows an attacker to execute arbitrary code via the power(uct_int_t x, uct_int_t n) in src/uct_upstream.c. | critical |
CVE-2024-47257 | Florent Thiéry has found that selected Axis devices were vulnerable to handling certain ethernet frames which could lead to the Axis device becoming unavailable in the network. Axis has released patched AXIS OS versions for the highlighted flaw for products that are still under AXIS OS software support. Please refer to the Axis security advisory for more information and solution. | high |
CVE-2024-47193 | WithSecure Elements Agent for Mac before 24.3, MDR before 24.3, and Elements Client Security for Mac before 16.10 allow a remote Denial of Service. | medium |
CVE-2024-47094 | Insertion of Sensitive Information into Log File in Checkmk GmbH's Checkmk versions <2.3.0p22, <2.2.0p37, <2.1.0p50 (EOL) causes remote site secrets to be written to web log files accessible to local site users. | medium |
CVE-2024-45495 | MSA FieldServer Gateway 5.0.0 through 6.5.2 allows cross-origin WebSocket hijacking. | high |
CVE-2024-44309 | A cookie management issue was addressed with improved state management. This issue is fixed in Safari 18.1.1, iOS 17.7.2 and iPadOS 17.7.2, macOS Sequoia 15.1.1, iOS 18.1.1 and iPadOS 18.1.1, visionOS 2.1.1. Processing maliciously crafted web content may lead to a cross site scripting attack. Apple is aware of a report that this issue may have been actively exploited on Intel-based Mac systems. | medium |
CVE-2024-41957 | Vim is an open source command line text editor. Vim < v9.1.0647 has double free in src/alloc.c:616. When closing a window, the corresponding tagstack data will be cleared and freed. However a bit later, the quickfix list belonging to that window will also be cleared and if that quickfix list points to the same tagstack data, Vim will try to free it again, resulting in a double-free/use-after-free access exception. Impact is low since the user must intentionally execute vim with several non-default flags, but it may cause a crash of Vim. The issue has been fixed as of Vim patch v9.1.0647 | medium |
CVE-2024-39460 | Jenkins Bitbucket Branch Source Plugin 886.v44cf5e4ecec5 and earlier prints the Bitbucket OAuth access token as part of the Bitbucket URL in the build log in some cases. | medium |
CVE-2024-39162 | pyspider through 0.3.10 allows /update XSS. NOTE: This vulnerability only affects products that are no longer supported by the maintainer | medium |
CVE-2024-38820 | The fix for CVE-2022-22968 made disallowedFields patterns in DataBinder case insensitive. However, String.toLowerCase() has some Locale dependent exceptions that could potentially result in fields not protected as expected. | medium |
CVE-2024-38658 | There is an Out-of-bounds read vulnerability in V-Server (v4.0.19.0 and earlier) and V-Server Lite (v4.0.19.0 and earlier). If a user opens a specially crafted file, information may be disclosed and/or arbitrary code may be executed. | high |
CVE-2024-38389 | There is an Out-of-bounds read vulnerability in TELLUS (v4.0.19.0 and earlier) and TELLUS Lite (v4.0.19.0 and earlier). If a user opens a specially crafted file, information may be disclosed and/or arbitrary code may be executed. | high |
CVE-2024-38309 | There are multiple stack-based buffer overflow vulnerabilities in V-SFT (v6.2.2.0 and earlier), TELLUS (v4.0.19.0 and earlier), and TELLUS Lite (v4.0.19.0 and earlier). If a user opens a specially crafted file, information may be disclosed and/or arbitrary code may be executed. | high |
CVE-2024-3703 | The Carousel Slider WordPress plugin before 2.2.10 does not validate and escape some of its Slide options before outputting them back in the page/post where the related Slide shortcode is embed, which could allow users with the Editor role and above to perform Stored Cross-Site Scripting attacks | medium |
CVE-2024-36671 | nodemcu before v3.0.0-release_20240225 was discovered to contain an integer overflow via the getnum function at /modules/struct.c. | critical |
CVE-2024-36626 | In prestashop 8.1.4, a NULL pointer dereference was identified in the math_round function within Tools.php. | medium |
CVE-2024-36625 | Zulip 8.3 is vulnerable to Cross Site Scripting (XSS) via the replace_emoji_with_text function in ui_util.ts. | medium |
CVE-2024-36624 | Zulip 8.3 is vulnerable to Cross Site Scripting (XSS) via the construct_copy_div function in copy_and_paste.js. | medium |
CVE-2024-36623 | moby v25.0.3 has a Race Condition vulnerability in the streamformatter package which can be used to trigger multiple concurrent write operations resulting in data corruption or application crashes. | high |
CVE-2024-36622 | In RaspAP raspap-webgui 3.0.9 and earlier, a command injection vulnerability exists in the clearlog.php script. The vulnerability is due to improper sanitization of user input passed via the logfile parameter. | critical |
CVE-2024-36621 | moby v25.0.5 is affected by a Race Condition in builder/builder-next/adapters/snapshot/layer.go. The vulnerability could be used to trigger concurrent builds that call the EnsureLayer function resulting in resource leaks/exhaustion. | medium |
CVE-2024-36620 | moby v25.0.0 - v26.0.2 is vulnerable to NULL Pointer Dereference via daemon/images/image_history.go. | high |
CVE-2024-36619 | FFmpeg n6.1.1 has a vulnerability in the WAVARC decoder of the libavcodec library which allows for an integer overflow when handling certain block types, leading to a denial-of-service (DoS) condition. | medium |
CVE-2024-36618 | FFmpeg n6.1.1 has a vulnerability in the AVI demuxer of the libavformat library which allows for an integer overflow, potentially resulting in a denial-of-service (DoS) condition. | high |
CVE-2024-36617 | FFmpeg n6.1.1 has an integer overflow vulnerability in the FFmpeg CAF decoder. | high |
CVE-2024-36616 | An integer overflow in the component /libavformat/westwood_vqa.c of FFmpeg n6.1.1 allows attackers to cause a denial of service in the application via a crafted VQA file. | medium |
CVE-2024-36615 | FFmpeg n7.0 has a race condition vulnerability in the VP9 decoder. This could lead to a data race if video encoding parameters were being exported, as the side data would be attached in the decoder thread while being read in the output thread. | medium |
CVE-2024-36612 | Zulip from 8.0 to 8.3 contains a memory leak vulnerability in the handling of popovers. | high |
CVE-2024-36611 | In Symfony v7.07, a security vulnerability was identified in the FormLoginAuthenticator component, where it failed to adequately handle cases where the username or password field of a login request is empty. This flaw could lead to various security risks, including improper authentication logic handling or denial of service. | high |
CVE-2024-36610 | A deserialization vulnerability exists in the Stub class of the VarDumper module in Symfony v7.0.3. The vulnerability stems from deficiencies in the original implementation when handling properties with null or uninitialized values. An attacker could construct specific serialized data and use this vulnerability to execute unauthorized code. | critical |
CVE-2024-36401 | GeoServer is an open source server that allows users to share and edit geospatial data. Prior to versions 2.23.6, 2.24.4, and 2.25.2, multiple OGC request parameters allow Remote Code Execution (RCE) by unauthenticated users through specially crafted input against a default GeoServer installation due to unsafely evaluating property names as XPath expressions. The GeoTools library API that GeoServer calls evaluates property/attribute names for feature types in a way that unsafely passes them to the commons-jxpath library which can execute arbitrary code when evaluating XPath expressions. This XPath evaluation is intended to be used only by complex feature types (i.e., Application Schema data stores) but is incorrectly being applied to simple feature types as well which makes this vulnerability apply to **ALL** GeoServer instances. No public PoC is provided but this vulnerability has been confirmed to be exploitable through WFS GetFeature, WFS GetPropertyValue, WMS GetMap, WMS GetFeatureInfo, WMS GetLegendGraphic and WPS Execute requests. This vulnerability can lead to executing arbitrary code. Versions 2.23.6, 2.24.4, and 2.25.2 contain a patch for the issue. A workaround exists by removing the `gt-complex-x.y.jar` file from the GeoServer where `x.y` is the GeoTools version (e.g., `gt-complex-31.1.jar` if running GeoServer 2.25.1). This will remove the vulnerable code from GeoServer but may break some GeoServer functionality or prevent GeoServer from deploying if the gt-complex module is needed. | critical |
CVE-2024-35451 | LinkStack 2.7.9 through 4.7.7 allows resources\views\components\favicon.blade.php link SSRF. | critical |
CVE-2024-35371 | Ant-Media-Serverv2.8.2 is affected by Improper Output Neutralization for Logs. The vulnerability stems from insufficient input sanitization in the logging mechanism. Without proper filtering or validation, user-controllable data, such as identifiers or other sensitive information, can be included in log entries without restrictions. | high |