x86_64 bad frame in signal deliver

From: Jan Kasprzak
Date: Mon Apr 19 2004 - 09:22:52 EST


Hello, all!

I have got the following messages on my FTP server running x86_64:

proftpd[16913]: segfault at 0000007fbf7ff170 rip 000000000041ecaa rsp 0000007fbf7ff160 error 6
proftpd[16913] bad frame in signal deliver frame:0000007fbf7fef18 rip:41ecaa rsp:7fbf7ff160 orax:ffffffffffffffff
proftpd[17332]: segfault at 0000007fbf7ff170 rip 000000000041ecaa rsp 0000007fbf7ff160 error 6
proftpd[17332] bad frame in signal deliver frame:0000007fbf7fef18 rip:41ecaa rsp:7fbf7ff160 orax:ffffffffffffffff
proftpd[17803]: segfault at 0000007fbf7ff170 rip 000000000041ecaa rsp 0000007fbf7ff160 error 6
proftpd[17803] bad frame in signal deliver frame:0000007fbf7fef18 rip:41ecaa rsp:7fbf7ff160 orax:ffffffffffffffff
proftpd[18200]: segfault at 0000007fbf7ff170 rip 000000000041ecaa rsp 0000007fbf7ff160 error 6
proftpd[18200] bad frame in signal deliver frame:0000007fbf7fef18 rip:41ecaa rsp:7fbf7ff160 orax:ffffffffffffffff

Does that mean that proftpd segfaulted inside user space (and is thus
buggy or even insecure) - as address rip:41ecaa suggests, or is it some kind
of kernel bug?

The /proc/<pid of proftpd>/maps on my system suggests that
0x41ecaa is a valid code address:

/proc/9878/maps:00400000-00460000 r-xp 00000000 09:00 765659 /usr/sbin/proftpd
/proc/9878/maps:0055f000-00568000 rw-p 0005f000 09:00 765659 /usr/sbin/proftpd
/proc/9878/maps:00667000-00668000 rw-p 00067000 09:00 765659 /usr/sbin/proftpd

Kernel is 2.6.5 on Fedora Core 1/x86_64.

Thanks,

-Yenya

--
| Jan "Yenya" Kasprzak <kas at {fi.muni.cz - work | yenya.net - private}> |
| GPG: ID 1024/D3498839 Fingerprint 0D99A7FB206605D7 8B35FCDE05B18A5E |
| http://www.fi.muni.cz/~kas/ Czech Linux Homepage: http://www.linux.cz/ |
Any compiler or language that likes to hide things like memory allocations
behind your back just isn't a good choice for a kernel. --Linus Torvalds
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/