[BUG] BRL-CAD dxf-g heap buffer overflow via unchecked POLYLINE face indices in DXF import

### Summary A crafted DXF file can trigger a heap-buffer-overflow in the latest BRL-CAD/brlcad dxf-g importer. The bug is reachable through the normal command-line conversion path and is caused by attacker-controlled POLYLINE face indices being used directly to index the stored vertex table without bounds validation. This is a native C memory-corruption issue and can at least cause a reliable denial of service. ### Details The latest upstream BRL-CAD/brlcad still contains the DXF importer flaw associated with CVE-2022-0496. I rebuilt the current upstream tree from a fresh full clone and exercised the real dxf-g converter with a crafted DXF file through the normal import path. Reachable source file: - `brlcad/src/conv/dxf/dxf-g.c` Entry path: ``` while ((code=readcodes()) > -900) { process_code[curr_state->state](code); } Relevant vulnerable fragment in src/conv/dxf/dxf-g.c: case 71: case 72: case 73: case 74: coord = (code % 70) - 1; face[coord] = abs(atoi(line)); break; case 0: get_layer(); if (vertex_flag == POLY_VERTEX_FACE) { add_triangle(polyline_vert_indices[face[0]-1], polyline_vert_indices[face[1]-1], polyline_vert_indices[face[2]-1], curr_layer); ``` The vulnerable condition is that face[] is populated directly from attacker-controlled DXF input, and then used as polyline_vert_indices[face[i]-1] without verifying that the face indices fall inside the actual vertex table. This is a real parser-state-machine path, not a helper-only harness. The parser reaches the face-processing state normally, then dereferences out-of-range heap memory when the crafted face indices reference non-existent vertices. ### ASan LOG ASan excerpt from the latest full-path rerun: ``` ================================================================= ==67407==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x504000002c2c at pc 0x63103b0315e5 bp 0x7ffe242fd790 sp 0x7ffe242fd780 READ of size 4 at 0x504000002c2c thread T0 #0 0x63103b0315e4 in process_entities_polyline_vertex_code /src/src/conv/dxf/dxf-g.c:764 #1 0x63103b02181c in main /src/src/conv/dxf/dxf-g.c:3286 #2 0x7e8e728181c9 (/usr/lib/x86_64-linux-gnu/libc.so.6+0x2a1c9) (BuildId: 8e9fd827446c24067541ac5390e6f527fb5947bb) #3 0x7e8e7281828a in __libc_start_main (/usr/lib/x86_64-linux-gnu/libc.so.6+0x2a28a) (BuildId: 8e9fd827446c24067541ac5390e6f527fb5947bb) #4 0x63103b023c74 in _start (/build/bin/dxf-g+0xdc74) (BuildId: 5c939b6e6658f264ccab8464f47fc895b3847b82) 0x504000002c2c is located 3636 bytes after 40-byte region [0x504000001dd0,0x504000001df8) allocated by thread T0 here: #0 0x7e8e973c9f1d in posix_memalign ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:145 #1 0x7e8e72b12dd4 in alloc /src/src/libbu/malloc.c:137 #2 0x7e8e959a5212 in bg_vert_tree_add /src/src/libbg/vert_tree.c:241 #3 0x63103b0311bc in process_entities_polyline_vertex_code /src/src/conv/dxf/dxf-g.c:784 #4 0x63103b02181c in main /src/src/conv/dxf/dxf-g.c:3286 #5 0x7e8e728181c9 (/usr/lib/x86_64-linux-gnu/libc.so.6+0x2a1c9) (BuildId: 8e9fd827446c24067541ac5390e6f527fb5947bb) #6 0x7e8e7281828a in __libc_start_main (/usr/lib/x86_64-linux-gnu/libc.so.6+0x2a28a) (BuildId: 8e9fd827446c24067541ac5390e6f527fb5947bb) #7 0x63103b023c74 in _start (/build/bin/dxf-g+0xdc74) (BuildId: 5c939b6e6658f264ccab8464f47fc895b3847b82) SUMMARY: AddressSanitizer: heap-buffer-overflow /src/src/conv/dxf/dxf-g.c:764 in process_entities_polyline_vertex_code Shadow bytes around the buggy address: 0x504000002980: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x504000002a00: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x504000002a80: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x504000002b00: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x504000002b80: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa =>0x504000002c00: fa fa fa fa fa[fa]fa fa fa fa fa fa fa fa fa fa 0x504000002c80: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x504000002d00: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x504000002d80: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x504000002e00: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x504000002e80: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 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 ==67407==ABORTING ``` This confirms that the latest importer still trusts DXF-provided face indices and performs an out-of-bounds heap read in the live import path. ### Impact ``` This is a heap out-of-bounds read in native C code reachable from the normal DXF import path. Who is impacted: users or services that process untrusted DXF files with dxf-g environments where BRL-CAD import is exposed to user-supplied CAD inputs Security impact: reliable crash / denial of service memory-corruption risk beyond a simple parse error possible further exploitability depending on allocator/layout conditions ``` Please check the information and fix the code. Also, let me know if there is anything you need to know when you proceed with the patch.