CWE-787
Allowed-with-ReviewOut-of-bounds Write
Abstraction: Base · Status: Draft
The product writes data past the end, or before the beginning, of the intended buffer.
16203 vulnerabilities reference this CWE, most recent first.
GHSA-V6VV-P627-G9H9
Vulnerability from github – Published: 2022-05-24 17:38 – Updated: 2022-05-24 17:38Foxit Reader before 9.5, and PhantomPDF before 8.3.10 and 9.x before 9.5, has a proxyCPDFAction race condition that can cause a stack-based buffer overflow or an out-of-bounds read.
{
"affected": [],
"aliases": [
"CVE-2018-20311"
],
"database_specific": {
"cwe_ids": [
"CWE-787"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-01-07T17:15:00Z",
"severity": "HIGH"
},
"details": "Foxit Reader before 9.5, and PhantomPDF before 8.3.10 and 9.x before 9.5, has a proxyCPDFAction race condition that can cause a stack-based buffer overflow or an out-of-bounds read.",
"id": "GHSA-v6vv-p627-g9h9",
"modified": "2022-05-24T17:38:09Z",
"published": "2022-05-24T17:38:09Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2018-20311"
},
{
"type": "WEB",
"url": "https://www.foxitsoftware.com/support/security-bulletins.php"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-V6W6-5G29-2CP9
Vulnerability from github – Published: 2022-05-24 16:51 – Updated: 2022-05-24 16:51SSDP Responder 1.x through 1.5 mishandles incoming network messages, leading to a stack-based buffer overflow by 1 byte. This results in a crash of the server, but only when strict stack checking is enabled. This is caused by an off-by-one error in ssdp_recv in ssdpd.c.
{
"affected": [],
"aliases": [
"CVE-2019-14323"
],
"database_specific": {
"cwe_ids": [
"CWE-787"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2019-07-28T13:15:00Z",
"severity": "HIGH"
},
"details": "SSDP Responder 1.x through 1.5 mishandles incoming network messages, leading to a stack-based buffer overflow by 1 byte. This results in a crash of the server, but only when strict stack checking is enabled. This is caused by an off-by-one error in ssdp_recv in ssdpd.c.",
"id": "GHSA-v6w6-5g29-2cp9",
"modified": "2022-05-24T16:51:34Z",
"published": "2022-05-24T16:51:34Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-14323"
},
{
"type": "WEB",
"url": "https://github.com/troglobit/ssdp-responder/issues/1"
},
{
"type": "WEB",
"url": "https://github.com/troglobit/ssdp-responder/commit/ce04b1f29a137198182f60bbb628d5ceb8171765"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-V6W6-862C-C8MM
Vulnerability from github – Published: 2025-05-07 09:31 – Updated: 2025-05-07 09:31An Heap-based Buffer Overflow in RT-Labs P-Net version 1.0.1 or earlier allows an attacker to induce a crash in IO devices that use the library by sending a malicious RPC packet.
{
"affected": [],
"aliases": [
"CVE-2025-32397"
],
"database_specific": {
"cwe_ids": [
"CWE-122",
"CWE-787"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-05-07T07:15:50Z",
"severity": "HIGH"
},
"details": "An Heap-based Buffer Overflow in RT-Labs P-Net version 1.0.1 or earlier allows an attacker to induce a crash in IO devices that use the library by sending a malicious RPC packet.",
"id": "GHSA-v6w6-862c-c8mm",
"modified": "2025-05-07T09:31:17Z",
"published": "2025-05-07T09:31:17Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-32397"
},
{
"type": "WEB",
"url": "https://www.nozominetworks.com/labs/vulnerability-advisories-cve-2025-32397"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-V74J-582J-7X9R
Vulnerability from github – Published: 2024-01-08 15:30 – Updated: 2025-11-04 21:30An out-of-bounds write vulnerability exists in the LXT2 num_time_table_entries functionality of GTKWave 3.3.115. A specially crafted .lxt2 file can lead to arbitrary code execution. A victim would need to open a malicious file to trigger this vulnerability.
{
"affected": [],
"aliases": [
"CVE-2023-34436"
],
"database_specific": {
"cwe_ids": [
"CWE-119",
"CWE-787"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-01-08T15:15:08Z",
"severity": "HIGH"
},
"details": "An out-of-bounds write vulnerability exists in the LXT2 num_time_table_entries functionality of GTKWave 3.3.115. A specially crafted .lxt2 file can lead to arbitrary code execution. A victim would need to open a malicious file to trigger this vulnerability.",
"id": "GHSA-v74j-582j-7x9r",
"modified": "2025-11-04T21:30:56Z",
"published": "2024-01-08T15:30:27Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-34436"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2024/04/msg00007.html"
},
{
"type": "WEB",
"url": "https://talosintelligence.com/vulnerability_reports/TALOS-2023-1819"
},
{
"type": "WEB",
"url": "https://www.talosintelligence.com/vulnerability_reports/TALOS-2023-1819"
}
],
"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-V752-6J86-7G43
Vulnerability from github – Published: 2022-05-24 19:04 – Updated: 2022-10-08 00:00SAP NetWeaver AS for ABAP (RFC Gateway), versions - KRNL32NUC - 7.22,7.22EXT, KRNL64NUC - 7.22,7.22EXT,7.49, KRNL64UC - 8.04,7.22,7.22EXT,7.49,7.53,7.73, KERNEL - 7.22,8.04,7.49,7.53,7.73,7.77,7.81,7.82,7.83, allows an unauthenticated attacker without specific knowledge of the system to send a specially crafted packet over a network which will trigger an internal error in the system due to improper input validation in method ThCpicDtCreate () causing the system to crash and rendering it unavailable. In this attack, no data in the system can be viewed or modified.
{
"affected": [],
"aliases": [
"CVE-2021-27634"
],
"database_specific": {
"cwe_ids": [
"CWE-20",
"CWE-787"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-06-09T14:15:00Z",
"severity": "MODERATE"
},
"details": "SAP NetWeaver AS for ABAP (RFC Gateway), versions - KRNL32NUC - 7.22,7.22EXT, KRNL64NUC - 7.22,7.22EXT,7.49, KRNL64UC - 8.04,7.22,7.22EXT,7.49,7.53,7.73, KERNEL - 7.22,8.04,7.49,7.53,7.73,7.77,7.81,7.82,7.83, allows an unauthenticated attacker without specific knowledge of the system to send a specially crafted packet over a network which will trigger an internal error in the system due to improper input validation in method ThCpicDtCreate () causing the system to crash and rendering it unavailable. In this attack, no data in the system can be viewed or modified.",
"id": "GHSA-v752-6j86-7g43",
"modified": "2022-10-08T00:00:33Z",
"published": "2022-05-24T19:04:37Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-27634"
},
{
"type": "WEB",
"url": "https://launchpad.support.sap.com/#/notes/3020209"
},
{
"type": "WEB",
"url": "https://wiki.scn.sap.com/wiki/pages/viewpage.action?pageId=578125999"
},
{
"type": "WEB",
"url": "http://packetstormsecurity.com/files/164596/SAP-NetWeaver-ABAP-Gateway-Memory-Corruption.html"
},
{
"type": "WEB",
"url": "http://seclists.org/fulldisclosure/2021/Oct/30"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-V76P-62QX-WWQ2
Vulnerability from github – Published: 2026-10-07 16:18 – Updated: 2026-10-07 16:18Summary
When decoding a tiled TIFF with fax compression (T4/T6/MH), DecodeTilesChunky allocates each tile buffer from TileWidth (ceil(TileWidth*bpp/8)*TileLength bytes) but constructs the fax decompressor with frame.Width: TiffDecompressorsFactory ignores the isTiled/tileWidth/tileHeight parameters entirely. The T4/T6/MH decompressors treat the full image width as the scanline length and advance (and really write, via read-modify-write bit ops) frame.Width bits per row, with no bounds check against the tile buffer. The very first tile therefore writes linearly out of bounds — about ImageWidth/8 bytes per row × TileLength rows into a TileWidth-sized buffer. With ImageWidth=4,000,000, TileWidth=16, TileLength=16 this writes ~2 MB past a 32-byte buffer and kills the process deterministically; a T6 all-white variant advances the bit offset by >512 MB silently, showing an alarm-free heap-corruption window for the same defect. A crafted file fully controls the OOB length per tile and works with perfectly legal per-row run codes (no overlong runs needed).
Verified at commit 5cd4d0d26a82a9549f297a237aea9cf665bddff8 (main; latest release v4.1.0, the supported major).
Details
Root cause: a size mismatch between tile buffer allocation and decompressor width, because the factory drops the tile parameters.
- Allocation: TiffDecoderCore.cs#L792-L794 —
bytesPerTileRow = RoundUpToMultipleOfEight(tileWidth*bitsPerPixel); tile buffer =bytesPerTileRow*tileLengthbytes (32 bytes in the PoC) - Mismatch: TiffDecoderCore.cs#L797 —
CreateDecompressor<TPixel>(frame.Width, ..., isTiled: true, tileWidth, tileLength)passes the full frame width - Factory drops tile params: TiffDecompressorsFactory.cs#L56-L64 — T4/T6/MH decompressors receive only
width(= frame.Width);isTiled/tileWidth/tileHeightignored - OOB write sink: T4TiffCompression.cs#L69-L119,
T6TiffCompression.cs#L76-L108— per-row advance ofthis.widthbits viaBitWriterUtils.WriteBitswith no buffer-length check (BitWriterUtils.cs#L51); noteTiffDecoderCore.cs:829-831later reads the buffer inbytesPerTileRowstrides, confirming the protocol expects tile-width rows
Attack surface: Image.Load(stream) on an attacker-supplied tiled TIFF (TiffDecoderCore.DecodeImageWithTiles → DecodeTilesChunky). Default configuration; only requirement is a standard tiled TIFF header (TileWidth=16, TileLength=16) + Compression=3 (T4; T6 also constructible).
Suggested remediation:
1. Short-term: when isTiled, construct the T4/T6/MH decompressor with tileWidth (not frame width), or clip row writes to the caller-provided buffer length.
2. Root fix: bound the write side of BitWriterUtils (pass remaining bits), and validate every fax row advance against buffer capacity on both tiled and strip paths.
3. Regression tests: Compression=2/3/4 × tiled with TileWidth < ImageWidth, including a T6 black-pixel row (forces real WriteBit).
PoC
Full PoC posted as the first comment below: Program.cs (driver), poc-tiled-t4.tif (crafted file, ~9.8 KB, base64 inline), README.
- Build a small console project referencing
src/ImageSharp/ImageSharp.csprojand run it against the crafted file (or callImage.Loadon it from any host). - Observed with ImageWidth=4,000,000, TileWidth=16, TileLength=16, T4 with 400 makeup codes + EOL per row:
tile payload 9642 bytes; rows write ~2,048,000 bytes into a 32-byte buffer
Fatal error. System.AccessViolationException: Attempted to read or write protected memory.
at SixLabors.ImageSharp.Formats.Tiff.Compression.BitWriterUtils.WriteBits(Span`1<Byte>, IntPtr, IntPtr, Byte)
at ...T4TiffCompression.WritePixelRun(...)
at ...T4TiffCompression.Decompress(...)
Aborted (core dumped); exit=134
- Controls: the same file with Compression=None decodes normally (container is fine); a T6 all-white-rows variant advances >512 MB of bit offset without a real write (silent corruption window) before tripping on a directory-level TileOffsets count check.
Impact
- What it is: out-of-bounds write (CWE-787). For any service decoding untrusted tiled TIFFs: remote, default-configuration, deterministic process crash (DoS), plus a heap OOB write whose per-tile length and row width are attacker-tunable — a potential code-execution surface. This is a vulnerability in the library itself, in scope of your SECURITY.md.
- Who is impacted: applications decoding untrusted TIFF with SixLabors.ImageSharp at the current major (verified on main past v4.1.0); tiled + fax-compressed files are the trigger, which ordinary TIFF writers can produce.
Reported by Kimi Security Team (bug-report@moonshot.ai).
{
"affected": [
{
"package": {
"ecosystem": "NuGet",
"name": "ImageSharp"
},
"ranges": [
{
"events": [
{
"introduced": "3.0.0"
},
{
"fixed": "4.1.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-106118"
],
"database_specific": {
"cwe_ids": [
"CWE-787"
],
"github_reviewed": true,
"github_reviewed_at": "2026-10-07T16:18:57Z",
"nvd_published_at": "2026-10-06T19:17:42Z",
"severity": "HIGH"
},
"details": "## Summary\n\nWhen decoding a tiled TIFF with fax compression (T4/T6/MH), `DecodeTilesChunky` allocates each tile buffer from **TileWidth** (`ceil(TileWidth*bpp/8)*TileLength` bytes) but constructs the fax decompressor with **frame.Width**: `TiffDecompressorsFactory` ignores the `isTiled/tileWidth/tileHeight` parameters entirely. The T4/T6/MH decompressors treat the full image width as the scanline length and advance (and really write, via read-modify-write bit ops) `frame.Width` bits per row, with no bounds check against the tile buffer. The very first tile therefore writes linearly out of bounds \u2014 about `ImageWidth/8` bytes per row \u00d7 TileLength rows into a `TileWidth`-sized buffer. With ImageWidth=4,000,000, TileWidth=16, TileLength=16 this writes ~2 MB past a 32-byte buffer and kills the process deterministically; a T6 all-white variant advances the bit offset by \u003e512 MB silently, showing an alarm-free heap-corruption window for the same defect. A crafted file fully controls the OOB length per tile and works with perfectly legal per-row run codes (no overlong runs needed).\n\nVerified at commit `5cd4d0d26a82a9549f297a237aea9cf665bddff8` (main; latest release v4.1.0, the supported major).\n\n## Details\n\nRoot cause: a size mismatch between tile buffer allocation and decompressor width, because the factory drops the tile parameters.\n\n- Allocation: [TiffDecoderCore.cs#L792-L794](https://github.com/SixLabors/ImageSharp/blob/5cd4d0d26a82a9549f297a237aea9cf665bddff8/src/ImageSharp/Formats/Tiff/TiffDecoderCore.cs#L792-L794) \u2014 `bytesPerTileRow = RoundUpToMultipleOfEight(tileWidth*bitsPerPixel)`; tile buffer = `bytesPerTileRow*tileLength` bytes (32 bytes in the PoC)\n- Mismatch: [TiffDecoderCore.cs#L797](https://github.com/SixLabors/ImageSharp/blob/5cd4d0d26a82a9549f297a237aea9cf665bddff8/src/ImageSharp/Formats/Tiff/TiffDecoderCore.cs#L797) \u2014 `CreateDecompressor\u003cTPixel\u003e(frame.Width, ..., isTiled: true, tileWidth, tileLength)` passes the full frame width\n- Factory drops tile params: [TiffDecompressorsFactory.cs#L56-L64](https://github.com/SixLabors/ImageSharp/blob/5cd4d0d26a82a9549f297a237aea9cf665bddff8/src/ImageSharp/Formats/Tiff/Compression/TiffDecompressorsFactory.cs#L56-L64) \u2014 T4/T6/MH decompressors receive only `width` (= frame.Width); `isTiled/tileWidth/tileHeight` ignored\n- OOB write sink: [T4TiffCompression.cs#L69-L119](https://github.com/SixLabors/ImageSharp/blob/5cd4d0d26a82a9549f297a237aea9cf665bddff8/src/ImageSharp/Formats/Tiff/Compression/Decompressors/T4TiffCompression.cs#L69-L119), `T6TiffCompression.cs#L76-L108` \u2014 per-row advance of `this.width` bits via `BitWriterUtils.WriteBits` with no buffer-length check ([BitWriterUtils.cs#L51](https://github.com/SixLabors/ImageSharp/blob/5cd4d0d26a82a9549f297a237aea9cf665bddff8/src/ImageSharp/Formats/Tiff/Compression/BitWriterUtils.cs#L51)); note `TiffDecoderCore.cs:829-831` later reads the buffer in `bytesPerTileRow` strides, confirming the protocol expects tile-width rows\n\nAttack surface: `Image.Load(stream)` on an attacker-supplied tiled TIFF (`TiffDecoderCore.DecodeImageWithTiles` \u2192 `DecodeTilesChunky`). Default configuration; only requirement is a standard tiled TIFF header (TileWidth=16, TileLength=16) + Compression=3 (T4; T6 also constructible).\n\n**Suggested remediation:**\n1. Short-term: when `isTiled`, construct the T4/T6/MH decompressor with `tileWidth` (not frame width), or clip row writes to the caller-provided buffer length.\n2. Root fix: bound the write side of `BitWriterUtils` (pass remaining bits), and validate every fax row advance against buffer capacity on both tiled and strip paths.\n3. Regression tests: Compression=2/3/4 \u00d7 tiled with TileWidth \u003c ImageWidth, including a T6 black-pixel row (forces real `WriteBit`).\n\n## PoC\n\nFull PoC posted as the first comment below: `Program.cs` (driver), `poc-tiled-t4.tif` (crafted file, ~9.8 KB, base64 inline), README.\n\n1. Build a small console project referencing `src/ImageSharp/ImageSharp.csproj` and run it against the crafted file (or call `Image.Load` on it from any host).\n2. Observed with ImageWidth=4,000,000, TileWidth=16, TileLength=16, T4 with 400 makeup codes + EOL per row:\n\n ```\n tile payload 9642 bytes; rows write ~2,048,000 bytes into a 32-byte buffer\n Fatal error. System.AccessViolationException: Attempted to read or write protected memory.\n at SixLabors.ImageSharp.Formats.Tiff.Compression.BitWriterUtils.WriteBits(Span`1\u003cByte\u003e, IntPtr, IntPtr, Byte)\n at ...T4TiffCompression.WritePixelRun(...)\n at ...T4TiffCompression.Decompress(...)\n Aborted (core dumped); exit=134\n ```\n\n3. Controls: the same file with Compression=None decodes normally (container is fine); a T6 all-white-rows variant advances \u003e512 MB of bit offset without a real write (silent corruption window) before tripping on a directory-level TileOffsets count check.\n\n## Impact\n\n- **What it is:** out-of-bounds write (CWE-787). For any service decoding untrusted tiled TIFFs: remote, default-configuration, deterministic process crash (DoS), plus a heap OOB write whose per-tile length and row width are attacker-tunable \u2014 a potential code-execution surface. This is a vulnerability in the library itself, in scope of your SECURITY.md.\n- **Who is impacted:** applications decoding untrusted TIFF with SixLabors.ImageSharp at the current major (verified on main past v4.1.0); tiled + fax-compressed files are the trigger, which ordinary TIFF writers can produce.\n\n---\n\n---\n\nReported by **Kimi Security Team** (bug-report@moonshot.ai).",
"id": "GHSA-v76p-62qx-wwq2",
"modified": "2026-10-07T16:18:57Z",
"published": "2026-10-07T16:18:57Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/SixLabors/ImageSharp/security/advisories/GHSA-v76p-62qx-wwq2"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-106118"
},
{
"type": "WEB",
"url": "https://github.com/SixLabors/ImageSharp/pull/3176"
},
{
"type": "WEB",
"url": "https://github.com/SixLabors/ImageSharp/commit/9ee7d1dd5b62d8c9f16cc755e76828386bc2191f"
},
{
"type": "PACKAGE",
"url": "https://github.com/SixLabors/ImageSharp"
},
{
"type": "WEB",
"url": "https://github.com/SixLabors/ImageSharp/releases/tag/v4.1.1"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
],
"summary": "ImageSharp: Tiled fax TIFF: tile buffer sized by TileWidth but fax decompressor writes scanlines of ImageWidth \u2014 heap OOB write"
}
GHSA-V76Q-G5WV-JJW6
Vulnerability from github – Published: 2026-05-06 12:30 – Updated: 2026-06-01 18:31In the Linux kernel, the following vulnerability has been resolved:
ocfs2: fix out-of-bounds write in ocfs2_write_end_inline
KASAN reports a use-after-free write of 4086 bytes in ocfs2_write_end_inline, called from ocfs2_write_end_nolock during a copy_file_range splice fallback on a corrupted ocfs2 filesystem mounted on a loop device. The actual bug is an out-of-bounds write past the inode block buffer, not a true use-after-free. The write overflows into an adjacent freed page, which KASAN reports as UAF.
The root cause is that ocfs2_try_to_write_inline_data trusts the on-disk id_count field to determine whether a write fits in inline data. On a corrupted filesystem, id_count can exceed the physical maximum inline data capacity, causing writes to overflow the inode block buffer.
Call trace (crash path):
vfs_copy_file_range (fs/read_write.c:1634) do_splice_direct splice_direct_to_actor iter_file_splice_write ocfs2_file_write_iter generic_perform_write ocfs2_write_end ocfs2_write_end_nolock (fs/ocfs2/aops.c:1949) ocfs2_write_end_inline (fs/ocfs2/aops.c:1915) memcpy_from_folio <-- KASAN: write OOB
So add id_count upper bound check in ocfs2_validate_inode_block() to alongside the existing i_size check to fix it.
{
"affected": [],
"aliases": [
"CVE-2026-43075"
],
"database_specific": {
"cwe_ids": [
"CWE-787"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-05-06T10:16:20Z",
"severity": "HIGH"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nocfs2: fix out-of-bounds write in ocfs2_write_end_inline\n\nKASAN reports a use-after-free write of 4086 bytes in\nocfs2_write_end_inline, called from ocfs2_write_end_nolock during a\ncopy_file_range splice fallback on a corrupted ocfs2 filesystem mounted on\na loop device. The actual bug is an out-of-bounds write past the inode\nblock buffer, not a true use-after-free. The write overflows into an\nadjacent freed page, which KASAN reports as UAF.\n\nThe root cause is that ocfs2_try_to_write_inline_data trusts the on-disk\nid_count field to determine whether a write fits in inline data. On a\ncorrupted filesystem, id_count can exceed the physical maximum inline data\ncapacity, causing writes to overflow the inode block buffer.\n\nCall trace (crash path):\n\n vfs_copy_file_range (fs/read_write.c:1634)\n do_splice_direct\n splice_direct_to_actor\n iter_file_splice_write\n ocfs2_file_write_iter\n generic_perform_write\n ocfs2_write_end\n ocfs2_write_end_nolock (fs/ocfs2/aops.c:1949)\n ocfs2_write_end_inline (fs/ocfs2/aops.c:1915)\n memcpy_from_folio \u003c-- KASAN: write OOB\n\nSo add id_count upper bound check in ocfs2_validate_inode_block() to\nalongside the existing i_size check to fix it.",
"id": "GHSA-v76q-g5wv-jjw6",
"modified": "2026-06-01T18:31:29Z",
"published": "2026-05-06T12:30:26Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43075"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/0c1af902223b6fcedb60904ca0b551254686c7b9"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/22df7d4de9c5cd42edf855a1de25f2106088c4c6"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/2e6a254f9cedf51b75cc20b8b92e2209bfa04c3e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/68f9cc3bbf2ae501770cea7dc0005fc9a85e48ea"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/69d3c69ade1e4285ab4ca48fe7acee0767e65604"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/7bc5da4842bed3252d26e742213741a4d0ac1b14"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/947f953978b0d9463498d548d0f054f5a75be2e9"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e2c9dc6b6e96f3585f2a1062ca3374a52db0938f"
}
],
"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"
}
]
}
GHSA-V76X-QFMC-M88P
Vulnerability from github – Published: 2023-08-02 06:30 – Updated: 2023-12-15 18:30Under some circumstances, this weakness allows a user who has access to run the “ps” utility on a machine, the ability to write almost unlimited amounts of unfiltered data into the process heap.
{
"affected": [],
"aliases": [
"CVE-2023-4016"
],
"database_specific": {
"cwe_ids": [
"CWE-122",
"CWE-787"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-08-02T05:15:09Z",
"severity": "LOW"
},
"details": "Under some circumstances, this weakness allows a user who has access to run the \u201cps\u201d utility on a machine, the ability to write almost unlimited amounts of unfiltered data into the process heap.",
"id": "GHSA-v76x-qfmc-m88p",
"modified": "2023-12-15T18:30:27Z",
"published": "2023-08-02T06:30:20Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-4016"
},
{
"type": "WEB",
"url": "https://gitlab.com/procps-ng/procps"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/SUETRRT24OFGPYK6ACPM5VUGHNKH5CQ5"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:L",
"type": "CVSS_V3"
}
]
}
GHSA-V77M-Q9MF-PWPM
Vulnerability from github – Published: 2022-05-24 17:48 – Updated: 2022-05-24 17:48CNCSoft-B Versions 1.0.0.3 and prior is vulnerable to an out-of-bounds write, which may allow an attacker to execute arbitrary code.
{
"affected": [],
"aliases": [
"CVE-2021-22664"
],
"database_specific": {
"cwe_ids": [
"CWE-787"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-04-27T13:15:00Z",
"severity": "HIGH"
},
"details": "CNCSoft-B Versions 1.0.0.3 and prior is vulnerable to an out-of-bounds write, which may allow an attacker to execute arbitrary code.",
"id": "GHSA-v77m-q9mf-pwpm",
"modified": "2022-05-24T17:48:55Z",
"published": "2022-05-24T17:48:55Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-22664"
},
{
"type": "WEB",
"url": "https://us-cert.cisa.gov/ics/advisories/icsa-21-110-05"
},
{
"type": "WEB",
"url": "https://www.zerodayinitiative.com/advisories/ZDI-21-444"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-V78V-GRQX-8C6G
Vulnerability from github – Published: 2022-09-17 00:00 – Updated: 2022-09-17 00:00Adobe Photoshop versions 22.5.8 (and earlier) and 23.4.2 (and earlier) are affected by an out-of-bounds write vulnerability that could result in arbitrary code execution in the context of the current user. Exploitation of this issue requires user interaction in that a victim must open a malicious file.
{
"affected": [],
"aliases": [
"CVE-2022-35713"
],
"database_specific": {
"cwe_ids": [
"CWE-787"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-09-16T18:15:00Z",
"severity": "HIGH"
},
"details": "Adobe Photoshop versions 22.5.8 (and earlier) and 23.4.2 (and earlier) are affected by an out-of-bounds write vulnerability that could result in arbitrary code execution in the context of the current user. Exploitation of this issue requires user interaction in that a victim must open a malicious file.",
"id": "GHSA-v78v-grqx-8c6g",
"modified": "2022-09-17T00:00:32Z",
"published": "2022-09-17T00:00:32Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-35713"
},
{
"type": "WEB",
"url": "https://helpx.adobe.com/security/products/photoshop/apsb22-52.html"
}
],
"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"
}
]
}
Mitigation MIT-3
Strategy: Language Selection
- Use a language that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.
- For example, many languages that perform their own memory management, such as Java and Perl, are not subject to buffer overflows. Other languages, such as Ada and C#, typically provide overflow protection, but the protection can be disabled by the programmer.
- Be wary that a language's interface to native code may still be subject to overflows, even if the language itself is theoretically safe.
Mitigation MIT-4.1
Strategy: Libraries or Frameworks
- Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.
- Examples include the Safe C String Library (SafeStr) by Messier and Viega [REF-57], and the Strsafe.h library from Microsoft [REF-56]. These libraries provide safer versions of overflow-prone string-handling functions.
Mitigation MIT-10
Strategy: Environment Hardening
- Use automatic buffer overflow detection mechanisms that are offered by certain compilers or compiler extensions. Examples include: the Microsoft Visual Studio /GS flag, Fedora/Red Hat FORTIFY_SOURCE GCC flag, StackGuard, and ProPolice, which provide various mechanisms including canary-based detection and range/index checking.
- D3-SFCV (Stack Frame Canary Validation) from D3FEND [REF-1334] discusses canary-based detection in detail.
Mitigation MIT-9
- Consider adhering to the following rules when allocating and managing an application's memory:
- Double check that the buffer is as large as specified.
- When using functions that accept a number of bytes to copy, such as strncpy(), be aware that if the destination buffer size is equal to the source buffer size, it may not NULL-terminate the string.
- Check buffer boundaries if accessing the buffer in a loop and make sure there is no danger of writing past the allocated space.
- If necessary, truncate all input strings to a reasonable length before passing them to the copy and concatenation functions.
Mitigation MIT-11
Strategy: Environment Hardening
- Run or compile the software using features or extensions that randomly arrange the positions of a program's executable and libraries in memory. Because this makes the addresses unpredictable, it can prevent an attacker from reliably jumping to exploitable code.
- Examples include Address Space Layout Randomization (ASLR) [REF-58] [REF-60] and Position-Independent Executables (PIE) [REF-64]. Imported modules may be similarly realigned if their default memory addresses conflict with other modules, in a process known as "rebasing" (for Windows) and "prelinking" (for Linux) [REF-1332] using randomly generated addresses. ASLR for libraries cannot be used in conjunction with prelink since it would require relocating the libraries at run-time, defeating the whole purpose of prelinking.
- For more information on these techniques see D3-SAOR (Segment Address Offset Randomization) from D3FEND [REF-1335].
Mitigation MIT-12
Strategy: Environment Hardening
- Use a CPU and operating system that offers Data Execution Protection (using hardware NX or XD bits) or the equivalent techniques that simulate this feature in software, such as PaX [REF-60] [REF-61]. These techniques ensure that any instruction executed is exclusively at a memory address that is part of the code segment.
- For more information on these techniques see D3-PSEP (Process Segment Execution Prevention) from D3FEND [REF-1336].
Mitigation MIT-13
Replace unbounded copy functions with analogous functions that support length arguments, such as strcpy with strncpy. Create these if they are not available.
No CAPEC attack patterns related to this CWE.