Bug 145258 - exec-shield randomisation breaks ntpd
Summary: exec-shield randomisation breaks ntpd
Status: CLOSED DUPLICATE of bug 154759
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Dave Jones
QA Contact: Brian Brock
: 155446 (view as bug list)
Depends On:
TreeView+ depends on / blocked
Reported: 2005-01-16 02:36 UTC by Sammy
Modified: 2015-01-04 22:15 UTC (History)
14 users (show)

Clone Of:
Last Closed: 2005-05-08 01:50:19 UTC

Attachments (Terms of Use)
ntpd crash output (1.78 KB, text/plain)
2005-01-16 02:51 UTC, Sammy
no flags Details

Description Sammy 2005-01-16 02:36:12 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (compatible; Konqueror/3.3; Linux; X11; en_US) KHTML/3.3.2 (like Gecko)

Description of problem:
ntpd dies immediately after being started with the latest FC4 kernels
(based on 2.6.11-rc1).  It is working fine with 2.6.10-1.1063_FC4smp
kernel. Options that are calculated in the /etc/rc.d/init.d/ntpd file are

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1.update to latest kernel
2.restart ntp

Additional info:

Comment 1 Sammy 2005-01-16 02:51:33 UTC
Created attachment 109835 [details]
ntpd crash output

Comment 2 Sammy 2005-01-17 14:23:59 UTC
I recompiled kernel with -bk4 patch and it stopped crashing. I'll monitor and 
report if there is any change. 

Comment 3 Sammy 2005-01-21 15:23:17 UTC
OK....ntpd is crashing again with the latest kernels based on -bk7 and -bk8. 

Comment 4 Sammy 2005-01-21 16:30:58 UTC
If I comment the Server lines in 0.pool etc in the ntp.conf file it 
no longer crashes. If I put anyting in there it does. I saw this by 
doing ntpd -D4 and looked were it crashed. 

Comment 5 G.Wolfe Woodbury 2005-01-27 14:00:08 UTC
I'm seeing this also under kernel ...1090_FC4 and ...1107_FC4
same symptoms
1090:Dell Lattitude CPi with PII-MMX
1107:AMD K6-2

Comment 6 Alexandre Oliva 2005-02-03 17:09:19 UTC
Ditto on 1115, on a Dell Inspiron with a Pentium III 1GHz.

I found that if I start strace -f ntp, it sometimes starts
successfully, other times it crashes after logging the ports it's
listening on, and then issuing the following syscalls:

rt_sigaction(SIGPIPE, {SIG_IGN}, NULL, 8) = 0
setsockopt(4, SOL_SOCKET, SO_REUSEADDR, [0], 4) = 0
setsockopt(5, SOL_SOCKET, SO_REUSEADDR, [0], 4) = 0
setsockopt(6, SOL_SOCKET, SO_REUSEADDR, [0], 4) = 0
setsockopt(7, SOL_SOCKET, SO_REUSEADDR, [0], 4) = 0
setsockopt(8, SOL_SOCKET, SO_REUSEADDR, [0], 4) = 0
setsockopt(9, SOL_SOCKET, SO_REUSEADDR, [0], 4) = 0
setsockopt(10, SOL_SOCKET, SO_REUSEADDR, [0], 4) = 0
rt_sigaction(SIGSYS, {0xa04b2f, [], SA_RESTORER, 0xb68a48}, {SIG_DFL},
8) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8)  = 0
adjtimex({modes=61, offset=0, freq=2563440, maxerror=16, esterror=16,
status=64, constant=0, precision=1, tolerance=33554432,
time={1107450206, 864189}}) = 5
rt_sigaction(SIGSYS, {SIG_DFL}, NULL, 8) = 0
--- SIGSEGV (Segmentation fault) @ 0 (0) ---

Comment 7 Alexandre Oliva 2005-02-08 06:45:23 UTC
Some more info: ntp doesn't always crash at the same spot, but it's
almost always within glibc, in function prologues, at the instruction
that calls __i686.get_pc_thunk.bx.  The stack pointer looks
reasonable, so I'd guess it's something wrong with the TLB handler.

Comment 8 Frank Ch. Eigler 2005-04-13 23:15:00 UTC
Rolling back to the FC3 2.6.10-1.770_FC3 kernel fixes this problem.
Therefore it is unlikely to be related to a concurrently-released glibc FC3 update.

Comment 9 Marco Colombo 2005-04-20 22:39:42 UTC
It seems this bug worked his way into FC3 updates (2.6.11-1.14_FC3).
See: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=155446
Can please someone confirm this?

Comment 10 Marco Colombo 2005-04-20 22:42:52 UTC
*** Bug 155446 has been marked as a duplicate of this bug. ***

Comment 11 Tomasz Ostrowski 2005-04-25 07:47:17 UTC
I can confirm that whis bug exists in up2dated FC3. I think it can have
something in common with bug #151262 (duplicate or depend).

There's a workaround for this issue. If an ntpd is started with:
        setarch i386 -L ntpd -u ntp:ntp -p /var/run/ntpd.pid
it doesn't crash.

Comment 12 Tomasz Ostrowski 2005-04-25 15:17:09 UTC
Another workaround:
Disable exec-shield-randomize by
        echo 0 > /proc/sys/kernel/exec-shield-randomize
        echo kernel.exec-shield-randomize = 1 >> /etc/sysctl.conf

Comment 13 Marco Colombo 2005-04-26 11:05:55 UTC
Yet another workaround:

execstack -s /usr/sbin/ntpd

As I understand it, it alters the binary:

rpm -V ntp
..5......   /usr/sbin/ntpd

but the rest of the system is unaffected.

Also, you can undo the change with:

execstack -c /usr/sbin/ntpd

which restores the old binary (rpm -V won't report it as changed).

Thanks to Tomasz for reporting the workarounds (as you may guess, mine
is based on the info he provided, it's just a different way to disable
the exec-shield for ntpd).

Comment 14 Rob Kearey 2005-05-03 00:15:48 UTC
Confirm the workaround works.

Comment 15 Florin Andrei 2005-05-04 19:03:50 UTC
FWIW, I did a fresh install but disabled anacron, so prelink has not been run
yet. I'm on the new kernel, and yet ntpd seems to be working fine.

Comment 16 Hans Ecke 2005-05-06 03:13:06 UTC
I just tested the prelink connection: 
I did a "prelink -uv" on the files that ntpd uses: 
And I still get the same Segmentation fault. 
The I did a "prelink -auv" and ntpd still Segfaults. 

Comment 17 Hans Ecke 2005-05-06 03:15:35 UTC
Could somebody please assign "DUPLICATE" status to two of the three bugs 
#145258 #154759 #151262 ? They are obviously the same problem. 

Comment 18 Warren Togami 2005-05-08 01:50:19 UTC

*** This bug has been marked as a duplicate of 154759 ***

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