| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| A privacy issue was addressed with improved private data redaction for log entries. This issue is fixed in iOS 16.7.5 and iPadOS 16.7.5, watchOS 10.2, macOS Ventura 13.6.4, macOS Sonoma 14.2, macOS Monterey 12.7.3, iOS 17.2 and iPadOS 17.2. An app may be able to access sensitive user data. |
| An authentication issue was addressed with improved state management. This issue is fixed in macOS Ventura 13.6.4. A local attacker may be able to view the previous logged in user’s desktop from the fast user switching screen. |
| The issue was addressed with improved checks. This issue is fixed in iOS 16.7.5 and iPadOS 16.7.5, watchOS 10.2, macOS Ventura 13.6.4, macOS Sonoma 14.2, macOS Monterey 12.7.3, iOS 17.2 and iPadOS 17.2. Processing a maliciously crafted image may result in disclosure of process memory. |
| An access issue was addressed with additional sandbox restrictions. This issue is fixed in macOS Ventura 13.6.4, macOS Sonoma 14.2. An app may be able to read arbitrary files. |
| Processing of user-defined mail search expressions is not limited. Availability of OX App Suite could be reduced due to high processing load. Please deploy the provided updates and patch releases. Processing time of mail search expressions now gets monitored, and the related request is terminated if a resource threshold is reached.
No publicly available exploits are known. |
| Processing time of drive search expressions now gets monitored, and the related request is terminated if a resource threshold is reached. Availability of OX App Suite could be reduced due to high processing load. Please deploy the provided updates and patch releases. Processing of user-defined drive search expressions is not limited No publicly available exploits are known. |
| Processing of user-defined DAV user-agent strings is not limited. Availability of OX App Suite could be reduced due to high processing load. Please deploy the provided updates and patch releases. Processing time of DAV user-agents now gets monitored, and the related request is terminated if a resource threshold is reached. No publicly available exploits are known. |
| This issue was addressed by removing the vulnerable code. This issue is fixed in tvOS 17, watchOS 10, macOS Sonoma 14, iOS 17 and iPadOS 17, macOS Ventura 13.6.4. An app may be able to bypass Privacy preferences. |
| The issue was addressed with improved restriction of data container access. This issue is fixed in macOS Ventura 13.6.5, macOS Monterey 12.7.4. An app may be able to access sensitive user data. |
| In GNU tar before 1.35, mishandled extension attributes in a PAX archive can lead to an application crash in xheader.c. |
| Multilaser RE160 v5.07.51_pt_MTL01 and v5.07.52_pt_MTL01, Multilaser RE160V v12.03.01.08_pt and V12.03.01.09_pt, and Multilaser RE163V v12.03.01.08_pt allows attackers to bypass the access control and gain complete access to the application via supplying a crafted URL. |
| Pandoc before 3.1.6 allows arbitrary file write: this can be triggered by providing a crafted image element in the input when generating files via the --extract-media option or outputting to PDF format. This allows an attacker to create or overwrite arbitrary files, depending on the privileges of the process running Pandoc. It only affects systems that pass untrusted user input to Pandoc and allow Pandoc to be used to produce a PDF or with the --extract-media option. NOTE: this issue exists because of an incomplete fix for CVE-2023-35936 (failure to properly account for double encoded path names). |
| ascii_load_sockaddr in smtpd in OpenBSD before 7.1 errata 024 and 7.2 before errata 020, and OpenSMTPD Portable before 7.0.0-portable commit f748277, can abort upon a connection from a local, scoped IPv6 address. |
| This issue was addressed with improved redaction of sensitive information. This issue is fixed in iOS 16.7.6 and iPadOS 16.7.6, macOS Monterey 12.7.4, macOS Sonoma 14.1, macOS Ventura 13.6.5. An app may be able to access sensitive user data. |
| In PHP version 8.1.* before 8.1.28, 8.2.* before 8.2.18, 8.3.* before 8.3.5, if a password stored with password_hash() starts with a null byte (\x00), testing a blank string as the password via password_verify() will incorrectly return true. |
| In the Linux kernel, the following vulnerability has been resolved:
drm/mediatek: Add 0 size check to mtk_drm_gem_obj
Add a check to mtk_drm_gem_init if we attempt to allocate a GEM object
of 0 bytes. Currently, no such check exists and the kernel will panic if
a userspace application attempts to allocate a 0x0 GBM buffer.
Tested by attempting to allocate a 0x0 GBM buffer on an MT8188 and
verifying that we now return EINVAL. |
| In the Linux kernel, the following vulnerability has been resolved:
genirq/cpuhotplug, x86/vector: Prevent vector leak during CPU offline
The absence of IRQD_MOVE_PCNTXT prevents immediate effectiveness of
interrupt affinity reconfiguration via procfs. Instead, the change is
deferred until the next instance of the interrupt being triggered on the
original CPU.
When the interrupt next triggers on the original CPU, the new affinity is
enforced within __irq_move_irq(). A vector is allocated from the new CPU,
but the old vector on the original CPU remains and is not immediately
reclaimed. Instead, apicd->move_in_progress is flagged, and the reclaiming
process is delayed until the next trigger of the interrupt on the new CPU.
Upon the subsequent triggering of the interrupt on the new CPU,
irq_complete_move() adds a task to the old CPU's vector_cleanup list if it
remains online. Subsequently, the timer on the old CPU iterates over its
vector_cleanup list, reclaiming old vectors.
However, a rare scenario arises if the old CPU is outgoing before the
interrupt triggers again on the new CPU.
In that case irq_force_complete_move() is not invoked on the outgoing CPU
to reclaim the old apicd->prev_vector because the interrupt isn't currently
affine to the outgoing CPU, and irq_needs_fixup() returns false. Even
though __vector_schedule_cleanup() is later called on the new CPU, it
doesn't reclaim apicd->prev_vector; instead, it simply resets both
apicd->move_in_progress and apicd->prev_vector to 0.
As a result, the vector remains unreclaimed in vector_matrix, leading to a
CPU vector leak.
To address this issue, move the invocation of irq_force_complete_move()
before the irq_needs_fixup() call to reclaim apicd->prev_vector, if the
interrupt is currently or used to be affine to the outgoing CPU.
Additionally, reclaim the vector in __vector_schedule_cleanup() as well,
following a warning message, although theoretically it should never see
apicd->move_in_progress with apicd->prev_cpu pointing to an offline CPU. |
| In PHP 8.3.* before 8.3.5, function mb_encode_mimeheader() runs endlessly for some inputs that contain long strings of non-space characters followed by a space. This could lead to a potential DoS attack if a hostile user sends data to an application that uses this function. |
| In the Linux kernel, the following vulnerability has been resolved:
netfilter: flowtable: incorrect pppoe tuple
pppoe traffic reaching ingress path does not match the flowtable entry
because the pppoe header is expected to be at the network header offset.
This bug causes a mismatch in the flow table lookup, so pppoe packets
enter the classical forwarding path. |
| In the Linux kernel, the following vulnerability has been resolved:
thermal/debugfs: Add missing count increment to thermal_debug_tz_trip_up()
The count field in struct trip_stats, representing the number of times
the zone temperature was above the trip point, needs to be incremented
in thermal_debug_tz_trip_up(), for two reasons.
First, if a trip point is crossed on the way up for the first time,
thermal_debug_update_temp() called from update_temperature() does
not see it because it has not been added to trips_crossed[] array
in the thermal zone's struct tz_debugfs object yet. Therefore, when
thermal_debug_tz_trip_up() is called after that, the trip point's
count value is 0, and the attempt to divide by it during the average
temperature computation leads to a divide error which causes the kernel
to crash. Setting the count to 1 before the division by incrementing it
fixes this problem.
Second, if a trip point is crossed on the way up, but it has been
crossed on the way up already before, its count value needs to be
incremented to make a record of the fact that the zone temperature is
above the trip now. Without doing that, if the mitigations applied
after crossing the trip cause the zone temperature to drop below its
threshold, the count will not be updated for this episode at all and
the average temperature in the trip statistics record will be somewhat
higher than it should be.
Cc :6.8+ <stable@vger.kernel.org> # 6.8+ |
