Search
Search Results (14 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-64269 | 1 Linux | 1 Linux Kernel | 2026-07-27 | 9.1 Critical |
| In the Linux kernel, the following vulnerability has been resolved: RDMA/rtrs-srv: Bound RDMA-Write length to chunk size in rdma_write_sg When the server answers an RTRS READ, rdma_write_sg() builds the source scatter/gather entry for the IB_WR_RDMA_WRITE that returns data to the peer. Its length is taken directly from the wire descriptor: plist->length = le32_to_cpu(id->rd_msg->desc[0].len); rd_msg points into the chunk buffer that the remote peer filled via RDMA-WRITE-WITH-IMM (rtrs_srv_rdma_done() -> process_io_req() -> process_read()), so desc[0].len is attacker-controlled and, before this change, was only rejected when zero. The source address is the fixed chunk start (dma_addr[msg_id]) and the source lkey is the PD-wide local_dma_lkey, which is not tied to the chunk's MR mapping, so the verbs layer does not constrain the transfer length to max_chunk_size. msg_id and off are bounded against queue_depth and max_chunk_size in rtrs_srv_rdma_done(), but desc[0].len is a separate field that was not checked against the chunk size. A peer that advertises desc[0].len larger than max_chunk_size can make the posted RDMA write read past the chunk's mapped region. The resulting behaviour depends on the IOMMU configuration: with no IOMMU or in passthrough mode the read may extend into memory adjacent to the chunk and be returned to the peer, which can disclose host memory; with a translating IOMMU the out-of-range access is expected to fault and abort the connection. In either case the transfer exceeds what the protocol permits and is driven by a remote peer. Reject a descriptor length above max_chunk_size, mirroring the existing off >= max_chunk_size bound in rtrs_srv_rdma_done(). Legitimate clients do not exceed it: the client sets desc[0].len to its MR length, which is capped at the negotiated max_io_size (max_chunk_size - MAX_HDR_SIZE). | ||||
| CVE-2026-64497 | 1 Linux | 1 Linux Kernel | 2026-07-26 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: iio: chemical: scd30: Cleanup initializations and fix sign-extension bug Include linux/bitfield.h for FIELD_GET(). Create new macros for bit manipulation in combination with manual bit manipulation being replaced with FIELD_GET(). The current variable declaration and initializations are barely readable and use comma separations across multiple lines. Refactor the initializations so that mantissa and exp have separate declarations and sign gets initialized later. In addition (and due to the nature of the cleanup), fix a sign-extension bug where, float32 would get bitwise anded with ~BIT(31) (which is 0xFFFFFFFF7FFFFFFF) which corrupted the exponent. | ||||
| CVE-2026-23085 | 1 Linux | 1 Linux Kernel | 2026-06-11 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: irqchip/gic-v3-its: Avoid truncating memory addresses On 32-bit machines with CONFIG_ARM_LPAE, it is possible for lowmem allocations to be backed by addresses physical memory above the 32-bit address limit, as found while experimenting with larger VMSPLIT configurations. This caused the qemu virt model to crash in the GICv3 driver, which allocates the 'itt' object using GFP_KERNEL. Since all memory below the 4GB physical address limit is in ZONE_DMA in this configuration, kmalloc() defaults to higher addresses for ZONE_NORMAL, and the ITS driver stores the physical address in a 32-bit 'unsigned long' variable. Change the itt_addr variable to the correct phys_addr_t type instead, along with all other variables in this driver that hold a physical address. The gicv5 driver correctly uses u64 variables, while all other irqchip drivers don't call virt_to_phys or similar interfaces. It's expected that other device drivers have similar issues, but fixing this one is sufficient for booting a virtio based guest. | ||||
| CVE-2025-13632 | 4 Apple, Google, Linux and 1 more | 4 Macos, Chrome, Linux Kernel and 1 more | 2025-12-04 | 5.4 Medium |
| Inappropriate implementation in DevTools in Google Chrome prior to 143.0.7499.41 allowed an attacker who convinced a user to install a malicious extension to potentially perform a sandbox escape via a crafted Chrome Extension. (Chromium security severity: High) | ||||
| CVE-2015-8869 | 4 Fedoraproject, Ocaml, Opensuse and 1 more | 4 Fedora, Ocaml, Opensuse and 1 more | 2025-04-12 | N/A |
| OCaml before 4.03.0 does not properly handle sign extensions, which allows remote attackers to conduct buffer overflow attacks or obtain sensitive information as demonstrated by a long string to the String.copy function. | ||||
| CVE-2016-2315 | 4 Git-scm, Opensuse, Redhat and 1 more | 10 Git, Leap, Opensuse and 7 more | 2025-04-12 | 9.8 Critical |
| revision.c in git before 2.7.4 uses an incorrect integer data type, which allows remote attackers to execute arbitrary code via a (1) long filename or (2) many nested trees, leading to a heap-based buffer overflow. | ||||
| CVE-2016-2324 | 4 Git-scm, Opensuse, Redhat and 1 more | 10 Git, Leap, Opensuse and 7 more | 2025-04-12 | 9.8 Critical |
| Integer overflow in Git before 2.7.4 allows remote attackers to execute arbitrary code via a (1) long filename or (2) many nested trees, which triggers a heap-based buffer overflow. | ||||
| CVE-2013-1996 | 1 X | 1 Libfs | 2025-04-11 | N/A |
| X.org libFS 1.0.4 and earlier allows X servers to trigger allocation of insufficient memory and a buffer overflow via vectors related to an unexpected sign extension in the FSOpenServer function. | ||||
| CVE-2022-32138 | 1 Codesys | 2 Plcwinnt, Runtime Toolkit | 2024-11-21 | 8.8 High |
| In multiple CODESYS products, a remote attacker may craft a request which may cause an unexpected sign extension, resulting in a denial-of-service condition or memory overwrite. | ||||
| CVE-2021-38434 | 1 Fatek | 1 Winproladder | 2024-11-21 | 7.8 High |
| FATEK Automation WinProladder versions 3.30 and prior lacks proper validation of user-supplied data when parsing project files, which could result in an unexpected sign extension. An attacker could leverage this vulnerability to execute arbitrary code. | ||||
| CVE-2020-13544 | 1 Softmaker | 1 Softmaker Office | 2024-11-21 | 7.8 High |
| An exploitable sign extension vulnerability exists in the TextMaker document parsing functionality of SoftMaker Office 2021’s TextMaker application. A specially crafted document can cause the document parser to sign-extend a length used to terminate a loop, which can later result in the loop’s index being used to write outside the bounds of a heap buffer during the reading of file data. An attacker can entice the victim to open a document to trigger this vulnerability. | ||||
| CVE-2019-7125 | 3 Adobe, Apple, Microsoft | 4 Acrobat Dc, Acrobat Reader Dc, Mac Os X and 1 more | 2024-11-21 | N/A |
| Adobe Acrobat and Reader versions 2019.010.20098 and earlier, 2019.010.20098 and earlier, 2017.011.30127 and earlier version, and 2015.006.30482 and earlier have a heap overflow vulnerability. Successful exploitation could lead to arbitrary code execution . | ||||
| CVE-2018-6412 | 1 Linux | 1 Linux Kernel | 2024-11-21 | N/A |
| In the function sbusfb_ioctl_helper() in drivers/video/fbdev/sbuslib.c in the Linux kernel through 4.15, an integer signedness error allows arbitrary information leakage for the FBIOPUTCMAP_SPARC and FBIOGETCMAP_SPARC commands. | ||||
| CVE-2018-10887 | 2 Debian, Libgit2 | 2 Debian Linux, Libgit2 | 2024-11-21 | 8.1 High |
| A flaw was found in libgit2 before version 0.27.3. It has been discovered that an unexpected sign extension in git_delta_apply function in delta.c file may lead to an integer overflow which in turn leads to an out of bound read, allowing to read before the base object. An attacker may use this flaw to leak memory addresses or cause a Denial of Service. | ||||
Page 1 of 1.