[Bug libc/16438] New: Security risks from definition of some types as __syscall_[su]long_t on x32

["bugdal at aerifal dot cx" <sourceware-bugzilla at sourceware dot org>]

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.