From: Dominique Martinet <asmadeus@codewreck.org>
To: Solar Designer <solar@openwall.com>
Cc: oss-security@lists.openwall.com,
Alejandro Colomar <alx.manpages@gmail.com>,
Michael Kerrisk <mtk.manpages@gmail.com>,
linux-kernel@vger.kernel.org, linux-man@vger.kernel.org
Subject: Re: [oss-security] [patch] proc.5: tell how to parse /proc/*/stat correctly
Date: Fri, 23 Dec 2022 09:15:45 +0900 [thread overview]
Message-ID: <Y6TzMR1Wh7jKmatU@codewreck.org> (raw)
In-Reply-To: <20221222232112.GA29438@openwall.com>
Solar Designer wrote on Fri, Dec 23, 2022 at 12:21:12AM +0100:
> On Fri, Dec 23, 2022 at 07:03:17AM +0900, Dominique Martinet wrote:
> > Alexey Dobriyan wrote on Thu, Dec 22, 2022 at 07:42:53PM +0300:
> > > --- a/man5/proc.5
> > > +++ b/man5/proc.5
> > > @@ -2092,6 +2092,11 @@ Strings longer than
> > > .B TASK_COMM_LEN
> > > (16) characters (including the terminating null byte) are silently truncated.
> > > This is visible whether or not the executable is swapped out.
> > > +
> > > +Note that \fIcomm\fP can contain space and closing parenthesis characters.
> > > +Parsing /proc/${pid}/stat with split() or equivalent, or scanf(3) isn't
> > > +reliable. The correct way is to locate closing parenthesis with strrchr(')')
> > > +from the end of the buffer and parse integers from there.
> >
> > That's still not enough unless new lines are escaped, which they aren't:
> >
> > $ echo -n 'test) 0 0 0
> > ' > /proc/$$/comm
> > $ cat /proc/$$/stat
> > 71076 (test) 0 0 0
> > ) S 71075 71076 71076 34840 71192 4194304 6623 6824 0 0 10 3 2 7 20 0 1 0 36396573 15208448 2888 18446744073709551615 94173281726464 94173282650929 140734972513568 0 0 0 65536 3686404 1266761467 1 0 0 17 1 0 0 0 0 0 94173282892592 94173282940880 94173287231488 140734972522071 140734972522076 140734972522076 140734972526574 0
> >
> > The silver lining here is that comm length is rather small (16) so we
> > cannot emulate full lines and a very careful process could notice that
> > there are not enough fields after the last parenthesis... So just look
> > for the last closing parenthesis in the next line and try again?
>
> No, just don't treat this file's content as a line (nor as several
> lines) - treat it as a string that might contain new line characters.
Ah, this came just after the /proc/net/unix discussion in another
thread[1] pointing to [2] with one line per entry, and I was still in
that mode.
For /proc/pid/stat with a single entry I agree treating it as a buffer
and looking for the last closing parenthesis should be correct as per
the man page suggestion -- sorry for the noise.
[1] https://www.openwall.com/lists/oss-security/2022/12/21/8
[2] https://lore.kernel.org/all/8a87957e-4d33-9351-ae74-243441cb03cd@opteya.com/
--
Dominique Martinet | Asmadeus
next prev parent reply other threads:[~2022-12-23 0:17 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-22 16:42 [patch] proc.5: tell how to parse /proc/*/stat correctly Alexey Dobriyan
2022-12-22 22:03 ` [oss-security] " Dominique Martinet
2022-12-22 23:21 ` Solar Designer
2022-12-23 0:15 ` Dominique Martinet [this message]
2022-12-23 0:21 ` Jan Engelhardt
2022-12-28 0:44 ` Lyndon Nerenberg (VE7TFX/VE6BBM)
2022-12-28 1:50 ` Tavis Ormandy
2022-12-30 20:15 ` Jakub Wilk
2022-12-28 15:24 ` Shawn Webb
2022-12-28 15:31 ` Shawn Webb
2022-12-28 16:47 ` Demi Marie Obenour
2022-12-28 17:09 ` Jan Engelhardt
2022-12-28 17:25 ` Shawn Webb
2022-12-28 18:02 ` Demi Marie Obenour
2022-12-28 18:36 ` John Helmert III
2022-12-28 19:24 ` Shawn Webb
2022-12-28 19:57 ` Alejandro Colomar
2022-12-28 22:14 ` Theodore Ts'o
2022-12-29 0:33 ` Demi Marie Obenour
2022-12-31 16:31 ` David Laight
2022-12-31 17:27 ` Solar Designer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Y6TzMR1Wh7jKmatU@codewreck.org \
--to=asmadeus@codewreck.org \
--cc=alx.manpages@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-man@vger.kernel.org \
--cc=mtk.manpages@gmail.com \
--cc=oss-security@lists.openwall.com \
--cc=solar@openwall.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox