This is the mail archive of the glibc-bugs@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug libc/1184] New: User stack data corruption by calling sched_getaffinity() and limitation of number of cpus


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]