The hardlink program is susceptible to buffer overflows
of fixed-size nambuf1 and nambuf2 buffers when run on a tree with
deeply nested directories and/or with long directory or file names.
The problem can be reproduced by running the program on a directory containing 20 nested directories with 250-character names to get a segfault.
Another problem is that the program uses full pathnames. It neither
changes the current directory, nor uses openat(2). Thus, if a pathname
component is replaced with a symlink while the program is running, this
may result in processing of directories/files outside of the intended
For the unsafe handling of potentially changing directory trees, Solar Designer
added a BUGS section to the man page:
hardlink assumes that its target directory trees do not change from
under it. If a directory tree does change, this may result in hardlink
accessing files and/or directories outside of the intended directory
tree. Thus, you must avoid running hardlink on potentially changing
directory trees, and especially on directory trees under control of
CVE-2011-3630 hardlink buffer overflows
CVE-2011-3631 hardlink integer overflows
CVE-2011-3632 hardlink symlink attacks
See hardlink.c here:
Which is completely different program than hardlink from here:
Plus the hardlink in openwall seems to be a third variant but also not same.
Anyway, the version 0.2.0 hardlink from jak-linux site is now in Portage as app-arch/hardlink and I doubt this security bug has *anything* to do with it at all
I suggest to close "INVALID". Agreed?
The git for the app-arch/hardlink in tree seems to be here,
This at least mentions closing of CVE-2011-3632
And after that a commit like, "Rewrite hardlink in C":
And a 0.2.0 release few commits after that...
Since this was never stable, I guess this could be closed as "FIXED" too
Please, ignore my last comments entirely. I've done a bit more research and got it right now:
The app-arch/hardlink-0.1.1 we had was Python, and the app-arch/hardlink-0.2.0 is C. Neither of these were the hardlink this bug was filed about.
So this would make this bug INVALID.
But today, I've committed app-arch/hardlink-fedora to Portage which actually is the same hardlink we are talking about in this bug, so adjusting $summary now.
And I've checked that the fixes for these security bugs, close(fd)'s, are included in the upstream app-arch/hardlink-fedora source already.
So we have no issues with any of the hardlink's in Portage currently.