Total
7759 CVE
| CVE | Vendors | Products | Updated | CVSS v2 | CVSS v3 |
|---|---|---|---|---|---|
| CVE-2022-48739 | 1 Linux | 1 Linux Kernel | 2025-01-06 | N/A | 7.1 HIGH |
| In the Linux kernel, the following vulnerability has been resolved: ASoC: hdmi-codec: Fix OOB memory accesses Correct size of iec_status array by changing it to the size of status array of the struct snd_aes_iec958. This fixes out-of-bounds slab read accesses made by memcpy() of the hdmi-codec driver. This problem is reported by KASAN. | |||||
| CVE-2023-52766 | 1 Linux | 1 Linux Kernel | 2025-01-06 | N/A | 7.1 HIGH |
| In the Linux kernel, the following vulnerability has been resolved: i3c: mipi-i3c-hci: Fix out of bounds access in hci_dma_irq_handler Do not loop over ring headers in hci_dma_irq_handler() that are not allocated and enabled in hci_dma_init(). Otherwise out of bounds access will occur from rings->headers[i] access when i >= number of allocated ring headers. | |||||
| CVE-2023-24535 | 1 Protobuf | 1 Protobuf | 2025-01-06 | N/A | 7.5 HIGH |
| Parsing invalid messages can panic. Parsing a text-format message which contains a potential number consisting of a minus sign, one or more characters of whitespace, and no further input will cause a panic. | |||||
| CVE-2023-50926 | 1 Contiki-ng | 1 Contiki-ng | 2025-01-06 | N/A | 7.5 HIGH |
| Contiki-NG is an open-source, cross-platform operating system for Next-Generation IoT devices. An out-of-bounds read can be caused by an incoming DIO message when using the RPL-Lite implementation in the Contiki-NG operating system. More specifically, the prefix information of the DIO message contains a field that specifies the length of an IPv6 address prefix. The value of this field is not validated, which means that an attacker can set a value that is longer than the maximum prefix length. Subsequently, a memcmp function call that compares different prefixes can be called with a length argument that surpasses the boundary of the array allocated for the prefix, causing an out-of-bounds read. The problem has been patched in the "develop" branch of Contiki-NG, and is expected to be included in the next release. Users are advised to update as soon as they are able to or to manually apply the changes in Contiki-NG pull request #2721. | |||||
| CVE-2023-29167 | 1 Fujielectric | 1 Frenic Rhc Loader | 2025-01-03 | N/A | 7.8 HIGH |
| Out-of-bound reads vulnerability exists in FRENIC RHC Loader v1.1.0.3. If a user opens a specially crafted FNE file, sensitive information on the system where the affected product is installed may be disclosed or arbitrary code may be executed. | |||||
| CVE-2024-23808 | 1 Openatom | 1 Openharmony | 2025-01-02 | N/A | 5.2 MEDIUM |
| in OpenHarmony v4.0.0 and prior versions allow a local attacker arbitrary code execution in pre-installed apps through use after free or cause DOS through NULL pointer dereference. | |||||
| CVE-2023-36803 | 1 Microsoft | 9 Windows 10 1607, Windows 10 1809, Windows 10 21h2 and 6 more | 2025-01-01 | N/A | 5.5 MEDIUM |
| Windows Kernel Information Disclosure Vulnerability | |||||
| CVE-2023-35386 | 1 Microsoft | 11 Windows 10 1507, Windows 10 1607, Windows 10 1809 and 8 more | 2025-01-01 | N/A | 7.8 HIGH |
| Windows Kernel Elevation of Privilege Vulnerability | |||||
| CVE-2023-35358 | 1 Microsoft | 9 Windows 10 1607, Windows 10 1809, Windows 10 21h2 and 6 more | 2025-01-01 | N/A | 7.8 HIGH |
| Windows Kernel Elevation of Privilege Vulnerability | |||||
| CVE-2023-35357 | 1 Microsoft | 9 Windows 10 1607, Windows 10 1809, Windows 10 21h2 and 6 more | 2025-01-01 | N/A | 7.8 HIGH |
| Windows Kernel Elevation of Privilege Vulnerability | |||||
| CVE-2023-32045 | 1 Microsoft | 12 Windows 10 1507, Windows 10 1607, Windows 10 1809 and 9 more | 2025-01-01 | N/A | 7.5 HIGH |
| Microsoft Message Queuing (MSMQ) Denial of Service Vulnerability | |||||
| CVE-2023-32044 | 1 Microsoft | 12 Windows 10 1507, Windows 10 1607, Windows 10 1809 and 9 more | 2025-01-01 | N/A | 7.5 HIGH |
| Microsoft Message Queuing (MSMQ) Denial of Service Vulnerability | |||||
| CVE-2023-21769 | 1 Microsoft | 12 Windows 10 1607, Windows 10 1809, Windows 10 20h2 and 9 more | 2025-01-01 | N/A | 7.5 HIGH |
| Microsoft Message Queuing (MSMQ) Denial of Service Vulnerability | |||||
| CVE-2023-21776 | 1 Microsoft | 10 Windows 10, Windows 11, Windows 7 and 7 more | 2025-01-01 | N/A | 5.5 MEDIUM |
| Windows Kernel Information Disclosure Vulnerability | |||||
| CVE-2021-46980 | 1 Linux | 1 Linux Kernel | 2024-12-31 | N/A | 7.1 HIGH |
| In the Linux kernel, the following vulnerability has been resolved: usb: typec: ucsi: Retrieve all the PDOs instead of just the first 4 commit 4dbc6a4ef06d ("usb: typec: ucsi: save power data objects in PD mode") introduced retrieval of the PDOs when connected to a PD-capable source. But only the first 4 PDOs are received since that is the maximum number that can be fetched at a time given the MESSAGE_IN length limitation (16 bytes). However, as per the PD spec a connected source may advertise up to a maximum of 7 PDOs. If such a source is connected it's possible the PPM could have negotiated a power contract with one of the PDOs at index greater than 4, and would be reflected in the request data object's (RDO) object position field. This would result in an out-of-bounds access when the rdo_index() is used to index into the src_pdos array in ucsi_psy_get_voltage_now(). With the help of the UBSAN -fsanitize=array-bounds checker enabled this exact issue is revealed when connecting to a PD source adapter that advertise 5 PDOs and the PPM enters a contract having selected the 5th one. [ 151.545106][ T70] Unexpected kernel BRK exception at EL1 [ 151.545112][ T70] Internal error: BRK handler: f2005512 [#1] PREEMPT SMP ... [ 151.545499][ T70] pc : ucsi_psy_get_prop+0x208/0x20c [ 151.545507][ T70] lr : power_supply_show_property+0xc0/0x328 ... [ 151.545542][ T70] Call trace: [ 151.545544][ T70] ucsi_psy_get_prop+0x208/0x20c [ 151.545546][ T70] power_supply_uevent+0x1a4/0x2f0 [ 151.545550][ T70] dev_uevent+0x200/0x384 [ 151.545555][ T70] kobject_uevent_env+0x1d4/0x7e8 [ 151.545557][ T70] power_supply_changed_work+0x174/0x31c [ 151.545562][ T70] process_one_work+0x244/0x6f0 [ 151.545564][ T70] worker_thread+0x3e0/0xa64 We can resolve this by instead retrieving and storing up to the maximum of 7 PDOs in the con->src_pdos array. This would involve two calls to the GET_PDOS command. | |||||
| CVE-2021-47390 | 1 Linux | 1 Linux Kernel | 2024-12-30 | N/A | 7.1 HIGH |
| In the Linux kernel, the following vulnerability has been resolved: KVM: x86: Fix stack-out-of-bounds memory access from ioapic_write_indirect() KASAN reports the following issue: BUG: KASAN: stack-out-of-bounds in kvm_make_vcpus_request_mask+0x174/0x440 [kvm] Read of size 8 at addr ffffc9001364f638 by task qemu-kvm/4798 CPU: 0 PID: 4798 Comm: qemu-kvm Tainted: G X --------- --- Hardware name: AMD Corporation DAYTONA_X/DAYTONA_X, BIOS RYM0081C 07/13/2020 Call Trace: dump_stack+0xa5/0xe6 print_address_description.constprop.0+0x18/0x130 ? kvm_make_vcpus_request_mask+0x174/0x440 [kvm] __kasan_report.cold+0x7f/0x114 ? kvm_make_vcpus_request_mask+0x174/0x440 [kvm] kasan_report+0x38/0x50 kasan_check_range+0xf5/0x1d0 kvm_make_vcpus_request_mask+0x174/0x440 [kvm] kvm_make_scan_ioapic_request_mask+0x84/0xc0 [kvm] ? kvm_arch_exit+0x110/0x110 [kvm] ? sched_clock+0x5/0x10 ioapic_write_indirect+0x59f/0x9e0 [kvm] ? static_obj+0xc0/0xc0 ? __lock_acquired+0x1d2/0x8c0 ? kvm_ioapic_eoi_inject_work+0x120/0x120 [kvm] The problem appears to be that 'vcpu_bitmap' is allocated as a single long on stack and it should really be KVM_MAX_VCPUS long. We also seem to clear the lower 16 bits of it with bitmap_zero() for no particular reason (my guess would be that 'bitmap' and 'vcpu_bitmap' variables in kvm_bitmap_or_dest_vcpus() caused the confusion: while the later is indeed 16-bit long, the later should accommodate all possible vCPUs). | |||||
| CVE-2021-47240 | 1 Linux | 1 Linux Kernel | 2024-12-30 | N/A | 7.1 HIGH |
| In the Linux kernel, the following vulnerability has been resolved: net: qrtr: fix OOB Read in qrtr_endpoint_post Syzbot reported slab-out-of-bounds Read in qrtr_endpoint_post. The problem was in wrong _size_ type: if (len != ALIGN(size, 4) + hdrlen) goto err; If size from qrtr_hdr is 4294967293 (0xfffffffd), the result of ALIGN(size, 4) will be 0. In case of len == hdrlen and size == 4294967293 in header this check won't fail and skb_put_data(skb, data + hdrlen, size); will read out of bound from data, which is hdrlen allocated block. | |||||
| CVE-2021-47243 | 1 Linux | 1 Linux Kernel | 2024-12-30 | N/A | 7.1 HIGH |
| In the Linux kernel, the following vulnerability has been resolved: sch_cake: Fix out of bounds when parsing TCP options and header The TCP option parser in cake qdisc (cake_get_tcpopt and cake_tcph_may_drop) could read one byte out of bounds. When the length is 1, the execution flow gets into the loop, reads one byte of the opcode, and if the opcode is neither TCPOPT_EOL nor TCPOPT_NOP, it reads one more byte, which exceeds the length of 1. This fix is inspired by commit 9609dad263f8 ("ipv4: tcp_input: fix stack out of bounds when parsing TCP options."). v2 changes: Added doff validation in cake_get_tcphdr to avoid parsing garbage as TCP header. Although it wasn't strictly an out-of-bounds access (memory was allocated), garbage values could be read where CAKE expected the TCP header if doff was smaller than 5. | |||||
| CVE-2021-47245 | 1 Linux | 1 Linux Kernel | 2024-12-30 | N/A | 7.1 HIGH |
| In the Linux kernel, the following vulnerability has been resolved: netfilter: synproxy: Fix out of bounds when parsing TCP options The TCP option parser in synproxy (synproxy_parse_options) could read one byte out of bounds. When the length is 1, the execution flow gets into the loop, reads one byte of the opcode, and if the opcode is neither TCPOPT_EOL nor TCPOPT_NOP, it reads one more byte, which exceeds the length of 1. This fix is inspired by commit 9609dad263f8 ("ipv4: tcp_input: fix stack out of bounds when parsing TCP options."). v2 changes: Added an early return when length < 0 to avoid calling skb_header_pointer with negative length. | |||||
| CVE-2024-26174 | 1 Microsoft | 14 Windows 10 1507, Windows 10 1607, Windows 10 1809 and 11 more | 2024-12-27 | N/A | 5.5 MEDIUM |
| Windows Kernel Information Disclosure Vulnerability | |||||