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@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@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@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 <hr...@physics.muni.cz>, Masaryk University,
Dept. of theor. physics and astrophysics, Brno, Moravia, CZ
