Out of Range Pointer offset in mb_charlen of mbyte.c in vim/vim


Reported on

Feb 6th 2023


Out of Range Pointer offset in mb_charlen of mbyte.c

# Vim Version
git log
commit 78012f55faf7444e554c0a97a589d99fa215bea9 (HEAD -> master, tag: v9.0.1275, origin/master, origin/HEAD)

 # POC
./vim -u NONE -X -Z -e -s -S poc01.dat -c ':qa!'
Segmentation Fault

gdb ./vim
(gdb) run -u NONE -X -Z -e -s -S /home1/poc01.dat
Starting program: /home1/vim/src/vim -u NONE -X -Z -e -s -S /home1/poc01.dat
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Program received signal SIGSEGV, Segmentation fault.
mb_charlen (str=str@entry=0x55554a1f61ad <error: Cannot access memory at address 0x55554a1f61ad>) at mbyte.c:4437
4437        for (count = 0; *p != NUL; count++)
Dump of assembler code for function mb_charlen:
   0x00005555558df190 <+0>: endbr64
   0x00005555558df194 <+4>: push   %r13
   0x00005555558df196 <+6>: push   %r12
   0x00005555558df198 <+8>: push   %rbp
   0x00005555558df199 <+9>: push   %rbx
   0x00005555558df19a <+10>:    sub    $0x8,%rsp
   0x00005555558df19e <+14>:    mov    0x633e43(%rip),%r12        # 0x555555f12fe8
   0x00005555558df1a5 <+21>:    mov    0x660714(%rip),%rbp        # 0x555555f3f8c0 <__afl_area_ptr>
   0x00005555558df1ac <+28>:    mov    %fs:(%r12),%eax
   0x00005555558df1b1 <+33>:    test   %rdi,%rdi
   0x00005555558df1b4 <+36>:    je     0x5555558df278 <mb_charlen+232>
   0x00005555558df1ba <+42>:    xor    $0xbcdd,%eax
   0x00005555558df1bf <+47>:    mov    %rdi,%rbx
   0x00005555558df1c2 <+50>:    xor    %ecx,%ecx
   0x00005555558df1c4 <+52>:    add    %rbp,%rax
   0x00005555558df1c7 <+55>:    movzbl (%rax),%edx
   0x00005555558df1ca <+58>:    add    $0x1,%dl
   0x00005555558df1cd <+61>:    jb     0x5555558df2b5 <mb_charlen+293>
   0x00005555558df1d3 <+67>:    add    %edx,%ecx
   0x00005555558df1d5 <+69>:    mov    %cl,(%rax)
   0x00005555558df1d7 <+71>:    movl   $0x5e6e,%fs:(%r12)
=> 0x00005555558df1e0 <+80>:    cmpb   $0x0,(%rbx)
   0x00005555558df1e3 <+83>:    je     0x5555558df2a0 <mb_charlen+272>
   0x00005555558df1e9 <+89>:    mov    $0x5e6e,%esi
   0x00005555558df1ee <+94>:    xor    %r13d,%r13d
   0x00005555558df1f1 <+97>:    nopl   0x0(%rax)
(gdb) info registers
rax            0x555555f55fd6      93825002725334
rbx            0x555520dd9b5d      93824111975261
rcx            0x2                 2
rdx            0x2                 2
rsi            0x2                 2
rdi            0x555520dd9b5d      93824111975261
rbp            0x555555f4bba0      0x555555f4bba0 <__afl_area_initial>
rsp            0x7fffffffc510      0x7fffffffc510
r8             0x7fffffffc940      140737488341312
r9             0x1                 1
r10            0x5                 5
r11            0x555555f55e9e      93825002725022
r12            0xffffffffffffffe0  -32
r13            0x555520dd9b5d      93824111975261
r14            0xffffffffffffffe0  -32
r15            0xffffffffffffffe0  -32
rip            0x5555558df1e0      0x5555558df1e0 <mb_charlen+80>
eflags         0x10202             [ IF RF ]
cs             0x33                51
ss             0x2b                43
ds             0x0                 0
es             0x0                 0
fs             0x0                 0
gs             0x0                 0
k0             0xcff80000          3489136640
k1             0x1                 1
k2             0x11100001          286261249
(gdb) list
4432        int     count;
4434        if (p == NULL)
4435        return 0;
4437        for (count = 0; *p != NUL; count++)
4438        p += (*mb_ptr2len)(p);
4440        return count;
4441    }
[Current thread is 1 (Thread 0x7ffff7b9d880 (LWP 3830611))]
(gdb) print p
$1 = (char_u *) 0x555520dd9b5d <error: Cannot access memory at address 0x555520dd9b5d>
(gdb) print count
$2 = 0
(gdb) bt
#0  mb_charlen (
    str=str@entry=0x555520dd9b5d <error: Cannot access memory at address 0x555520dd9b5d>)
    at mbyte.c:4437
#1  0x0000555555b49135 in fuzzy_match (
    str=str@entry=0x555520dd9b5d <error: Cannot access memory at address 0x555520dd9b5d>, 
    pat_arg=pat_arg@entry=0x555556161b93 "ss ", matchseq=matchseq@entry=0, 
    outScore=outScore@entry=0x7fffffffc6f0, matches=matches@entry=0x7fffffffc940, 
    maxMatches=maxMatches@entry=256) at search.c:4522
#2  0x0000555555a3b79c in vgr_match_buflines (flags=<optimized out>, 
    duplicate_name=<optimized out>, tomatch=0x7fffffffc7b0, regmatch=0x7fffffffc7d8, 
    spat=<optimized out>, buf=<optimized out>, fname=<optimized out>, qfl=<optimized out>)
    at quickfix.c:6115
#3  vgr_process_files (target_dir=<synthetic pointer>, first_match_buf=<synthetic pointer>, 
    redraw_for_dummy=<synthetic pointer>, cmd_args=0x7fffffffc7b0, qi=<optimized out>, 
    wp=<optimized out>) at quickfix.c:6351
#4  ex_vimgrep (eap=<optimized out>) at quickfix.c:6478
#5  0x00005555557952a8 in do_one_cmd (cookie=<optimized out>, fgetline=<optimized out>, 
    cstack=0x7fffffffd0f0, flags=<optimized out>, cmdlinep=0x7fffffffcea0) at ex_docmd.c:2580
#6  do_cmdline (cmdline=cmdline@entry=0x55555616ead0 "lv[ss [fg\233", 
    fgetline=fgetline@entry=0x555555b1bb40 <getsourceline>, cookie=cookie@entry=0x7fffffffd830, 
    flags=flags@entry=7) at ex_docmd.c:993
#7  0x0000555555b1f8e0 in do_source_ext (fname=<optimized out>, check_other=<optimized out>, 
    is_vimrc=<optimized out>, ret_sid=<optimized out>, eap=<optimized out>, 
    clearvars=<optimized out>) at scriptfile.c:1759
#8  0x0000555555b22efc in do_source (ret_sid=0x0, is_vimrc=0, check_other=0, 
    fname=0x55555615cbb3 "output/fuzzer04/crashes/id:000000,sig:11,sync:fuzzer07,src:040482")
    at scriptfile.c:1905

# Impact

This vulnerability is capable of crashing software, reading and modify memory.
We are processing your report and will contact the vim team within 24 hours. 10 months ago
We have contacted a member of the vim team and are waiting to hear back 10 months ago
10 months ago


Hi Admin, can I check if there are any updates to the current CWE discovered for Vim?

ongk0077 modified the report
9 months ago
9 months ago


Hi Sir, this is the shortened POC for your reference: https://drive.google.com/file/d/1HZOYLlrQPTdaL5TkkNNvFLigUPwjeXRq/view?usp=share_link

Issue could still be replicated as of the latest version.

ongk0077 modified the report
9 months ago
Bram Moolenaar validated this vulnerability 7 months ago

Finally found time to try to reproduce this. And yes, I can reproduce. It appears it goes into an endless loop though. I'll have to do some work to make a regression test for this.

ongk0077 has been awarded the disclosure bounty
The fix bounty is now up for grabs
The researcher's credibility has increased: +7
Bram Moolenaar marked this as fixed in 9.0.1499 with commit caf642 7 months ago
Bram Moolenaar has been awarded the fix bounty
This vulnerability has been assigned a CVE
Bram Moolenaar published this vulnerability 7 months ago
to join this conversation