This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug libc/1184] New: User stack data corruption by calling sched_getaffinity() and limitation of number of cpus
- From: "fenghua dot yu at intel dot com" <sourceware-bugzilla at sources dot redhat dot com>
- To: glibc-bugs at sources dot redhat dot com
- Date: 9 Aug 2005 00:37:29 -0000
- Subject: [Bug libc/1184] New: User stack data corruption by calling sched_getaffinity() and limitation of number of cpus
- Reply-to: sourceware-bugzilla at sources dot redhat dot com
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.