This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug nptl/5481] New: Possible integer overflow in sem_post
- From: "mjb at cs dot bath dot ac dot uk" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sources dot redhat dot com
- Date: 12 Dec 2007 18:26:04 -0000
- Subject: [Bug nptl/5481] New: Possible integer overflow in sem_post
- Reply-to: sourceware-bugzilla at sourceware dot org
There might be an issue with integer overflow in sem_post in the CVS / 2.7
versions of libc.
__new_sem_post in nptl/sysdeps/unix/sysv/linux/sem_post.c seems to atomically
increment isem->value (which, I believe is an unsigned int
(nptl/sysdeps/unix/sysv/linux/internaltypes.h)) and then assigns this to an int
nr (should nr be an unsigned int ?). Although only horrendously badly designed
code would trigger this, I think it should perhaps have a catch for overflow for
the following reasons:
1. The POSIX standard includes SEM_VALUE_MAX, which is the upper limit on the
value of a POSIX semaphore (the equivalent of SEMVMX for SysV IPC semaphores).
2. __new_sem_init checks that the starting value is < SEM_VALUE_MAX
3. The LinuxThreads implementation performed this check in sem_post.
--
Summary: Possible integer overflow in sem_post
Product: glibc
Version: unspecified
Status: NEW
Severity: normal
Priority: P2
Component: nptl
AssignedTo: drepper at redhat dot com
ReportedBy: mjb at cs dot bath dot ac dot uk
CC: glibc-bugs at sources dot redhat dot com
http://sourceware.org/bugzilla/show_bug.cgi?id=5481
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.