LibreCAD / LibreCAD

LibreCAD is a cross-platform 2D CAD program written in C++17. It can read DXF/DWG files and can write DXF/PDF/SVG files. It supports point/line/circle/ellipse/parabola/spline primitives. The user interface is highly customizable, and has dozens of translations.

Home Page:http://librecad.org/

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Crash due to Assert on Line Angle action (QT6)

sand1024 opened this issue · comments

Hi!

It seems that invocation of Line Angle action leads to crash (version built from master branch).
I'm not sure whether it's to QT6 - related issues, or with some saved settings, so it's better to check.

Expected behavior

Invoked action

Observed behavior

Assert and crash

Steps to reproduce or sample file

Using either empty drawing or existing one - just invoke Line Angle action.

As far as I can see, crash is due to assert in QString
ASSERT: "n <= d.size - pos" in file D:/Qt/QT6/6.7.0/mingw_64/include/QtCore/qstring.h, line 1061

What is strange - it seems it occurred in rs_dimensions.cpp:849, function stripZerosLinear, code

    while (i < ls-1 && linear[i] == QChar('0')) {
            i++;
        }

Assert occurs during processing settings, starting from qg_lineangleoptions.cpp:110.

Text read from option is "0", so the call from qg_lineangleoptions.cpp:38 that invokes strip of leading zero activates such assertion.

What is strange, that under QT5 this functionality worked pretty fine, so potentially, if this assert was introduced in QT6 - it may affect other parts of the codebase.

Anyway, please test in your environment to be sure whether such problem actually exists and is not related, say, to my environment.

Operating System and LibreCAD version info

(64 bit version, from master)

Version: 2.2.2-alpha
Compiler: GNU GCC 11.2.0
Compiled on: May 12 2024
Qt Version: 6.7.0
Boost Version: 1.84.0
System: Windows 10 Version 22H2

Amazing, this is a serious bug from the very beginning.

It was clearly a potential buffer overflow as the assertion as identified, so previous, the bug was there, but as there was no assertion, so not identified.

The bug is also quite clear:

  1. The string length is assigned to a variable "ls";
  2. The string is allowed to be trimmed from back, but "ls" is not updated, so potentially larger than the string length;
  3. The string is now trimmed from front, now, with an assumed length "ls", which is larger, so the comparison goes beyond the buffer size, and potentially causing writing beyond the string size.

It has been running properly so far, because the QString buffer is probably not immediately reduced after trimming in step 2, but it's still considered an undefined behavior.

The issue is so serious, I also pushed the fix to the 2.2.1 release candidate branch