Segmentation fault caused by strb w1, [x22,x23] when x23 reaches a certain value

Encountered an interesting segmentation fault on strb w1, [x22,x23] instruction in ARMv8 Assembly code when x23 reaches a certain value (which is 635), when I’m not using bl write function.

However, if I use bl instruction to call write function, the segmentation fault does not occur; but the program finishes with “… exited with code 02” in gdb or echo $? is 2.

machine: Linux alarm 3.10.65-4-pine64-longsleep #16 SMP PREEMPT Sun Apr 3 10:56:40 CEST 2016 aarch64 GNU/Linux

gdb -v GNU gdb (GDB) 7.11.1

gcc version 6.1.1 20160707 (GCC)

What is causing this behavior?

  5 .bss
  6         n_array:        .byte 0
  7 .data
  8         fmt:    .asciz  "t%d"
  9         c_array:.ascii  "73167176531330624919225119674426574742355349194934"
 10                 .ascii  "96983520312774506326239578318016984801869478851843"
 11                 .ascii  "85861560789112949495459501737958331952853208805511"
 12                 .ascii  "12540698747158523863050715693290963295227443043557"
 13                 .ascii  "66896648950445244523161731856403098711121722383113"
 14                 .ascii  "62229893423380308135336276614282806444486645238749"
 15                 .ascii  "30358907296290491560440772390713810515859307960866"
 16                 .ascii  "70172427121883998797908792274921901699720888093776"
 17                 .ascii  "65727333001053367881220235421809751254540594752243"
 18                 .ascii  "52584907711670556013604839586446706324415722155397"
 19                 .ascii  "53697817977846174064955149290862569321978468622482"
 20                 .ascii  "83972241375657056057490261407972968652414535100474"
 21                 .ascii  "82166370484403199890008895243450658541227588666881"
 22                 .ascii  "16427171479924442928230863465674813919123162824586"
 23                 .ascii  "17866458359124566529476545682848912883142607690042"
 24                 .ascii  "24219022671055626321111109370544217506941658960408"
 25                 .ascii  "07198403850962455444362981230987879927244284909188"
 26                 .ascii  "84580156166097919133875499200524063689912560717606"
 27                 .ascii  "05886116467109405077541002256983155200055935729725"
 28                 .ascii  "71636269561882670428252483600823257530420752963450"
 29         .equ    len_c_array,.-c_array
 30 .text
 31         .global main
 32         .include "mymac_armv8.s"
 33 main:
 34         nop
 35         mov w19, 0x30
 36         ldr x20,=c_array
 37         mov x21, #len_c_array
 38         sub x21, x21, 1
 39         ldr x22,=n_array
 40         mov x23, xzr
 41         1:
 42                 ldrb w1, [x20,x23]      // get ascii char
 43                 sub w1, w1, w19         // ascii value - 0x30; assumes ascii number chars only
 44                 strb w1, [x22,x23]      // store byte into n_array element
 45                 bl write
 46         add x23, x23, 1
 47         cmp x23, x21
 48         b.le 1b
 49 _exit
 50 write:
 51         push2 x29,x30
 52         ldr x0,=fmt
 53         bl printf
 54         pop2 x29, x30
 55         ret


dmesg
[23493.499193] CPU: 0 PID: 18212 Comm: ascii_array_con Tainted: G           O 3.10.65-4-pine64-longsleep #16
[23493.515436] task: ffffffc0764b4ec0 ti: ffffffc073804000 task.ti: ffffffc073804000
[23493.529484] PC is at 0x4005d0
[23493.538487] LR is at 0x7faccae8a4
[23493.547816] pc : [<00000000004005d0>] lr : [<0000007faccae8a4>] pstate: 80000000
[23493.561648] sp : 0000007ffee581a0
[23493.570951] x29: 0000007ffee581a0 x28: 0000000000000000
[23493.582394] x27: 0000000000000000 x26: 0000000000000000
[23493.593717] x25: 0000000000000000 x24: 0000000000000000
[23493.604933] x23: 000000000000027b x22: 0000000000410d85
[23493.616092] x21: 00000000000003e8 x20: 000000000041099c
[23493.627122] x19: 0000000000000030 x18: 0000000000030a41
[23493.638002] x17: 0000000000410968 x16: 0000007faccae7c8
[23493.648801] x15: 0000000000000809 x14: 0000000000000000
[23493.659629] x13: 0000000000000000 x12: 0000007face1d000
[23493.670353] x11: 0000000004000000 x10: 0101010101010101
[23493.681037] x9 : 3fffffffffffffff x8 : ffffffffffffffff
[23493.691716] x7 : 0000000004000000 x6 : 0000000000000000
[23493.702436] x5 : 0000000000000000 x4 : 0000007ffee581f8
[23493.713174] x3 : 00000000004005b0 x2 : 0000007ffee582e8
[23493.723904] x1 : 0000000000000005 x0 : 0000000000000001

[23493.746914] systemd-coredump[18214]: Failed to get COMM, falling back to the command line: No such process
[23493.762810] systemd-coredump[18214]: Failed to get EXE, ignoring: No such process

Answer

The size of the bss is just not properly sized as stated in my first comment, and reinforced by NotLikeThat clue: as the size is incorrect, you hit a MMU boundary after a while => SEGV.

Use that (as stated in http://web.mit.edu/gnu/doc/html/as_7.html):

n_array:
    .fill 1000 , 1 , 0

Just tried and worked (well, for x86 but should work for arm too):

>objdump -d ascii_array

ascii_array_conv.o:     file format pe-x86-64


Disassembly of section .text:

0000000000000000 <data1>:
        ...
 3e8:   90                      nop
 3e9:   90                      nop
 3ea:   90                      nop
 3eb:   90                      nop
 3ec:   90                      nop
 3ed:   90                      nop
 3ee:   90                      nop
 3ef:   90                      nop

Advertisement

Answer