Total
421 CVE
| CVE | Vendors | Products | Updated | CVSS v2 | CVSS v3 |
|---|---|---|---|---|---|
| CVE-2024-50184 | 1 Linux | 1 Linux Kernel | 2024-12-09 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: virtio_pmem: Check device status before requesting flush If a pmem device is in a bad status, the driver side could wait for host ack forever in virtio_pmem_flush(), causing the system to hang. So add a status check in the beginning of virtio_pmem_flush() to return early if the device is not activated. | |||||
| CVE-2024-53432 | 2024-12-04 | N/A | 7.5 HIGH | ||
| While parsing certain malformed PLY files, PCL version 1.14.1 crashes due to an uncaught std::out_of_range exception in PCLPointCloud2::at. This issue could potentially be exploited to cause a denial-of-service (DoS) attack when processing untrusted PLY files. | |||||
| CVE-2024-50196 | 1 Linux | 1 Linux Kernel | 2024-11-29 | N/A | 5.5 MEDIUM |
| 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 ``` | |||||
| CVE-2024-50195 | 1 Linux | 1 Linux Kernel | 2024-11-29 | N/A | 5.5 MEDIUM |
| 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. | |||||
| CVE-2023-41993 | 6 Apple, Debian, Fedoraproject and 3 more | 14 Ipados, Iphone Os, Macos and 11 more | 2024-11-29 | N/A | 8.8 HIGH |
| The issue was addressed with improved checks. This issue is fixed in macOS Sonoma 14. Processing web content may lead to arbitrary code execution. Apple is aware of a report that this issue may have been actively exploited against versions of iOS before iOS 16.7. | |||||
| CVE-2024-11599 | 2024-11-28 | N/A | 8.2 HIGH | ||
| Mattermost versions 10.0.x <= 10.0.1, 10.1.x <= 10.1.1, 9.11.x <= 9.11.3, 9.5.x <= 9.5.11 fail to properly validate email addresses which allows an unauthenticated user to bypass email domain restrictions via carefully crafted input on email registration. | |||||
| CVE-2023-37303 | 1 Mediawiki | 1 Mediawiki | 2024-11-27 | N/A | 9.8 CRITICAL |
| An issue was discovered in the CheckUser extension for MediaWiki through 1.39.3. In certain situations, an attempt to block a user fails after a temporary browser hang and a DBQueryDisconnectedError error message. | |||||
| CVE-2024-50284 | 1 Linux | 1 Linux Kernel | 2024-11-27 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: ksmbd: Fix the missing xa_store error check xa_store() can fail, it return xa_err(-EINVAL) if the entry cannot be stored in an XArray, or xa_err(-ENOMEM) if memory allocation failed, so check error for xa_store() to fix it. | |||||
| CVE-2024-9124 | 2024-11-21 | N/A | N/A | ||
| A denial-of-service vulnerability exists in the Rockwell Automation PowerFlex® 600T. If the device is overloaded with requests, it will become unavailable. The device may require a power cycle to recover it if it does not re-establish a connection after it stops receiving requests. | |||||
| CVE-2024-5469 | 1 Gitlab | 1 Gitlab | 2024-11-21 | N/A | 3.1 LOW |
| DoS in KAS in GitLab CE/EE affecting all versions from 16.10.0 prior to 16.10.6 and 16.11.0 prior to 16.11.3 allows an attacker to crash KAS via crafted gRPC requests. | |||||
| CVE-2024-42224 | 1 Linux | 1 Linux Kernel | 2024-11-21 | N/A | 6.1 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: net: dsa: mv88e6xxx: Correct check for empty list Since commit a3c53be55c95 ("net: dsa: mv88e6xxx: Support multiple MDIO busses") mv88e6xxx_default_mdio_bus() has checked that the return value of list_first_entry() is non-NULL. This appears to be intended to guard against the list chip->mdios being empty. However, it is not the correct check as the implementation of list_first_entry is not designed to return NULL for empty lists. Instead, use list_first_entry_or_null() which does return NULL if the list is empty. Flagged by Smatch. Compile tested only. | |||||
| CVE-2024-42162 | 1 Linux | 1 Linux Kernel | 2024-11-21 | N/A | 7.0 HIGH |
| In the Linux kernel, the following vulnerability has been resolved: gve: Account for stopped queues when reading NIC stats We now account for the fact that the NIC might send us stats for a subset of queues. Without this change, gve_get_ethtool_stats might make an invalid access on the priv->stats_report->stats array. | |||||
| CVE-2024-42159 | 1 Linux | 1 Linux Kernel | 2024-11-21 | N/A | 7.8 HIGH |
| In the Linux kernel, the following vulnerability has been resolved: scsi: mpi3mr: Sanitise num_phys Information is stored in mr_sas_port->phy_mask, values larger then size of this field shouldn't be allowed. | |||||
| CVE-2024-42154 | 1 Linux | 1 Linux Kernel | 2024-11-21 | N/A | 4.4 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: tcp_metrics: validate source addr length I don't see anything checking that TCP_METRICS_ATTR_SADDR_IPV4 is at least 4 bytes long, and the policy doesn't have an entry for this attribute at all (neither does it for IPv6 but v6 is manually validated). | |||||
| CVE-2024-39869 | 1 Siemens | 1 Sinema Remote Connect Server | 2024-11-21 | N/A | 6.5 MEDIUM |
| A vulnerability has been identified in SINEMA Remote Connect Server (All versions < V3.2 SP1). Affected products allow to upload certificates. An authenticated attacker could upload a crafted certificates leading to a permanent denial-of-service situation. In order to recover from such an attack, the offending certificate needs to be removed manually. | |||||
| CVE-2024-39545 | 2024-11-21 | N/A | 7.5 HIGH | ||
| An Improper Check for Unusual or Exceptional Conditions vulnerability in the the IKE daemon (iked) of Juniper Networks Junos OS on SRX Series, MX Series with SPC3 and NFX350 allows allows an unauthenticated, network-based attacker sending specific mismatching parameters as part of the IPsec negotiation to trigger an iked crash leading to Denial of Service (DoS). This issue is applicable to all platforms that run iked. This issue affects Junos OS on SRX Series, MX Series with SPC3 and NFX350: * All versions before 21.2R3-S8, * from 21.4 before 21.4R3-S7, * from 22.1 before 22.1R3-S2, * from 22.2 before 22.2R3-S1, * from 22.3 before 22.3R2-S1, 22.3R3, * from 22.4 before 22.4R1-S2, 22.4R2, 22.4R3. | |||||
| CVE-2024-39535 | 2024-11-21 | N/A | 6.5 MEDIUM | ||
| An Improper Check for Unusual or Exceptional Conditions vulnerability in the Packet Forwarding Engine (PFE) of Juniper Networks Junos OS Evolved on ACX 7000 Series allows an unauthenticated, adjacent attacker to cause a Denial-of-Service (DoS). When a device has a Layer 3 or an IRB interface configured in a VPLS instance and specific traffic is received, the evo-pfemand processes crashes which causes a service outage for the respective FPC until the system is recovered manually. This issue only affects Junos OS Evolved 22.4R2-S1 and 22.4R2-S2 releases and is fixed in 22.4R3. No other releases are affected. | |||||
| CVE-2024-39530 | 1 Juniper | 1 Junos | 2024-11-21 | N/A | 7.5 HIGH |
| An Improper Check for Unusual or Exceptional Conditions vulnerability in the chassis management daemon (chassisd) of Juniper Networks Junos OS allows an unauthenticated, network-based attacker to cause a Denial-of-Service (DoS). If an attempt is made to access specific sensors on platforms not supporting these sensors, either via GRPC or netconf, chassisd will crash and restart leading to a restart of all FPCs and thereby a complete outage. This issue affects Junos OS: * 21.4 versions from 21.4R3 before 21.4R3-S5, * 22.1 versions from 22.1R3 before 22.1R3-S4, * 22.2 versions from 22.2R2 before 22.2R3, * 22.3 versions from 22.3R1 before 22.3R2-S2, 22.3R3, * 22.4 versions from 22.4R1 before 22.4R2. This issue does not affect Junos OS versions earlier than 21.4. | |||||
| CVE-2024-39519 | 1 Juniper | 8 Acx7024, Acx7024x, Acx7100-32c and 5 more | 2024-11-21 | N/A | 6.5 MEDIUM |
| An Improper Check for Unusual or Exceptional Conditions vulnerability in the Packet Forwarding Engine (PFE) of Juniper Networks Junos OS Evolved on ACX7000 Series allows an unauthenticated, adjacent attacker to cause a Denial-of-Service (DoS). On all ACX 7000 Series platforms running Junos OS Evolved, and configured with IRBs, if a Customer Edge device (CE) device is dual homed to two Provider Edge devices (PE) a traffic loop will occur when the CE sends multicast packets. This issue can be triggered by IPv4 and IPv6 traffic. This issue affects Junos OS Evolved: All versions from 22.2R1-EVO and later versions before 22.4R2-EVO, This issue does not affect Junos OS Evolved versions before 22.1R1-EVO. | |||||
| CVE-2024-38461 | 1 Irods | 1 Irods | 2024-11-21 | N/A | 7.5 HIGH |
| irodsServerMonPerf in iRODS before 4.3.2 attempts to proceed with use of a path even if it is not a directory. | |||||