This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug libc/16438] New: Security risks from definition of some types as __syscall_[su]long_t on x32
- From: "bugdal at aerifal dot cx" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sourceware dot org
- Date: Sun, 12 Jan 2014 01:18:59 +0000
- Subject: [Bug libc/16438] New: Security risks from definition of some types as __syscall_[su]long_t on x32
- Auto-submitted: auto-generated
https://sourceware.org/bugzilla/show_bug.cgi?id=16438
Bug ID: 16438
Summary: Security risks from definition of some types as
__syscall_[su]long_t on x32
Product: glibc
Version: unspecified
Status: NEW
Severity: normal
Priority: P2
Component: libc
Assignee: unassigned at sourceware dot org
Reporter: bugdal at aerifal dot cx
CC: drepper.fsp at gmail dot com
As part of the x32 port, a number of types/struct fields which were originally
"long" or "unsigned long" were changed to __syscall_slong_t or
__syscall_ulong_t, when an obvious alternative choice of leaving them as "long"
and adding an adjacent padding field would have been equally compatible with
the kernel. In at least some cases, the use of 64-bit types poses a security
risk by breaking reasonable overflow checks. For example, if len has 64-bit
type but size_t is just 32-bit, then:
if (size < SIZE_MAX - len) p = malloc(size + len);
fails to detect overflows and passes a truncated size to malloc.
The first example I noticed is in sysdeps/unix/sysv/linux/x86/bits/msq.h:
typedef __syscall_ulong_t msglen_t;
I'm not sure if this one is itself dangerous.
My preference would be to have all of these usages changed from 64-bit to
32-bit with an adjacent 32-bit padding field. The risk of unexpected, possibly
dangerous behavior when fields which contain lengths/counts/etc. are larger
than size_t are too great, especially on a target that's still not widely used
and not getting heavy testing.
--
You are receiving this mail because:
You are on the CC list for the bug.