Total
7759 CVE
| CVE | Vendors | Products | Updated | CVSS v2 | CVSS v3 |
|---|---|---|---|---|---|
| CVE-2024-46724 | 1 Linux | 1 Linux Kernel | 2025-11-03 | N/A | 7.1 HIGH |
| In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Fix out-of-bounds read of df_v1_7_channel_number Check the fb_channel_number range to avoid the array out-of-bounds read error | |||||
| CVE-2024-46723 | 1 Linux | 1 Linux Kernel | 2025-11-03 | N/A | 7.1 HIGH |
| In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: fix ucode out-of-bounds read warning Clear warning that read ucode[] may out-of-bounds. | |||||
| CVE-2024-46722 | 1 Linux | 1 Linux Kernel | 2025-11-03 | N/A | 7.1 HIGH |
| In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: fix mc_data out-of-bounds read warning Clear warning that read mc_data[i-1] may out-of-bounds. | |||||
| CVE-2024-44283 | 1 Apple | 1 Macos | 2025-11-03 | N/A | 5.5 MEDIUM |
| An out-of-bounds read was addressed with improved bounds checking. This issue is fixed in macOS Ventura 13.7.1, macOS Sonoma 14.7.1. Parsing a maliciously crafted file may lead to an unexpected app termination. | |||||
| CVE-2024-44282 | 1 Apple | 6 Ipados, Iphone Os, Macos and 3 more | 2025-11-03 | N/A | 5.5 MEDIUM |
| An out-of-bounds read was addressed with improved input validation. 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. Parsing a file may lead to disclosure of user information. | |||||
| CVE-2024-44281 | 1 Apple | 1 Macos | 2025-11-03 | N/A | 5.5 MEDIUM |
| An out-of-bounds read was addressed with improved input validation. This issue is fixed in macOS Ventura 13.7.1, macOS Sonoma 14.7.1. Parsing a file may lead to disclosure of user information. | |||||
| CVE-2024-44279 | 1 Apple | 1 Macos | 2025-11-03 | N/A | 5.5 MEDIUM |
| An out-of-bounds read was addressed with improved input validation. This issue is fixed in macOS Ventura 13.7.1, macOS Sonoma 14.7.1. Parsing a file may lead to disclosure of user information. | |||||
| CVE-2025-30458 | 1 Apple | 1 Macos | 2025-11-03 | N/A | 9.8 CRITICAL |
| A permissions issue was addressed with additional restrictions. This issue is fixed in macOS Sequoia 15.4. An app may be able to read files outside of its sandbox. | |||||
| CVE-2025-24265 | 1 Apple | 1 Macos | 2025-11-03 | N/A | 9.8 CRITICAL |
| An out-of-bounds read was addressed with improved bounds checking. 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 cause unexpected system termination. | |||||
| CVE-2025-24256 | 1 Apple | 1 Macos | 2025-11-03 | N/A | 9.8 CRITICAL |
| The issue was addressed with improved bounds 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 disclose kernel memory. | |||||
| CVE-2024-44246 | 1 Apple | 4 Ipados, Iphone Os, Macos and 1 more | 2025-11-03 | N/A | 5.3 MEDIUM |
| The issue was addressed with improved routing of Safari-originated requests. This issue is fixed in macOS Sequoia 15.2, iOS 18.2 and iPadOS 18.2, Safari 18.2, iPadOS 17.7.3. On a device with Private Relay enabled, adding a website to the Safari Reading List may reveal the originating IP address to the website. | |||||
| CVE-2024-44237 | 1 Apple | 1 Macos | 2025-11-03 | N/A | 5.5 MEDIUM |
| An out-of-bounds access issue was addressed with improved bounds checking. This issue is fixed in macOS Ventura 13.7.1, macOS Sonoma 14.7.1. Processing a maliciously crafted file may lead to unexpected app termination. | |||||
| CVE-2024-44236 | 1 Apple | 1 Macos | 2025-11-03 | N/A | 5.5 MEDIUM |
| An out-of-bounds access issue was addressed with improved bounds checking. This issue is fixed in macOS Ventura 13.7.1, macOS Sonoma 14.7.1. Processing a maliciously crafted file may lead to unexpected app termination. | |||||
| CVE-2024-43877 | 1 Linux | 1 Linux Kernel | 2025-11-03 | N/A | 7.1 HIGH |
| In the Linux kernel, the following vulnerability has been resolved: media: pci: ivtv: Add check for DMA map result In case DMA fails, 'dma->SG_length' is 0. This value is later used to access 'dma->SGarray[dma->SG_length - 1]', which will cause out of bounds access. Add check to return early on invalid value. Adjust warnings accordingly. Found by Linux Verification Center (linuxtesting.org) with SVACE. | |||||
| CVE-2024-42305 | 1 Linux | 1 Linux Kernel | 2025-11-03 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: ext4: check dot and dotdot of dx_root before making dir indexed Syzbot reports a issue as follows: ============================================ BUG: unable to handle page fault for address: ffffed11022e24fe PGD 23ffee067 P4D 23ffee067 PUD 0 Oops: Oops: 0000 [#1] PREEMPT SMP KASAN PTI CPU: 0 PID: 5079 Comm: syz-executor306 Not tainted 6.10.0-rc5-g55027e689933 #0 Call Trace: <TASK> make_indexed_dir+0xdaf/0x13c0 fs/ext4/namei.c:2341 ext4_add_entry+0x222a/0x25d0 fs/ext4/namei.c:2451 ext4_rename fs/ext4/namei.c:3936 [inline] ext4_rename2+0x26e5/0x4370 fs/ext4/namei.c:4214 [...] ============================================ The immediate cause of this problem is that there is only one valid dentry for the block to be split during do_split, so split==0 results in out of bounds accesses to the map triggering the issue. do_split unsigned split dx_make_map count = 1 split = count/2 = 0; continued = hash2 == map[split - 1].hash; ---> map[4294967295] The maximum length of a filename is 255 and the minimum block size is 1024, so it is always guaranteed that the number of entries is greater than or equal to 2 when do_split() is called. But syzbot's crafted image has no dot and dotdot in dir, and the dentry distribution in dirblock is as follows: bus dentry1 hole dentry2 free |xx--|xx-------------|...............|xx-------------|...............| 0 12 (8+248)=256 268 256 524 (8+256)=264 788 236 1024 So when renaming dentry1 increases its name_len length by 1, neither hole nor free is sufficient to hold the new dentry, and make_indexed_dir() is called. In make_indexed_dir() it is assumed that the first two entries of the dirblock must be dot and dotdot, so bus and dentry1 are left in dx_root because they are treated as dot and dotdot, and only dentry2 is moved to the new leaf block. That's why count is equal to 1. Therefore add the ext4_check_dx_root() helper function to add more sanity checks to dot and dotdot before starting the conversion to avoid the above issue. | |||||
| CVE-2024-42292 | 1 Linux | 1 Linux Kernel | 2025-11-03 | N/A | 7.1 HIGH |
| In the Linux kernel, the following vulnerability has been resolved: kobject_uevent: Fix OOB access within zap_modalias_env() zap_modalias_env() wrongly calculates size of memory block to move, so will cause OOB memory access issue if variable MODALIAS is not the last one within its @env parameter, fixed by correcting size to memmove. | |||||
| CVE-2024-41091 | 1 Linux | 1 Linux Kernel | 2025-11-03 | N/A | 7.1 HIGH |
| In the Linux kernel, the following vulnerability has been resolved: tun: add missing verification for short frame The cited commit missed to check against the validity of the frame length in the tun_xdp_one() path, which could cause a corrupted skb to be sent downstack. Even before the skb is transmitted, the tun_xdp_one-->eth_type_trans() may access the Ethernet header although it can be less than ETH_HLEN. Once transmitted, this could either cause out-of-bound access beyond the actual length, or confuse the underlayer with incorrect or inconsistent header length in the skb metadata. In the alternative path, tun_get_user() already prohibits short frame which has the length less than Ethernet header size from being transmitted for IFF_TAP. This is to drop any frame shorter than the Ethernet header size just like how tun_get_user() does. CVE: CVE-2024-41091 | |||||
| CVE-2024-41090 | 1 Linux | 1 Linux Kernel | 2025-11-03 | N/A | 7.1 HIGH |
| In the Linux kernel, the following vulnerability has been resolved: tap: add missing verification for short frame The cited commit missed to check against the validity of the frame length in the tap_get_user_xdp() path, which could cause a corrupted skb to be sent downstack. Even before the skb is transmitted, the tap_get_user_xdp()-->skb_set_network_header() may assume the size is more than ETH_HLEN. Once transmitted, this could either cause out-of-bound access beyond the actual length, or confuse the underlayer with incorrect or inconsistent header length in the skb metadata. In the alternative path, tap_get_user() already prohibits short frame which has the length less than Ethernet header size from being transmitted. This is to drop any frame shorter than the Ethernet header size just like how tap_get_user() does. CVE: CVE-2024-41090 | |||||
| CVE-2024-41019 | 1 Linux | 1 Linux Kernel | 2025-11-03 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Validate ff offset This adds sanity checks for ff offset. There is a check on rt->first_free at first, but walking through by ff without any check. If the second ff is a large offset. We may encounter an out-of-bound read. | |||||
| CVE-2024-40978 | 1 Linux | 1 Linux Kernel | 2025-11-03 | N/A | 7.1 HIGH |
| In the Linux kernel, the following vulnerability has been resolved: scsi: qedi: Fix crash while reading debugfs attribute The qedi_dbg_do_not_recover_cmd_read() function invokes sprintf() directly on a __user pointer, which results into the crash. To fix this issue, use a small local stack buffer for sprintf() and then call simple_read_from_buffer(), which in turns make the copy_to_user() call. BUG: unable to handle page fault for address: 00007f4801111000 PGD 8000000864df6067 P4D 8000000864df6067 PUD 864df7067 PMD 846028067 PTE 0 Oops: 0002 [#1] PREEMPT SMP PTI Hardware name: HPE ProLiant DL380 Gen10/ProLiant DL380 Gen10, BIOS U30 06/15/2023 RIP: 0010:memcpy_orig+0xcd/0x130 RSP: 0018:ffffb7a18c3ffc40 EFLAGS: 00010202 RAX: 00007f4801111000 RBX: 00007f4801111000 RCX: 000000000000000f RDX: 000000000000000f RSI: ffffffffc0bfd7a0 RDI: 00007f4801111000 RBP: ffffffffc0bfd7a0 R08: 725f746f6e5f6f64 R09: 3d7265766f636572 R10: ffffb7a18c3ffd08 R11: 0000000000000000 R12: 00007f4881110fff R13: 000000007fffffff R14: ffffb7a18c3ffca0 R15: ffffffffc0bfd7af FS: 00007f480118a740(0000) GS:ffff98e38af00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f4801111000 CR3: 0000000864b8e001 CR4: 00000000007706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: <TASK> ? __die_body+0x1a/0x60 ? page_fault_oops+0x183/0x510 ? exc_page_fault+0x69/0x150 ? asm_exc_page_fault+0x22/0x30 ? memcpy_orig+0xcd/0x130 vsnprintf+0x102/0x4c0 sprintf+0x51/0x80 qedi_dbg_do_not_recover_cmd_read+0x2f/0x50 [qedi 6bcfdeeecdea037da47069eca2ba717c84a77324] full_proxy_read+0x50/0x80 vfs_read+0xa5/0x2e0 ? folio_add_new_anon_rmap+0x44/0xa0 ? set_pte_at+0x15/0x30 ? do_pte_missing+0x426/0x7f0 ksys_read+0xa5/0xe0 do_syscall_64+0x58/0x80 ? __count_memcg_events+0x46/0x90 ? count_memcg_event_mm+0x3d/0x60 ? handle_mm_fault+0x196/0x2f0 ? do_user_addr_fault+0x267/0x890 ? exc_page_fault+0x69/0x150 entry_SYSCALL_64_after_hwframe+0x72/0xdc RIP: 0033:0x7f4800f20b4d | |||||