GHSA-QX8F-4V7P-9M35

Vulnerability from github – Published: 2026-05-06 12:30 – Updated: 2026-05-08 15:31
VLAI
Details

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

netfilter: nf_conntrack_h323: fix OOB read in decode_choice()

In decode_choice(), the boundary check before get_len() uses the variable len, which is still 0 from its initialization at the top of the function:

unsigned int type, ext, len = 0;
...
if (ext || (son->attr & OPEN)) {
    BYTE_ALIGN(bs);
    if (nf_h323_error_boundary(bs, len, 0))  /* len is 0 here */
        return H323_ERROR_BOUND;
    len = get_len(bs);                        /* OOB read */

When the bitstream is exactly consumed (bs->cur == bs->end), the check nf_h323_error_boundary(bs, 0, 0) evaluates to (bs->cur + 0 > bs->end), which is false. The subsequent get_len() call then dereferences *bs->cur++, reading 1 byte past the end of the buffer. If that byte has bit 7 set, get_len() reads a second byte as well.

This can be triggered remotely by sending a crafted Q.931 SETUP message with a User-User Information Element containing exactly 2 bytes of PER-encoded data ({0x08, 0x00}) to port 1720 through a firewall with the nf_conntrack_h323 helper active. The decoder fully consumes the PER buffer before reaching this code path, resulting in a 1-2 byte heap-buffer-overflow read confirmed by AddressSanitizer.

Fix this by checking for 2 bytes (the maximum that get_len() may read) instead of the uninitialized len. This matches the pattern used at every other get_len() call site in the same file, where the caller checks for 2 bytes of available data before calling get_len().

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-43233"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-125"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-05-06T12:16:43Z",
    "severity": "HIGH"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nf_conntrack_h323: fix OOB read in decode_choice()\n\nIn decode_choice(), the boundary check before get_len() uses the\nvariable `len`, which is still 0 from its initialization at the top of\nthe function:\n\n    unsigned int type, ext, len = 0;\n    ...\n    if (ext || (son-\u003eattr \u0026 OPEN)) {\n        BYTE_ALIGN(bs);\n        if (nf_h323_error_boundary(bs, len, 0))  /* len is 0 here */\n            return H323_ERROR_BOUND;\n        len = get_len(bs);                        /* OOB read */\n\nWhen the bitstream is exactly consumed (bs-\u003ecur == bs-\u003eend), the check\nnf_h323_error_boundary(bs, 0, 0) evaluates to (bs-\u003ecur + 0 \u003e bs-\u003eend),\nwhich is false.  The subsequent get_len() call then dereferences\n*bs-\u003ecur++, reading 1 byte past the end of the buffer.  If that byte\nhas bit 7 set, get_len() reads a second byte as well.\n\nThis can be triggered remotely by sending a crafted Q.931 SETUP message\nwith a User-User Information Element containing exactly 2 bytes of\nPER-encoded data ({0x08, 0x00}) to port 1720 through a firewall with\nthe nf_conntrack_h323 helper active.  The decoder fully consumes the\nPER buffer before reaching this code path, resulting in a 1-2 byte\nheap-buffer-overflow read confirmed by AddressSanitizer.\n\nFix this by checking for 2 bytes (the maximum that get_len() may read)\ninstead of the uninitialized `len`.  This matches the pattern used at\nevery other get_len() call site in the same file, where the caller\nchecks for 2 bytes of available data before calling get_len().",
  "id": "GHSA-qx8f-4v7p-9m35",
  "modified": "2026-05-08T15:31:18Z",
  "published": "2026-05-06T12:30:34Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43233"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/2a3aac4205e7d2f1aca2e3827de8cdd517d36c4a"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/35f1943d242e1b9f0b6e91c0c93bfb293a9f8224"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/53d32735d77ab56cc3fc7bd53a7d099418f19be1"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/7ef82863d42261817a6394c6c881bd6757a70f16"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/81f2fc5b0d0cf4696146f00f837596d10b92dead"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/baed0d9ba91d4f390da12d5039128ee897253d60"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/bcb50aa0b8f2b74a9fe5a1c7bee6f2657a288041"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/f0a83d0a4b7c127d32ac06d607a9214937716129"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…

Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.

Loading…

Loading…

Loading…

Related by attack behaviour

Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.


Loading…