[clug] Code question: Why doesn't this seqfault (kernel/printk.c)

[Martin Pool]

On 20 Oct 2003, Michael Still <mikal at stillhq.com> wrote:
> 
> Folk,
> 
> So, I'm reading kernel/printk.c, specifically looking at the printk() 
> function. Anyways, I see these lines:
> 
> 	for (p = printk_buf; *p; p++) {
> 		if (log_level_unknown) {
> 			if (p[0] != '<' || p[1] < '0' || p[1] > '7' || p[2] != '>') {
> 				emit_log_char('<');
> 				emit_log_char(default_message_loglevel + '0');
> 				emit_log_char('>');
> 			}
> 			log_level_unknown = 0;
> 		}
> 		emit_log_char(*p);
> 		if (*p == '\n')
> 			log_level_unknown = 1;
> 	}
> 
> Which is a few lines in. Anyways, I'm now left wondering why the first if 
> statement doesn't cause a segmentation fault. As best as I can see, there 
> is no check to make sure that two characters after *p is in our memory 
> space.

The first if statement checks the value of log_level_unknown, which is
just an auto int.  I don't see how that could segfault.

Did you mean the second if statement?

printk_buf is an auto char array, so printk_buf != NULL.  printk_buf
is written using vsnprintf() which always nul terminates.

log_level_unknown is true at the start of a line: that is, on the
first pass or after seeing a newline character.  So the code that
reads p[0] etc will only be run then.

Perhaps it could have trouble if there is a terminated severity
specifier just near the end of the string?

 "......<1\0"

If any of the characters p[0..2] are \0, then we stop at that point,
because the null will terminate the attempt to match against
"<[0-7]>".  We don't read any further than the nul.

Even if we did, I think it won't cause a segfault, because the
printk_buf is in the middle of the stack and it's safe (if not polite)
to read a couple of bytes past its end.

Why would it segfault?
-- 
Martin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.samba.org/archive/linux/attachments/20031020/2da5f893/attachment.bin