Bug 85018 - SMP Register Corruption
Summary: SMP Register Corruption
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: kernel
Version: 7.1
Hardware: i686
OS: Linux
high
high
Target Milestone: ---
Assignee: Arjan van de Ven
QA Contact: Brian Brock
URL: http://www.cs.helsinki.fi/linux/linux...
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2003-02-24 21:57 UTC by Need Real Name
Modified: 2005-10-31 22:00 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2003-12-17 01:48:47 UTC


Attachments (Terms of Use)

Description Need Real Name 2003-02-24 21:57:23 UTC
Description of problem:

Following text has been replicated verbatim from original patch submission from 
John Byrne. See URL above.

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.)

Version-Release number of selected component (if applicable):
LAS 2.1
Red Hat 7.1

How reproducible:
Absolutely.

Steps to Reproduce:
1. See URL above for sample program
    
Actual results:


Expected results:


Additional info:

Comment 1 Arjan van de Ven 2003-02-24 22:34:22 UTC
the most current 7.1 kernel is 2.4.18-24.... I'd expect it to be fixed there....

Comment 2 Paul Hansen 2003-02-25 14:21:29 UTC
This bug was found in RedHat 7.1.  The patch has been incorporated
in Linux Advanced Server 2.1, as I verified from the source code.
As our upgrade plans are to go from 7.1 to LAS 2.1, I don't think
any further action is necessary on this bug; the fix is to upgrade. 


Note You need to log in before you can comment on or make changes to this bug.