linux-kernel - Re: [PATCH printk v3 6/6] printk: syslog: close window between wait and read

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <YNSj59rKfGARoWRD@alley>
Date:   Thu, 24 Jun 2021 17:25:27 +0200
From:   Petr Mladek <pmladek@...e.com>
To:     John Ogness <john.ogness@...utronix.de>
Cc:     Sergey Senozhatsky <senozhatsky@...omium.org>,
        Steven Rostedt <rostedt@...dmis.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH printk v3 6/6] printk: syslog: close window between wait
 and read

On Thu 2021-06-24 13:17:48, John Ogness wrote:
> Syslog's SYSLOG_ACTION_READ is supposed to block until the next
> syslog record can be read, and then it should read that record.
> However, because @syslog_lock is not held between waking up and
> reading the record, another reader could read the record first,
> thus causing SYSLOG_ACTION_READ to return with a value of 0, never
> having read _anything_.
> 
> By holding @syslog_lock between waking up and reading, it can be
> guaranteed that SYSLOG_ACTION_READ blocks until it successfully
> reads a syslog record (or a real error occurs).
> 
> Signed-off-by: John Ogness <john.ogness@...utronix.de>
> ---
>  kernel/printk/printk.c | 50 +++++++++++++++++++++++++++++++-----------
>  1 file changed, 37 insertions(+), 13 deletions(-)
> 
> diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
> index 90954cb5a0ab..4737804d6c6d 100644
> --- a/kernel/printk/printk.c
> +++ b/kernel/printk/printk.c
> @@ -1542,8 +1570,13 @@ static int syslog_print(char __user *buf, int size)
>  		len += n;
>  		size -= n;
>  		buf += n;
> -	}
>  
> +		if (!size)
> +			break;

This looks like an unrelated optimization. If I get it correctly,
it does not change the existing behavior. The next cycle would
end up with n == 0 and break anyway.

It would have been better to do it in a separate patch or do not do
it at all or at least mention it in the commit message.

> +
> +		mutex_lock(&syslog_lock);
> +	}
> +out:
>  	kfree(text);
>  	return len;
>  }

The patch itself makes sense. It somehow fixes a long standing race.
Even though the result still might be racy. The lock is released
when each record is copied to the user-provided buffer.

I do not want to block it because of details. Feel free to use:

Reviewed-by: Petr Mladek <pmladek@...e.com>

but I would feel more comfortable if we handled the optimization one
of the suggested way.

Best Regards,
Petr