| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| Improper neutralization in Microsoft Management Console allows an unauthorized attacker to bypass a security feature locally. |
| Improper authorization in Microsoft Partner Center allows an authorized attacker to elevate privileges over a network. |
| An inconsistent user interface issue was addressed with improved state management. This issue is fixed in watchOS 26.2, macOS Sonoma 14.8.3, iOS 18.7.3 and iPadOS 18.7.3, iOS 26.2 and iPadOS 26.2, macOS Tahoe 26.2, macOS Sequoia 15.7.3, visionOS 26.2. An attacker may be able to spoof their FaceTime caller ID. |
| An information disclosure issue was addressed with improved privacy controls. This issue is fixed in watchOS 26.2, macOS Sonoma 14.8.3, iOS 18.7.3 and iPadOS 18.7.3, iOS 26.2 and iPadOS 26.2, macOS Tahoe 26.2, macOS Sequoia 15.7.3, visionOS 26.2. An app may be able to access sensitive user data. |
| A logging issue was addressed with improved data redaction. This issue is fixed in watchOS 26.2, macOS Sonoma 14.8.3, iOS 18.7.3 and iPadOS 18.7.3, iOS 26.2 and iPadOS 26.2, macOS Tahoe 26.2, visionOS 26.2. An app may be able to access sensitive user data. |
| This issue was addressed with improved checks. This issue is fixed in macOS Tahoe 26.2, macOS Sonoma 14.8.3, macOS Sequoia 15.7.3, iOS 18.7.3 and iPadOS 18.7.3. An app may be able to access sensitive user data. |
| A permissions issue was addressed with additional restrictions. This issue is fixed in macOS Tahoe 26.2, macOS Sequoia 15.7.3, macOS Sonoma 14.8.3. An app may be able to access sensitive user data. |
| A privacy issue was addressed with improved private data redaction for log entries. This issue is fixed in macOS Tahoe 26.2, macOS Sequoia 15.7.3, macOS Sonoma 14.8.3. An app may be able to access protected user data. |
| A permissions issue was addressed by removing the vulnerable code. This issue is fixed in macOS Tahoe 26.2, macOS Sequoia 15.7.3, macOS Sonoma 14.8.3. An app may be able to read sensitive location information. |
| A logic issue was addressed with improved checks. This issue is fixed in macOS Tahoe 26.2, macOS Sonoma 14.8.3, macOS Sequoia 15.7.3, iOS 18.7.3 and iPadOS 18.7.3. An app may be able to elevate privileges. |
| This issue was addressed with improved state management. This issue is fixed in macOS Tahoe 26.1. An app may be able to access sensitive user data. |
| This issue was addressed with improved checks. This issue is fixed in tvOS 26.1, watchOS 26.1, macOS Tahoe 26.1, iOS 26.1 and iPadOS 26.1, Safari 26.1, iOS 18.7.2 and iPadOS 18.7.2, visionOS 26.1. Processing maliciously crafted web content may lead to an unexpected process crash. |
| A logging issue was addressed with improved data redaction. This issue is fixed in macOS Tahoe 26.1, iOS 26.1 and iPadOS 26.1, iOS 18.7.2 and iPadOS 18.7.2, macOS Sequoia 15.7.2, visionOS 26.1. An attacker with physical access to an unlocked device paired with a Mac may be able to view sensitive user information in system logging. |
| A logic issue was addressed with improved restrictions. This issue is fixed in macOS Tahoe 26.2, macOS Sequoia 15.7.3, macOS Sonoma 14.8.3. An app may be able to access protected user data. |
| The issue was addressed by adding additional logic. This issue is fixed in macOS Tahoe 26, macOS Sequoia 15.7.3. An app may be able to bypass launch constraint protections and execute malicious code with elevated privileges. |
| In the Linux kernel, the following vulnerability has been resolved:
can: bcm: add missing rcu read protection for procfs content
When the procfs content is generated for a bcm_op which is in the process
to be removed the procfs output might show unreliable data (UAF).
As the removal of bcm_op's is already implemented with rcu handling this
patch adds the missing rcu_read_lock() and makes sure the list entries
are properly removed under rcu protection. |
| In the Linux kernel, the following vulnerability has been resolved:
wifi: mt76: disable napi on driver removal
A warning on driver removal started occurring after commit 9dd05df8403b
("net: warn if NAPI instance wasn't shut down"). Disable tx napi before
deleting it in mt76_dma_cleanup().
WARNING: CPU: 4 PID: 18828 at net/core/dev.c:7288 __netif_napi_del_locked+0xf0/0x100
CPU: 4 UID: 0 PID: 18828 Comm: modprobe Not tainted 6.15.0-rc4 #4 PREEMPT(lazy)
Hardware name: ASUS System Product Name/PRIME X670E-PRO WIFI, BIOS 3035 09/05/2024
RIP: 0010:__netif_napi_del_locked+0xf0/0x100
Call Trace:
<TASK>
mt76_dma_cleanup+0x54/0x2f0 [mt76]
mt7921_pci_remove+0xd5/0x190 [mt7921e]
pci_device_remove+0x47/0xc0
device_release_driver_internal+0x19e/0x200
driver_detach+0x48/0x90
bus_remove_driver+0x6d/0xf0
pci_unregister_driver+0x2e/0xb0
__do_sys_delete_module.isra.0+0x197/0x2e0
do_syscall_64+0x7b/0x160
entry_SYSCALL_64_after_hwframe+0x76/0x7e
Tested with mt7921e but the same pattern can be actually applied to other
mt76 drivers calling mt76_dma_cleanup() during removal. Tx napi is enabled
in their *_dma_init() functions and only toggled off and on again inside
their suspend/resume/reset paths. So it should be okay to disable tx
napi in such a generic way.
Found by Linux Verification Center (linuxtesting.org). |
| In the Linux kernel, the following vulnerability has been resolved:
wifi: nl80211: reject iftype change with mesh ID change
It's currently possible to change the mesh ID when the
interface isn't yet in mesh mode, at the same time as
changing it into mesh mode. This leads to an overwrite
of data in the wdev->u union for the interface type it
currently has, causing cfg80211_change_iface() to do
wrong things when switching.
We could probably allow setting an interface to mesh
while setting the mesh ID at the same time by doing a
different order of operations here, but realistically
there's no userspace that's going to do this, so just
disallow changes in iftype when setting mesh ID. |
| In the Linux kernel, the following vulnerability has been resolved:
power: supply: bq27xxx-i2c: Do not free non existing IRQ
The bq27xxx i2c-client may not have an IRQ, in which case
client->irq will be 0. bq27xxx_battery_i2c_probe() already has
an if (client->irq) check wrapping the request_threaded_irq().
But bq27xxx_battery_i2c_remove() unconditionally calls
free_irq(client->irq) leading to:
[ 190.310742] ------------[ cut here ]------------
[ 190.310843] Trying to free already-free IRQ 0
[ 190.310861] WARNING: CPU: 2 PID: 1304 at kernel/irq/manage.c:1893 free_irq+0x1b8/0x310
Followed by a backtrace when unbinding the driver. Add
an if (client->irq) to bq27xxx_battery_i2c_remove() mirroring
probe() to fix this. |
| In the Linux kernel, the following vulnerability has been resolved:
efi/capsule-loader: fix incorrect allocation size
gcc-14 notices that the allocation with sizeof(void) on 32-bit architectures
is not enough for a 64-bit phys_addr_t:
drivers/firmware/efi/capsule-loader.c: In function 'efi_capsule_open':
drivers/firmware/efi/capsule-loader.c:295:24: error: allocation of insufficient size '4' for type 'phys_addr_t' {aka 'long long unsigned int'} with size '8' [-Werror=alloc-size]
295 | cap_info->phys = kzalloc(sizeof(void *), GFP_KERNEL);
| ^
Use the correct type instead here. |
