[PATCH] fmtmsg: verify that label is in the correct format.

[PATCH] fmtmsg: verify that label is in the correct format.

[Isaac Dunham]

According to POSIX, "the format is two fields separated by a colon.
The first field is up to 10 bytes, the second is up to 14 bytes."
The original implementation assumed that the application provided
a valid label.
---
 src/misc/fmtmsg.c | 12 ++++++++++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/src/misc/fmtmsg.c b/src/misc/fmtmsg.c
index 69170b2..956fa5d 100644
--- a/src/misc/fmtmsg.c
+++ b/src/misc/fmtmsg.c
@@ -33,12 +33,20 @@ int fmtmsg(long classification, const char *label, int severity,
 
 	pthread_setcancelstate(PTHREAD_CANCEL_DISABLE, &cs);
 
+	if (label) {
+		char *col = strchr(label, ':');
+		i = strlen(label);
+		if (!col || (col-label)>10 || (label+i-col)>15 ||
+		    col==label || label+i-1==col)
+			ret = MM_NOTOK;
+	}
+
 	if (severity == MM_HALT) errstring = "HALT: ";
 	else if (severity == MM_ERROR) errstring = "ERROR: ";
 	else if (severity == MM_WARNING) errstring = "WARNING: ";
 	else if (severity == MM_INFO) errstring = "INFO: ";
 
-	if (classification & MM_CONSOLE) {
+	if (!ret && classification & MM_CONSOLE) {
 		consolefd = open("/dev/console", O_WRONLY);
 		if (consolefd < 0) {
 			ret = MM_NOCON;
@@ -54,7 +62,7 @@ int fmtmsg(long classification, const char *label, int severity,
 		}
 	}
 
-	if (classification & MM_PRINT) {
+	if (ret != MM_NOTOK && classification & MM_PRINT) {
 		while (cmsg && cmsg[0]) {
 			for(i=0; msgs[i]; i++) {
 				if (!_strcolcmp(msgs[i], cmsg)) break;
-- 
2.3.6

Re: [PATCH] fmtmsg: verify that label is in the correct format.

[Rich Felker]

On Sat, Apr 25, 2015 at 09:15:35AM -0700, Isaac Dunham wrote:
> According to POSIX, "the format is two fields separated by a colon.
> The first field is up to 10 bytes, the second is up to 14 bytes."
> The original implementation assumed that the application provided
> a valid label.

Is there a particular problem you're trying to solve? It's not clear
to me from the text (which seems under-specified) whether there's an
obligation to diagnose errors here, or whether failure to meet the
contract for the format of the inputs yields unspecified or undefined
behavior. I'm not necessarily opposed to the change but I'd like to
understand this better so that it would be well-motivated.

Rich

Re: [PATCH] fmtmsg: verify that label is in the correct format

[Isaac Dunham]

On Sat, Apr 25, 2015 at 01:14:17PM -0400, Rich Felker wrote:
> On Sat, Apr 25, 2015 at 09:15:35AM -0700, Isaac Dunham wrote:
> > According to POSIX, "the format is two fields separated by a colon.
> > The first field is up to 10 bytes, the second is up to 14 bytes."
> > The original implementation assumed that the application provided
> > a valid label.
> 
> Is there a particular problem you're trying to solve? It's not clear
> to me from the text (which seems under-specified) whether there's an
> obligation to diagnose errors here, or whether failure to meet the
> contract for the format of the inputs yields unspecified or undefined
> behavior. I'm not necessarily opposed to the change but I'd like to
> understand this better so that it would be well-motivated.

It's not clear to me whether there's an obligation according to POSIX,
and I haven't seen any issues.

The discussion of how to handle setenv(..., NULL, ...) reminded me
that glibc fmtmsg *does* fail on incorrectly-formatted labels,
and I thought it was worthwile to be consistent about rejecting
invalid inputs, so as to discourage the spread of wrong code (ie,
if people use invalid labels while testing with musl and then learn
about the issue when someone uses it on a non-musl platform).
But that's the only reason.

I will acknowledge that the meaning of
fmtmsg(MM_CONSOLE|MM_SOFT|MM_APPL|MM_RECOV, "a bad label", MM_INFO,
       "the label here is wrong", "change the label in the source",
       MM_NULLTAG);
is clear, unlike whether setenv("VAR", NULL, 1) should set VAR to ""
or unset VAR.

Thanks,
Isaac Dunham