Bug #210

another SSP bug? (Re: userland ppp ("No context" errors))

Added by qhwt+dfly almost 10 years ago. Updated over 7 years ago.

Status:ClosedStart date:
Priority:NormalDue date:
Assignee:-% Done:

0%

Category:-
Target version:-

Description

(bringing an old mail from users@)
On Thu, Feb 09, 2006 at 12:48:06PM +0000, Francis Gudin wrote:
> about compilation flags, i use the following:
> CCVER= gcc34
> CFLAGS= -Os -pipe
> COPTFLAGS= -Os -pipe
> CPUTYPE= i686
>
> I checked ppp.conf for weird chars but nothing came out:
> aimable# tr '[\200-\377]' @ < /mnt/etc/ppp/ppp.conf | diff -u -
> /mnt/etc/ppp/ppp.conf
> aimable#
>
> I will try to recompile ppp with '-O -pipe' only and report if things
> are different. I must leave for two days: results by saturday/sunday.

This seems like another stack-smash-protector bug and still lives
in our compiler, only triggered when you use -O(s|[2-9]) flags AND
-march flag (which defaults to pentiumpro) .

If you do one of the following and the problem disappears:
- add -fno-stack-smash-protector to CFLAGS
- change prefix[] in function FindExec() shown below to a static array
so as there's no char array in the local parameter. char array of
size more than 8 bytes on the stack can trigger the bug.

%%%
static int
FindExec(struct bundle *bundle, struct cmdtab const *cmds, int argc, int argn,
char const *const *argv, struct prompt *prompt, struct datalink *cx)
{
struct cmdtab const *cmd;
int val = 1;
int nmatch;
struct cmdargs arg;
char prefix[100];
%%%

I havn't managed to trim down the source code to a handy size yet.

ssp.c Magnifier (1.14 KB) qhwt+dfly, 06/19/2006 04:25 PM

History

#1 Updated by joerg over 10 years ago

On Mon, Jun 19, 2006 at 07:06:40PM +0900, YONETANI Tomokazu wrote:
> This seems like another stack-smash-protector bug and still lives
> in our compiler, only triggered when you use -O(s|[2-9]) flags AND
> -march flag (which defaults to pentiumpro) .

-march or -mcpu? The former is certainly not default and can trigger a
variety of bugs.

> If you do one of the following and the problem disappears:
> - add -fno-stack-smash-protector to CFLAGS
> - change prefix[] in function FindExec() shown below to a static array
> so as there's no char array in the local parameter. char array of
> size more than 8 bytes on the stack can trigger the bug.

Well, under 8 byte the stack protection would not be active.

Joerg

#2 Updated by qhwt+dfly over 10 years ago

On Mon, Jun 19, 2006 at 01:30:51PM +0200, wrote:
> On Mon, Jun 19, 2006 at 07:06:40PM +0900, YONETANI Tomokazu wrote:
> > This seems like another stack-smash-protector bug and still lives
> > in our compiler, only triggered when you use -O(s|[2-9]) flags AND
> > -march flag (which defaults to pentiumpro) .
>
> -march or -mcpu? The former is certainly not default and can trigger a
> variety of bugs.

Sorry, the default is -mtune, but both -march=pentiumpro and
-mtune=pentiumpro can trigger the bug(and the compiler complained
that -mcpu is deprecated).

> > If you do one of the following and the problem disappears:
> > - add -fno-stack-smash-protector to CFLAGS
> > - change prefix[] in function FindExec() shown below to a static array
> > so as there's no char array in the local parameter. char array of
> > size more than 8 bytes on the stack can trigger the bug.
>
> Well, under 8 byte the stack protection would not be active.

I have almost zero knowledge of how stack protector works, but
does it only care about char array of size greater than 8 bytes
(8 bytes was ok)? I also tried int[] and double[], but none of them
did it.

#3 Updated by joerg over 10 years ago

On Mon, Jun 19, 2006 at 09:13:15PM +0900, YONETANI Tomokazu wrote:
> I have almost zero knowledge of how stack protector works, but
> does it only care about char array of size greater than 8 bytes
> (8 bytes was ok)? I also tried int[] and double[], but none of them
> did it.

Hm. Could be a bug in the reordering done for character arrays only.
If you can create a smaller testcase, we can bug Etoh about it :-)

Joerg

#4 Updated by qhwt+dfly over 10 years ago

On Mon, Jun 19, 2006 at 02:20:36PM +0200, wrote:
> On Mon, Jun 19, 2006 at 09:13:15PM +0900, YONETANI Tomokazu wrote:
> > I have almost zero knowledge of how stack protector works, but
> > does it only care about char array of size greater than 8 bytes
> > (8 bytes was ok)? I also tried int[] and double[], but none of them
> > did it.
>
> Hm. Could be a bug in the reordering done for character arrays only.
> If you can create a smaller testcase, we can bug Etoh about it :-)

Done. It's very hard to narrow down when gdb lies to me :)
(attached)

#5 Updated by qhwt+dfly over 10 years ago

Additional notes:

On Tue, Jun 20, 2006 at 01:20:56AM +0900, YONETANI Tomokazu wrote:
> > Hm. Could be a bug in the reordering done for character arrays only.
> > If you can create a smaller testcase, we can bug Etoh about it :-)
>
> Done. It's very hard to narrow down when gdb lies to me :)
> (attached)

> static int
> bar(void *p)
> {
> char baz[9];
> int val = 1;
>
> /* just to quiet gcc, no effects on the result */
> (void)baz; (void)val;

Turned out that `val' is not needed, only baz[] with its size > 8bytes
is needed.

> if (true_expr && !p)
> p = &foo;
> if (true_expr && !p)

And if you exchange `true_expr' and `!p' around `&&' in either or both
of if-statement above, the bug is not triggered.

#6 Updated by qhwt+dfly over 10 years ago

On Mon, Jun 19, 2006 at 02:20:36PM +0200, wrote:
> Hm. Could be a bug in the reordering done for character arrays only.
> If you can create a smaller testcase, we can bug Etoh about it :-)

Anyone already told him about this problem? If not, please tell me
his email address.

Thanks.

#7 Updated by joerg over 10 years ago

On Tue, Jun 27, 2006 at 04:36:24PM +0900, YONETANI Tomokazu wrote:
> On Mon, Jun 19, 2006 at 02:20:36PM +0200, wrote:
> > Hm. Could be a bug in the reordering done for character arrays only.
> > If you can create a smaller testcase, we can bug Etoh about it :-)
>
> Anyone already told him about this problem? If not, please tell me
> his email address.

I did, but it often takes some time for him to respond.

Joerg

#8 Updated by qhwt+dfly over 10 years ago

On Tue, Jun 27, 2006 at 01:04:09PM +0200, wrote:
> On Tue, Jun 27, 2006 at 04:36:24PM +0900, YONETANI Tomokazu wrote:
> > On Mon, Jun 19, 2006 at 02:20:36PM +0200, wrote:
> > > Hm. Could be a bug in the reordering done for character arrays only.
> > > If you can create a smaller testcase, we can bug Etoh about it :-)
> >
> > Anyone already told him about this problem? If not, please tell me
> > his email address.
>
> I did, but it often takes some time for him to respond.

Thanks, I just wanted to make sure he's been notified :)

#9 Updated by qhwt+dfly over 10 years ago

Just FYI, the current release version of GCC, 4.1.1, has incorporated
a reimplemented version of SSP and that version doesn't have this bug.

Cheers.

#10 Updated by qhwt+dfly over 10 years ago

As the default compiler has been switched to gcc4 this doesn't
seem to be important anymore. Do we want to close this one?

Also available in: Atom PDF