| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| A logging issue was addressed with improved data redaction. This issue is fixed in macOS Ventura 13.7.5, macOS Sequoia 15.4, macOS Sonoma 14.7.5. Deleting a conversation in Messages may expose user contact information in system logging. |
| A security issue was discovered in ingress-nginx https://github.com/kubernetes/ingress-nginx where the `auth-url` Ingress annotation can be used to inject configuration into nginx. This can lead to arbitrary code execution in the context of the ingress-nginx controller, and disclosure of Secrets accessible to the controller. (Note that in the default installation, the controller can access all Secrets cluster-wide.) |
| A security issue was discovered in ingress-nginx https://github.com/kubernetes/ingress-nginx where attacker-provided data are included in a filename by the ingress-nginx Admission Controller feature, resulting in directory traversal within the container. This could result in denial of service, or when combined with other vulnerabilities, limited disclosure of Secret objects from the cluster. |
| A logging issue was addressed with improved data redaction. This issue is fixed in visionOS 2.4, iOS 18.4 and iPadOS 18.4, macOS Sequoia 15.4. An app may be able to access sensitive user data. |
| A library injection issue was addressed with additional restrictions. This issue is fixed in macOS Sequoia 15.4. An app may be able to modify protected parts of the file system. |
| This issue was addressed with improved data protection. This issue is fixed in macOS Sequoia 15.4. An app may be able to access sensitive user data. |
| An access issue was addressed with additional sandbox restrictions. This issue is fixed in macOS Sequoia 15.4, macOS Sonoma 14.7.5. An app may be able to access user-sensitive data. |
| This issue was addressed with improved file handling. This issue is fixed in macOS Ventura 13.7.5, macOS Sequoia 15.4, macOS Sonoma 14.7.5. An app may be able to access contacts. |
| This issue was addressed by removing the vulnerable code. This issue is fixed in macOS Ventura 13.7.5, macOS Sequoia 15.4, macOS Sonoma 14.7.5. A malicious app may be able to access private information. |
| A privacy issue was addressed with improved private data redaction for log entries. This issue is fixed in macOS Sequoia 15.4. A sandboxed app may be able to access sensitive user data in system logs. |
| The issue was addressed with improved checks. This issue is fixed in macOS Ventura 13.7.5, macOS Sequoia 15.4, macOS Sonoma 14.7.5. An app may be able to modify protected parts of the file system. |
| A file access issue was addressed with improved input validation. This issue is fixed in macOS Ventura 13.7.5, macOS Sequoia 15.4, macOS Sonoma 14.7.5. An app may be able to break out of its sandbox. |
| This issue was addressed with improved handling of symlinks. This issue is fixed in macOS Ventura 13.7.5, macOS Sequoia 15.4, macOS Sonoma 14.7.5. An app may be able to access protected user data. |
| This issue was addressed with improved access restrictions. This issue is fixed in macOS Ventura 13.7.5, macOS Sequoia 15.4, macOS Sonoma 14.7.5. A malicious app acting as a HTTPS proxy could get access to sensitive user data. |
| An injection issue was addressed with improved validation. This issue is fixed in macOS Ventura 13.7.5, macOS Sequoia 15.4, macOS Sonoma 14.7.5. An app may be able to access user-sensitive data. |
| The issue was addressed with improved memory handling. This issue is fixed in macOS Ventura 13.7.5, tvOS 18.4, iPadOS 17.7.6, iOS 18.4 and iPadOS 18.4, macOS Sequoia 15.4, macOS Sonoma 14.7.5. Processing a maliciously crafted font may result in the disclosure of process memory. |
| A downgrade issue was addressed with additional code-signing restrictions. This issue is fixed in macOS Sequoia 15.4. An app may be able to access protected user data. |
| In the Linux kernel, the following vulnerability has been resolved:
wifi: nl80211: disallow setting special AP channel widths
Setting the AP channel width is meant for use with the normal
20/40/... MHz channel width progression, and switching around
in S1G or narrow channels isn't supported. Disallow that. |
| In the Linux kernel, the following vulnerability has been resolved:
PCI: rcar: Demote WARN() to dev_warn_ratelimited() in rcar_pcie_wakeup()
Avoid large backtrace, it is sufficient to warn the user that there has
been a link problem. Either the link has failed and the system is in need
of maintenance, or the link continues to work and user has been informed.
The message from the warning can be looked up in the sources.
This makes an actual link issue less verbose.
First of all, this controller has a limitation in that the controller
driver has to assist the hardware with transition to L1 link state by
writing L1IATN to PMCTRL register, the L1 and L0 link state switching
is not fully automatic on this controller.
In case of an ASMedia ASM1062 PCIe SATA controller which does not support
ASPM, on entry to suspend or during platform pm_test, the SATA controller
enters D3hot state and the link enters L1 state. If the SATA controller
wakes up before rcar_pcie_wakeup() was called and returns to D0, the link
returns to L0 before the controller driver even started its transition to
L1 link state. At this point, the SATA controller did send an PM_ENTER_L1
DLLP to the PCIe controller and the PCIe controller received it, and the
PCIe controller did set PMSR PMEL1RX bit.
Once rcar_pcie_wakeup() is called, if the link is already back in L0 state
and PMEL1RX bit is set, the controller driver has no way to determine if
it should perform the link transition to L1 state, or treat the link as if
it is in L0 state. Currently the driver attempts to perform the transition
to L1 link state unconditionally, which in this specific case fails with a
PMSR L1FAEG poll timeout, however the link still works as it is already
back in L0 state.
Reduce this warning verbosity. In case the link is really broken, the
rcar_pcie_config_access() would fail, otherwise it will succeed and any
system with this controller and ASM1062 can suspend without generating
a backtrace. |
| In the Linux kernel, the following vulnerability has been resolved:
riscv/purgatory: align riscv_kernel_entry
When alignment handling is delegated to the kernel, everything must be
word-aligned in purgatory, since the trap handler is then set to the
kexec one. Without the alignment, hitting the exception would
ultimately crash. On other occasions, the kernel's handler would take
care of exceptions.
This has been tested on a JH7110 SoC with oreboot and its SBI delegating
unaligned access exceptions and the kernel configured to handle them. |
