Bug#968606: vte: Racy NULL-ptr segfault in vte::terminal::update_repeat_timeout()

[Simon McVittie]

Control: retitle -1 vte: Racy NULL-ptr segfault in vte::terminal::update_repeat_timeout()
Control: forwarded -1 https://gitlab.gnome.org/GNOME/vte/-/issues/270
Control: affects -1 + guake

On Tue, 18 Aug 2020 at 17:52:40 +0300, ulidtko at gmail.com wrote:
> Despite this being formally a [low-risk] security issue (CWE-476, null
> pointer dereference)

Is it triggerable by an attacker? If not, then it isn't a security issue:
it might well be a very annoying bug, but it's "just a bug".

If it's attacker-triggerable, please contact the security team *privately*
with details. (Don't contact this bug report's email address with details,
because Debian bug reports are public.)

> .. What I got in response was "No, I'd rather like to find the problem than
> paper over it."

I realise this is frustrating, but I can understand why the upstream
maintainer has taken this line, because for this to happen, something
that "shouldn't happen" must have happened somewhere (somehow a list of
non-NULL things has acquired a NULL item), which could indicate a more
serious bug. You have an environment that can reproduce this crash, he
doesn't, so you are more likely to be able to get enough information to
find the root cause than he is.

> There's only so much time I can devote to Open Source volunteering.

Sorry, the same is true for the vte upstream maintainer, the vte
maintainers in Debian, the Debian security team, and me. We're all in
this together, and I don't think any of the people involved here have
a contractual relationship that requires them to do particular work.

> 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]

Backtraces and stderr (as seen on the upstream vte and guake bug reports)
are going to be a lot more useful for figuring out what is going on.
No need to send them here, the upstream vte bug report is probably a
better place for that information anyway.

One thing that would definitely be useful, which I haven't seen done in
a brief skim-read of the vte bug, would be to attempt to reproduce this
issue under gdb with the G_DEBUG=fatal-criticals environment variable.
That will cause an event that is caught by gdb (usually SIGABRT or SIGTRAP
or something, but it depends on the CPU architecture) whenever there
is a critical warning.

Critical warnings are issued by g_critical() or by
the macros described as diagnosing programming errors in
https://developer.gnome.org/glib/stable/glib-Warnings-and-Assertions.html;
by default they try to continue without aborting the program, to try to
mitigate data loss, but they (should) always indicate that something is
badly wrong, and it's often more enlightening to get a backtrace for the
point where a programming error was first diagnosed, rather than for a
crash that happens at some later time.

> 2) Can I submit a distribution-patch as a shortcut so that at least Debian
> users of Guake are protected from the crash?

You're welcome to suggest one. I would recommend using g_return_if_fail(),
g_return_val_if_fail() or g_critical() to indicate the problem, so that
a critical warning is logged - otherwise nobody will know that anything
is wrong, hiding the problem.

> 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.

CVE IDs are a mechanism for tracking known security vulnerabilities
so that sysadmins and users can know which packages need updating or
avoiding. They are not a weapon to beat maintainers with; please don't
treat them as that.

(Procedurally, I don't think the Debian CNA is allowed to assign CVE
numbers to vulnerabilities that are already known outside Debian.)

    smcv