[Debian-astro-maintainers] Bug#1087911: Memory leaks in dcraw

[Filip Hroch]

Dear Colleagues,

I have investigated and fixed the issue:

* Below is cited an instance of the desired behaviour, and the 
  reason,
  why I wrote wrappers of fseek() and similar (introduced in 
  Debian's
  version 9.28-3). The procedure finish by exit(1), and indicates 
  of a fail.
  In this case, the memory is cleaned by the operating system 
  anyway.
  I'am unsure about the core of the issue.

  osboxes at osboxes:~/Desktop$ dcraw [..] leak
  fseek(0x5a1841ba9430, -2145648639,0): Invalid argument

* The leak indicated by fseek() is a trifle. The memory is 
  recovered
  when dcraw exits --- dcraw, as an executable rather than a 
  library,
  proves its design quality. The program block 472 bytes for a 
  while:

   f at dell:/tmp/dcraw/dcraw$ valgrind ./dcraw /tmp/leak
   ==45177== Memcheck, a memory error detector
   ==45177== Copyright (C) 2002-2022, and GNU GPL'd, by Julian 
   Seward et al.
   ==45177== Using Valgrind-3.19.0 and LibVEX; rerun with -h for 
   copyright info
   ==45177== Command: ./dcraw /tmp/leak
   ==45177==
   fseek(0x4c25250,-2145648639,0): Invalid argument
   ==45177==
   ==45177== HEAP SUMMARY:
   ==45177==     in use at exit: 472 bytes in 1 blocks
   ==45177==   total heap usage: 5 allocs, 4 frees, 6,528 bytes 
   allocated
   ==45177==
   ==45177== LEAK SUMMARY:
   ==45177==    definitely lost: 0 bytes in 0 blocks
   ==45177==    indirectly lost: 0 bytes in 0 blocks
   ==45177==      possibly lost: 0 bytes in 0 blocks
   ==45177==    still reachable: 472 bytes in 1 blocks
   ==45177==         suppressed: 0 bytes in 0 blocks
   ==45177== Rerun with --leak-check=full to see details of leaked 
   memory
   ==45177==
   ==45177== For lists of detected and suppressed errors, rerun 
   with: -s
   ==45177== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 
   0 from 0)

* Thanks that, I found a minor defect in parse_tiff() for unsigned 
  integer,
  which is, in fact, the whole patch I made. From user point of 
  view,
  dcraw reports, in friendly way, that a file is corrupted and 
  returns a fail.

   f at dell:/tmp/dcraw/dcraw$ valgrind ./dcraw /tmp/leak
   ==46346== Memcheck, a memory error detector
   ==46346== Copyright (C) 2002-2022, and GNU GPL'd, by Julian 
   Seward et al.
   ==46346== Using Valgrind-3.19.0 and LibVEX; rerun with -h for 
   copyright info
   ==46346== Command: ./dcraw /tmp/leak
   ==46346==
   /tmp/leak: Unexpected end of file
   ==46346==
   ==46346== HEAP SUMMARY:
   ==46346==     in use at exit: 0 bytes in 0 blocks
   ==46346==   total heap usage: 3 allocs, 3 frees, 5,032 bytes 
   allocated
   ==46346==
   ==46346== All heap blocks were freed -- no leaks are possible
   ==46346==
   ==46346== For lists of detected and suppressed errors, rerun 
   with: -s
   ==46346== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 
   0 from 0)

* dcraw is written in style of '90. From a current perspective, 
  there could be
  strangle language constructions, yet unattainable in 
  functionality.
  Don't use dcraw, if you are paranoid. Generally, memory leaks 
  are present
  in any software, often via shared libraries. A memory leak does 
  not mean
  a vulnerability. Don't use any software, if you are afraid of 
  memory leaks.

* For Debian's package, I expect that all the patches has been 
  applied.
  Both the runtime errors `dcraw.c:315:17' and `dcraw.c:313:49' 
  corresponds
  to the original, the unpatched variant.

Best regards,
FH
--
F. Hroch <hroch at physics.muni.cz>, Masaryk University,
Dept. of theor. physics and astrophysics, Brno, Moravia, CZ