CVE-2023-39272 is a high severity (CVSS 7.8) integer overflow in GTKWave 3.3.115, the waveform viewer. A crafted .lxt2 file can lead to code execution when someone opens it. This entry covers the lsb array allocation. The record names no fixed version, so check your distribution advisory.
What's affected
The NVD record names one product: GTKWave 3.3.115 from Tony Bybell. Linux distributions package the tool too, so the same code can sit behind a distro package name. The score is 7.8 (High) with the vector CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H.
This entry is one of several overflows in the same function area. The description says it concerns the integer overflow when allocating the lsb array while parsing the LXT2 facgeometry data. The sibling CVEs cover the other arrays in that routine, and each has its own identifier. The weakness class is CWE-190 (integer overflow or wraparound).
The record does not mark this CVE as being in the CISA Known Exploited Vulnerabilities catalog, and nothing we could read says it is exploited in the wild. No fixed version is given in the record. Treat 3.3.115 as exposed until your vendor says otherwise.
In plain terms the vector means a local attack. It needs no account on the machine, but it does need a person to open the file. The impact on confidentiality, integrity and availability is rated high.
How to check if you're exposed
GTKWave is usually installed from a distribution package, so ask the package manager first.
dpkg -l gtkwave
gtkwave --version
rpm -q gtkwave
Use the line that matches your system. The record names version 3.3.115 as affected. If you build from source, check the tag you built from. Then look for stray inputs: ask the people who run simulations whether they open .lxt2 files that came from outside the team, and check shared drives and ticket attachments for them.
What to do now
- List every workstation, container image and CI runner that has GTKWave installed, with the version.
- Open the Debian LTS announcement and the Talos report linked from the record, then find the fixed package for your distribution and update. The record does not name a fixed upstream version, so confirm it from the advisory.
- Until the update is in, do not open
.lxt2files from outside sources, and do not pass them to any tool that reads the same format. - If a job opens waveform files automatically, run it in a disposable container with no secrets and no network access.
- Treat the whole group of LXT2 facgeometry CVEs (CVE-2023-39272 to CVE-2023-39275) as one patching job, since they affect the same release.
- Rescan after patching so the finding closes in your inventory.
Why it matters
LXT2 is a compressed waveform format that GTKWave reads for hardware and logic simulation results. When the program reads the facgeometry section, it works out how much memory to reserve for several arrays. The lsb array is one of them. An integer overflow in that size calculation can leave the buffer smaller than the data the program later writes into it. The advisory says a crafted file can turn that into arbitrary code execution.
The attack needs a person or a script to open the file, which narrows who is at risk. It is still a real exposure in verification and FPGA teams, where dumps move around through email, tickets and shared folders. A waveform file feels like data, so people open it without a second thought. Treat files from outside your team as untrusted input and keep the tool updated.
Try it yourself
Not every installed copy of a tool sits in a path an attacker can reach. This demo shows how reachability analysis separates exposure that matters from noise.
Click through it at your own pace, or open it full screen.
Quick check
Can someone exploit this over the network?
Not directly. The vector is local and needs a user to open a crafted file. The risk comes from where the file came from, such as an email, a ticket or a shared drive, and not from a listening service.
Why are there four CVEs for one function?
The advisory describes multiple integer overflows in the LXT2 facgeometry handling. Each allocation (lsb, flags, len and value) got its own CVE. A single package update should cover them if the fix addresses the whole routine, which is worth confirming in the advisory.
Sources
- Talos report TALOS-2023-1818 (listed in the NVD record; the page blocked automated access when we tried to read it, so this post relies on the NVD description)
- Debian LTS announcement, April 2024 (listed in the NVD record; it could not be loaded here, check it for packaged fix versions)
- Safeguard Gold entry for CVE-2023-39272
Last reviewed: 19 October 2026.
