Export limit exceeded: 48521 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (48521 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-20488 | 2 Mediatek, Mediatek, Inc. | 35 Mt6991, Mt6991 Firmware, Mt6993 and 32 more | 2026-08-19 | 4.4 Medium |
| In display, there is a possible information disclosure due to a missing bounds check. This could lead to local information disclosure if a malicious actor has already obtained the System privilege. User interaction is not needed for exploitation. Patch ID: ALPS11004276; Issue ID: MSV-7757. | ||||
| CVE-2026-20489 | 2 Mediatek, Mediatek, Inc. | 35 Mt6991, Mt6991 Firmware, Mt6993 and 32 more | 2026-08-19 | 4.4 Medium |
| In display, there is a possible information disclosure due to an integer overflow. This could lead to local information disclosure if a malicious actor has already obtained the System privilege. User interaction is not needed for exploitation. Patch ID: ALPS11004274; Issue ID: MSV-7749. | ||||
| CVE-2026-17212 | 1 Ibm | 1 I | 2026-08-19 | 5.3 Medium |
| IBM i 7.6, 7.5, 7.4, and 7.3 could allow a remote attacker to cause a denial of service due to an out-of-bounds read. | ||||
| CVE-2026-74579 | 1 Linux | 1 Linux Kernel | 2026-08-19 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_payload: fix mask build for partial field offload nft_payload_offload_mask() builds the offload match mask for a payload expression that covers only part of a header field. For a partial IPv6 address match (field_len = 16, priv_len = 1) that shift is 1 << 120, which is undefined on the 32-bit int operand. It also trims only one word, so the remaining words stay 0xffffffff (and when priv_len is a multiple of 4 the trim is skipped entirely), leaving the mask covering more bytes than the rule matches. UBSAN: shift-out-of-bounds in net/netfilter/nft_payload.c:278:20 shift exponent 120 is too large for 32-bit type 'int' ... The match is byte-granular and struct nft_data is zero-initialised, so the correct mask is simply the first priv_len bytes set to 0xff. Set those bytes directly and drop the word/shift trimming; this removes the undefined shift and no longer over-masks the trailing bytes. | ||||
| CVE-2026-17216 | 1 Ibm | 1 I | 2026-08-19 | 5.3 Medium |
| IBM i 7.6, 7.5, 7.4, and 7.3 could allow a remote attacker to cause a denial of service due to an integer error when processing DRDA large-object headers. | ||||
| CVE-2026-17226 | 1 Ibm | 1 I | 2026-08-19 | 5.4 Medium |
| IBM i 7.6, 7.5, 7.4, and 7.3 could allow a remote authenticated attacker to obtain sensitive information or cause a denial of service due to an out-of-bounds read. | ||||
| CVE-2026-74549 | 1 Linux | 1 Linux Kernel | 2026-08-19 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: hwmon: (nct6775-core) Prevent access to unsupported weight registers Sashiko reports: During initialization of the nct6116 chip, the driver sets data->pwm_num to 5. However, it assigns several NCT6106 register arrays (such as NCT6106_REG_WEIGHT_DUTY_STEP, NCT6106_REG_WEIGHT_TEMP_SEL, and NCT6106_REG_WEIGHT_TEMP_*) to data->REG_PWM and data->REG_WEIGHT_TEMP. These arrays only contain 3 elements. In nct6775_update_pwm(), the driver iterates up to data->pwm_num. If data->has_pwm has bits 3 or 4 set (which is structurally possible for nct6116), the loop attempts to read elements at index 3 and 4 from these 3-element arrays. This results in a global out-of-bounds read, which can be caught by KASAN. Furthermore, the driver uses these garbage out-of-bounds values as hardware register addresses for subsequent read and write operations. This leads to invalid hardware register access, potentially causing hardware misconfiguration or system crashes. The underlying problem is that the chip does support up to five fan control channels, but only the first three support weight control. Fix the problem by extending the affected weight register arrays with zeroed fields. The driver uses zeroed register addresses to determine if a register is supported or not, and skips accesses for unsupported registers. | ||||
| CVE-2026-74519 | 1 Linux | 1 Linux Kernel | 2026-08-19 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: pinctrl: devicetree: don't free uninitialized dev_name on error path dt_remember_or_free_map() duplicates dev_name for each map entry. If kstrdup_const() fails, dt_free_map() frees dev_name in all num_maps entries, including entries that have not been initialized. Some pinctrl drivers, including pinctrl-imx, allocate the map with kmalloc() and leave dev_name for the core to initialize. The untouched entries therefore contain uninitialized data which is passed to kfree_const(). Reproduced on qemu's mcimx6ul-evk (pinctrl-imx) with failslab injection while binding the pinctrl-consuming device, under KASAN: BUG: KASAN: double-free in dt_free_map+0x34/0xa4 Free of addr c425a900 by task init/1 kfree from dt_free_map+0x34/0xa4 dt_free_map from dt_remember_or_free_map+0x184/0x198 dt_remember_or_free_map from pinctrl_dt_to_map+0x33c/0x4c8 pinctrl_dt_to_map from create_pinctrl+0x9c/0x5c0 Initialize all dev_name fields to NULL before duplicating the device name, making the full-map cleanup safe after a partial failure. | ||||
| CVE-2026-74964 | 1 Mozilla | 2 Firefox, Thunderbird | 2026-08-19 | 9.8 Critical |
| Integer overflow in the Graphics component. This vulnerability was fixed in Firefox 154, Firefox ESR 140.14, Firefox ESR 153.1, Thunderbird 154, Thunderbird 140.14, and Thunderbird 153.1. | ||||
| CVE-2026-74508 | 1 Linux | 1 Linux Kernel | 2026-08-19 | 8.8 High |
| In the Linux kernel, the following vulnerability has been resolved: Bluetooth: HIDP: reject frames without a transaction header hidp_recv_ctrl_frame() and hidp_recv_intr_frame() read skb->data[0] before checking that the L2CAP SDU contains a transaction header. A connected HIDP peer can send an empty basic-mode SDU and make both paths use an uninitialized byte from skb tailroom. KMSAN reports the use in hidp_session_run(), with the uninitialized value originating in __alloc_skb() through vhci_write(). The control path produces two reports and the interrupt path produces one. The byte can also be controlled by a malformed lower-layer packet. If an HCI ACL packet contains an L2CAP PDU with a declared zero-length payload followed by an extra 0x15 byte, l2cap_recv_acldata() reduces skb->len to the declared PDU length before dispatch. The current HIDP path nevertheless consumes the extra byte as HIDP_TRANS_HID_CONTROL | HIDP_CTRL_VIRTUAL_CABLE_UNPLUG and terminates the HIDP session. With this change, the same packet is discarded and a subsequent feature report request succeeds. Pull the transaction header with skb_pull_data() and discard frames that do not contain it. | ||||
| CVE-2026-74456 | 1 Linux | 1 Linux Kernel | 2026-08-19 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: can: peak_usb: peak_usb_start(): fix double free of transfer buffer on URB submit error In peak_usb_start(), each RX URB transfer buffer is allocated with kmalloc() and the URB is flagged URB_FREE_BUFFER so that the final usb_free_urb() also frees the transfer buffer. If usb_submit_urb() fails, the error path frees the buffer explicitly with kfree(buf) and then calls usb_free_urb(urb). Because URB_FREE_BUFFER is set, usb_free_urb() -> urb_destroy() frees the same buffer a second time, a double free of the transfer buffer. BUG: KASAN: double-free in usb_free_urb.part.0+0x91/0xb0 Free of addr ffff8881069ccb80 by task trigger.sh/285 Call Trace: kfree+0x113/0x3c0 usb_free_urb.part.0+0x91/0xb0 Drop the redundant kfree(buf); usb_free_urb() already releases the transfer buffer. This mirrors commit 03819abbeb11 ("net: usb: lan78xx: Fix double free issue with interrupt buffer allocation"). | ||||
| CVE-2026-72237 | 1 Linux | 1 Linux Kernel | 2026-08-19 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: perf/x86/amd/brs: Fix kernel address leakage A user-only branch stack can contain branches that originate from the kernel. As a result, kernel addresses are exposed to user space even when PERF_SAMPLE_BRANCH_USER is requested. On AMD processors supporting X86_FEATURE_BRS (Zen 3 only), perf can still report entries such as SYSRET/interrupt returns for which the branch-from addresses are in the kernel. E.g. $ perf record -j any,u -c 4000 -e branch-brs -o - -- \ perf bench syscall basic --loop 1000 | \ perf script -i - -F brstack|tr ' ' '\n'| \ grep -E '0x[89a-f][0-9a-f]{15}' ... 0xffffffff810001c4/0x72e2e32955eb/-/-/-/0//- 0xffffffff810001c4/0x72e2d94a9821/-/-/-/0//- 0xffffffff810001c4/0x72e2d94ffa1b/-/-/-/0//- ... BRS provides no hardware branch filtering, so privilege level filtering is performed entirely in software. However, amd_brs_match_plm() only validates the branch-to address against the requested privilege levels. For branches from the kernel to user space, the branch-from address is left unchecked and is leaked. Extend the software filter to also validate the branch-from address, so that any branch record whose branch-from address is in the kernel is dropped when PERF_SAMPLE_BRANCH_USER is requested. | ||||
| CVE-2026-72181 | 1 Linux | 1 Linux Kernel | 2026-08-19 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: mips: sched: Fix CPUMASK_OFFSTACK memory corruption This patch addresses a critical memory management flaw. When CONFIG_CPUMASK_OFFSTACK is enabled, cpumask_var_t is a pointer. Consequently, sizeof(new_mask) evaluates to the pointer size, causing copy_from_user() to clobber the mask pointer. Furthermore, the old logic performed copy_from_user() before allocating the mask. Fix this by allocating new_mask first. To handle variable-sized user masks correctly, use cpumask_size() to truncate overly large user masks or pad undersized masks with zeros before copying the data directly into the allocated buffer. | ||||
| CVE-2026-72114 | 1 Linux | 1 Linux Kernel | 2026-08-19 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: can: bcm: validate frame length in bcm_rx_setup() for RTR replies bcm_tx_setup() validates cf->len against the CAN/CAN FD DLC limits before installing frames for TX_SETUP, but bcm_rx_setup() never did the same for the RTR-reply frame configured via RX_SETUP with RX_RTR_FRAME. | ||||
| CVE-2026-72066 | 1 Linux | 1 Linux Kernel | 2026-08-19 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: cpu: hotplug: Bound hotplug states sysfs output states_show() adds CPU hotplug state names into a single sysfs buffer using sprintf(). With enough registered states, this can write past the end of the PAGE_SIZE buffer. Use sysfs_emit_at() so output is bounded. | ||||
| CVE-2026-72019 | 1 Linux | 1 Linux Kernel | 2026-08-19 | 7.3 High |
| In the Linux kernel, the following vulnerability has been resolved: macsec: don't read an unset MAC header in macsec_encrypt() macsec_encrypt() reads the Ethernet header via eth_hdr(skb) (skb->head + skb->mac_header) to memmove() the 12 source/destination MAC bytes forward and make room for the SecTAG. On the AF_PACKET SOCK_RAW + PACKET_QDISC_BYPASS transmit path the skb reaches the macsec ndo_start_xmit() with the MAC header unset, so eth_hdr(skb) resolves to skb->head + (u16)~0 and the read is out of bounds: a 12-byte heap over-read that is also emitted on the wire as the frame's outer source/destination MAC. KASAN reports a slab-out-of-bounds read in macsec_start_xmit() on 6.0; on current mainline a CONFIG_DEBUG_NET build flags it as an unset mac header in skb_mac_header(). On the TX path the L2 header is at skb->data, so use skb_eth_hdr(), added by commit 96cc4b69581d ("macvlan: do not assume mac_header is set in macvlan_broadcast()") for exactly this purpose. | ||||
| CVE-2026-68452 | 1 Linux | 1 Linux Kernel | 2026-08-19 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: s390/zcrypt: Validate length for CCA AES cipher key requests cca_cipher2protkey() derives the copy length for the CPRB parameter block directly from the length field in the key token. Reject the request early if the token length exceeds the available space in the parameter block. | ||||
| CVE-2026-68446 | 1 Linux | 1 Linux Kernel | 2026-08-19 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: drm/vmwgfx: Validate vmw_surface_metadata::array_size This field comes from userspace and should be validated against specific limits depending on which Shader Model (SM) is available. | ||||
| CVE-2026-18020 | 1 Ibm | 1 I | 2026-08-19 | 5.3 Medium |
| IBM i 7.6, 7.5, 7.4, and 7.3 could allow a remote attacker to cause a denial of service due to an off-by-one error in bounds checking. | ||||
| CVE-2026-68433 | 1 Linux | 1 Linux Kernel | 2026-08-19 | 8.6 High |
| In the Linux kernel, the following vulnerability has been resolved: libceph: bound get_version reply decode to front len handle_get_version_reply() uses msg->front_alloc_len as the decode boundary for MON_GET_VERSION_REPLY. That is the size of the reused reply buffer, not the number of bytes actually received. A truncated reply can therefore pass ceph_decode_need() and decode the second u64 from stale tail bytes left in the buffer by an earlier message, causing an uninitialized memory read. Use msg->front.iov_len as the receive-side decode boundary, matching other libceph reply handlers and limiting decoding to the bytes that were actually read from the wire. | ||||