Community
cancel
Showing results for 
Search instead for 
Did you mean: 
YongWu
Novice
300 Views

[Crash] Buffer read overflow with istrconv:__IML_string_to_int

Dear Intel,

We found a crash issue with ICC/istrconv. Function call to __IMLstring_to_int() will load 16bytes into xmm even near a page boundary and causes overflow read.  Please check the test case below.

// test case to repro the overflow read near page boundary 
// icc -std=c++11 -o str2int str2int.cpp -listrconv

#include <stdlib.h>
#include <stdio.h>
#include <sys/mman.h>
#include "istrconv.h"

int main() {

  // allocate 2 pages
  char *buf = (char *)mmap(NULL, 8192, PROT_READ | PROT_WRITE,
                           MAP_PRIVATE | MAP_ANONYMOUS, 0, 0);
  printf("buf=%p\n", buf);

  // fill '7654321' to end of the 1st page
  buf[4096-1] = '\0';
  buf[4096-2] = '1';
  buf[4096-3] = '2';
  buf[4096-4] = '3';
  buf[4096-5] = '4';
  buf[4096-6] = '5';
  buf[4096-7] = '6';
  buf[4096-8] = '7';

  // unmap 2nd page to trigger any possible read overflow
  munmap(&buf[4096], 4096);

  // libc: atoi, works okay
  int n1 = atoi(&buf[4096-8]);
  printf("atoi=%d\n", n1);
  fflush(NULL);

  // Intel istrconv, will crash
  int n2 = __IML_string_to_int(&buf[4096-8], nullptr);
  printf("IML=%d\n", n2);

  return 0;
}

 

Platform:

Architecture:          x86_64
CPU op-mode(s):        32-bit, 64-bit
Byte Order:            Little Endian
CPU(s):                64
On-line CPU(s) list:   0-63
Thread(s) per core:    2
Core(s) per socket:    16
Socket(s):             2
NUMA node(s):          2
Vendor ID:             GenuineIntel
CPU family:            6
Model:                 79
Model name:            Intel(R) Xeon(R) CPU E5-2682 v4 @ 2.50GHz
Stepping:              1
CPU MHz:               2500.000
CPU max MHz:           2500.0000
CPU min MHz:           1200.0000
BogoMIPS:              4988.67
Virtualization:        VT-x
L1d cache:             32K
L1i cache:             32K
L2 cache:              256K
L3 cache:              40960K
NUMA node0 CPU(s):     0-15,32-47
NUMA node1 CPU(s):     16-31,48-63
Flags:                 fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf pni pclmulqdq dtes64 ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch epb invpcid_single cdp_l3 tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm cqm rdt_a rdseed adx smap intel_pt xsaveopt cqm_llc cqm_occup_llc cqm_mbm_total cqm_mbm_local dtherm arat pln pts

ICC version
$ icc --version
icc (ICC) 2021.1 Beta 20200827

OS:
Enterprise Linux Server release 7.

Labels (1)
Tags (3)
0 Kudos
10 Replies
YongWu
Novice
291 Views

Please find the gdb debugging info below: loading of 8 bytes with movdqu causes the overflow read.

(gdb) disassemble
Dump of assembler code for function __IML_string_to_int_sse4:
   0x00007ffff7b9ec70 <+0>:     repz nop %edx
   0x00007ffff7b9ec74 <+4>:     push   %r12
   0x00007ffff7b9ec76 <+6>:     push   %r13
   0x00007ffff7b9ec78 <+8>:     push   %r14
   0x00007ffff7b9ec7a <+10>:    push   %rbx
   0x00007ffff7b9ec7b <+11>:    push   %rbp
   0x00007ffff7b9ec7c <+12>:    mov    %rdi,%rbp
   0x00007ffff7b9ec7f <+15>:    mov    %rsi,%r14
   0x00007ffff7b9ec82 <+18>:    xor    %r13d,%r13d
   0x00007ffff7b9ec85 <+21>:    mov    %rbp,%r12
   0x00007ffff7b9ec88 <+24>:    movsbl 0x0(%rbp),%ebx
   0x00007ffff7b9ec8c <+28>:    callq  0x7ffff7b90180 <__ctype_b_loc@plt>
   0x00007ffff7b9ec91 <+33>:    movsbq %bl,%rdx
   0x00007ffff7b9ec95 <+37>:    mov    (%rax),%rax
   0x00007ffff7b9ec98 <+40>:    movzwl (%rax,%rdx,2),%ecx
   0x00007ffff7b9ec9c <+44>:    test   $0x2000,%ecx
   0x00007ffff7b9eca2 <+50>:    je     0x7ffff7b9ecbc <__IML_string_to_int_sse4+76>
   0x00007ffff7b9eca4 <+52>:    inc    %r12
   0x00007ffff7b9eca7 <+55>:    movsbl (%r12),%ebx
   0x00007ffff7b9ecac <+60>:    movsbq %bl,%rdx
   0x00007ffff7b9ecb0 <+64>:    movzwl (%rax,%rdx,2),%ecx
   0x00007ffff7b9ecb4 <+68>:    test   $0x2000,%ecx
   0x00007ffff7b9ecba <+74>:    jne    0x7ffff7b9eca4 <__IML_string_to_int_sse4+52>
   0x00007ffff7b9ecbc <+76>:    lea    -0x2b(%rbx),%eax
   0x00007ffff7b9ecbf <+79>:    test   $0xfffffffd,%eax
   0x00007ffff7b9ecc4 <+84>:    jne    0x7ffff7b9ecd3 <__IML_string_to_int_sse4+99>
   0x00007ffff7b9ecc6 <+86>:    xor    %r13d,%r13d
   0x00007ffff7b9ecc9 <+89>:    cmp    $0x2d,%ebx
   0x00007ffff7b9eccc <+92>:    sete   %r13b
   0x00007ffff7b9ecd0 <+96>:    inc    %r12
=> 0x00007ffff7b9ecd3 <+99>:    movdqu (%r12),%xmm2
   0x00007ffff7b9ecd9 <+105>:   movdqu 0x3235f(%rip),%xmm1        # 0x7ffff7bd1040 <__libirc_dig_range_vec>
   0x00007ffff7b9ece1 <+113>:   pcmpistrm $0x46,%xmm2,%xmm1
   0x00007ffff7b9ece7 <+119>:   pmovmskb %xmm0,%edx
   0x00007ffff7b9eceb <+123>:   mov    %edx,%eax
   0x00007ffff7b9eced <+125>:   not    %eax
   0x00007ffff7b9ecef <+127>:   dec    %eax
   0x00007ffff7b9ecf1 <+129>:   and    %eax,%edx
   0x00007ffff7b9ecf3 <+131>:   je     0x7ffff7b9ee2e <__IML_string_to_int_sse4+446>
   0x00007ffff7b9ecf9 <+137>:   bsr    %edx,%edx
   0x00007ffff7b9ecfc <+140>:   lea    0x1(%rdx),%eax
   0x00007ffff7b9ecff <+143>:   test   %r14,%r14
   0x00007ffff7b9ed02 <+146>:   je     0x7ffff7b9ed0a <__IML_string_to_int_sse4+154>
   0x00007ffff7b9ed04 <+148>:   add    %rax,%r12
   0x00007ffff7b9ed07 <+151>:   mov    %r12,(%r14)
   0x00007ffff7b9ed0a <+154>:   psubb  0x3233e(%rip),%xmm2        # 0x7ffff7bd1050 <__libirc_zero_vec>
   0x00007ffff7b9ed12 <+162>:   pand   %xmm0,%xmm2
   0x00007ffff7b9ed16 <+166>:   cmp    $0x8,%eax
   0x00007ffff7b9ed19 <+169>:   ja     0x7ffff7b9ed30 <__IML_string_to_int_sse4+192>
   0x00007ffff7b9ed1b <+171>:   mov    %eax,%edx
   0x00007ffff7b9ed1d <+173>:   neg    %edx
   0x00007ffff7b9ed1f <+175>:   lea    0x40(,%rdx,8),%ecx
   0x00007ffff7b9ed26 <+182>:   movd   %ecx,%xmm0
   0x00007ffff7b9ed2a <+186>:   psllq  %xmm0,%xmm2
   0x00007ffff7b9ed2e <+190>:   jmp    0x7ffff7b9ed69 <__IML_string_to_int_sse4+249>
   0x00007ffff7b9ed30 <+192>:   movq   %xmm2,%rbx
---Type <return> to continue, or q <return> to quit---
(gdb) x/4x $r12
0x7ffff7e80ff8: 0x34353637      0x00313233     Cannot access memory at 
(gdb) x/8c $r12
0x7ffff7e80ff8: 55 '7'  54 '6'  53 '5'  52 '4' 51 '3'   50 '2'  49 '1' 0 '\000'
(gdb)

 

YongWu
Novice
274 Views

correction: "loading of 8 bytes with movdqu causes the overflow read" should be "loading 16 bytes with movdqu causes the overflow read", on the page boundary. 

Gopika_Intel
Moderator
227 Views

Hi

 

Thank you for posting in Intel C++ Compiler forum and providing all the information. We ran the reproducer code and it did not crash. We are using the latest version of intel C++ compiler.

 

# icc --version

icc (ICC) 2021.1 Beta 20201112

Copyright (C) 1985-2020 Intel Corporation. All rights reserved.

 

We suggest you to try upgrading to the latest version and try executing the code. See if you still face any issues. To get the latest version of Intel C++ Compiler install the combination of Intel Base toolkit and Intel HPC toolkit. Links are given below.

 

Intel Base toolkit : https://software.intel.com/content/www/us/en/develop/tools/oneapi/base-toolkit/download.html  

Intel HPC toolkit : https://software.intel.com/content/www/us/en/develop/tools/oneapi/hpc-toolkit.html


Regards

Gopika


Gopika_Intel
Moderator
200 Views

Hi,

We haven’t heard from you in awhile. Is your issue resolved. Let us know your updates.

Regards

Gopika


pinzhenx
Beginner
184 Views

Still crashed on my machine with your version. Am I missing something?

 

$ lscpu
Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Byte Order: Little Endian
CPU(s): 64
On-line CPU(s) list: 0-63
Thread(s) per core: 2
Core(s) per socket: 16
Socket(s): 2
NUMA node(s): 1
Vendor ID: GenuineIntel
CPU family: 6
Model: 79
Model name: Intel(R) Xeon(R) CPU E5-2682 v4 @ 2.50GHz
Stepping: 1
CPU MHz: 2499.847
CPU max MHz: 2500.0000
CPU min MHz: 1200.0000
BogoMIPS: 4988.82
Virtualization: VT-x
L1d cache: 32K
L1i cache: 32K
L2 cache: 256K
L3 cache: 40960K
NUMA node0 CPU(s): 0-63
Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf pni pclmulqdq dtes64 ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch epb invpcid_single cdp_l3 tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm cqm rdt_a rdseed adx smap intel_pt xsaveopt cqm_llc cqm_occup_llc cqm_mbm_total cqm_mbm_local dtherm arat pln pts

$ icc --version
icc (ICC) 2021.1 Beta 20201112
Copyright (C) 1985-2020 Intel Corporation. All rights reserved.

$ icc crash.cpp -I/path/to/intel/oneapi/compiler/latest/linux/compiler/include/ -listrconv -o crash

$ ./crash
buf=0x7f09233e9000
atoi=7654321
Segmentation fault

Gopika_Intel
Moderator
150 Views

Hi,


We're forwarding this case to the internal team who can help you out.


Regards

Gopika


YongWu
Novice
76 Views

Any update @Gopika_Intel ? We are waiting for a fix from Intel.

Viet_H_Intel
Moderator
51 Views

It is a bug in our library and will be fixed in the next release.

Thanks,


YongWu
Novice
48 Views

Thanks for the reply @Viet_H_Intel. May I know when will be the next release?

Viet_H_Intel
Moderator
45 Views

Unfortunately, I don't have that info to share with you.