Bug #413
closed
Memory corruption in regcmp(3c)
0%
Description
When regcmp(3c) is called with a single non-special character three bytes get
allocated for the return value, but a total of four bytes is written to the
buffer. When running with libumem this causes the boundary value 0xbb to be
overwritten and a redzone violation. A small testprogram is attached and output
from dbx and mdb follows:
uname -a
SunOS hostname 5.11 snv_89 i86pc i386 i86xpv Solaris
Output from dbx after return from regcmp:
(dbx) print regexp regexp = 0x80f7fe8 "^Ta4" (dbx) examine 0x80f7fe8/6X 0x080f7fe8: 0x00346114 0xbaddcafe 0xfeedface 0x00000aca 0x080f7ff8: 0x080fd200 0xa91f1aed
Output from mdb after crash in free:
> ::umem_status
Status: ready and active
Concurrency: 2
Logs: transaction=256k content=256k (inactive)
Message buffer:
umem allocator: redzone violation: write past end of buffer
buffer=80f7fe0 bufctl=80fd200 cache: umem_alloc_16
previous transaction on buffer 80f7fe0:
thread=1 time=T-0.000005570 slab=80f9f98 cache: umem_alloc_16
libumem.so.1'umem_cache_alloc_debug+0x14f
libumem.so.1'umem_cache_alloc+0x180
libumem.so.1'umem_alloc+0xc5
libumem.so.1'malloc+0x27
libc.so.1'regcmp+0x5c
regcmptst'main+0x3c
regcmptst'_start+0x7d
umem: heap corruption detected
stack trace:
libumem.so.1'umem_err_recoverable+0x39
libumem.so.1'umem_error+0x47f
libumem.so.1'umem_free+0xf7
libumem.so.1'process_free+0x55
libumem.so.1'free+0x17
regcmptst'main+0x66
regcmptst'_start+0x7d
> 80fd200::bufctl_audit
ADDR BUFADDR TIMESTAMP THREAD
CACHE LASTLOG CONTENTS
80fd200 80f7fe0 11e2d3ac40102f 1
80e9a10 8077000 0
libumem.so.1`umem_cache_alloc_debug+0x14f
libumem.so.1`umem_cache_alloc+0x180
libumem.so.1`umem_alloc+0xc5
libumem.so.1`malloc+0x27
libc.so.1`regcmp+0x5c
main+0x3c
_start+0x7d
> 80f7fe0/8X
0x80f7fe0: b deadbeef 346114 baddcafe
feedface aca 80fd200 a91f1aed
Files
Updated by Stefan Berglund about 13 years ago
- File regcmptst.c regcmptst.c added
I discovered a small error in the enclosed source file, the call to regcmp(3c) should end with a NULL argument. A corrected version is attached.
Updated by Albert Lee about 13 years ago
- Project changed from OpenIndiana Distribution to illumos gate
Updated by Jason King almost 13 years ago
- Category set to lib - userland libraries
I'm wondering if source:usr/src/lib/libc/port/regex/regcmp.c#L173 should merely read compile_startp = (char *)malloc(3 * arg_strlen + 1);
The big factor is that I'm unfamiliar with the multibyte character implementation --- it might be more correct to use (MB_CUR_MAX + 3) * arg_strlen + 1 as the allocation size, but it's unclear if MB_CUR_MAX is a static or dynamic value based on the current locale. Need to research that.