Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 833444 - app-crypt/veracrypt-1.25.7: runtime errors with GLIBCXX_ASSERTIONS
Summary: app-crypt/veracrypt-1.25.7: runtime errors with GLIBCXX_ASSERTIONS
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Göktürk Yüksek
Keywords: PATCH
Depends on:
Reported: 2022-02-16 00:14 UTC by Peter
Modified: 2022-02-18 00:57 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---

veracrypt-output.txt (veracrypt-output.txt,915 bytes, text/plain)
2022-02-16 00:16 UTC, Peter
veracrypt-output-gtk.txt (veracrypt-output-gtk.txt,137 bytes, text/plain)
2022-02-16 00:17 UTC, Peter
backtrace.log (backtrace.log,10.74 KB, text/plain)
2022-02-16 00:17 UTC, Peter
Possible fix (v1-0001-Platform-Unix-Process.cpp-remove-calls-to-std-vec.patch,1.63 KB, patch)
2022-02-16 02:12 UTC, Göktürk Yüksek
Details | Diff
Patch Attempt #1 Output (build.log,8.12 KB, text/x-log)
2022-02-16 05:59 UTC, Peter
Possible fix v2 (v2-0001-Platform-Unix-Process.cpp-remove-calls-to-std-vec.patch,1.63 KB, patch)
2022-02-16 08:06 UTC, Göktürk Yüksek
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Peter 2022-02-16 00:14:59 UTC
VeraCrypt crashes upon entering a password, when using the new volume wizard, with the error displayed on `veracrypt-output.txt`. Upon compiling VeraCrypt without `GLIBCXX_ASSERTIONS`, the program because usable again; however still displaying the error shown in `veracrypt-output-gtk.txt`.

Only when compiling `gui-libs/gtk` without `GLIBCXX_ASSERTIONS`, and also having compiled VeraCrypt without `GLIBCXX_ASSERTIONS`, was I able to run VeraCrypt without any errors.

Attached is also the backtrace of the original problem.

Reproducible: Always

Steps to Reproduce:
1. Open VeraCrypt
2. Select "Create Volume"
3. Progress through "Create Volume" Wizard
Actual Results:  
Crashes with `veracrypt-output.txt` dispalyed on console.

Expected Results:  
No crashes
Comment 1 Peter 2022-02-16 00:16:22 UTC
Created attachment 765215 [details]

Original VeraCrypt crash
Comment 2 Peter 2022-02-16 00:17:12 UTC
Created attachment 765216 [details]

VeraCrypt output (built w/o GLIBCXX_ASSERTIONS)
Comment 3 Peter 2022-02-16 00:17:48 UTC
Created attachment 765217 [details]

Backtrace of original VeraCrypt crash
Comment 4 Sam James archtester Gentoo Infrastructure gentoo-dev Security 2022-02-16 00:26:03 UTC
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.
Comment 5 Peter 2022-02-16 00:41:23 UTC
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.
Comment 6 Göktürk Yüksek archtester gentoo-dev 2022-02-16 01:55:04 UTC
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 (

  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:

  operator[](size_type __n) _GLIBCXX_NOEXCEPT
    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.
Comment 7 Göktürk Yüksek archtester gentoo-dev 2022-02-16 02:12:42 UTC
Created attachment 765219 [details, diff]
Possible fix

Can you give this patch a try and see if it triggers the assertion?
Comment 8 Peter 2022-02-16 05:56:02 UTC
Yes, this happens on 1.24_p8.
Patch testing results, in tow.
Comment 9 Peter 2022-02-16 05:57:27 UTC
Patch didn't apply
Comment 10 Peter 2022-02-16 05:59:15 UTC
Created attachment 765222 [details]
Patch Attempt #1 Output
Comment 11 Göktürk Yüksek archtester gentoo-dev 2022-02-16 08:06:44 UTC
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.
Comment 12 Peter 2022-02-16 19:13:21 UTC
Yep, it applied now. No error, we're good.
Comment 13 Peter 2022-02-16 19:13:55 UTC
Thank you, Göktürk for your promptness and effort.
Comment 14 Sam James archtester Gentoo Infrastructure gentoo-dev Security 2022-02-18 00:57:13 UTC
Upstream have adopted a different patch: