On Mon, Jan 14, 2019 at 11:01 AM Guenter Roeck <groeck@xxxxxxxxxx> wrote:
>
> On Mon, Jan 14, 2019 at 10:50 AM Greg Kroah-Hartman
> <gregkh@xxxxxxxxxxxxxxxxxxx> wrote:
> >
> > On Mon, Jan 14, 2019 at 10:21:45AM -0800, Guenter Roeck wrote:
> > > On Mon, Jan 14, 2019 at 10:13 AM Gwendal Grignou <gwendal@xxxxxxxxxxxx> wrote:
> > > >
> > > > Prevent an empty line in /proc/self/status, allow iotop to work.
> > > >
> > > > iotop does not like empty lines, fails with:
> > > > File "/usr/local/lib64/python2.7/site-packages/iotop/data.py", line
> > > > 196, in parse_proc_pid_status
> > > > key, value = line.split(':\t', 1)
> > > > ValueError: need more than 1 value to unpack
> > > >
> > > > [reading /proc/self/status]
> > > >
> > > > Fixes: 84964fa3e5a0 ("proc: Provide details on speculation flaw mitigations")
> > > >
> > > > Signed-off-by: Gwendal Grignou <gwendal@xxxxxxxxxxxx>
> > > > ---
> > > > v2: Format commit message properly with proper subject and fixes
> > > > keyword.
> > > >
> > > You might want to mention that this patch only applies to v4.4.y.
> > > v4.9.y has a similar problem, but only if CONFIG_SECCOMP=n, and would
> > > require a slightly different patch to fix. Other releases are, as far
> > > as I can see, not affected.
> > >
> > > Guenter
> > >
> > > > fs/proc/array.c | 2 +-
> > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > >
> > > > diff --git a/fs/proc/array.c b/fs/proc/array.c
> > > > index 0c142916a8c7d..f11df9ab4256e 100644
> > > > --- a/fs/proc/array.c
> > > > +++ b/fs/proc/array.c
> > > > @@ -334,7 +334,7 @@ static inline void task_seccomp(struct seq_file *m, struct task_struct *p)
> > > > #ifdef CONFIG_SECCOMP
> > > > seq_printf(m, "Seccomp:\t%d\n", p->seccomp.mode);
> > > > #endif
> > > > - seq_printf(m, "\nSpeculation_Store_Bypass:\t");
> > > > + seq_printf(m, "Speculation_Store_Bypass:\t");
> >
> > Why isn't this issue showing up in all kernel releases, as this line is
> > still the same in 5.0-rc2?
> >
> > What makes the 4.4.y and 4.9.y trees so special here?
> >
>
> v4.14 and later:
>
> {
> seq_put_decimal_ull(m, "NoNewPrivs:\t", task_no_new_privs(p));
> #ifdef CONFIG_SECCOMP
> seq_put_decimal_ull(m, "\nSeccomp:\t", p->seccomp.mode);
> #endif
> seq_printf(m, "\nSpeculation_Store_Bypass:\t");
>
> ---
> v4.9:
>
> {
> #ifdef CONFIG_SECCOMP
> seq_put_decimal_ull(m, "Seccomp:\t", p->seccomp.mode);
> ^^^
> #endif
> seq_printf(m, "\nSpeculation_Store_Bypass:\t");
> ^^^
>
> -> extra newline if CONFIG_SECCOMP=n
>
> ---
> v4.4:
>
> {
> #ifdef CONFIG_SECCOMP
> seq_printf(m, "Seccomp:\t%d\n", p->seccomp.mode);
> ^^^
> #endif
> seq_printf(m, "\nSpeculation_Store_Bypass:\t");
> ^^^
>
> -> always extra newline
>
> Guenter
Yeah, this grew out of odd placement of the trailing "\n". I agree it
needs fixing universally.
--
Kees Cook
