Common Weakness Enumeration

CWE-125

Allowed

Out-of-bounds Read

Abstraction: Base · Status: Draft

API response cwe.mitre.org

The product reads data past the end, or before the beginning, of the intended buffer.

11454 vulnerabilities reference this CWE, most recent first.

GHSA-5876-WPJ2-HW48

Vulnerability from github – Published: 2025-03-18 21:32 – Updated: 2025-03-18 21:32
VLAI
Details

In the Linux kernel, the following vulnerability has been resolved:

drm/dp: Fix OOB read when handling Post Cursor2 register

The link_status array was not large enough to read the Adjust Request Post Cursor2 register, so remove the common helper function to avoid an OOB read, found with a -Warray-bounds build:

drivers/gpu/drm/drm_dp_helper.c: In function 'drm_dp_get_adjust_request_post_cursor': drivers/gpu/drm/drm_dp_helper.c:59:27: error: array subscript 10 is outside array bounds of 'const u8[6]' {aka 'const unsigned char[6]'} [-Werror=array-bounds] 59 | return link_status[r - DP_LANE0_1_STATUS]; | ~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~ drivers/gpu/drm/drm_dp_helper.c:147:51: note: while referencing 'link_status' 147 | u8 drm_dp_get_adjust_request_post_cursor(const u8 link_status[DP_LINK_STATUS_SIZE], | ~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Replace the only user of the helper with an open-coded fetch and decode, similar to drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c.

Severity
7.1 (High)
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2022-49218"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-125"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-02-26T07:00:58Z",
    "severity": "HIGH"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/dp: Fix OOB read when handling Post Cursor2 register\n\nThe link_status array was not large enough to read the Adjust Request\nPost Cursor2 register, so remove the common helper function to avoid\nan OOB read, found with a -Warray-bounds build:\n\ndrivers/gpu/drm/drm_dp_helper.c: In function \u0027drm_dp_get_adjust_request_post_cursor\u0027:\ndrivers/gpu/drm/drm_dp_helper.c:59:27: error: array subscript 10 is outside array bounds of \u0027const u8[6]\u0027 {aka \u0027const unsigned char[6]\u0027} [-Werror=array-bounds]\n   59 |         return link_status[r - DP_LANE0_1_STATUS];\n      |                ~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~\ndrivers/gpu/drm/drm_dp_helper.c:147:51: note: while referencing \u0027link_status\u0027\n  147 | u8 drm_dp_get_adjust_request_post_cursor(const u8 link_status[DP_LINK_STATUS_SIZE],\n      |                                          ~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n\nReplace the only user of the helper with an open-coded fetch and decode,\nsimilar to drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c.",
  "id": "GHSA-5876-wpj2-hw48",
  "modified": "2025-03-18T21:32:00Z",
  "published": "2025-03-18T21:32:00Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49218"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/a2151490cc6c57b368d7974ffd447a8b36ade639"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/aeaed9a9fe694f8b1462fb81e2d33298c929180b"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-588R-CR5C-W6HF

Vulnerability from github – Published: 2026-04-08 15:09 – Updated: 2026-04-08 15:09
VLAI
Summary
OpenEXR has a signed 32-bit Overflow in PIZ Decoder Leads to OOB Read/Write
Details

Summary

internal_exr_undo_piz() advances the working wavelet pointer with signed 32-bit arithmetic:

wavbuf += nx * ny * wcount;

Because nx, ny, and wcount are int, a crafted EXR file can make this product overflow and wrap. The next channel then decodes from an incorrect address. The wavelet decode path operates in place, so this yields both out-of-bounds reads and out-of-bounds writes.

Tested on commit 7820b7e1b93405ba1d551c43a945018226b75bc5

Technical Details

The vulnerable decode path is:

  1. internal_exr_undo_piz() sets wavbuf = decode->scratch_buffer_1.
  2. For each channel, it calls wav_2D_decode (wavbuf + j, ...).
  3. It then advances wavbuf with wavbuf += nx * ny * wcount.

The overflow happens in step 3. Once wavbuf is wrapped, the next channel's wavelet decode runs on the wrong address.

In the 14-bit wavelet path, wdec14_4() first reads:

  • *px
  • *p10
  • *p01
  • *p11

and then writes back to the same locations:

  • *px = ...
  • *p01 = ...
  • *p10 = ...
  • *p11 = ...

As a result, the bug is not just a crash-only invalid read. It is an out-of-bounds read/write condition.

Reproduction

piz_scanline_redzone.zip

Build exrcheck with ASAN and run:

❯ ./build-asan/bin/exrcheck /tmp/piz_scanline_redzone.exr
 file /tmp/piz_scanline_redzone.exr /home/pop/sec/openexr/src/lib/OpenEXRCore/internal_piz.c:373:19: runtime error: signed integer overflow: 134217724 * 32 cannot be represented in type 'int'
=================================================================
==1711239==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x7bedc3934700 at pc 0x7bf1f100f498 bp 0x7ffe032d8f00 sp 0x7ffe032d8ef0
READ of size 2 at 0x7bedc3934700 thread T0
    #0 0x7bf1f100f497 in wdec14_4 /home/pop/sec/openexr/src/lib/OpenEXRCore/internal_piz.c:148
    #1 0x7bf1f100f497 in wav_2D_decode /home/pop/sec/openexr/src/lib/OpenEXRCore/internal_piz.c:403
    #2 0x7bf1f100f497 in internal_exr_undo_piz /home/pop/sec/openexr/src/lib/OpenEXRCore/internal_piz.c:727
    #3 0x7bf1f115b038 in exr_uncompress_chunk /home/pop/sec/openexr/src/lib/OpenEXRCore/compression.c:546
    #4 0x7bf1f1161168 in exr_decoding_run /home/pop/sec/openexr/src/lib/OpenEXRCore/decoding.c:580
    #5 0x7bf1f2a71add in run_decode /home/pop/sec/openexr/src/lib/OpenEXR/ImfScanLineInputFile.cpp:586
    #6 0x7bf1f2a83dc4 in Imf_4_0::ScanLineInputFile::Data::readPixels(Imf_4_0::FrameBuffer const&, int, int) /home/pop/sec/openexr/src/lib/OpenEXR/ImfScanLineInputFile.cpp:500
    #7 0x7bf1f28c6a81 in Imf_4_0::InputFile::Data::readPixels(int, int) /home/pop/sec/openexr/src/lib/OpenEXR/ImfInputFile.cpp:458
    #8 0x7bf1f3bfe2dc in readScanline<Imf_4_0::InputPart> /home/pop/sec/openexr/src/lib/OpenEXRUtil/ImfCheckFile.cpp:239
    #9 0x7bf1f3c05b04 in readMultiPart /home/pop/sec/openexr/src/lib/OpenEXRUtil/ImfCheckFile.cpp:905
    #10 0x7bf1f3c126fd in runChecks<char const*> /home/pop/sec/openexr/src/lib/OpenEXRUtil/ImfCheckFile.cpp:1171
    #11 0x7bf1f3c146b9 in Imf_4_0::checkOpenEXRFile(char const*, bool, bool, bool) /home/pop/sec/openexr/src/lib/OpenEXRUtil/ImfCheckFile.cpp:1835
    #12 0x5d9675fce8f8 in exrCheck(char const*, bool, bool, bool, bool) /home/pop/sec/openexr/src/bin/exrcheck/main.cpp:96
    #13 0x5d9675fcb2b1 in main /home/pop/sec/openexr/src/bin/exrcheck/main.cpp:164
    #14 0x7bf1efe2a1c9 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
    #15 0x7bf1efe2a28a in __libc_start_main_impl ../csu/libc-start.c:360
    #16 0x5d9675fcc844 in _start (/home/pop/sec/openexr/build-asan/bin/exrcheck+0xe844) (BuildId: 087c972343a5372940c42c0a2e7bce4a84288aec)

0x7bedc3934700 is located 256 bytes before 8590720784-byte region [0x7bedc3934800,0x7befc39f4710)
allocated by thread T0 here:
    #0 0x7bf1f40fd9c7 in malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:69
    #1 0x7bf1f115883e in internal_decode_alloc_buffer /home/pop/sec/openexr/src/lib/OpenEXRCore/coding.c:256
    #2 0x7bf1f100da97 in internal_exr_undo_piz /home/pop/sec/openexr/src/lib/OpenEXRCore/internal_piz.c:643
    #3 0x7bf1f115b038 in exr_uncompress_chunk /home/pop/sec/openexr/src/lib/OpenEXRCore/compression.c:546
    #4 0x7bf1f1161168 in exr_decoding_run /home/pop/sec/openexr/src/lib/OpenEXRCore/decoding.c:580
    #5 0x7bf1f2a71add in run_decode /home/pop/sec/openexr/src/lib/OpenEXR/ImfScanLineInputFile.cpp:586
    #6 0x7bf1f2a83dc4 in Imf_4_0::ScanLineInputFile::Data::readPixels(Imf_4_0::FrameBuffer const&, int, int) /home/pop/sec/openexr/src/lib/OpenEXR/ImfScanLineInputFile.cpp:500
    #7 0x7bf1f28c6a81 in Imf_4_0::InputFile::Data::readPixels(int, int) /home/pop/sec/openexr/src/lib/OpenEXR/ImfInputFile.cpp:458
    #8 0x7bf1f3bfe2dc in readScanline<Imf_4_0::InputPart> /home/pop/sec/openexr/src/lib/OpenEXRUtil/ImfCheckFile.cpp:239
    #9 0x7bf1f3c05b04 in readMultiPart /home/pop/sec/openexr/src/lib/OpenEXRUtil/ImfCheckFile.cpp:905
    #10 0x7bf1f3c126fd in runChecks<char const*> /home/pop/sec/openexr/src/lib/OpenEXRUtil/ImfCheckFile.cpp:1171
    #11 0x7bf1f3c146b9 in Imf_4_0::checkOpenEXRFile(char const*, bool, bool, bool) /home/pop/sec/openexr/src/lib/OpenEXRUtil/ImfCheckFile.cpp:1835
    #12 0x5d9675fce8f8 in exrCheck(char const*, bool, bool, bool, bool) /home/pop/sec/openexr/src/bin/exrcheck/main.cpp:96
    #13 0x5d9675fcb2b1 in main /home/pop/sec/openexr/src/bin/exrcheck/main.cpp:164
    #14 0x7bf1efe2a1c9 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
    #15 0x7bf1efe2a28a in __libc_start_main_impl ../csu/libc-start.c:360
    #16 0x5d9675fcc844 in _start (/home/pop/sec/openexr/build-asan/bin/exrcheck+0xe844) (BuildId: 087c972343a5372940c42c0a2e7bce4a84288aec)

SUMMARY: AddressSanitizer: heap-buffer-overflow /home/pop/sec/openexr/src/lib/OpenEXRCore/internal_piz.c:148 in wdec14_4
Shadow bytes around the buggy address:
  0x7bedc3934480: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x7bedc3934500: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x7bedc3934580: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x7bedc3934600: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x7bedc3934680: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
=>0x7bedc3934700:[fa]fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x7bedc3934780: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x7bedc3934800: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x7bedc3934880: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x7bedc3934900: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x7bedc3934980: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07
  Heap left redzone:       fa
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
  Left alloca redzone:     ca
  Right alloca redzone:    cb
==1711239==ABORTING

To prove this is both READ and WRITE, we can also memcheck against non-ASAN release build:

valgrind --tool=memcheck --leak-check=no --track-origins=no \
  --error-limit=no --num-callers=20 \
  ./build-relwithdebinfo/bin/exrcheck /tmp/piz_scanline_redzone.exr

Observed result:

This confirms the bug is an OOB read/write, not only a read-first crash.

Redzone-Oriented File

  • width: 67108862
  • height: 32
  • channel A: FLOAT, sampling 1 x 1
  • channel B: HALF, sampling 33554431 x 16

This makes:

width * 32 * 2 = 4294967168

which wraps signed 32-bit arithmetic to -128.

That places the next wavbuf access just before the allocated buffer, producing a clean heap-overflow report.

Impact

A crafted EXR file can trigger out-of-bounds memory access during PIZ decompression. The primitive includes both invalid reads and invalid writes. Depending on allocator layout and surrounding memory, this could lead to process crash, memory corruption, or potentially stronger exploitation outcomes.

Recommended Fix

  • compute channel span in 64-bit arithmetic
  • reject any overflow in nx * ny * wcount
  • validate cumulative per-channel decoded footprint against outsz before wavelet decode
  • fail decompression if channel-derived layout does not exactly fit the decompression buffer

Found by: Quang Luong of Calif.io

Severity
7.8 (High)
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
8.6 (High)
CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "OpenEXR"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.1.0"
            },
            {
              "fixed": "3.2.7"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "OpenEXR"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.3.0"
            },
            {
              "fixed": "3.3.9"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "OpenEXR"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.4.0"
            },
            {
              "fixed": "3.4.9"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-34588"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-125",
      "CWE-190",
      "CWE-787"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-08T15:09:01Z",
    "nvd_published_at": "2026-04-06T16:16:35Z",
    "severity": "HIGH"
  },
  "details": "## Summary\n\n`internal_exr_undo_piz()` advances the working wavelet pointer with signed 32-bit arithmetic:\n\n```c\nwavbuf += nx * ny * wcount;\n```\n\nBecause `nx`, `ny`, and `wcount` are `int`, a crafted EXR file can make this product overflow and wrap. The next channel then decodes from an incorrect address. The wavelet decode path operates in place, so this yields both out-of-bounds reads and out-of-bounds writes.\n\nTested on commit 7820b7e1b93405ba1d551c43a945018226b75bc5\n\n## Technical Details\n\nThe vulnerable decode path is:\n\n1. `internal_exr_undo_piz()` sets `wavbuf = decode-\u003escratch_buffer_1`.\n2. For each channel, it calls `wav_2D_decode (wavbuf + j, ...)`.\n3. It then advances `wavbuf` with `wavbuf += nx * ny * wcount`.\n\nThe overflow happens in step 3. Once `wavbuf` is wrapped, the next channel\u0027s wavelet decode runs on the wrong address.\n\nIn the 14-bit wavelet path, `wdec14_4()` first reads:\n\n- `*px`\n- `*p10`\n- `*p01`\n- `*p11`\n\nand then writes back to the same locations:\n\n- `*px  = ...`\n- `*p01 = ...`\n- `*p10 = ...`\n- `*p11 = ...`\n\nAs a result, the bug is not just a crash-only invalid read. It is an out-of-bounds read/write condition.\n\n## Reproduction\n\n[piz_scanline_redzone.zip](https://github.com/user-attachments/files/26318946/piz_scanline_redzone.zip)\n\nBuild `exrcheck` with ASAN and run:\n\n```\n\u276f ./build-asan/bin/exrcheck /tmp/piz_scanline_redzone.exr\n file /tmp/piz_scanline_redzone.exr /home/pop/sec/openexr/src/lib/OpenEXRCore/internal_piz.c:373:19: runtime error: signed integer overflow: 134217724 * 32 cannot be represented in type \u0027int\u0027\n=================================================================\n==1711239==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x7bedc3934700 at pc 0x7bf1f100f498 bp 0x7ffe032d8f00 sp 0x7ffe032d8ef0\nREAD of size 2 at 0x7bedc3934700 thread T0\n    #0 0x7bf1f100f497 in wdec14_4 /home/pop/sec/openexr/src/lib/OpenEXRCore/internal_piz.c:148\n    #1 0x7bf1f100f497 in wav_2D_decode /home/pop/sec/openexr/src/lib/OpenEXRCore/internal_piz.c:403\n    #2 0x7bf1f100f497 in internal_exr_undo_piz /home/pop/sec/openexr/src/lib/OpenEXRCore/internal_piz.c:727\n    #3 0x7bf1f115b038 in exr_uncompress_chunk /home/pop/sec/openexr/src/lib/OpenEXRCore/compression.c:546\n    #4 0x7bf1f1161168 in exr_decoding_run /home/pop/sec/openexr/src/lib/OpenEXRCore/decoding.c:580\n    #5 0x7bf1f2a71add in run_decode /home/pop/sec/openexr/src/lib/OpenEXR/ImfScanLineInputFile.cpp:586\n    #6 0x7bf1f2a83dc4 in Imf_4_0::ScanLineInputFile::Data::readPixels(Imf_4_0::FrameBuffer const\u0026, int, int) /home/pop/sec/openexr/src/lib/OpenEXR/ImfScanLineInputFile.cpp:500\n    #7 0x7bf1f28c6a81 in Imf_4_0::InputFile::Data::readPixels(int, int) /home/pop/sec/openexr/src/lib/OpenEXR/ImfInputFile.cpp:458\n    #8 0x7bf1f3bfe2dc in readScanline\u003cImf_4_0::InputPart\u003e /home/pop/sec/openexr/src/lib/OpenEXRUtil/ImfCheckFile.cpp:239\n    #9 0x7bf1f3c05b04 in readMultiPart /home/pop/sec/openexr/src/lib/OpenEXRUtil/ImfCheckFile.cpp:905\n    #10 0x7bf1f3c126fd in runChecks\u003cchar const*\u003e /home/pop/sec/openexr/src/lib/OpenEXRUtil/ImfCheckFile.cpp:1171\n    #11 0x7bf1f3c146b9 in Imf_4_0::checkOpenEXRFile(char const*, bool, bool, bool) /home/pop/sec/openexr/src/lib/OpenEXRUtil/ImfCheckFile.cpp:1835\n    #12 0x5d9675fce8f8 in exrCheck(char const*, bool, bool, bool, bool) /home/pop/sec/openexr/src/bin/exrcheck/main.cpp:96\n    #13 0x5d9675fcb2b1 in main /home/pop/sec/openexr/src/bin/exrcheck/main.cpp:164\n    #14 0x7bf1efe2a1c9 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58\n    #15 0x7bf1efe2a28a in __libc_start_main_impl ../csu/libc-start.c:360\n    #16 0x5d9675fcc844 in _start (/home/pop/sec/openexr/build-asan/bin/exrcheck+0xe844) (BuildId: 087c972343a5372940c42c0a2e7bce4a84288aec)\n\n0x7bedc3934700 is located 256 bytes before 8590720784-byte region [0x7bedc3934800,0x7befc39f4710)\nallocated by thread T0 here:\n    #0 0x7bf1f40fd9c7 in malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:69\n    #1 0x7bf1f115883e in internal_decode_alloc_buffer /home/pop/sec/openexr/src/lib/OpenEXRCore/coding.c:256\n    #2 0x7bf1f100da97 in internal_exr_undo_piz /home/pop/sec/openexr/src/lib/OpenEXRCore/internal_piz.c:643\n    #3 0x7bf1f115b038 in exr_uncompress_chunk /home/pop/sec/openexr/src/lib/OpenEXRCore/compression.c:546\n    #4 0x7bf1f1161168 in exr_decoding_run /home/pop/sec/openexr/src/lib/OpenEXRCore/decoding.c:580\n    #5 0x7bf1f2a71add in run_decode /home/pop/sec/openexr/src/lib/OpenEXR/ImfScanLineInputFile.cpp:586\n    #6 0x7bf1f2a83dc4 in Imf_4_0::ScanLineInputFile::Data::readPixels(Imf_4_0::FrameBuffer const\u0026, int, int) /home/pop/sec/openexr/src/lib/OpenEXR/ImfScanLineInputFile.cpp:500\n    #7 0x7bf1f28c6a81 in Imf_4_0::InputFile::Data::readPixels(int, int) /home/pop/sec/openexr/src/lib/OpenEXR/ImfInputFile.cpp:458\n    #8 0x7bf1f3bfe2dc in readScanline\u003cImf_4_0::InputPart\u003e /home/pop/sec/openexr/src/lib/OpenEXRUtil/ImfCheckFile.cpp:239\n    #9 0x7bf1f3c05b04 in readMultiPart /home/pop/sec/openexr/src/lib/OpenEXRUtil/ImfCheckFile.cpp:905\n    #10 0x7bf1f3c126fd in runChecks\u003cchar const*\u003e /home/pop/sec/openexr/src/lib/OpenEXRUtil/ImfCheckFile.cpp:1171\n    #11 0x7bf1f3c146b9 in Imf_4_0::checkOpenEXRFile(char const*, bool, bool, bool) /home/pop/sec/openexr/src/lib/OpenEXRUtil/ImfCheckFile.cpp:1835\n    #12 0x5d9675fce8f8 in exrCheck(char const*, bool, bool, bool, bool) /home/pop/sec/openexr/src/bin/exrcheck/main.cpp:96\n    #13 0x5d9675fcb2b1 in main /home/pop/sec/openexr/src/bin/exrcheck/main.cpp:164\n    #14 0x7bf1efe2a1c9 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58\n    #15 0x7bf1efe2a28a in __libc_start_main_impl ../csu/libc-start.c:360\n    #16 0x5d9675fcc844 in _start (/home/pop/sec/openexr/build-asan/bin/exrcheck+0xe844) (BuildId: 087c972343a5372940c42c0a2e7bce4a84288aec)\n\nSUMMARY: AddressSanitizer: heap-buffer-overflow /home/pop/sec/openexr/src/lib/OpenEXRCore/internal_piz.c:148 in wdec14_4\nShadow bytes around the buggy address:\n  0x7bedc3934480: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa\n  0x7bedc3934500: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa\n  0x7bedc3934580: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa\n  0x7bedc3934600: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa\n  0x7bedc3934680: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa\n=\u003e0x7bedc3934700:[fa]fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa\n  0x7bedc3934780: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa\n  0x7bedc3934800: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00\n  0x7bedc3934880: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00\n  0x7bedc3934900: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00\n  0x7bedc3934980: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00\nShadow byte legend (one shadow byte represents 8 application bytes):\n  Addressable:           00\n  Partially addressable: 01 02 03 04 05 06 07\n  Heap left redzone:       fa\n  Freed heap region:       fd\n  Stack left redzone:      f1\n  Stack mid redzone:       f2\n  Stack right redzone:     f3\n  Stack after return:      f5\n  Stack use after scope:   f8\n  Global redzone:          f9\n  Global init order:       f6\n  Poisoned by user:        f7\n  Container overflow:      fc\n  Array cookie:            ac\n  Intra object redzone:    bb\n  ASan internal:           fe\n  Left alloca redzone:     ca\n  Right alloca redzone:    cb\n==1711239==ABORTING\n```\n\nTo prove this is both READ and WRITE, we can also `memcheck` against non-ASAN release build:\n\n```sh\nvalgrind --tool=memcheck --leak-check=no --track-origins=no \\\n  --error-limit=no --num-callers=20 \\\n  ./build-relwithdebinfo/bin/exrcheck /tmp/piz_scanline_redzone.exr\n```\n\nObserved result:\n\n- `Invalid read of size 2` at [internal_piz.c:150](/home/pop/sec/openexr/src/lib/OpenEXRCore/internal_piz.c#L150)\n- `Invalid write of size 2` at [internal_piz.c:171](/home/pop/sec/openexr/src/lib/OpenEXRCore/internal_piz.c#L171)\n\nThis confirms the bug is an OOB read/write, not only a read-first crash.\n\n### Redzone-Oriented File\n\n- width: `67108862`\n- height: `32`\n- channel A: `FLOAT`, sampling `1 x 1`\n- channel B: `HALF`, sampling `33554431 x 16`\n\nThis makes:\n\n```text\nwidth * 32 * 2 = 4294967168\n```\n\nwhich wraps signed 32-bit arithmetic to `-128`.\n\nThat places the next `wavbuf` access just before the allocated buffer, producing a clean heap-overflow report.\n\n## Impact\n\nA crafted EXR file can trigger out-of-bounds memory access during PIZ decompression. The primitive includes both invalid reads and invalid writes. Depending on allocator layout and surrounding memory, this could lead to process crash, memory corruption, or potentially stronger exploitation outcomes.\n\n## Recommended Fix\n\n- compute channel span in 64-bit arithmetic\n- reject any overflow in `nx * ny * wcount`\n- validate cumulative per-channel decoded footprint against `outsz` before wavelet decode\n- fail decompression if channel-derived layout does not exactly fit the decompression buffer\n--------\nFound by: Quang Luong of Calif.io",
  "id": "GHSA-588r-cr5c-w6hf",
  "modified": "2026-04-08T15:09:01Z",
  "published": "2026-04-08T15:09:01Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/AcademySoftwareFoundation/openexr/security/advisories/GHSA-588r-cr5c-w6hf"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-34588"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/AcademySoftwareFoundation/openexr"
    },
    {
      "type": "WEB",
      "url": "https://github.com/AcademySoftwareFoundation/openexr/releases/tag/v3.2.7"
    },
    {
      "type": "WEB",
      "url": "https://github.com/AcademySoftwareFoundation/openexr/releases/tag/v3.3.9"
    },
    {
      "type": "WEB",
      "url": "https://github.com/AcademySoftwareFoundation/openexr/releases/tag/v3.4.9"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "OpenEXR has a signed 32-bit Overflow in PIZ Decoder Leads to OOB Read/Write"
}

GHSA-589X-GJWX-QHHC

Vulnerability from github – Published: 2022-05-17 00:15 – Updated: 2022-05-17 00:15
VLAI
Details

An issue was discovered in Adobe Acrobat and Reader: 2017.012.20098 and earlier versions, 2017.011.30066 and earlier versions, 2015.006.30355 and earlier versions, and 11.0.22 and earlier versions. This vulnerability occurs as a result of a computation that reads data that is past the end of the target buffer; the computation is in the part of the JavaScript engine that handles annotation abstraction. The use of an invalid (out-of-range) pointer offset during access of internal data structure fields causes the vulnerability. A successful attack can lead to sensitive data exposure.

Severity
8.8 (High)
CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2017-16420"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-125"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2017-12-09T06:29:00Z",
    "severity": "HIGH"
  },
  "details": "An issue was discovered in Adobe Acrobat and Reader: 2017.012.20098 and earlier versions, 2017.011.30066 and earlier versions, 2015.006.30355 and earlier versions, and 11.0.22 and earlier versions. This vulnerability occurs as a result of a computation that reads data that is past the end of the target buffer; the computation is in the part of the JavaScript engine that handles annotation abstraction. The use of an invalid (out-of-range) pointer offset during access of internal data structure fields causes the vulnerability. A successful attack can lead to sensitive data exposure.",
  "id": "GHSA-589x-gjwx-qhhc",
  "modified": "2022-05-17T00:15:12Z",
  "published": "2022-05-17T00:15:12Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2017-16420"
    },
    {
      "type": "WEB",
      "url": "https://helpx.adobe.com/security/products/acrobat/apsb17-36.html"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/102140"
    },
    {
      "type": "WEB",
      "url": "http://www.securitytracker.com/id/1039791"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-58GV-FHHX-J74W

Vulnerability from github – Published: 2022-05-12 00:00 – Updated: 2022-05-12 00:00
VLAI
Details

Acrobat Reader DC version 22.001.2011x (and earlier), 20.005.3033x (and earlier) and 17.012.3022x (and earlier) are affected by an out-of-bounds read vulnerability when parsing a crafted file, which could result in a read past the end of an allocated memory structure. An attacker could leverage this vulnerability to bypass mitigations such as ASLR. Exploitation of this issue requires user interaction in that a victim must open a malicious file.

Severity
5.5 (Medium)
CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2022-28251"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-125"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-05-11T18:15:00Z",
    "severity": "MODERATE"
  },
  "details": "Acrobat Reader DC version 22.001.2011x (and earlier), 20.005.3033x (and earlier) and 17.012.3022x (and earlier) are affected by an out-of-bounds read vulnerability when parsing a crafted file, which could result in a read past the end of an allocated memory structure. An attacker could leverage this vulnerability to bypass mitigations such as ASLR. Exploitation of this issue requires user interaction in that a victim must open a malicious file.",
  "id": "GHSA-58gv-fhhx-j74w",
  "modified": "2022-05-12T00:00:54Z",
  "published": "2022-05-12T00:00:54Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-28251"
    },
    {
      "type": "WEB",
      "url": "https://helpx.adobe.com/security/products/acrobat/apsb22-16.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-58J4-6QW5-X8F7

Vulnerability from github – Published: 2022-04-19 00:00 – Updated: 2022-04-24 00:00
VLAI
Details

Multiple code execution vulnerabilities exists in the Nef polygon-parsing functionality of CGAL libcgal CGAL-5.1.1. A specially crafted malformed file can lead to an out-of-bounds read and type confusion, which could lead to code execution. An attacker can provide malicious input to trigger any of these vulnerabilities. An oob read vulnerability exists in Nef_S2/SNC_io_parser.h SNC_io_parser::read_sface() SD.link_as_face_cycle().

Severity
8.8 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2020-35631"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-125",
      "CWE-129"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-04-18T17:15:00Z",
    "severity": "HIGH"
  },
  "details": "Multiple code execution vulnerabilities exists in the Nef polygon-parsing functionality of CGAL libcgal CGAL-5.1.1. A specially crafted malformed file can lead to an out-of-bounds read and type confusion, which could lead to code execution. An attacker can provide malicious input to trigger any of these vulnerabilities. An oob read vulnerability exists in Nef_S2/SNC_io_parser.h SNC_io_parser\u003cEW\u003e::read_sface() SD.link_as_face_cycle().",
  "id": "GHSA-58j4-6qw5-x8f7",
  "modified": "2022-04-24T00:00:30Z",
  "published": "2022-04-19T00:00:50Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-35631"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2022/12/msg00011.html"
    },
    {
      "type": "WEB",
      "url": "https://security.gentoo.org/glsa/202305-34"
    },
    {
      "type": "WEB",
      "url": "https://talosintelligence.com/vulnerability_reports/TALOS-2020-1225"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-58MG-4Q88-9644

Vulnerability from github – Published: 2022-02-11 00:00 – Updated: 2025-05-05 18:31
VLAI
Details

Out-of-bounds read in the Intel(R) Trace Analyzer and Collector before version 2021.5 may allow an authenticated user to potentially enable information disclosure via local access.

Severity
5.5 (Medium)
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2022-21226"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-125"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-02-09T23:15:00Z",
    "severity": "MODERATE"
  },
  "details": "Out-of-bounds read in the Intel(R) Trace Analyzer and Collector before version 2021.5 may allow an authenticated user to potentially enable information disclosure via local access.",
  "id": "GHSA-58mg-4q88-9644",
  "modified": "2025-05-05T18:31:36Z",
  "published": "2022-02-11T00:00:50Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-21226"
    },
    {
      "type": "WEB",
      "url": "https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00639.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-58PR-F4Q3-X425

Vulnerability from github – Published: 2026-02-14 18:30 – Updated: 2026-03-17 21:31
VLAI
Details

In the Linux kernel, the following vulnerability has been resolved:

netfs: Fix early read unlock of page with EOF in middle

The read result collection for buffered reads seems to run ahead of the completion of subrequests under some circumstances, as can be seen in the following log snippet:

9p_client_res: client 18446612686390831168 response P9_TREAD tag  0 err 0
...
netfs_sreq: R=00001b55[1] DOWN TERM  f=192 s=0 5fb2/5fb2 s=5 e=0
...
netfs_collect_folio: R=00001b55 ix=00004 r=4000-5000 t=4000/5fb2
netfs_folio: i=157f3 ix=00004-00004 read-done
netfs_folio: i=157f3 ix=00004-00004 read-unlock
netfs_collect_folio: R=00001b55 ix=00005 r=5000-5fb2 t=5000/5fb2
netfs_folio: i=157f3 ix=00005-00005 read-done
netfs_folio: i=157f3 ix=00005-00005 read-unlock
...
netfs_collect_stream: R=00001b55[0:] cto=5fb2 frn=ffffffff
netfs_collect_state: R=00001b55 col=5fb2 cln=6000 n=c
netfs_collect_stream: R=00001b55[0:] cto=5fb2 frn=ffffffff
netfs_collect_state: R=00001b55 col=5fb2 cln=6000 n=8
...
netfs_sreq: R=00001b55[2] ZERO SUBMT f=000 s=5fb2 0/4e s=0 e=0
netfs_sreq: R=00001b55[2] ZERO TERM  f=102 s=5fb2 4e/4e s=5 e=0

The 'cto=5fb2' indicates the collected file pos we've collected results to so far - but we still have 0x4e more bytes to go - so we shouldn't have collected folio ix=00005 yet. The 'ZERO' subreq that clears the tail happens after we unlock the folio, allowing the application to see the uncleared tail through mmap.

The problem is that netfs_read_unlock_folios() will unlock a folio in which the amount of read results collected hits EOF position - but the ZERO subreq lies beyond that and so happens after.

Fix this by changing the end check to always be the end of the folio and never the end of the file.

In the future, I should look at clearing to the end of the folio here rather than adding a ZERO subreq to do this. On the other hand, the ZERO subreq can run in parallel with an async READ subreq. Further, the ZERO subreq may still be necessary to, say, handle extents in a ceph file that don't have any backing store and are thus implicitly all zeros.

This can be reproduced by creating a file, the size of which doesn't align to a page boundary, e.g. 24998 (0x5fb2) bytes and then doing something like:

xfs_io -c "mmap -r 0 0x6000" -c "madvise -d 0 0x6000" \
       -c "mread -v 0 0x6000" /xfstest.test/x

The last 0x4e bytes should all be 00, but if the tail hasn't been cleared yet, you may see rubbish there. This can be reproduced with kafs by modifying the kernel to disable the call to netfs_read_subreq_progress() and to stop afs_issue_read() from doing the async call for NETFS_READAHEAD. Reproduction can be made easier by inserting an mdelay(100) in netfs_issue_read() for the ZERO-subreq case.

AFS and CIFS are normally unlikely to show this as they dispatch READ ops asynchronously, which allows the ZERO-subreq to finish first. 9P's READ op is completely synchronous, so the ZERO-subreq will always happen after. It isn't seen all the time, though, because the collection may be done in a worker thread.

Severity
7.1 (High)
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2025-71201"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-125"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-02-14T16:15:52Z",
    "severity": "HIGH"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnetfs: Fix early read unlock of page with EOF in middle\n\nThe read result collection for buffered reads seems to run ahead of the\ncompletion of subrequests under some circumstances, as can be seen in the\nfollowing log snippet:\n\n    9p_client_res: client 18446612686390831168 response P9_TREAD tag  0 err 0\n    ...\n    netfs_sreq: R=00001b55[1] DOWN TERM  f=192 s=0 5fb2/5fb2 s=5 e=0\n    ...\n    netfs_collect_folio: R=00001b55 ix=00004 r=4000-5000 t=4000/5fb2\n    netfs_folio: i=157f3 ix=00004-00004 read-done\n    netfs_folio: i=157f3 ix=00004-00004 read-unlock\n    netfs_collect_folio: R=00001b55 ix=00005 r=5000-5fb2 t=5000/5fb2\n    netfs_folio: i=157f3 ix=00005-00005 read-done\n    netfs_folio: i=157f3 ix=00005-00005 read-unlock\n    ...\n    netfs_collect_stream: R=00001b55[0:] cto=5fb2 frn=ffffffff\n    netfs_collect_state: R=00001b55 col=5fb2 cln=6000 n=c\n    netfs_collect_stream: R=00001b55[0:] cto=5fb2 frn=ffffffff\n    netfs_collect_state: R=00001b55 col=5fb2 cln=6000 n=8\n    ...\n    netfs_sreq: R=00001b55[2] ZERO SUBMT f=000 s=5fb2 0/4e s=0 e=0\n    netfs_sreq: R=00001b55[2] ZERO TERM  f=102 s=5fb2 4e/4e s=5 e=0\n\nThe \u0027cto=5fb2\u0027 indicates the collected file pos we\u0027ve collected results to\nso far - but we still have 0x4e more bytes to go - so we shouldn\u0027t have\ncollected folio ix=00005 yet.  The \u0027ZERO\u0027 subreq that clears the tail\nhappens after we unlock the folio, allowing the application to see the\nuncleared tail through mmap.\n\nThe problem is that netfs_read_unlock_folios() will unlock a folio in which\nthe amount of read results collected hits EOF position - but the ZERO\nsubreq lies beyond that and so happens after.\n\nFix this by changing the end check to always be the end of the folio and\nnever the end of the file.\n\nIn the future, I should look at clearing to the end of the folio here rather\nthan adding a ZERO subreq to do this.  On the other hand, the ZERO subreq can\nrun in parallel with an async READ subreq.  Further, the ZERO subreq may still\nbe necessary to, say, handle extents in a ceph file that don\u0027t have any\nbacking store and are thus implicitly all zeros.\n\nThis can be reproduced by creating a file, the size of which doesn\u0027t align\nto a page boundary, e.g. 24998 (0x5fb2) bytes and then doing something\nlike:\n\n    xfs_io -c \"mmap -r 0 0x6000\" -c \"madvise -d 0 0x6000\" \\\n           -c \"mread -v 0 0x6000\" /xfstest.test/x\n\nThe last 0x4e bytes should all be 00, but if the tail hasn\u0027t been cleared\nyet, you may see rubbish there.  This can be reproduced with kafs by\nmodifying the kernel to disable the call to netfs_read_subreq_progress()\nand to stop afs_issue_read() from doing the async call for NETFS_READAHEAD.\nReproduction can be made easier by inserting an mdelay(100) in\nnetfs_issue_read() for the ZERO-subreq case.\n\nAFS and CIFS are normally unlikely to show this as they dispatch READ ops\nasynchronously, which allows the ZERO-subreq to finish first.  9P\u0027s READ op is\ncompletely synchronous, so the ZERO-subreq will always happen after.  It isn\u0027t\nseen all the time, though, because the collection may be done in a worker\nthread.",
  "id": "GHSA-58pr-f4q3-x425",
  "modified": "2026-03-17T21:31:41Z",
  "published": "2026-02-14T18:30:13Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-71201"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/570ad253a3455a520f03c2136af8714bc780186d"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/5b5482c0e5ee740b35a70759d3582477aea8e8e4"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-58Q5-MW2X-C4M2

Vulnerability from github – Published: 2023-08-08 12:30 – Updated: 2024-04-04 06:38
VLAI
Details

A vulnerability has been identified in JT2Go (All versions < V14.2.0.5), Teamcenter Visualization V13.2 (All versions < V13.2.0.14), Teamcenter Visualization V14.1 (All versions < V14.1.0.10), Teamcenter Visualization V14.2 (All versions < V14.2.0.5). The affected applications contain an out of bounds read past the end of an allocated structure while parsing specially crafted TIFF files. This could allow an attacker to execute code in the context of the current process.

Severity
7.8 (High)
CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2023-38682"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-125"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-08-08T10:15:16Z",
    "severity": "HIGH"
  },
  "details": "A vulnerability has been identified in JT2Go (All versions \u003c V14.2.0.5), Teamcenter Visualization V13.2 (All versions \u003c V13.2.0.14), Teamcenter Visualization V14.1 (All versions \u003c V14.1.0.10), Teamcenter Visualization V14.2 (All versions \u003c V14.2.0.5). The affected applications contain an out of bounds read past the end of an allocated structure while parsing specially crafted TIFF files. This could allow an attacker to execute code in the context of the current process.",
  "id": "GHSA-58q5-mw2x-c4m2",
  "modified": "2024-04-04T06:38:57Z",
  "published": "2023-08-08T12:30:20Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-38682"
    },
    {
      "type": "WEB",
      "url": "https://cert-portal.siemens.com/productcert/pdf/ssa-131450.pdf"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-58QH-X4FQ-VH49

Vulnerability from github – Published: 2024-11-22 21:32 – Updated: 2024-11-22 21:32
VLAI
Details

PDF-XChange Editor U3D File Parsing Out-Of-Bounds Read Remote Code Execution Vulnerability. This vulnerability allows remote attackers to execute arbitrary code on affected installations of PDF-XChange Editor. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file.

The specific flaw exists within the parsing of U3D files. The issue results from the lack of proper validation of user-supplied data, which can result in a read past the end of an allocated buffer. An attacker can leverage this vulnerability to execute code in the context of the current process. Was ZDI-CAN-24209.

Severity
7.8 (High)
CVSS:3.0/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2024-8814"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-125"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-11-22T21:15:19Z",
    "severity": "HIGH"
  },
  "details": "PDF-XChange Editor U3D File Parsing Out-Of-Bounds Read Remote Code Execution Vulnerability. This vulnerability allows remote attackers to execute arbitrary code on affected installations of PDF-XChange Editor. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file.\n\nThe specific flaw exists within the parsing of U3D files. The issue results from the lack of proper validation of user-supplied data, which can result in a read past the end of an allocated buffer. An attacker can leverage this vulnerability to execute code in the context of the current process. Was ZDI-CAN-24209.",
  "id": "GHSA-58qh-x4fq-vh49",
  "modified": "2024-11-22T21:32:18Z",
  "published": "2024-11-22T21:32:18Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-8814"
    },
    {
      "type": "WEB",
      "url": "https://www.zerodayinitiative.com/advisories/ZDI-24-1237"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-58R6-G6VR-4GPP

Vulnerability from github – Published: 2022-05-24 19:13 – Updated: 2022-05-24 19:13
VLAI
Details

OOB read vulnerability in libswmfextractor.so library prior to SMR Sep-2021 Release 1 allows attackers to execute memcpy at arbitrary address via forged wmf file.

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2021-25456"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-125"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-09-09T19:15:00Z",
    "severity": "MODERATE"
  },
  "details": "OOB read vulnerability in libswmfextractor.so library prior to SMR Sep-2021 Release 1 allows attackers to execute memcpy at arbitrary address via forged wmf file.",
  "id": "GHSA-58r6-g6vr-4gpp",
  "modified": "2022-05-24T19:13:57Z",
  "published": "2022-05-24T19:13:57Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-25456"
    },
    {
      "type": "WEB",
      "url": "https://security.samsungmobile.com/securityUpdate.smsb?year=2021\u0026month=9"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}
Mitigation MIT-5
Implementation

Strategy: Input Validation

  • Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does.
  • When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue."
  • Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.
  • To reduce the likelihood of introducing an out-of-bounds read, ensure that you validate and ensure correct calculations for any length argument, buffer size calculation, or offset. Be especially careful of relying on a sentinel (i.e. special character such as NUL) in untrusted inputs.
Mitigation
Architecture and Design

Strategy: Language Selection

Use a language that provides appropriate memory abstractions.

CAPEC-540: Overread Buffers

An adversary attacks a target by providing input that causes an application to read beyond the boundary of a defined buffer. This typically occurs when a value influencing where to start or stop reading is set to reflect positions outside of the valid memory location of the buffer. This type of attack may result in exposure of sensitive information, a system crash, or arbitrary code execution.

← Back to the CWE list