Search
Search Results (14 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-72014 | 1 Linux | 1 Linux Kernel | 2026-08-17 | 9.8 Critical |
| In the Linux kernel, the following vulnerability has been resolved: drbd: reject data replies with an out-of-range payload size recv_dless_read() receives a P_DATA_REPLY from a peer into the bio of an outstanding read request. The peer-supplied payload length reaches it as the signed int data_size, and two peer-controlled inputs can make it negative. With a negotiated data-integrity-alg the digest length is subtracted first, so a reply whose payload is smaller than the digest underflows data_size. With no integrity algorithm (the default) data_size is assigned from the unsigned h95/h100 wire length and drbdd() never bounds it for a payload-carrying command, so a length above INT_MAX casts it negative; this path needs no non-default feature. The bio receive loop then computes expect = min_t(int, data_size, bv_len), which is negative, and drbd_recv_all_warn(mapped, expect) receives with a size_t of SIZE_MAX into the first mapped page. The sibling receive path read_in_block() is not affected: it uses an unsigned size and rejects it against DRBD_MAX_BIO_SIZE before receiving. Reject a data reply whose size is negative after the optional digest subtraction, covering both triggers. Impact: a malicious or man-in-the-middle DRBD peer copies attacker-chosen bytes past a bio page in the receiver, corrupting kernel memory. A node that reads from its peer (a diskless node, or read-balancing to the peer) is exposed in the default configuration; data-integrity-alg is not required. | ||||
| CVE-2026-72367 | 1 Linux | 1 Linux Kernel | 2026-08-17 | 8.8 High |
| In the Linux kernel, the following vulnerability has been resolved: iomap: guard io_size EOF trim against concurrent truncate underflow iomap: fix zero padding data issue in concurrent append writes changed ioend accounting so that io_size tracks only valid data within EOF. This trims io_size when a writeback range extends past end_pos: ioend->io_size += map_len; if (ioend->io_offset + ioend->io_size > end_pos) ioend->io_size = end_pos - ioend->io_offset; However, if end_pos ends up below ioend->io_offset, the subtraction becomes negative and is stored in size_t io_size, causing an unsigned wrap to a huge value. This can happen when writeback continues past byte-level EOF up to a block-aligned range, or when a concurrent truncate shrinks the file after end_pos was sampled in iomap_writeback_handle_eof(). A wrapped io_size can mislead append detection and corrupt completion-time size handling, since filesystem end_io paths consume io_size for decisions such as on-disk EOF updates and unwritten/COW completion ranges. Fix this by clamping io_size to zero when EOF has moved to or before the ioend start offset. This preserves the original intent of trimming io_size to valid in-EOF data while avoiding the underflow. | ||||
| 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.