Total
34061 CVE
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2024-44220 | 1 Apple | 1 Macos | 2025-11-03 | 6.5 Medium |
| The issue was addressed with improved memory handling. This issue is fixed in macOS Sequoia 15.2, macOS Sonoma 14.7.2. Parsing a maliciously crafted video file may lead to unexpected system termination. | ||||
| CVE-2024-44216 | 1 Apple | 1 Macos | 2025-11-03 | 6.2 Medium |
| An access issue was addressed with additional sandbox restrictions. This issue is fixed in macOS Ventura 13.7.1, macOS Sonoma 14.7.1. An app may be able to access user-sensitive data. | ||||
| CVE-2024-44215 | 1 Apple | 6 Ipados, Iphone Os, Macos and 3 more | 2025-11-03 | 5.5 Medium |
| This issue was addressed with improved checks. This issue is fixed in tvOS 18.1, iOS 18.1 and iPadOS 18.1, iOS 17.7.1 and iPadOS 17.7.1, macOS Ventura 13.7.1, macOS Sonoma 14.7.1, watchOS 11.1, visionOS 2.1. Processing an image may result in disclosure of process memory. | ||||
| CVE-2024-44213 | 1 Apple | 1 Macos | 2025-11-03 | 7.5 High |
| An issue existed in the parsing of URLs. This issue was addressed with improved input validation. This issue is fixed in macOS Ventura 13.7.1, macOS Sonoma 14.7.1. An attacker in a privileged network position may be able to leak sensitive user information. | ||||
| CVE-2024-44207 | 1 Apple | 2 Ipados, Iphone Os | 2025-11-03 | 4.3 Medium |
| This issue was addressed with improved checks. This issue is fixed in iOS 18.0.1 and iPadOS 18.0.1. Audio messages in Messages may be able to capture a few seconds of audio before the microphone indicator is activated. | ||||
| CVE-2024-44204 | 1 Apple | 2 Ipados, Iphone Os | 2025-11-03 | 5.5 Medium |
| A logic issue was addressed with improved validation. This issue is fixed in iOS 18.0.1 and iPadOS 18.0.1. A user's saved passwords may be read aloud by VoiceOver. | ||||
| CVE-2024-44201 | 1 Apple | 3 Ipados, Iphone Os, Macos | 2025-11-03 | 5.5 Medium |
| The issue was addressed with improved memory handling. This issue is fixed in iPadOS 17.7.3, macOS Ventura 13.7.2, iOS 18.1 and iPadOS 18.1, macOS Sonoma 14.7.2. Processing a malicious crafted file may lead to a denial-of-service. | ||||
| CVE-2024-44197 | 1 Apple | 1 Macos | 2025-11-03 | 2.7 Low |
| The issue was addressed with improved memory handling. This issue is fixed in macOS Ventura 13.7.1, macOS Sonoma 14.7.1. A malicious app may be able to cause a denial-of-service. | ||||
| CVE-2024-44196 | 1 Apple | 1 Macos | 2025-11-03 | 7.5 High |
| A permissions issue was addressed with additional restrictions. This issue is fixed in macOS Ventura 13.7.1, macOS Sonoma 14.7.1. An app may be able to modify protected parts of the file system. | ||||
| CVE-2024-44195 | 1 Apple | 1 Macos | 2025-11-03 | 7.5 High |
| A logic issue was addressed with improved validation. This issue is fixed in macOS Sequoia 15.1. An app may be able to read arbitrary files. | ||||
| CVE-2024-44194 | 1 Apple | 4 Ipados, Iphone Os, Visionos and 1 more | 2025-11-03 | 5.5 Medium |
| This issue was addressed with improved redaction of sensitive information. This issue is fixed in watchOS 11.1, visionOS 2.1, iOS 18.1 and iPadOS 18.1. An app may be able to access sensitive user data. | ||||
| CVE-2024-44185 | 2 Apple, Redhat | 13 Ipados, Iphone Os, Macos and 10 more | 2025-11-03 | 5.5 Medium |
| The issue was addressed with improved checks. This issue is fixed in tvOS 17.6, visionOS 1.3, Safari 17.6, watchOS 10.6, iOS 17.6 and iPadOS 17.6, macOS Sonoma 14.6. Processing maliciously crafted web content may lead to an unexpected process crash. | ||||
| CVE-2024-44159 | 1 Apple | 1 Macos | 2025-11-03 | 7.1 High |
| A path deletion vulnerability was addressed by preventing vulnerable code from running with privileges. This issue is fixed in macOS Ventura 13.7.1, macOS Sonoma 14.7.1. An app may be able to bypass Privacy preferences. | ||||
| CVE-2024-44156 | 1 Apple | 1 Macos | 2025-11-03 | 7.1 High |
| A path deletion vulnerability was addressed by preventing vulnerable code from running with privileges. This issue is fixed in macOS Ventura 13.7.1, macOS Sonoma 14.7.1. An app may be able to bypass Privacy preferences. | ||||
| CVE-2024-44155 | 1 Apple | 5 Ipados, Iphone Os, Macos and 2 more | 2025-11-03 | 6.5 Medium |
| A custom URL scheme handling issue was addressed with improved input validation. This issue is fixed in Safari 18, iOS 17.7.1 and iPadOS 17.7.1, macOS Sequoia 15, watchOS 11, iOS 18 and iPadOS 18. Maliciously crafted web content may violate iframe sandboxing policy. | ||||
| CVE-2024-44137 | 1 Apple | 1 Macos | 2025-11-03 | 4.6 Medium |
| The issue was addressed with improved checks. This issue is fixed in macOS Ventura 13.7.1, macOS Sequoia 15, macOS Sonoma 14.7.1. An attacker with physical access may be able to share items from the lock screen. | ||||
| CVE-2024-44122 | 1 Apple | 1 Macos | 2025-11-03 | 8.8 High |
| A logic issue was addressed with improved checks. This issue is fixed in macOS Ventura 13.7.1, macOS Sequoia 15, macOS Sonoma 14.7.1. An application may be able to break out of its sandbox. | ||||
| CVE-2024-43914 | 2 Linux, Redhat | 2 Linux Kernel, Enterprise Linux | 2025-11-03 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: md/raid5: avoid BUG_ON() while continue reshape after reassembling Currently, mdadm support --revert-reshape to abort the reshape while reassembling, as the test 07revert-grow. However, following BUG_ON() can be triggerred by the test: kernel BUG at drivers/md/raid5.c:6278! invalid opcode: 0000 [#1] PREEMPT SMP PTI irq event stamp: 158985 CPU: 6 PID: 891 Comm: md0_reshape Not tainted 6.9.0-03335-g7592a0b0049a #94 RIP: 0010:reshape_request+0x3f1/0xe60 Call Trace: <TASK> raid5_sync_request+0x43d/0x550 md_do_sync+0xb7a/0x2110 md_thread+0x294/0x2b0 kthread+0x147/0x1c0 ret_from_fork+0x59/0x70 ret_from_fork_asm+0x1a/0x30 </TASK> Root cause is that --revert-reshape update the raid_disks from 5 to 4, while reshape position is still set, and after reassembling the array, reshape position will be read from super block, then during reshape the checking of 'writepos' that is caculated by old reshape position will fail. Fix this panic the easy way first, by converting the BUG_ON() to WARN_ON(), and stop the reshape if checkings fail. Noted that mdadm must fix --revert-shape as well, and probably md/raid should enhance metadata validation as well, however this means reassemble will fail and there must be user tools to fix the wrong metadata. | ||||
| CVE-2024-43912 | 1 Linux | 1 Linux Kernel | 2025-11-03 | 5.5 Medium |
| 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. | ||||
| CVE-2024-43897 | 1 Linux | 1 Linux Kernel | 2025-11-03 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: net: drop bad gso csum_start and offset in virtio_net_hdr Tighten csum_start and csum_offset checks in virtio_net_hdr_to_skb for GSO packets. The function already checks that a checksum requested with VIRTIO_NET_HDR_F_NEEDS_CSUM is in skb linear. But for GSO packets this might not hold for segs after segmentation. Syzkaller demonstrated to reach this warning in skb_checksum_help offset = skb_checksum_start_offset(skb); ret = -EINVAL; if (WARN_ON_ONCE(offset >= skb_headlen(skb))) By injecting a TSO packet: WARNING: CPU: 1 PID: 3539 at net/core/dev.c:3284 skb_checksum_help+0x3d0/0x5b0 ip_do_fragment+0x209/0x1b20 net/ipv4/ip_output.c:774 ip_finish_output_gso net/ipv4/ip_output.c:279 [inline] __ip_finish_output+0x2bd/0x4b0 net/ipv4/ip_output.c:301 iptunnel_xmit+0x50c/0x930 net/ipv4/ip_tunnel_core.c:82 ip_tunnel_xmit+0x2296/0x2c70 net/ipv4/ip_tunnel.c:813 __gre_xmit net/ipv4/ip_gre.c:469 [inline] ipgre_xmit+0x759/0xa60 net/ipv4/ip_gre.c:661 __netdev_start_xmit include/linux/netdevice.h:4850 [inline] netdev_start_xmit include/linux/netdevice.h:4864 [inline] xmit_one net/core/dev.c:3595 [inline] dev_hard_start_xmit+0x261/0x8c0 net/core/dev.c:3611 __dev_queue_xmit+0x1b97/0x3c90 net/core/dev.c:4261 packet_snd net/packet/af_packet.c:3073 [inline] The geometry of the bad input packet at tcp_gso_segment: [ 52.003050][ T8403] skb len=12202 headroom=244 headlen=12093 tailroom=0 [ 52.003050][ T8403] mac=(168,24) mac_len=24 net=(192,52) trans=244 [ 52.003050][ T8403] shinfo(txflags=0 nr_frags=1 gso(size=1552 type=3 segs=0)) [ 52.003050][ T8403] csum(0x60000c7 start=199 offset=1536 ip_summed=3 complete_sw=0 valid=0 level=0) Mitigate with stricter input validation. csum_offset: for GSO packets, deduce the correct value from gso_type. This is already done for USO. Extend it to TSO. Let UFO be: udp[46]_ufo_fragment ignores these fields and always computes the checksum in software. csum_start: finding the real offset requires parsing to the transport header. Do not add a parser, use existing segmentation parsing. Thanks to SKB_GSO_DODGY, that also catches bad packets that are hw offloaded. Again test both TSO and USO. Do not test UFO for the above reason, and do not test UDP tunnel offload. GSO packet are almost always CHECKSUM_PARTIAL. USO packets may be CHECKSUM_NONE since commit 10154dbded6d6 ("udp: Allow GSO transmit from devices with no checksum offload"), but then still these fields are initialized correctly in udp4_hwcsum/udp6_hwcsum_outgoing. So no need to test for ip_summed == CHECKSUM_PARTIAL first. This revises an existing fix mentioned in the Fixes tag, which broke small packets with GSO offload, as detected by kselftests. | ||||