Total
33985 CVE
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2025-46287 | 1 Apple | 3 Macos, Macos Sequoia, Macos Sonoma | 2025-12-17 | 9.8 Critical |
| 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. | ||||
| CVE-2025-46276 | 1 Apple | 3 Macos, Macos Sequoia, Macos Sonoma | 2025-12-17 | 3.3 Low |
| 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. | ||||
| CVE-2025-43538 | 1 Apple | 2 Macos, Macos Sonoma | 2025-12-17 | 5.5 Medium |
| 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. | ||||
| CVE-2025-43530 | 1 Apple | 3 Macos, Macos Sequoia, Macos Sonoma | 2025-12-17 | 5.5 Medium |
| 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. | ||||
| CVE-2025-43519 | 1 Apple | 3 Macos, Macos Sequoia, Macos Sonoma | 2025-12-17 | 7.5 High |
| 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. | ||||
| CVE-2025-43517 | 1 Apple | 3 Macos, Macos Sequoia, Macos Sonoma | 2025-12-17 | 3.3 Low |
| 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. | ||||
| CVE-2025-43513 | 1 Apple | 3 Macos, Macos Sequoia, Macos Sonoma | 2025-12-17 | 5.5 Medium |
| 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. | ||||
| CVE-2025-43512 | 1 Apple | 3 Macos, Macos Sequoia, Macos Sonoma | 2025-12-17 | 7.8 High |
| 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. | ||||
| CVE-2025-43473 | 1 Apple | 2 Macos, Macos Tahoe | 2025-12-17 | 5.5 Medium |
| 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. | ||||
| CVE-2025-43443 | 1 Apple | 7 Ios, Ipados, Iphone Os and 4 more | 2025-12-17 | 4.3 Medium |
| 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. | ||||
| CVE-2025-43416 | 1 Apple | 3 Macos, Macos Sequoia, Macos Sonoma | 2025-12-17 | 9.8 Critical |
| 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. | ||||
| CVE-2025-43320 | 1 Apple | 2 Macos, Macos Sequoia | 2025-12-17 | 7.8 High |
| 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. | ||||
| CVE-2025-38003 | 2 Debian, Linux | 2 Debian Linux, Linux Kernel | 2025-12-17 | 5.5 Medium |
| 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. | ||||
| CVE-2025-38009 | 2 Debian, Linux | 2 Debian Linux, Linux Kernel | 2025-12-17 | 5.5 Medium |
| 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). | ||||
| CVE-2024-27410 | 3 Debian, Linux, Redhat | 4 Debian Linux, Linux Kernel, Enterprise Linux and 1 more | 2025-12-17 | 5.5 Medium |
| 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. | ||||
| CVE-2024-27412 | 2 Debian, Linux | 2 Debian Linux, Linux Kernel | 2025-12-17 | 5.5 Medium |
| 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. | ||||
| CVE-2024-27413 | 2 Debian, Linux | 2 Debian Linux, Linux Kernel | 2025-12-17 | 5.5 Medium |
| 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. | ||||
| CVE-2024-27414 | 3 Debian, Linux, Redhat | 3 Debian Linux, Linux Kernel, Enterprise Linux | 2025-12-17 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: rtnetlink: fix error logic of IFLA_BRIDGE_FLAGS writing back In the commit d73ef2d69c0d ("rtnetlink: let rtnl_bridge_setlink checks IFLA_BRIDGE_MODE length"), an adjustment was made to the old loop logic in the function `rtnl_bridge_setlink` to enable the loop to also check the length of the IFLA_BRIDGE_MODE attribute. However, this adjustment removed the `break` statement and led to an error logic of the flags writing back at the end of this function. if (have_flags) memcpy(nla_data(attr), &flags, sizeof(flags)); // attr should point to IFLA_BRIDGE_FLAGS NLA !!! Before the mentioned commit, the `attr` is granted to be IFLA_BRIDGE_FLAGS. However, this is not necessarily true fow now as the updated loop will let the attr point to the last NLA, even an invalid NLA which could cause overflow writes. This patch introduces a new variable `br_flag` to save the NLA pointer that points to IFLA_BRIDGE_FLAGS and uses it to resolve the mentioned error logic. | ||||
| CVE-2024-27416 | 2 Debian, Linux | 2 Debian Linux, Linux Kernel | 2025-12-17 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_event: Fix handling of HCI_EV_IO_CAPA_REQUEST If we received HCI_EV_IO_CAPA_REQUEST while HCI_OP_READ_REMOTE_EXT_FEATURES is yet to be responded assume the remote does support SSP since otherwise this event shouldn't be generated. | ||||
| CVE-2024-35807 | 3 Debian, Linux, Redhat | 4 Debian Linux, Linux Kernel, Enterprise Linux and 1 more | 2025-12-17 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: ext4: fix corruption during on-line resize We observed a corruption during on-line resize of a file system that is larger than 16 TiB with 4k block size. With having more then 2^32 blocks resize_inode is turned off by default by mke2fs. The issue can be reproduced on a smaller file system for convenience by explicitly turning off resize_inode. An on-line resize across an 8 GiB boundary (the size of a meta block group in this setup) then leads to a corruption: dev=/dev/<some_dev> # should be >= 16 GiB mkdir -p /corruption /sbin/mke2fs -t ext4 -b 4096 -O ^resize_inode $dev $((2 * 2**21 - 2**15)) mount -t ext4 $dev /corruption dd if=/dev/zero bs=4096 of=/corruption/test count=$((2*2**21 - 4*2**15)) sha1sum /corruption/test # 79d2658b39dcfd77274e435b0934028adafaab11 /corruption/test /sbin/resize2fs $dev $((2*2**21)) # drop page cache to force reload the block from disk echo 1 > /proc/sys/vm/drop_caches sha1sum /corruption/test # 3c2abc63cbf1a94c9e6977e0fbd72cd832c4d5c3 /corruption/test 2^21 = 2^15*2^6 equals 8 GiB whereof 2^15 is the number of blocks per block group and 2^6 are the number of block groups that make a meta block group. The last checksum might be different depending on how the file is laid out across the physical blocks. The actual corruption occurs at physical block 63*2^15 = 2064384 which would be the location of the backup of the meta block group's block descriptor. During the on-line resize the file system will be converted to meta_bg starting at s_first_meta_bg which is 2 in the example - meaning all block groups after 16 GiB. However, in ext4_flex_group_add we might add block groups that are not part of the first meta block group yet. In the reproducer we achieved this by substracting the size of a whole block group from the point where the meta block group would start. This must be considered when updating the backup block group descriptors to follow the non-meta_bg layout. The fix is to add a test whether the group to add is already part of the meta block group or not. | ||||