[PATCH] 2.4.x i386 SMP interrupts can corrupt registers

[PATCH] 2.4.x i386 SMP interrupts can corrupt registers

[john.l.byrne]

Currently, the SMP interrupt code generated by the macros
BUILD_SMP_INTERRUPT and BUILD_SMP_TIMER_INTERRUPT push the positive
interrupt vector number on the stack. If the correct signal is pending
on the process and %eax happens to have the correct value, do_signal()
can be spoofed into adjusting %eax and %eip with almost certainly bad
results. For example, trying to do a "strace -p" the following program
will result in its dumping core with an illegal instruction.

int
main(void)
{
	int i;

	asm (
		"mov %1,%0\n\t"
		"1:\t"
		"cmp %1,%0\n\t"
		"rep;nop\n\t"
		"je 1b\n\t"
		:"=&a" (i)
		:"i" (-512));

	return i;
}

I suspect what was wanted was to subtract 256, as is done in BUILD_IRQ,
to make the values negative, but leave the vector available in %al, so
I offer the following patch against 2.4.10-pre2 to do so. (The 2.2.x
code simply pushes -1. I don't see anything that uses the vector for
these interrupt, so this should work. However, I assume the change was
made so the vector number would be available on the stack, perhaps for
debugging.)

This has only been tested by me on my SMP box, but... (I don't want to
complete that sentence with words I might be forced to regret for some
reason.)

John Byrne

diff -Nar -u4 orig/include/asm-i386/hw_irq.h linux/include/asm-i386/hw_irq.h
--- orig/include/asm-i386/hw_irq.h	Mon Jul  9 13:28:00 2001
+++ linux/include/asm-i386/hw_irq.h	Wed Aug 29 09:48:38 2001
@@ -129,9 +129,9 @@
 asmlinkage void call_##x(void); \
 __asm__( \
 "\n"__ALIGN_STR"\n" \
 SYMBOL_NAME_STR(x) ":\n\t" \
-	"pushl $"#v"\n\t" \
+	"pushl $"#v"-256\n\t" \
 	SAVE_ALL \
 	SYMBOL_NAME_STR(call_##x)":\n\t" \
 	"call "SYMBOL_NAME_STR(smp_##x)"\n\t" \
 	"jmp ret_from_intr\n");
@@ -142,9 +142,9 @@
 asmlinkage void call_##x(void); \
 __asm__( \
 "\n"__ALIGN_STR"\n" \
 SYMBOL_NAME_STR(x) ":\n\t" \
-	"pushl $"#v"\n\t" \
+	"pushl $"#v"-256\n\t" \
 	SAVE_ALL \
 	"movl %esp,%eax\n\t" \
 	"pushl %eax\n\t" \
 	SYMBOL_NAME_STR(call_##x)":\n\t" \

Re: [PATCH] 2.4.x i386 SMP interrupts can corrupt registers

[Linus Torvalds]

On Wed, 29 Aug 2001 john.l.byrne@compaq.com wrote:
>
> Currently, the SMP interrupt code generated by the macros
> BUILD_SMP_INTERRUPT and BUILD_SMP_TIMER_INTERRUPT push the positive
> interrupt vector number on the stack.

[ Details deleted ]

Wow. Good catch - that's just incredibly broken, and I wonder how come the
SMP interrupt build stuff didn't get the right code copied from
BUILD_IRQ..

How the h*ll did you happen to actually notice this?

Obviously applied, thanks,

		Linus

Re: [PATCH] 2.4.x i386 SMP interrupts can corrupt registers

[John Byrne]

Linus Torvalds wrote:
> 
> On Wed, 29 Aug 2001 john.l.byrne@compaq.com wrote:
> >
> > Currently, the SMP interrupt code generated by the macros
> > BUILD_SMP_INTERRUPT and BUILD_SMP_TIMER_INTERRUPT push the positive
> > interrupt vector number on the stack.
> 
> [ Details deleted ]
> 
> Wow. Good catch - that's just incredibly broken, and I wonder how come
> the
> SMP interrupt build stuff didn't get the right code copied from
> BUILD_IRQ..

Thanks.

Incredibly broken, true, but I'm not sure how often anyone has seen the
bug.

While I'm not sure why the code wasn't copied properly, I looked through
the history via CVSweb and the reason the bug got through looks pretty
obvious:

The bug came into existence in 2.3.14, when the file
arch/i386/kernel/irq.h became include/asm-i386/hw_irq.h. The file was
moved and changed at the same time, but the bug was missed because the
diff would have shown the entire file being deleted in one place and
added in another. If the file had been moved first, and then the changes
made, the bug almost certainly would have been caught.

> 
> How the h*ll did you happen to actually notice this?

Some combination of blind luck, curiosity, pride, and Obsessive
Compulsive Disorder...

I happened to read the code and the difference between the macros looked
wrong; if the code was right, for some nonobvious reason, I was d*mn
well going to what it was!

> 
> Obviously applied, thanks,
> 
>                 Linus

You're welcome.

                John