LibreCAD
Crash due to Assert on Line Angle action (QT6)
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:
- The string length is assigned to a variable "ls";
- The string is allowed to be trimmed from back, but "ls" is not updated, so potentially larger than the string length;
- 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