Bug #210

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

Added by qhwt+dfly about 8 years ago. Updated over 5 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 about 8 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 about 8 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 about 8 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 about 8 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 about 8 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 about 8 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 about 8 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 about 8 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 about 8 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 about 6 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