ARM e7f000f0 udf instruction exception

Recently I encountered a program crash with an unusual SIGILL. I debugged it.

Core was generated by `/usr/bin/xxxxx'.

Program terminated with signal SIGILL, Illegal instruction

GDB checked and crashed in the free function

(gdb) disassemble 

Dump of assembler code for function free:

   0xb6f408f0 <+0>: cmp r0, #0

   0xb6f408f4 <+4>: bxeq lr

   0xb6f408f8 <+8>: ldr r3, [r0, #-4]

   0xb6f408fc <+12>: push {r4, r5, r6, r7, r8, r9, r10, r11, lr}

   0xb6f40900 <+16>: tst r3, #1

   0xb6f40904 <+20>: bic r8, r3, #1

   0xb6f40908 <+24>: sub sp, sp, #20

   0xb6f4090c <+28>: sub r4, r0, #8

   0xb6f40910 <+32>: bne 0xb6f40938

   0xb6f40914 <+36>: ldr r3, [r0, #-8]

   0xb6f40918 <+40>: sub r0, r4, r3

   0xb6f4091c <+44>: tst r3, #1

   0xb6f40920 <+48>: add r1, r8, r3

   0xb6f40924 <+52>: beq 0xb6f4092c

=> 0xb6f40928 <+56>: udf #0

   0xb6f4092c <+60>: add sp, sp, #20

   0xb6f40930 <+64>: pop {r4, r5, r6, r7, r8, r9, r10, r11, lr}

   0xb6f40934 <+68>: b 0xb6f5c620 <__munmap>

There is indeed a udf instruction in the free function

View musk's free function implementation

void free(void *p)

{

struct chunk *self = MEM_TO_CHUNK(p);

struct chunk *next;

size_t final_size, new_size, size;

int reclaim=0;

int i;

if (!p) return;

if (IS_MMAPPED(self)) {

size_t extra = self->psize;

char *base = (char *)self - extra;

size_t len = CHUNK_SIZE(self) + extra;

/* Crash on double free */

if (extra & 1) a_crash();

__munmap(base, len);

return;

}

static inline void a_crash()

{

__asm__ __volatile__(

#ifndef __thumb__

".word 0xe7f000f0"

#else

".short 0xdeff"

#endif

: : : "memory");

}

When musl finds that the memory may be double freed, it will actively call a_crash(), that is, insert an arm udf instruction to actively trap the program crash.

In fact, if you think about it, this is more scientific, and it can avoid the problem of memory list trashing caused by double free in some allocator implementations. Usually, the double free is fine. The program will crash in a place far away. It is very painful to debug.

While Googling this question, I found another interesting problem: the gcc compiler will also actively insert UDF instructions

This is a problem encountered by others on the forum

question

       The function written in C language to determine whether to start from nor or nand was not fully compiled during compilation and linking. The disassembly result is as follows (the part in red font). Please help me find out the reason. Thank you!

The c function is as follows:

int isBootFromNorFlash(void)

{

        volatile int *p = (volatile int *)0;

        int val;

        val = *p;

        *p = 0x12345678;

        if (*p == 0x12345678)

        {

                *p = val;

                puts("boot from nor.nr");

                return 0;

        }

        else

        {

                puts("boot from nand.nr");

                return 1;

        }

}

The disassembly results are as follows. In the red font part, only the first few lines of commands are compiled, and the rest are not compiled.

33f80304 :

33f80304:        e3a03000         mov        r3, #0

33f80308: e5933000 ldr r3, [r3]

33f8030c:        e7f000f0         udf        #0

In fact, this is a feature of arm gcc. When undefined behavior is detected, it will actively insert udf instructions to trap the exception.

GCC6 and later can detect this error during compilation via -Wnull-dereference.

ktkachov 2017-07-27 09:28:26 UTC

That inst is the trap instruction that is inserted by the isolate-paths pass because it detects undefined behaviour.

While the result of calling data() is unspecified, this is not what the testcase is doing. It's using operator[] which performs an access to the underlying storage directly and is thus out of bounds and undefined