I can see that in strfn.cpp from the upstream unrar sources that the IntToExt() is defined like this:

void IntToExt(const char *Src,char *Dest,size_t DestSize)
{
#ifdef _WIN_ALL
  OemToCharBuffA(Src,Dest,(DWORD)DestSize);
  Dest[DestSize-1]=0;
#elif defined(_ANDROID)
  wchar DestW[NM];
  JniCharToWide(Src,DestW,ASIZE(DestW),true);
  WideToChar(DestW,Dest,DestSize);
#else
  if (Dest!=Src)
    strncpyz(Dest,Src,DestSize);
#endif
}

However, I can see in the disassembly of IntToExt() in Avast that the DestSize parameter is just discarded, and dep_strOemToAnsi() is called, which just invokes strcpy(). That seems like an stack buffer overflow vulnerability.

(gdb) disassemble IntToExt
Dump of assembler code for function _Z8IntToExtPKcPcj:
   0xf6f32520 <+0>:	push   ebp
   0xf6f32521 <+1>:	mov    ebp,esp
   0xf6f32523 <+3>:	push   ebx
   0xf6f32524 <+4>:	sub    esp,0x14
   0xf6f32527 <+7>:	mov    eax,DWORD PTR [ebp+0xc]
   0xf6f3252a <+10>:	call   0xf6e67d69 <__i686.get_pc_thunk.bx>
   0xf6f3252f <+15>:	add    ebx,0x1a6c99
   0xf6f32535 <+21>:	mov    DWORD PTR [esp+0x4],eax
   0xf6f32539 <+25>:	mov    eax,DWORD PTR [ebp+0x8]
   0xf6f3253c <+28>:	mov    DWORD PTR [esp],eax
   0xf6f3253f <+31>:	call   0xf7021e50 <dep_strOemToAnsi>
   0xf6f32544 <+36>:	add    esp,0x14
   0xf6f32547 <+39>:	pop    ebx
   0xf6f32548 <+40>:	pop    ebp
   0xf6f32549 <+41>:	ret    
End of assembler dump.
(gdb) disassemble dep_strOemToAnsi
Dump of assembler code for function dep_strOemToAnsi:
   0xf7021e50 <+0>:	push   ebp
   0xf7021e51 <+1>:	mov    ebp,esp
   0xf7021e53 <+3>:	push   ebx
   0xf7021e54 <+4>:	sub    esp,0x14
   0xf7021e57 <+7>:	mov    edx,DWORD PTR [ebp+0x8]
   0xf7021e5a <+10>:	mov    eax,DWORD PTR [ebp+0xc]
   0xf7021e5d <+13>:	call   0xf6e67d69 <__i686.get_pc_thunk.bx>
   0xf7021e62 <+18>:	add    ebx,0xb7366
   0xf7021e68 <+24>:	cmp    eax,edx
   0xf7021e6a <+26>:	je     0xf7021e78 <dep_strOemToAnsi+40>
   0xf7021e6c <+28>:	mov    DWORD PTR [esp+0x4],edx
   0xf7021e70 <+32>:	mov    DWORD PTR [esp],eax
   0xf7021e73 <+35>:	call   0xf6e67594 <strcpy@plt>
   0xf7021e78 <+40>:	add    esp,0x14
   0xf7021e7b <+43>:	xor    eax,eax
   0xf7021e7d <+45>:	pop    ebx
   0xf7021e7e <+46>:	pop    ebp
   0xf7021e7f <+47>:	ret    
End of assembler dump.

I'm confused how this could have happened, but regardless, this is obviously a very critical flaw.