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…

Detection rules are retrieved from Rulezet.

Loading…

Loading…