cgit-0.8.3.5p1 segfault on 5.0 GENERIC#53 amd64

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

cgit-0.8.3.5p1 segfault on 5.0 GENERIC#53 amd64

Olivier Mehani-5
Hi,

I'm trying to run cgit on 5.0 GENERIC#53 amd64 on a VIA Nano U2250 (Dell
XS11-VX8). But I get segfaults right at the start.

I've tried both the binary package (cgit-0.8.3.5p1 from
ftp.fr.openbsd.org) and one built from ports (same from OPENBSD_5_0 on
anoncvs.fr.openbsd.org).

In both cases, it segfaults in trim_end() (line 114 [0]: t[len] = '\0';)
called from main() (line 686 [1]; both according to gdb*).  This bit of
code tries to trim the path after the last '/' in argv[0], whitc never
seems to have one even when manually called from a different directory
(e.g. ./cgi-bin/cgit.cgi).

What is odd is that in trim_end(), at the previous line also references
t[len] (c = t[len];), but doesn't fail there. c then changes to '\0'
(and gdb says it's "not available"), supposedly at line 113, then the
segfault occurs. len is 8, which is the length of str ("cgit.cgi").

However, there is some possibly dirty things happening as *t is a
pointer equals to trim_end's argument const char *str. Could this be
some protection forbidding functions to modifiy anything in the memory
passed as const?

Did anybody notice anything similar? Any idea on how to fix it or
investigate it further?

[0] http://hjemli.net/git/cgit/tree/shared.c?id=9e849950dc7c1f2fb6ffa62ab65bd30f35717d13#n114
[1] http://hjemli.net/git/cgit/tree/cgit.c?id=9e849950dc7c1f2fb6ffa62ab65bd30f35717d13#n686

* Starting program: /srv/www/cgi-bin/cgit.cgi

Program received signal SIGSEGV, Segmentation fault.
[Switching to process 28106, thread 0x203488800]
trim_end (str=0x56bc08 "cgit.cgi", c=0 '\0') at shared.c:114
114             t[len] = '\0';
(gdb) bt
#0  trim_end (str=0x56bc08 "cgit.cgi", c=0 '\0') at shared.c:114
#1  0x0000000000404f76 in main (argc=1, argv=0x7f7ffffc5800) at cgit.c:686

--
Olivier Mehani <[hidden email]>
PGP fingerprint: 4435 CF6A 7C8D DD9B E2DE  F5F9 F012 A6E2 98C6 6655

Reply | Threaded
Open this post in threaded view
|

Re: cgit-0.8.3.5p1 segfault on 5.0 GENERIC#53 amd64

Landry Breuil-6
On Mon, Mar 12, 2012 at 12:56:36PM +0000, Olivier Mehani wrote:

> Hi,
>
> I'm trying to run cgit on 5.0 GENERIC#53 amd64 on a VIA Nano U2250 (Dell
> XS11-VX8). But I get segfaults right at the start.
>
> I've tried both the binary package (cgit-0.8.3.5p1 from
> ftp.fr.openbsd.org) and one built from ports (same from OPENBSD_5_0 on
> anoncvs.fr.openbsd.org).
>
> In both cases, it segfaults in trim_end() (line 114 [0]: t[len] = '\0';)
> called from main() (line 686 [1]; both according to gdb*).  This bit of
> code tries to trim the path after the last '/' in argv[0], whitc never
> seems to have one even when manually called from a different directory
> (e.g. ./cgi-bin/cgit.cgi).
>
> What is odd is that in trim_end(), at the previous line also references
> t[len] (c = t[len];), but doesn't fail there. c then changes to '\0'
> (and gdb says it's "not available"), supposedly at line 113, then the
> segfault occurs. len is 8, which is the length of str ("cgit.cgi").
>
> However, there is some possibly dirty things happening as *t is a
> pointer equals to trim_end's argument const char *str. Could this be
> some protection forbidding functions to modifiy anything in the memory
> passed as const?

/etc/malloc.conf ?

> Did anybody notice anything similar? Any idea on how to fix it or
> investigate it further?

Never had any issue on amd64 since i've imported it. You may discuss it
with upstream... or try the new versions (0.9.0.2 is in current)

Landry

Reply | Threaded
Open this post in threaded view
|

Re: cgit-0.8.3.5p1 segfault on 5.0 GENERIC#53 amd64

Olivier Mehani
In gmane.os.openbsd.ports, you wrote:
> On Mon, Mar 12, 2012 at 12:56:36PM +0000, Olivier Mehani wrote:
>> However, there is some possibly dirty things happening as *t is a
>> pointer equals to trim_end's argument const char *str. Could this be
>> some protection forbidding functions to modifiy anything in the memory
>> passed as const?
> /etc/malloc.conf ?

Right. I wasn't aware of that. Thanks for the pointer.  However, nothing
special is set there (neither the symlink nor the environment variable).

I confirmed that the problem seems to be due to the const manipulation
addness, as the following test program segfaults in the same way.

int test (const char* a) {
        char *t=a;
        t[0]='a';
        return 0;
}

int main() {
        test("bbba");
        return 0;
}

GCC also complains when this get compiled but, oddly enough, not the
port when compiling shared.c...

>> Did anybody notice anything similar? Any idea on how to fix it or
>> investigate it further?
> Never had any issue on amd64 since i've imported it. You may discuss it
> with upstream... or try the new versions (0.9.0.2 is in current)

Yeah, the code for that function actually changed to something cleaner [0,1].
I'm not too keen on upgrading this server to current, but backporting the patch
[0] with the following as patches/patch-shared_c seems to fix the problem.

$OpenBSD$
--- shared.c.orig       Sat Mar  5 13:52:39 2011
+++ shared.c    Wed Mar 14 05:12:25 2012
@@ -98,23 +98,17 @@ void *cgit_free_commitinfo(struct commitinfo *info)
 char *trim_end(const char *str, char c)
 {
        int len;
-       char *s, *t;
 
        if (str == NULL)
                return NULL;
-       t = (char *)str;
-       len = strlen(t);
-       while(len > 0 && t[len - 1] == c)
                len--;
-
+       len = strlen(str);
+       while(len > 0 && str[len - 1] == c)
+               len--;
        if (len == 0)
                return NULL;
 
-       c = t[len];
-       t[len] = '\0';
-       s = xstrdup(t);
-       t[len] = c;
-       return s;
+       return strndup(str, len);
 }
 
 char *strlpart(char *txt, int maxlen)


Thanks for your help!

[0] http://hjemli.net/git/cgit/diff/shared.c?id=v0.8.3.5&id2=master
[1] http://hjemli.net/git/cgit/tree/shared.c?id=master#n102

--
Olivier Mehani <[hidden email]>
PGP fingerprint: 4435 CF6A 7C8D DD9B E2DE  F5F9 F012 A6E2 98C6 6655