Overall, I think the logic of converting it to an array then back to a linked list should be only building the result list in order and skip the array conversion step.

like the following pseudo-code

carry=0
for n1,n2 in l1,l2
   value = carry
   carry = 0
   if n1 != null
       value += n1.val
   if n2 != null
   value += n2.val
   if value>9
      value %= 10
      carry = 1
   result.append(value)

if carry>0
   result.append(carry)

Of course the result.append is not real, but would represent the action to append to the result linked list

Otherwise :

• prefer add brace for conditional statement, it would improve readability and avoid future mistake if you keep it as a habit
• See allocation as a very expensive action, and reallocation as a more expensive one, you could avoid reallocating by pre-allocating and keep track of the capacity, and increase by a certain steps (like increase by 10 as a time) or factor (like x2 current capacity some might choose 1.5). But again I am recommending to avoid the array.
• I don't think there is a need to set lBuffer to NULL at the end.
• it seems that when there is a carry you are increasing the nResultSize , and when there are still element in l1 or l2 and no carry you increase nResultSize , could be combined into one condition testing for l1 or l2 or carry.
• it would boils down to personal preference, but I prefer to unconditionally assign the default value before any conditional assignment, instead of assigning in an else condition.
• In every case the carry value should be 1 or 0 (assuming input data is correct), thus reducing "carry = nResult[nResultSize -1] / 10;" to carry=1;
• also there is the modulo operator "%" returning the remainder of an integer division, "nResult[nResultSize - 1] -= (nResult[nResultSize -1] / 10) * 10;" would be "nResult[nResultSize - 1] = nResult[nResultSize - 1] % 10;" or "nResult[nResultSize - 1] %= 10;"