Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 14 Dec 2017 09:04:26 +0000
From:      bugzilla-noreply@freebsd.org
To:        xfce@FreeBSD.org
Subject:   [Bug 212176] x11/xfce4-taskmanager segfault
Message-ID:  <bug-212176-28711-AKc0uIF6Wz@https.bugs.freebsd.org/bugzilla/>
In-Reply-To: <bug-212176-28711@https.bugs.freebsd.org/bugzilla/>
References:  <bug-212176-28711@https.bugs.freebsd.org/bugzilla/>

next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D212176

Guido Falsi <madpilot@FreeBSD.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
              Flags|maintainer-feedback?(xfce@F |maintainer-feedback+
                   |reeBSD.org)                 |
                 CC|                            |madpilot@FreeBSD.org

--- Comment #9 from Guido Falsi <madpilot@FreeBSD.org> ---
(In reply to Ivan from comment #6)
> Created attachment 174716 [details]
> patch
>=20
> Problem is here
> g_strlcpy (text, p, g_utf8_strlen (text, -1));
>=20
> To utf-8 unaware function number of chars are passed instead of bytes, so
> it's possible for 2 bytes chars it will split in half leading to incorrect
> unicode sequence.
>=20
> Attached patch resolves the issue, however crash still can occur if p >=3D
> text, however as p is substring of text, the situation is expected to nev=
er
> happen in normal conditions.
>=20
> I found no safe analog in gtk functions for strlcpy, only strncpy which is
> not considered safe. The alternative is switch to icu, however this is
> another story.

Hi,

The fix looks simple enough, but I'm not sure that using non utf aware
functions is better that using g_utf8_strncpy(), which would warrant utf8
conforming results.

also, looking at the g_utf8_strncpy() sources here:

https://github.com/GNOME/glib/blob/9c8c6094fdb3b7bff35c0f36a68e1da3fd2e8ff7=
/glib/gutf8.c#L413

it would be quite easy to cook up a g_utf8_strlcpy() (or any other name) us=
ing
the safer system provided strlcpy() call.

I'd like your opinion before proceeding though.

Any patch we prepare should be created accounting for upstreaming it if
possible.

--=20
You are receiving this mail because:
You are the assignee for the bug.=



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-212176-28711-AKc0uIF6Wz>