"Segmentation fault (core dumped)" when trying to create new context

[emanruse]

STR:

1. Follow the build instructions from the README to build on a Linux system:

autoreconf -i
./configure
make
sudo cp ./seinfo ./sesearch ./sepolicy-inject /usr/local/bin  # optional

The result is successful.
Then, using a sepolicy file from unpacked Android boot.img:

2. Test to inject a policy as described in the README:

$ sepolicy-inject -s vdc -t devpts -c chr_file -p read,write -P sepolicy -o sepolicy2
(Android M policy compatibility mode)
libsepol.policydb_index_others: security:  1 users, 2 roles, 577 types, 0 bools
libsepol.policydb_index_others: security: 1 sens, 1024 cats
libsepol.policydb_index_others: security:  87 classes, 5374 rules, 0 cond rules
Success

So, this works.

Now, I want to create a new context. For the sake of testing I name it tezzzt:

3. Run this command

$ sepolicy-inject -s tezzzt -t devpts -c chr_file -p read,write -P sepolicy -o sepolicy2
(Android M policy compatibility mode)
libsepol.policydb_index_others: security:  1 users, 2 roles, 577 types, 0 bools
libsepol.policydb_index_others: security: 1 sens, 1024 cats
libsepol.policydb_index_others: security:  87 classes, 5374 rules, 0 cond rules
type tezzzt does not exist, creating
Segmentation fault (core dumped)

The problem:

seplicy-inject says it is creating the non-existing source context but for some reason this ends up with a segmentation fault. I have no clue how to fix this and how to create a new context in the sepolicy.

Please advise.

[emanruse]

Based on a SO answer, I tried to debug this myself. I added the -fsanitize=address option to each of the following lines in Makefile.am:

grep fsanitize ./Makefile.am
libapol_a_CFLAGS = -fsanitize=address -std=gnu99 $(libapol_includes)
libqpol_a_CFLAGS = -fsanitize=address -std=gnu99 $(libqpol_includes)
libsepol_a_CFLAGS = -fsanitize=address $(libsepol_includes)
seinfo_CFLAGS = -fsanitize=address $(secmds_includes)
sesearch_CFLAGS = -fsanitize=address $(secmds_includes) -std=c99
sepolicy_inject_CFLAGS = -fsanitize=address -Ijni/libsepol/include

Then, I repeated the build procedure for Linux and ran the problematic command again. The result is:

$ ./sepolicy-inject -s tezzzt -t devpts -c chr_file -p read,write -P sepolicy -o sepolicy
(Android M policy compatibility mode)
libsepol.policydb_index_others: security:  1 users, 2 roles, 577 types, 0 bools
libsepol.policydb_index_others: security: 1 sens, 1024 cats
libsepol.policydb_index_others: security:  87 classes, 5374 rules, 0 cond rules
type tezzzt does not exist, creating
=================================================================
==25812==ERROR: AddressSanitizer: heap-buffer-overflow on address 0xb4502784 at pc 0x08065668 bp 0xbff78a48 sp 0xbff78a3c
READ of size 4 at 0xb4502784 thread T0
    #0 0x8065667 in type_set_expand jni/libsepol/src/expand.c:2557
    #1 0x804bdf1 in create_domain jni/sepolicy-inject/sepolicy-inject.c:99
    #2 0x804aee1 in main jni/sepolicy-inject/sepolicy-inject.c:369
    #3 0xb7423294 in __libc_start_call_main (/lib/libc.so.6+0x23294) (BuildId: 87c7a50c8792985dd164f5af2d45b8e91d9f4391)
    #4 0xb7423357 in __libc_start_main@@GLIBC_2.34 (/lib/libc.so.6+0x23357) (BuildId: 87c7a50c8792985dd164f5af2d45b8e91d9f4391)
    #5 0x804b447 in _start ../sysdeps/i386/start.S:111

0xb4502784 is located 0 bytes after 2308-byte region [0xb4501e80,0xb4502784)
allocated by thread T0 here:
    #0 0xb78e1e0b in __interceptor_calloc (/lib/libasan.so.8+0xe1e0b) (BuildId: 8add7fe4138bc2257822755f90f63fc124e487b0)
    #1 0x808618c in policydb_index_others jni/libsepol/src/policydb.c:1225

SUMMARY: AddressSanitizer: heap-buffer-overflow jni/libsepol/src/expand.c:2557 in type_set_expand
Shadow bytes around the buggy address:
  0xb4502500: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0xb4502580: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0xb4502600: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0xb4502680: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0xb4502700: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0xb4502780:[04]fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0xb4502800: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0xb4502880: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0xb4502900: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0xb4502980: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0xb4502a00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:       fa
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
  Left alloca redzone:     ca
  Right alloca redzone:    cb
==25812==ABORTING

IIUC, the problematic line seems to be the one listed as #0, i.e:

#0 0x8065667 in type_set_expand jni/libsepol/src/expand.c:2557

Looking at that actual code, I see:

type = p->type_val_to_struct[i];

Unfortunately, I don't know how to fix it as my C knowledge is from many years ago and the code is not really readable. Perhaps the i index is the culprit and needs stricter check.

I hope this repo is not abandoned, so someone can look into it.