bugGNU patch - Bugs: bug #62092, AddressSanitizer:...

 
 

bug #62092: AddressSanitizer: heap-use-after-free at src/pch.c:2290

Submitter:  DandanXu <dandanxu>
Submitted:  Mon 21 Feb 2022 01:54:36 PM UTC
 
Category:  Parser / Internal Representation Severity:  3 - Normal
Item Group:  None Status:  None
Privacy:  Public Assigned to:  None
Open/Closed:  Open
* Mandatory Fields

Add a New Comment (Rich Markup)
   

Comment Type & Canned Response:
       No canned response available

 

Mon 21 Feb 2022 01:54:36 PM UTC, original submission:  

version: master (commit 24f81be)
poc: https://github.com/dandanxu96/PoC/raw/main/patch/patch-heap-use-after-free-poc
command: patch -Rf < $poc$

Here is the trace reported by ASAN:
==2677==ERROR: AddressSanitizer: heap-use-after-free on address 0x6020000005f0 at pc 0x555555586e60 bp 0x7fffffffdd10 sp 0x7fffffffdd00
READ of size 1 at 0x6020000005f0 thread T0
    #0 0x555555586e5f in pch_write_line /home/user/test-data/patch/patch_lastest/patch/src/pch.c:2290
    #1 0x555555575b7b in abort_hunk_context /home/user/test-data/patch/patch_lastest/patch/src/patch.c:1397
    #2 0x555555575d06 in abort_hunk /home/user/test-data/patch/patch_lastest/patch/src/patch.c:1418
    #3 0x555555571ef0 in main /home/user/test-data/patch/patch_lastest/patch/src/patch.c:489
    #4 0x7ffff73c50b2 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x270b2)
    #5 0x55555556e3fd in _start (/home/user/test-data/patch/patch_lastest/patch/build/bin/patch+0x1a3fd)

0x6020000005f0 is located 0 bytes inside of 1-byte region [0x6020000005f0,0x6020000005f1)
freed by thread T0 here:
    #0 0x7ffff769d7cf in __interceptor_free (/lib/x86_64-linux-gnu/libasan.so.5+0x10d7cf)
    #1 0x555555580bc6 in another_hunk /home/user/test-data/patch/patch_lastest/patch/src/pch.c:1187
    #2 0x5555555720d9 in main /home/user/test-data/patch/patch_lastest/patch/src/patch.c:408
    #3 0x7ffff73c50b2 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x270b2)

previously allocated by thread T0 here:
    #0 0x7ffff769dbc8 in malloc (/lib/x86_64-linux-gnu/libasan.so.5+0x10dbc8)
    #1 0x55555558ffea in savebuf /home/user/test-data/patch/patch_lastest/patch/src/util.c:869
    #2 0x5555555825fa in another_hunk /home/user/test-data/patch/patch_lastest/patch/src/pch.c:1507
    #3 0x5555555720d9 in main /home/user/test-data/patch/patch_lastest/patch/src/patch.c:408
    #4 0x7ffff73c50b2 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x270b2)

A heap use-after-free vulnerability is reported at src/pch.c:2290. After some analysis, I noticed that this vulnerability might share the same root cause as CVE-2019-20633 (still not fixed); thus, I attach my analysis for it. Hopefully, it will be of help.

At the beginning of `another_hunk` function, the pointer in `p_line` is not set to NULL after it's freed.

1183    while (p_end >= 0) {
1184 if (p_end == p_efake)
1185     p_end = p_bfake; /* don't free twice */
1186 else
1187     free(p_line[p_end]);
1188 p_end--;
1189    }

In subsequent code, when `p_end=1`, we have `p_end = p_ptrn_lines + 1` (which is 5 in the poc) at line 1340. As a result, pointers with index=5 in p_line will be updated in line 1369, while p_line[1]~p_line[4] still keeps the danling pointers.

1335     if (p_end == 1)
1336       {
1337 /* 'Old' lines were omitted.  Set up to fill
1338    them in from 'new' context lines.  */
1339 ptrn_missing = true;
1340 p_end = p_ptrn_lines + 1;
1341 ptrn_prefix_context = ptrn_suffix_context = -1;
1342 fillsrc = p_end + 1;
1343 filldst = 1;
1344 fillcnt = p_ptrn_lines;
1345       }
...
1369 if (! (p_line[p_end] = savestr (buf)))

When `abort_hunk_context` is executed, it tries to access `p_line[0]`~`p_line[5]`, causing the UAF when dereferencing `p_line[1]` at pch.c:2290.

1340 static void
1341 abort_hunk_context (bool header, bool reverse)
1342 {
1343    lin i;
1344    lin pat_end = pch_end ();
...

1367     for (i=0; i<=pat_end; i++) {
...
1397     pch_write_line (i, rejfp);
...
1404     }

2286 bool
2287 pch_write_line (lin line, FILE *file)
2288 {
2289  bool after_newline =
2290    (p_len[line] > 0) && (p_line[line][p_len[line] - 1] == '\n');

DandanXu <dandanxu>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by dandanxu (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

     

     

     

    No changes have been made to this item

    Back to the top


    Powered by Savane 3.9