[clug] Code question: Why doesn't this seqfault (kernel/printk.c)
Martin Pool
mbp at samba.org
Mon Oct 20 13:16:45 EST 2003
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
More information about the linux
mailing list