This is the mail archive of the glibc-bugs@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug locale/22390] New: Rare memory corruption in localedef related to malloc


https://sourceware.org/bugzilla/show_bug.cgi?id=22390

            Bug ID: 22390
           Summary: Rare memory corruption in localedef related to malloc
           Product: glibc
           Version: 2.26
            Status: NEW
          Severity: normal
          Priority: P2
         Component: locale
          Assignee: unassigned at sourceware dot org
          Reporter: fweimer at redhat dot com
  Target Milestone: ---

We occasionally see a crash in localedef during “make install”.  I was able to
capture a backtrace from a core file:

#0  sysmalloc (nb=nb@entry=1361968, av=av@entry=0x7fffbe400ed8 <main_arena>)
    at malloc.c:2768
#1  0x00007fffbe2b0f64 in _int_malloc (av=0x7fffbe400ed8 <main_arena>, 
    bytes=1361953) at malloc.c:4134
#2  0x00007fffbe2b6c4c in _int_realloc (nb=1361968, oldsize=680992, 
    oldp=0x7fffffb52690, av=0x7fffbe400ed8 <main_arena>) at malloc.c:4626
#3  __GI___libc_realloc (oldmem=0x7fffffb526a0, bytes=1361952) at malloc.c:3245
#4  0x0000000010049684 in xrealloc (p=<optimized out>, n=<optimized out>)
    at programs/xmalloc.c:102
#5  0x0000000010006938 in idx_table_add (value=105661, wc=<optimized out>, 
    t=0x7fffffb36438) at programs/3level.h:127
#6  find_idx (ctype=ctype@entry=0x7fffffb36420, table=0x7fffffb369a8, 
    table@entry=0xfbf, max=max@entry=0x7fffffb369b0, 
    act=act@entry=0x7fffffb369b8, idx=idx@entry=170244)
    at programs/ld-ctype.c:1234
#7  0x000000001000fe78 in find_idx (idx=170244, act=<optimized out>, 
    max=<optimized out>, table=<optimized out>, ctype=<optimized out>)
    at programs/ld-ctype.c:1526
#8  charclass_ucs4_ellipsis (ldfile=<optimized out>, ldfile=<optimized out>, 
    now=0x7fffffb362a0, step=1, handle_digits=<optimized out>, 
    ignore_content=<optimized out>, class_bit=<optimized out>, 
    class256_bit=<optimized out>, last_wch=170244, repertoire=<optimized out>, 
    charmap=<optimized out>, ctype=<optimized out>) at programs/ld-ctype.c:1542
#9  ctype_read (ldfile=<optimized out>, result=<optimized out>, 
    charmap=0x7ffffe0d0640, repertoire_name=<optimized out>, 
    ignore_content=<optimized out>) at programs/ld-ctype.c:2401
#10 0x000000001003c3ec in locfile_read (result=0x7fffffb35ed0, 
    charmap=0x7ffffe0d0640) at programs/locfile.c:173
#11 0x000000001000490c in load_locale (category=<optimized out>, 
    name=0x7fffffb35e90 "i18n", repertoire_name=0x0, charmap=0x7ffffe0d0640, 
    copy_locale=0x0) at programs/localedef.c:621
#12 0x0000000010010c9c in ctype_read (ldfile=0x7fffffb35d10, 
    result=0x7fffffb35980, charmap=0x7ffffe0d0640, repertoire_name=0x0, 
    ignore_content=<optimized out>) at programs/ld-ctype.c:2141
#13 0x000000001003c3ec in locfile_read (result=0x7fffffb35980, 
    charmap=0x7ffffe0d0640) at programs/locfile.c:173
#14 0x000000001000490c in load_locale (category=<optimized out>, 
    name=0x7fffffb35940 "nl_NL", repertoire_name=0x0, charmap=0x7ffffe0d0640, 
    copy_locale=0x0) at programs/localedef.c:621
#15 0x0000000010010c9c in ctype_read (ldfile=0x7ffffe0d0520, 
    result=0x7ffff5cbfef0, charmap=0x7ffffe0d0640, repertoire_name=0x0, 
    ignore_content=<optimized out>) at programs/ld-ctype.c:2141
#16 0x000000001003c3ec in locfile_read (result=0x7ffff5cbfef0, 
    charmap=0x7ffffe0d0640) at programs/locfile.c:173
#17 0x0000000010003720 in main (argc=<optimized out>, argv=0x7ffff5cc0520)
    at programs/localedef.c:252

2763        {
2764          remainder_size = size - nb;
2765          remainder = chunk_at_offset (p, nb);
2766          av->top = remainder;
2767          set_head (p, nb | PREV_INUSE | (av != &main_arena ?
NON_MAIN_ARENA : 0));
2768          set_head (remainder, remainder_size | PREV_INUSE);
2769          check_malloced_chunk (av, p, nb);
2770          return chunk2mem (p);
2771        }

The fault happens here:

   0x00007fffbe2af090 <+384>:   xor     r8,r30,r26
   0x00007fffbe2af094 <+388>:   subf    r9,r31,r9
   0x00007fffbe2af098 <+392>:   addic   r26,r8,-1
   0x00007fffbe2af09c <+396>:   ori     r10,r31,1
   0x00007fffbe2af0a0 <+400>:   subfe   r26,r26,r8
   0x00007fffbe2af0a4 <+404>:   add     r31,r22,r31
   0x00007fffbe2af0a8 <+408>:   rldicr  r26,r26,2,61
   0x00007fffbe2af0ac <+412>:   ori     r9,r9,1
   0x00007fffbe2af0b0 <+416>:   or      r26,r10,r26
   0x00007fffbe2af0b4 <+420>:   std     r31,88(r30)
   0x00007fffbe2af0b8 <+424>:   addi    r3,r22,16
   0x00007fffbe2af0bc <+428>:   std     r26,8(r22)
=> 0x00007fffbe2af0c0 <+432>:   std     r9,8(r31)

Most variables have been optimized out, but:

remainder = 0x800000004800
r9 = 0x2b801
r31 = 0x800000004800

“info file” says this:

        0x0000000010000000 - 0x0000000010010000 is load1a
        0x0000000010010000 - 0x0000000010010000 is load1b
        0x0000000010060000 - 0x0000000010070000 is load2
        0x0000000010070000 - 0x0000000010080000 is load3
        0x00007fffba840000 - 0x00007fffbbce0000 is load4
        0x00007fffbcaf0000 - 0x00007fffbdf90000 is load5
        0x00007fffbe1a0000 - 0x00007fffbe1a0000 is load6
        0x00007fffbe1d0000 - 0x00007fffbe1d0000 is load7
        0x00007fffbe1e0000 - 0x00007fffbe1e0000 is load8
        0x00007fffbe1f0000 - 0x00007fffbe200000 is load9a
        0x00007fffbe200000 - 0x00007fffbe200000 is load9b
        0x00007fffbe3e0000 - 0x00007fffbe3e0000 is load10
        0x00007fffbe3f0000 - 0x00007fffbe400000 is load11
        0x00007fffbe400000 - 0x00007fffbe410000 is load12
        0x00007fffbe410000 - 0x00007fffbe430000 is load13
        0x00007fffbe430000 - 0x00007fffbe440000 is load14a
        0x00007fffbe440000 - 0x00007fffbe440000 is load14b
        0x00007fffbe470000 - 0x00007fffbe480000 is load15
        0x00007fffbe480000 - 0x00007fffbe490000 is load16
        0x00007ffff5ca0000 - 0x00007ffff5cd0000 is load17
        0x00007ffffe0d0000 - 0x0000800000030000 is load18

So address appears to be above the top of the heap.

This glibc is based on 2.26.  We've only seen this on ppc64 so far (not s390x).

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]