public inbox for glibc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug libc/1184] New: User stack data corruption by calling sched_getaffinity() and limitation of number of cpus
@ 2005-08-09 0:37 fenghua dot yu at intel dot com
2005-08-09 0:42 ` [Bug libc/1184] " fenghua dot yu at intel dot com
` (2 more replies)
0 siblings, 3 replies; 4+ messages in thread
From: fenghua dot yu at intel dot com @ 2005-08-09 0:37 UTC (permalink / raw)
To: glibc-bugs
Currently len in sched_getaffinity(pid, len, *mask) is hard coded as 128 bytes
in glibc regardless user's assignment. In kernel, real_len, which is real
bytes of cpu_mask, is compared against len. If len<real_len, kernel returns
EINVAL. But this checking never fails because len is hard coded as a big
number of 128 bytes( 1024 bits or 1024 cpus) between user program and kernel
by glibc.
This hard coding might cause two issues:
1. When user program gives a len value smaller than real kernel cpu_mask, the
system call goes through sanity checking and doesn't report error. Kernel just
handles the system call and returns successfully. But then kernel will corrupt
user stack silently because copy_to_user() copies real_len bytes of buffer to
user while user expects len bytes.
The attached (incorrectly coded) test case shows the data corruption. On
kernel with NR_CPUS<64 (EL3 and EL4), the test case runs ok. But on kernel
with NR_CPUS>64, the test case observes data corruption coming from
sched_getaffinity() although sched_getaffinity() doesn't report any error.
The attached trivial patch fixes this issue. With the fix, sched_getaffinity()
will report EINVAL error as expected.
2. This coding assumes NR_CPUS<=1024. With NR_CPUS>1024, this hard coding will
cause every sched_getaffinity() failure because len<real_len is true in kernel.
--
Summary: User stack data corruption by calling
sched_getaffinity() and limitation of number of cpus
Product: glibc
Version: unspecified
Status: NEW
Severity: normal
Priority: P2
Component: libc
AssignedTo: gotom at debian dot or dot jp
ReportedBy: fenghua dot yu at intel dot com
CC: glibc-bugs at sources dot redhat dot com
http://sources.redhat.com/bugzilla/show_bug.cgi?id=1184
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
^ permalink raw reply [flat|nested] 4+ messages in thread
* [Bug libc/1184] User stack data corruption by calling sched_getaffinity() and limitation of number of cpus
2005-08-09 0:37 [Bug libc/1184] New: User stack data corruption by calling sched_getaffinity() and limitation of number of cpus fenghua dot yu at intel dot com
@ 2005-08-09 0:42 ` fenghua dot yu at intel dot com
2005-08-09 0:43 ` fenghua dot yu at intel dot com
2005-09-28 5:33 ` drepper at redhat dot com
2 siblings, 0 replies; 4+ messages in thread
From: fenghua dot yu at intel dot com @ 2005-08-09 0:42 UTC (permalink / raw)
To: glibc-bugs
------- Additional Comments From fenghua dot yu at intel dot com 2005-08-09 00:42 -------
Created an attachment (id=584)
--> (http://sources.redhat.com/bugzilla/attachment.cgi?id=584&action=view)
This is a test case to demonstrate user stack data corruption when calling
sched_getaffinity() on IA64
--
http://sources.redhat.com/bugzilla/show_bug.cgi?id=1184
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
^ permalink raw reply [flat|nested] 4+ messages in thread
* [Bug libc/1184] User stack data corruption by calling sched_getaffinity() and limitation of number of cpus
2005-08-09 0:37 [Bug libc/1184] New: User stack data corruption by calling sched_getaffinity() and limitation of number of cpus fenghua dot yu at intel dot com
2005-08-09 0:42 ` [Bug libc/1184] " fenghua dot yu at intel dot com
@ 2005-08-09 0:43 ` fenghua dot yu at intel dot com
2005-09-28 5:33 ` drepper at redhat dot com
2 siblings, 0 replies; 4+ messages in thread
From: fenghua dot yu at intel dot com @ 2005-08-09 0:43 UTC (permalink / raw)
To: glibc-bugs
------- Additional Comments From fenghua dot yu at intel dot com 2005-08-09 00:43 -------
Created an attachment (id=585)
--> (http://sources.redhat.com/bugzilla/attachment.cgi?id=585&action=view)
Patch to fix the hard coding issue in sched_getaffinity() system call
--
http://sources.redhat.com/bugzilla/show_bug.cgi?id=1184
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
^ permalink raw reply [flat|nested] 4+ messages in thread
* [Bug libc/1184] User stack data corruption by calling sched_getaffinity() and limitation of number of cpus
2005-08-09 0:37 [Bug libc/1184] New: User stack data corruption by calling sched_getaffinity() and limitation of number of cpus fenghua dot yu at intel dot com
2005-08-09 0:42 ` [Bug libc/1184] " fenghua dot yu at intel dot com
2005-08-09 0:43 ` fenghua dot yu at intel dot com
@ 2005-09-28 5:33 ` drepper at redhat dot com
2 siblings, 0 replies; 4+ messages in thread
From: drepper at redhat dot com @ 2005-09-28 5:33 UTC (permalink / raw)
To: glibc-bugs
------- Additional Comments From drepper at redhat dot com 2005-09-28 05:33 -------
The cpu_set_t type is currently 1024 bits and can only ever grow. This is why
there is a size parameter. It does not exist to allow a programmer to pass in a
pointer to an object other than cpu_set_t. Therefore every program which sees
problems is broken.
--
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |INVALID
http://sourceware.org/bugzilla/show_bug.cgi?id=1184
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2005-09-28 5:33 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2005-08-09 0:37 [Bug libc/1184] New: User stack data corruption by calling sched_getaffinity() and limitation of number of cpus fenghua dot yu at intel dot com
2005-08-09 0:42 ` [Bug libc/1184] " fenghua dot yu at intel dot com
2005-08-09 0:43 ` fenghua dot yu at intel dot com
2005-09-28 5:33 ` drepper at redhat dot com
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).