Your message dated Mon, 15 Feb 2021 22:08:01 +0000
with message-id <[email protected]>
and subject line Re: Bug#968606: vte: Racy NULL-ptr segfault in
vte::terminal::update_repeat_timeout()
has caused the Debian Bug report #968606,
regarding vte: Racy NULL-ptr segfault in vte::terminal::update_repeat_timeout()
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
968606: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=968606
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: vte2.91
Version: 0.60.3-1
X-Debbugs-CC: Sylvestre Ledru <[email protected]>
X-Debbugs-CC: Pierre-Yves Chibon <[email protected]>
X-Debbugs-CC: [email protected]
Dear Debian Maintainers!
I'm a co-maintainer of Guake -- which is a graphical terminal emulator
built on top of libvte.
Recently, we started receiving an influx of crash reports. The crashes
are caused by a bug in libvte which leads to SIGSEGV under certain
conditions. See details in our issue:
https://github.com/Guake/guake/issues/1749
Despite this being formally a [low-risk] security issue (CWE-476, null
pointer dereference) -- I went by the constructive path and escalated
it publicly to the libvte upstream, in hopes of getting a quick
resolution: https://gitlab.gnome.org/GNOME/vte/-/issues/270
Please notice that I had provided excruciatingly detailed and complete
information about the bug there: including ASAN trace, gdb backtraces,
and even a suggestion on how to fix this (add a null check) at exact
line numbers.
The only thing I didn't do: I didn't provide minimized repro case.
That's because I tried several times to factor out Guake from the
crash, and failed, just as several other contributors who attempted the
same, and failed just as well.
.. What I got in response was "No, I'd rather like to find the problem
than paper over it." and more requests to do their development work for
them under the guise of "please retest with this patch".
There's only so much time I can devote to Open Source volunteering. I
hope you understand how I perceive the libvte developer's reaction as
lax, irresponsible and disrespectful to my time and to suffering of
Guake users. We are currently getting a new hand-written crash report
roughly every 2 weeks from Guake users.
So, as continuing the conversation with upstream seems unproductive --
I'm reaching out to Debian for help.
1) Can the Debian CNA assign a CVE number to this issue? It is
technically a vulnerability, and a CVE might convince the upstream
developer towards more collaborative attitude.
2) Can I submit a distribution-patch as a shortcut so that at least
Debian users of Guake are protected from the crash?
P.S. This is my first ever submission to bugs.debian.org -- I'm eager
to receive feedback in cases I missed some requirements or did
something wrong.
P.P.S: This is the error log as Debian BTS guide requires, from one of
GitHub reporters. Notice that the called address isn't 0x0 despite this
being an NPE -- my guess is that it's due to C++ vtable offsets and
garbled pointers.
[ 658.163288] guake[14712]: segfault at 9f0 ip 00006724096293a8 sp
000073bb8b72c9c0 error 4 in libvte-2.91.so.0.6000.1[67240960e000+48000]
[ 700.762559] guake[18766]: segfault at 5b787a69 ip 00006cd4e4aebcbf sp
000070de90039390 error 4 in libvte-2.91.so.0.6000.1[6cd4e4acf000+48000]
Best regards
Max
--- End Message ---
--- Begin Message ---
Version: 0.62.1-1
On Mon, 15 Feb 2021 at 22:40:55 +0100, Bernhard Übelacker wrote:
> marking fixed as mentioned in message by submitter to upstream bug [1].
> [1] https://gitlab.gnome.org/GNOME/vte/-/issues/270#note_1037042
Thanks! Closing the bug so the BTS will consider it to have been dealt
with (the fixed keyword doesn't do this).
smcv
--- End Message ---
