Bug 16438 - [x86_64] Security risks from definition of some types as __syscall_[su]long_t on x32
Summary: [x86_64] Security risks from definition of some types as __syscall_[su]long_t...
Status: NEW
Alias: None
Product: glibc
Classification: Unclassified
Component: libc (show other bugs)
Version: unspecified
: P2 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
Depends on:
Reported: 2014-01-12 01:18 UTC by Rich Felker
Modified: 2014-06-13 09:00 UTC (History)
3 users (show)

See Also:
Host: x86_64-*-*
Last reconfirmed:
fweimer: security-


Note You need to log in before you can comment on or make changes to this bug.
Description Rich Felker 2014-01-12 01:18:59 UTC
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.
Comment 1 Florian Weimer 2014-06-13 09:00:08 UTC
I'm not treating this as a security bug, only concrete instances of a failing overflow check on x32 would qualify for that.