Hi,
Digging into a mysterious behavior of lpsched as of Solaris 10 GA,
which seems to be a variant of Bug ID 6276783, I found a bug in
a function named makepath() included in the binary of lpsched, and
many other programs of Solaris LP subsystem.
The source, hand-discomplied from the binaries, looks like:
--- OpenSolaris/20050612/usr/src/cmd/lp/lib/lp/makepath.c Thu Aug 4 16:24
:23 2005
+++ Solaris10-GA/hand-discompiled/makepath.c Thu Aug 4 16:35:41 2005
@@ -107,6 +107,13 @@
}
p[-1] = 0;
+ /*
+ * The following bogus code is found in the binaries of LP
+ * subsystem, e.g., lpsched, lp, accept, of Solaris 10 GA.
+ */
+ if (len > 1 && p[len-1] == '/')
+ p[len-1] = 0;
+
va_end (ap);
return (ret);
--- end of diff ---
The author's intention might be:
if (len > 1 && ret[len-1] == '/')
ret[len-1] = 0;
The author's intention might be:
if (len > 1 && ret[len-1] == '/')
ret[len-1] = 0;
The rest of the source of makepath() seems to be identical to the one
of OpenSolaris:
http://cvs.opensolaris.org/source/xref/usr/src/cmd/lp/lib/lp/makepath.c
This bug can obviously corrupt the data outside the memory block
allocated by malloc(), and it is possible to change a path name
stored in the process heap such as "/var/spool/lp/tmp/hostname/538-1" to
"/var/spool/lp/tmp" by substituting an occurrence of '/' by NUL.
So, if this happens, lpsched would unlink "/var/spool/lp/tmp" instead
of "/var/spool/lp/tmp/hostname/538-1" at the completion of a job.
Being running as root, lpsched can unlink any directory even if not empty.
I do not find this bug in the binary of NV18 or the source of OpenSolaris
20050612. So, I guess someone has already fixed it.
However, I have not been able to find any sign indicating a patch to
Solaris 10 coming, yet. I think this is a kind of serious bug, which
is definitely worth to be fixed ASAP.
Any information about the current state of this bug?
This message posted from opensolaris.org
