Hi,

The following vulnerabilities were published for man2html.

CVE-2021-40647[0]:
| In man2html 1.6g, a specific string being read in from a file will
| overwrite the size parameter in the top chunk of the heap. This at
| least causes the program to segmentation abort if the heap size
| parameter isn't aligned correctly. In version before GLIBC version
| 2.29 and aligned correctly, it allows arbitrary write anywhere in the
| programs memory.

CVE-2021-40648[1]:
| In man2html 1.6g, a filename can be created to overwrite the previous
| size parameter of the next chunk and the fd, bk, fd_nextsize,
| bk_nextsize of the current chunk. The next chunk is then freed later
| on, causing a freeing of an arbitrary amount of memory.

https://gist.github.com/untaman/cb58123fe89fc65e3984165db5d40933

If you fix the vulnerabilities please also make sure to include the
CVE (Common Vulnerabilities & Exposures) ids in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2021-40647
https://www.cve.org/CVERecord?id=CVE-2021-40647
[1] https://security-tracker.debian.org/tracker/CVE-2021-40648
https://www.cve.org/CVERecord?id=CVE-2021-40648

Please adjust the affected versions in the BTS as needed.

clone 1021738 -1
retitle 1021738 man2html: CVE-2021-40647
tags 1021738 +pending
retitle -1 man2html: CVE-2021-40648
tags -1 +moreinfo
thanks

Moritz Mühlenhoff pisze:

Hi

First of all I'm sorry for not taking care about it earlier, I didn't
have time for Debian work in the previous year.
Ok, this is quite easy to fix, I will upload fixed version soon.

According to instructions given at
https://gist.github.com/untaman/cb58123fe89fc65e3984165db5d40933 I tried
to reproduce this with the following commands:
   file=$(perl -e 'print "A" x 132')
   touch $file
   man2html $file
I used man2html built with AddressSanitizer and it found only a few
small memory leaks coming from global variables.

So I have no idea what really is wrong in this CVE. The source code
references given at the above link actually refer to calls to
fopen()/fclose() functions rather then to directly malloc() and free()
directly.

Regards,
robert

Hi,

This should have actually gone to #1062069.

Regards,
Salvatore

There was a followup as
https://gist.github.com/untaman/cb58123fe89fc65e3984165db5d40933?permalink_comment_id=5226339#gistcomment-5226339
.

I'm marking the CVE as unimportant now in the tracker.

Regards,
Salvatore