public inbox for linux-man@vger.kernel.org
 help / color / mirror / Atom feed
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

  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