[Bug runtime/6524] New: user_long() on "bad" address makes system unstable

[Bug runtime/6524] New: user_long() on "bad" address makes system unstable

[mwielaard at redhat dot com]

kernel location: /usr/lib/debug/lib/modules/2.6.24.7-92.fc8/vmlinux
kernel version: 2.6.24.7-92.fc8
systemtap location: /home/mark/src/systemtap/stap
systemtap version: version 0.7/0.131 git branch master, commit c3799d72

Found while trying to clean up syscall2.stp for utime. There is no easy way to
get at __user struct fields so I am using hand calculated offsets into the
utimbuf for now.

Take the following stap script:

# long sys_utime(char __user * filename, struct utimbuf __user * times)
probe kernel.function("sys_utime") {
        actime = user_long($times + 0)
        utime = user_long($times + 8)
        print("utime(" . ctime(actime) . ", " . ctime(utime) . ")\n")
}

And the following little c program:

#include <sys/types.h>
#include <utime.h>

int
main (int argc, char *argv)
{
  struct utimbuf buf;
  buf.actime = 123456789;
  buf.modtime = 987654321;
  utime("/tmp/testfile", &buf);  
}

$ gcc -g -o utime utime.c
$ /usr/local/systemtap/bin/stap utime.stp &
[... wait ...]
$ ./utime
utime(Thu Nov 29 21:33:09 1973, Thu Apr 19 04:25:21 2001)

So that works pretty well.

Now however I made a mistake thinking longs were 4 bytes, but this is x86_64. So
change this line:
        utime = user_long($times + 8)
to:
        utime = user_long($times + 4)

Horrible things happen making the machine unusable.

-- 
           Summary: user_long() on "bad" address makes system unstable
           Product: systemtap
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: runtime
        AssignedTo: systemtap at sources dot redhat dot com
        ReportedBy: mwielaard at redhat dot com


http://sourceware.org/bugzilla/show_bug.cgi?id=6524

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug runtime/6524] user_long() on "bad" address makes system unstable

[mwielaard at redhat dot com]

------- Additional Comments From mwielaard at redhat dot com  2008-05-16 14:03 -------
Some extra data points:

On x86_64 2.6.18-84.el5 (as in comment #1) it fails.

On x84 (32 bit fedora 9) 2.6.25.3-18.fc9.i686 it never fails it always works,
just gives the wrong data of course (whether it is offset 1, 2, 3, 4, 5, ...)

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=6524

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug runtime/6524] ctime() on bad values hangs system

[fche at redhat dot com]

------- Additional Comments From fche at redhat dot com  2008-05-16 14:09 -------
Problem reduced to ctime() being invoked with big negative values.
user_long() itself did its job, just brought back big silly numbers.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|systemtap at sources dot    |mwielaard at redhat dot com
                   |redhat dot com              |
             Status|NEW                         |ASSIGNED
            Summary|user_long() on "bad" address|ctime() on bad values hangs
                   |makes system unstable       |system


http://sourceware.org/bugzilla/show_bug.cgi?id=6524

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug runtime/6524] user_long() on "bad" address makes system unstable

[fche at redhat dot com]

------- Additional Comments From fche at redhat dot com  2008-05-16 13:58 -------
Reproduced on RHEL5.2ish x86-64.


-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|0000-00-00 00:00:00         |2008-05-16 13:58:53
               date|                            |


http://sourceware.org/bugzilla/show_bug.cgi?id=6524

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.