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).