Summary: | app-crypt/veracrypt-1.25.7: runtime errors with GLIBCXX_ASSERTIONS | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Peter <plobster> |
Component: | Current packages | Assignee: | Göktürk Yüksek <gokturk> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | sam |
Priority: | Normal | Keywords: | PATCH |
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
URL: | https://github.com/veracrypt/VeraCrypt/issues/896 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | 844928 | ||
Bug Blocks: | |||
Attachments: |
veracrypt-output.txt
veracrypt-output-gtk.txt backtrace.log Possible fix Patch Attempt #1 Output Possible fix v2 |
Description
Peter
2022-02-16 00:14:59 UTC
Created attachment 765215 [details]
veracrypt-output.txt
Original VeraCrypt crash
Created attachment 765216 [details]
veracrypt-output-gtk.txt
VeraCrypt output (built w/o GLIBCXX_ASSERTIONS)
Created attachment 765217 [details]
backtrace.log
Backtrace of original VeraCrypt crash
I told Peter to file this bug so we can keep an eye on the upstream one & add a filter-flags for now given it causes a runtime crash. Turns out when compiling `gui-libs/gtk` without `GLIBCXX_ASSERTIONS`, doesn't solve the output displayed on `veracrypt-output-gtk.txt`. The problem is still present, however it happens to appear less often it may seem. Would you be able to confirm that this is isolated to 1.25.7 by temporarily downgrading to a previous version? It fails on its way to executing mkfs.ext4. A quick glance at the tag diff doesn't point to anything obvious. The problem is triggered at frame 5: #5 VeraCrypt::Process::Execute(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::__cxx11::list<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > > const&, int, VeraCrypt::ProcessExecFunctor*, VeraCrypt::Buffer const*) (processName="mkfs.ext4", arguments=<optimized out>, timeOut=-1, execFunctor=<optimized out>, inputData=0x7fffffffd100) at ../Platform/Unix/Process.cpp:144 Process.cpp line 144 is (https://github.com/veracrypt/VeraCrypt/blob/VeraCrypt_1.25.7/src/Platform/Unix/Process.cpp#L144): bytesRead = read (fd, &buffer[0], buffer.capacity()); where buffer is declared as: vector <char> buffer (4096) Looking at frame 4 in the backtrace, `buffer[0]` triggers ::operator[](unsigned long), which is: reference operator[](size_type __n) _GLIBCXX_NOEXCEPT { __glibcxx_requires_subscript(__n); return *(this->_M_impl._M_start + __n); } So it must be hitting __glibcxx_requires_subscript, which is: define __glibcxx_requires_subscript(_N) \ __glibcxx_assert(_N < this->size()) The parameter `_N` should be 0 in this case. I think I know what the problem is: 121 vector <char> buffer (4096) ... // Sets size to 4096 122 buffer.clear () // Sets size to 0 ... 144 ... &buffer[0] ... // ::operator[0] triggers (_N < this->size()) which fails due to (0 < 0) Most likely the standard library copes with this just fine in general. Apparently clear() is not guaranteed to deallocate the space. In the cases that it does though, this sounds like a possible dangling pointer issue. I think the author meant to accomplish something akin to memset(0) with clear(), not actually ask to deallocate the space. Created attachment 765219 [details, diff]
Possible fix
Can you give this patch a try and see if it triggers the assertion?
Yes, this happens on 1.24_p8. Patch testing results, in tow. Patch didn't apply Created attachment 765222 [details]
Patch Attempt #1 Output
Created attachment 765224 [details, diff]
Possible fix v2
Sigh, I forgot that I override ${S} in the ebuild. The patch was against the git repo. This should apply fine now, does so on my machine.
Yep, it applied now. No error, we're good. Thank you, Göktürk for your promptness and effort. Upstream have adopted a different patch: https://github.com/veracrypt/VeraCrypt/commit/b52ce86040e25dc5906adab872558547355b5637. |