Attempts to set date with 'date -s' hang the machine

Attempts to set date with 'date -s' hang the machine

[Jurij Smakov]

Hi,

It has been recently reported on debian-sparc mailing list [0] that 
attempting to set date using 'date -s' results in a hang. I was able to 
reproduce it with 2.6.15.1 (on Ultra60, original report was for Ultra5) 
and did some preliminary debugging. It appears that the hang happens in 
get_compat_timespec(), called from compat_sys_clock_settime() in 
kernel/compat.c. I have printed the values of pointers passed to 
get_compat_timespec(), for the call which hangs the box they looked like 
this:

get_compat_timespec: tsÿfff800bf7a7e80
get_compat_timespec: ts->tv_secÿfff800bf7a7e80
get_compat_timespec: ts->tv_nsecÿfff800bf7a7e88
get_compat_timespec: ctsÿffffffef8d7cd8
get_compat_timespec: cts->tv_secÿffffffef8d7cd8
get_compat_timespec: cts->tv_nsecÿffffffef8d7cdc

I've also got the debugging output from a few other (successful)
calls to get_compat_timespec(), the output then typically looks 
like that:

get_compat_timespec: tsÿfff800bfbc7e80
get_compat_timespec: ts->tv_secÿfff800bfbc7e80
get_compat_timespec: ts->tv_nsecÿfff800bfbc7e88
get_compat_timespec: cts\0000000efa23c88
get_compat_timespec: cts->tv_sec\0000000efa23c88
get_compat_timespec: cts->tv_nsec\0000000efa23c8c

Here the higher byte of the cts is set to zero, as I believe it should be 
for a userspace address. In the failing case the upper byte is set to
ffffffff, which probably causes the problem. I'd appreciate any ideas on 
how to resolve this issue.

[0] http://lists.debian.org/debian-sparc/2006/01/msg00129.html

Best regards,

Jurij Smakov                                        jurij@wooyd.org
Key: http://www.wooyd.org/pgpkey/                   KeyID: C99E03CC

Re: Attempts to set date with 'date -s' hang the machine

[David S. Miller]

From: Jurij Smakov <jurij@wooyd.org>
Date: Mon, 30 Jan 2006 00:34:51 -0800 (PST)

> get_compat_timespec: tsÿfff800bf7a7e80
> get_compat_timespec: ts->tv_secÿfff800bf7a7e80
> get_compat_timespec: ts->tv_nsecÿfff800bf7a7e88
> get_compat_timespec: ctsÿffffffef8d7cd8
> get_compat_timespec: cts->tv_secÿffffffef8d7cd8
> get_compat_timespec: cts->tv_nsecÿffffffef8d7cdc
> 
> I've also got the debugging output from a few other (successful)
> calls to get_compat_timespec(), the output then typically looks 
> like that:
> 
> get_compat_timespec: tsÿfff800bfbc7e80
> get_compat_timespec: ts->tv_secÿfff800bfbc7e80
> get_compat_timespec: ts->tv_nsecÿfff800bfbc7e88
> get_compat_timespec: cts\0000000efa23c88
> get_compat_timespec: cts->tv_sec\0000000efa23c88
> get_compat_timespec: cts->tv_nsec\0000000efa23c8c
> 
> Here the higher byte of the cts is set to zero, as I believe it should be 
> for a userspace address. In the failing case the upper byte is set to
> ffffffff, which probably causes the problem. I'd appreciate any ideas on 
> how to resolve this issue.

In the first case get_compat_timespec() is being called with user
pointers which have been sign extended, and that's the bug.

A simple tree-wide grep for compat_sys_clock_settime() shows where
this is occuring, in arch/sparc64/kernel/sys32.S with this compat
syscall stub:

SIGN1(sys32_clock_settime, compat_sys_clock_settime, %o1)

Which is extending the pointer second arg.  In fact no sign extensions
are actually necessary here, so this stub can just be completely
eliminated.

This patch does that, and should fix this bug.

diff --git a/arch/sparc64/kernel/sys32.S b/arch/sparc64/kernel/sys32.S
index 9cd272a..60b5937 100644
--- a/arch/sparc64/kernel/sys32.S
+++ b/arch/sparc64/kernel/sys32.S
@@ -84,7 +84,6 @@ SIGN2(sys32_fadvise64_64, compat_sys_fad
 SIGN2(sys32_bdflush, sys_bdflush, %o0, %o1)
 SIGN1(sys32_mlockall, sys_mlockall, %o0)
 SIGN1(sys32_nfsservctl, compat_sys_nfsservctl, %o0)
-SIGN1(sys32_clock_settime, compat_sys_clock_settime, %o1)
 SIGN1(sys32_clock_nanosleep, compat_sys_clock_nanosleep, %o1)
 SIGN1(sys32_timer_settime, compat_sys_timer_settime, %o1)
 SIGN1(sys32_io_submit, compat_sys_io_submit, %o1)
diff --git a/arch/sparc64/kernel/systbls.S b/arch/sparc64/kernel/systbls.S
index bf0fc5b..2881faf 100644
--- a/arch/sparc64/kernel/systbls.S
+++ b/arch/sparc64/kernel/systbls.S
@@ -71,7 +71,7 @@ sys_call_table32:
 /*240*/	.word sys_munlockall, sys32_sched_setparam, sys32_sched_getparam, sys32_sched_setscheduler, sys32_sched_getscheduler
 	.word sys_sched_yield, sys32_sched_get_priority_max, sys32_sched_get_priority_min, sys32_sched_rr_get_interval, compat_sys_nanosleep
 /*250*/	.word sys32_mremap, sys32_sysctl, sys32_getsid, sys_fdatasync, sys32_nfsservctl
-	.word sys_ni_syscall, sys32_clock_settime, compat_sys_clock_gettime, compat_sys_clock_getres, sys32_clock_nanosleep
+	.word sys_ni_syscall, compat_sys_clock_settime, compat_sys_clock_gettime, compat_sys_clock_getres, sys32_clock_nanosleep
 /*260*/	.word compat_sys_sched_getaffinity, compat_sys_sched_setaffinity, sys32_timer_settime, compat_sys_timer_gettime, sys_timer_getoverrun
 	.word sys_timer_delete, compat_sys_timer_create, sys_ni_syscall, compat_sys_io_setup, sys_io_destroy
 /*270*/	.word sys32_io_submit, sys_io_cancel, compat_sys_io_getevents, sys32_mq_open, sys_mq_unlink

Re: Attempts to set date with 'date -s' hang the machine

[Frans Pop]

[-- Attachment #1: Type: text/plain, Size: 227 bytes --]

On Monday 30 January 2006 10:19, David S. Miller wrote:
> This patch does that, and should fix this bug.

I've tested this patch on my Ultra10 and it works. The date is now set 
correctly without hanging.

Thanks David.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: Attempts to set date with 'date -s' hang the machine

[David S. Miller]

From: Frans Pop <aragorn@tiscali.nl>
Date: Mon, 30 Jan 2006 14:07:24 +0100

> I've tested this patch on my Ultra10 and it works. The date is now set 
> correctly without hanging.
> 
> Thanks David.

Thanks for testing.

Re: Attempts to set date with 'date -s' hang the machine

[Horms]

For anyone who cares, this problem has now been assigned CVE-2006-0482
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-0482
(That link isn't active yet, but hopefully it will be soon)

-- 
Horms